"Ant" <duitoolkit@yahoo.ca> wrote in message news:d3faf8$17um$1@digitaldaemon.com...
> Charles Hixson wrote:
> > J C Calvarese wrote:
> >
> >> Charles Hixson wrote:
> >>
> >>> Does anyone have examples of GTK code in D?
> >>
> >>
> >>
> >> Have you tried DUI (http://dui.sourceforge.net/)? It's a wrapper based
> >> on GTK+.
> >>
> >>
> >  From what I seen of it (I haven't looked into it deeply) it's dependent
> > on more than just GTK+.
>
> there are no other dependencies.
> things like zlib1.dll are required by gtk it self.
> other like libpng are optional.
>
*snip*

But it is, unless there is an updated version that I don't know about, full of deprecated code.
I spent a week or so correcting errors in it, and then gave up because I simply don't have that much time to devote to making it work.

TZ

In article <d5mp05$1o8$1@digitaldaemon.com>, TechnoZeus says...
>
>
>"Ant" <duitoolkit@yahoo.ca> wrote in message news:d3faf8$17um$1@digitaldaemon.com...
>> Charles Hixson wrote:
>> > J C Calvarese wrote:
>> >
>> >> Charles Hixson wrote:
>> >>
>> >>> Does anyone have examples of GTK code in D?
>> >>
>> >>
>> >>
>> >> Have you tried DUI (http://dui.sourceforge.net/)? It's a wrapper based
>> >> on GTK+.
>> >>
>> >>
>> >  From what I seen of it (I haven't looked into it deeply) it's dependent
>> > on more than just GTK+.
>>
>> there are no other dependencies.
>> things like zlib1.dll are required by gtk it self.
>> other like libpng are optional.
>>
>*snip*
>
>But it is, unless there is an updated version that I don't know about, full of deprecated code.
>I spent a week or so correcting errors in it, and then gave up because I simply don't have that much time to devote to making it work.
>

The progress of DUI depends directly on how much I'm using it
and I don't have the time right now.
The latests svn on dsource (now down it seems) works perfectly on linux.
It's the best version ever (Gtk+2.6.x)!
I'll make a release as soon as possible.
John Reimer found and corrected the problems on the windows version while
working on his dynDUI (I plan to merge both versions) so I will also look at
the making a windows release when I have time.

Ant

Ant wrote:
>>But it is, unless there is an updated version that I don't know about, full of deprecated code.
>>I spent a week or so correcting errors in it, and then gave up because I simply don't have that much time to devote to making it work.
>>
> 
> 
> The progress of DUI depends directly on how much I'm using it
> and I don't have the time right now.
> The latests svn on dsource (now down it seems) works perfectly on linux.
> It's the best version ever (Gtk+2.6.x)!
> I'll make a release as soon as possible.
> John Reimer found and corrected the problems on the windows version while working on his dynDUI (I plan to merge both versions) so I will also look at
> the making a windows release when I have time.
> 
> Ant
> 
> 

I just wanted to point out that I haven't yet managed to get (dynamic) DUI working with Gtk+2.6.x on win32; it works fine with 2.4.x.  I will continue to look into this.  I spent very little time trying it with 2.6.x and all of my time on 2.4.x, so it's probably quite feasible with a little effort.  DynDUI, otherwise, works the same on both win32 and linux.

A big thank you to Ant for all his hard work with DUI.  I don't know if people realize how much time he put into that project, but considering the bug squashing he did there over the last 2 years (?), I think his contribution to the D language is significant. See him in Walter's acknowledgements list?  How do you think he got there? :-)

Concerning my DUI modification:

Using a method inspired by Kris Bells dynamic loader in Mango.ICU, DynDUI makes the build process a whole lot easier then before.  Just install your gtk+ libraries with one of the win32 gtk+ installers and import DUI into your project.  You need only link with the DynDUI library now:  all gtk symbols are loaded internally from the dll's (so's on linux).   Derek's build tool makes the whole process even simpler: just add the new DUI import directory to the \dmd\bin\sc.ini (dmd.conf on linux) file "-I" option, then place a dynDUI.lib in \dmd\lib directory (or other such that dmd knows where to look for it), and build a project with the following command:

build myproject.d dynDUI.lib -XDynDUI

I still have to make some updates to dynDUI to make things work flawlessly.  Right now, for example, opengl is not yet operational in my version until I convert the sources over.  Otherwise everything else works: sample apps were available at dsource.org, but it's down ATM. Also, I need to add "dynDUI.lib" to the project direcory or provide the build command to make it.

I'm kind of entertaining the idea of a DUI port to win32 native.   It looks like it would be a lot of work, but may be a great exercise. Meanwhile, I hoping to also help Sean Liu shape up DWT for a usable release.  We'll see where we go.  I may be biting off a little too much. :-)

-JJR

"Ant" <Ant_member@pathlink.com> wrote in message news:d5npku$qbn$1@digitaldaemon.com...
> In article <d5mp05$1o8$1@digitaldaemon.com>, TechnoZeus says...
> >
> >
> >"Ant" <duitoolkit@yahoo.ca> wrote in message news:d3faf8$17um$1@digitaldaemon.com...
> >> Charles Hixson wrote:
> >> > J C Calvarese wrote:
> >> >
> >> >> Charles Hixson wrote:
> >> >>
> >> >>> Does anyone have examples of GTK code in D?
> >> >>
> >> >>
> >> >>
> >> >> Have you tried DUI (http://dui.sourceforge.net/)? It's a wrapper based
> >> >> on GTK+.
> >> >>
> >> >>
> >> >  From what I seen of it (I haven't looked into it deeply) it's dependent
> >> > on more than just GTK+.
> >>
> >> there are no other dependencies.
> >> things like zlib1.dll are required by gtk it self.
> >> other like libpng are optional.
> >>
> >*snip*
> >
> >But it is, unless there is an updated version that I don't know about, full of deprecated code.
> >I spent a week or so correcting errors in it, and then gave up because I simply don't have that much time to devote to making it work.
> >
>
> The progress of DUI depends directly on how much I'm using it
> and I don't have the time right now.
> The latests svn on dsource (now down it seems) works perfectly on linux.
> It's the best version ever (Gtk+2.6.x)!
> I'll make a release as soon as possible.
> John Reimer found and corrected the problems on the windows version while
> working on his dynDUI (I plan to merge both versions) so I will also look at
> the making a windows release when I have time.
>
> Ant
>
>

I take it you're the one developing it?

Perhaps I could help get it up to date somehow.
It may not be worth my time to work on it just for me,
especially since I have never seen it working right and would likely run into questions that I don't have the answers to,
but if I am working in cooperation with the developer to get it working right for everyone,
that would be at least a worth while endeavor.

TZ

In article <d5pkan$ge1$1@digitaldaemon.com>, TechnoZeus says...
>
>
>> The progress of DUI depends directly on how much I'm using it
>
>I take it you're the one developing it?

yes.

>
>Perhaps I could help get it up to date somehow.

If we are talking linux it should be simple.
I'll try to update the sourceforge download tonight (again: linux only).
I'll make an announcement on the announcements group.

Ant

In article <d5qm9h$1elt$1@digitaldaemon.com>, Ant says...
>
>In article <d5pkan$ge1$1@digitaldaemon.com>, TechnoZeus says...
>>
>>
>>> The progress of DUI depends directly on how much I'm using it
>>
>>I take it you're the one developing it?
>
>yes.
>
>>
>>Perhaps I could help get it up to date somehow.
>
>If we are talking linux it should be simple.
>I'll try to update the sourceforge download tonight (again: linux only).
>I'll make an announcement on the announcements group.
>

SVN on dsource is back up, for linux, go there and grab dool and DUI.
(I hope the Makefiles are up to date, can't remember).
The Makefiles will need small customizations.
Last compiled with DMD 0.121.
http://svn.dsource.org/projects/dool/
http://svn.dsource.org/projects/dui/

Ant

PS
for a wonderfull IDE experience on linux grab the leds preview release
from the leds SVN repository :)
http://svn.dsource.org/projects/leds/trunk/leds_linux_preview.gz
(setting up a project is still only for those who can follow instructions:
http://leds.sourceforge.net/projTarget.html

if the project is not properly setup intellisence will not find the references.

I never tried it but you can probably set new d build tools on the make command as described on http://leds.sourceforge.net/projBuild.html

leds face: http://sourceforge.net/project/screenshots.php?group_id=97732

"Ant" <Ant_member@pathlink.com> wrote in message news:d5qu8f$1kqn$1@digitaldaemon.com...
> In article <d5qm9h$1elt$1@digitaldaemon.com>, Ant says...
> >
> >In article <d5pkan$ge1$1@digitaldaemon.com>, TechnoZeus says...
> >>
> >>
> >>> The progress of DUI depends directly on how much I'm using it
> >>
> >>I take it you're the one developing it?
> >
> >yes.
> >
> >>
> >>Perhaps I could help get it up to date somehow.
> >
> >If we are talking linux it should be simple.
> >I'll try to update the sourceforge download tonight (again: linux only).
> >I'll make an announcement on the announcements group.
> >
>
> SVN on dsource is back up, for linux, go there and grab dool and DUI.
> (I hope the Makefiles are up to date, can't remember).
> The Makefiles will need small customizations.
> Last compiled with DMD 0.121.
> http://svn.dsource.org/projects/dool/
> http://svn.dsource.org/projects/dui/
>
> Ant
>
> PS
> for a wonderfull IDE experience on linux grab the leds preview release
> from the leds SVN repository :)
> http://svn.dsource.org/projects/leds/trunk/leds_linux_preview.gz
> (setting up a project is still only for those who can follow instructions:
> http://leds.sourceforge.net/projTarget.html
>
> if the project is not properly setup intellisence will not find the references.
>
> I never tried it but you can probably set new d build tools on the make command as described on http://leds.sourceforge.net/projBuild.html
>
> leds face: http://sourceforge.net/project/screenshots.php?group_id=97732
>
>

Cool.

I'm on a Windows 98 system myself though.  Still... good to hear.  :)

TZ

"Chris Sauls" <ibisbasenji@gmail.com> wrote in message news:d3rj80$3b8$1@digitaldaemon.com...
> G.Vidal wrote:
> > You don't even need to learn GTK. Get GLADE, it's a wysiwyg Gtk gui builder that will output a XML file. Then use the libglade binding (it's on dsource) and with 3 or 4 lines of D code, you can dynamically load the XML file etc... sooo easy.
>
> Interesting... I'm actually in the middle of setting up something similar for Win32 (in the middle means I just finished the (fairly minimalistic) XML parser).  Its part of a library I've been working on for one reason and one reason only: I could use it myself, and I wanted to test a couple of ideas.  One of them being this "store a GUI as an XML file" thing.
>
> What does the GLADE XML look like?  My CGX (Casal GUI XML) files look
> something like this:
> # <AppFrame caption="Test Window" controls="min,max"
> icon="file:icon.bmp" width="640" height="480" position="center">
> #     <BorderLayout north="*,20%" south="*,20%" east="20%,*" west="20%,*">
> #         <Label position="north" caption="Hello World, from Casual
> Win32!" name="top text"/>
> #         <Panel position="west">
> #             <ColumnLayout>
> #                 <Button caption="Text 1" action="appframe text 1" />
> #                 <Button caption="Text 2" action="appframe text 2" />
> #             </ColumnLayout>
> #         </Panel>
> #         <Label position="center" caption="Just a simple demonstration
> application that does extremely little.  Play around with the buttons a
> bit, and check out the file 'text.cgx' where this entire GUI is defined!
>   Amazing, huh?" />
> #         <Button position="east" caption="Press me!" action="appframe
> pressme" name="pressme button" />
> #         <Panel position="south">
> #             <Button caption="Minimize" action="appframe min"
> name="min/max button" />
> #             <Button caption="Exit" action="app exit" />
> #         </Panel>
> #     </BorderLayout>
> # </AppFrame>
>
> I have a singleton called CgxManager (module casual.cgx.manager) which can be notified of new classes implementing interface ICgxWidget (module casual.cgx.widget) and thus expand on what can be put in the CGX file. But... this thing is going to be forever in coming, so I should hush about it.
>
> -- Chris Sauls

I'm curious... How far along are you on this, and are you planning to release it?

TZ

TechnoZeus wrote:
> I'm curious... How far along are you on this, and are you planning to release it?

Sadly I'm not a whole lot farther along, mostly because of a lack of time to devote to it.  Once it is somewhere near really usable I will probably ask to put it on DSource or otherwise share it.  I've got a few other ideas I'm toying with in this lib, such as the Command singleton.  Commands can be "bound to"/"unbound from" widgets, via "command slots".  For instance, the Button widget supports the "on click" slot. So in code you would do something like this: (note this is prototype code)

# import casual.all;
# import casual.cgx.manager;
#
# Command["my cmd"] = delegate bit (IWidget origin) {
#   /* do something */
#   return true;
# }
#
# // the following might become:
# // AppFrame myframe = AppFrame.loadCgx("myframe.cgx");
# // this removes the need for casting and importing casual.cgx.manager
# AppFrame myframe = cast(AppFrame) CgxManager.load("myframe.cgx");
# myframe["my button"].bindCommand("on click", "my cmd");
#
# Application.run();
#
# // later if you want to detach that command
# myframe["my button"].unbindCommand("on click", "my cmd");

Note that if a given Command does not "exist" (meaning it is an invalid key into the Command singleton's assoc-array-like interface) then it simply isn't ran.  In other words, it is not an error to have a "null" command.  It is just a command that doesn't do anything.

# public alias bit delegate(IWidget) CommandDelegate;
#
# public abstract class Command { static:
#   // bunch of stuff
#
#   public bit invoke (in IWidget origin, in char[] cmd) {
#     CommandDelegate* dlg = cmd in p_map;
#     if (dlg is null) return false         ;
#     else             return (*dlg)(origin);
#   }
#
#   // bunch of stuff
# }

Although, to be honest, I've been looking at the Harmonia library and wondering of a loading-from-xml approach could be worked into it.  I like Harmonia overall, and may well be using it myself in the future.

-- Chris Sauls

"Chris Sauls" <ibisbasenji@gmail.com> wrote in message news:d79gj7$guu$1@digitaldaemon.com...
> TechnoZeus wrote:
> > I'm curious... How far along are you on this, and are you planning to release it?
>
> Sadly I'm not a whole lot farther along, mostly because of a lack of
> time to devote to it.  Once it is somewhere near really usable I will
> probably ask to put it on DSource or otherwise share it.  I've got a few
> other ideas I'm toying with in this lib, such as the Command singleton.
>   Commands can be "bound to"/"unbound from" widgets, via "command
> slots".  For instance, the Button widget supports the "on click" slot.
> So in code you would do something like this: (note this is prototype code)
>
> # import casual.all;
> # import casual.cgx.manager;
> #
> # Command["my cmd"] = delegate bit (IWidget origin) {
> #   /* do something */
> #   return true;
> # }
> #
> # // the following might become:
> # // AppFrame myframe = AppFrame.loadCgx("myframe.cgx");
> # // this removes the need for casting and importing casual.cgx.manager
> # AppFrame myframe = cast(AppFrame) CgxManager.load("myframe.cgx");
> # myframe["my button"].bindCommand("on click", "my cmd");
> #
> # Application.run();
> #
> # // later if you want to detach that command
> # myframe["my button"].unbindCommand("on click", "my cmd");
>
> Note that if a given Command does not "exist" (meaning it is an invalid key into the Command singleton's assoc-array-like interface) then it simply isn't ran.  In other words, it is not an error to have a "null" command.  It is just a command that doesn't do anything.
>
> # public alias bit delegate(IWidget) CommandDelegate;
> #
> # public abstract class Command { static:
> #   // bunch of stuff
> #
> #   public bit invoke (in IWidget origin, in char[] cmd) {
> #     CommandDelegate* dlg = cmd in p_map;
> #     if (dlg is null) return false         ;
> #     else             return (*dlg)(origin);
> #   }
> #
> #   // bunch of stuff
> # }
>
> Although, to be honest, I've been looking at the Harmonia library and wondering of a loading-from-xml approach could be worked into it.  I like Harmonia overall, and may well be using it myself in the future.
>
> -- Chris Sauls

Looks promising.
I also fully understand the time constraints issue,
and wish you the best of luck in finding the time to accomplish your goals on the project.

If you get it to a stage where you would like an outside tester, let me know. I'll see what I can find time to do.

TZ