www.digitalmars.com         C & C++   DMDScript  

D - Announce: DUI 0.10 for dmd 0.81 (linux)

reply Ant <duitoolkit yahoo.ca> writes:
This is kinda slow so here is something

I released the first version of DUI that
supports the GUI event callbacks through
delegates.
still limited:
- still missing many events (the obscure ones nobody uses)
- can't remove delegates
(leds uses only delegates, no more listener interfaces)
The old listener interfaces are still there.

get it at

http://dui.sourceforge.net

DUI is a D GUI toolkit for linux and windows
(you need GTK+ 2.2.4)

leds is my light editor for D (linux only)
and you can find it at 
http://leds.sourceforge.net
(that's an old release that doesn't use delegates yet)

My event handler templates are inspired on Andy's
dfbth. a couple of points:

- to be able to do button.onClick += &delegate;
I have to make onClick public.
I don't like it (but it's there). I there another way?
also that doesn't allow for lazy instanciation
of the event handlers.

- all but onClick delegates are added by a method:
button.addOnButtonPress(&delegate);
button.addOnButtonClick(&delegate); // yes is the same as onClick +=
that way I can instanciate the event handlers only
when necessary.

Ant
Mar 09 2004
parent reply Andy Friesen <andy ikagames.com> writes:
Ant wrote:

 My event handler templates are inspired on Andy's
 dfbth. a couple of points:
 
 - to be able to do button.onClick += &delegate;
 I have to make onClick public.
 I don't like it (but it's there). I there another way?
 also that doesn't allow for lazy instanciation
 of the event handlers.

Is this an ideological irk or a functional one? My delegate template was written to behave in an atomic fashion, so that it could safely be made public. It was made as a struct so that it didn't have to be explicitly instantiated. (this way, all delegates are valid by virtue of being declared in the class definition) I don't understand why lazy instantiation is useful, but you could always turn the delegate type into a class and not a struct, then create accessors that lazily allocate and return the delegate object. -- andy
Mar 09 2004
parent reply Ant <duitoolkit yahoo.ca> writes:
On Tue, 09 Mar 2004 20:38:49 -0800, Andy Friesen wrote:

 Ant wrote:
 
 My event handler templates are inspired on Andy's
 dfbth. a couple of points:
 
 - to be able to do button.onClick += &delegate;
 I have to make onClick public.
 I don't like it (but it's there). I there another way?
 also that doesn't allow for lazy instanciation
 of the event handlers.

Is this an ideological irk or a functional one? My delegate template was written to behave in an atomic fashion, so that it could safely be made public. It was made as a struct so that it didn't have to be explicitly instantiated. (this way, all delegates are valid by virtue of being declared in the class definition) I don't understand why lazy instantiation is useful, but you could always turn the delegate type into a class and not a struct, then create accessors that lazily allocate and return the delegate object. -- andy

What prevent the app to assign onClick to something else? and my problem with the instantiation is that for the Widget class alone there are 39 different events. then every widget adds it's own events. Maybe the struct is small enough that we don't have to worry about that Ant
Mar 09 2004
parent reply Andy Friesen <andy ikagames.com> writes:
Ant wrote:

 What prevent the app to assign onClick to something else?

Good call. On the upside, doing so wouldn't break anything, just potentially cause some strange behaviour. It's a shame D doesn't offer any way to override or disallow duplication in this manner.
 and my problem with the instantiation is that for 
 the Widget class alone there are 39 different events.
 then every widget adds it's own events.
 Maybe the struct is small enough that we don't have to worry
 about that

The struct only has one data member, so the whole thing should be scrunched down to however big an associative array is. (as long as it's a struct, there's no vtable to bulk it up) -- andy
Mar 09 2004
parent Ant <duitoolkit yahoo.ca> writes:
On Tue, 09 Mar 2004 22:21:51 -0800, Andy Friesen wrote:

 Ant wrote:
 
 What prevent the app to assign onClick to something else?

Good call. On the upside, doing so wouldn't break anything, just potentially cause some strange behaviour. It's a shame D doesn't offer any way to override or disallow duplication in this manner.

maybe it does! (I didn't test this) what if we create a method: void onClick(OnClickType onClick) { } it doesn't do a thing and it might prevent changing the public onClick ok I'll test it ... ######################### class C { private int i = 14; public int i(int ii) { } } void main() { C c = new C; printf("c.i = %d\n",i); c.i = 13; printf("c.i = %d\n",i); } ------------- dmd PU -I~/dmd/src/phobos PU.d(5): function i conflicts with C.i at PU.d(3) ########################## that's what I expected, but I expected the same for java but it is legal. but that would be a workaround anyway. the correct way is to make it a const. but const must be evaluated at compile time so it's out. Do we have a suggestion/request for D here?
 
 and my problem with the instantiation is that for 
 the Widget class alone there are 39 different events.
 then every widget adds it's own events.
 Maybe the struct is small enough that we don't have to worry
 about that

The struct only has one data member, so the whole thing should be scrunched down to however big an associative array is. (as long as it's a struct, there's no vtable to bulk it up)

yes, I have only 3 or 4 (I have 4 but I think I can drop one). because I only connect the signal when needed. (so I store the event mask and the signal identifier) Ant
Mar 10 2004