Thread overview | |||||||
---|---|---|---|---|---|---|---|
|
March 10, 2004 Announce: DUI 0.10 for dmd 0.81 (linux) | ||||
---|---|---|---|---|
| ||||
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 |
March 10, 2004 Re: Announce: DUI 0.10 for dmd 0.81 (linux) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ant | 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
|
March 10, 2004 Re: Announce: DUI 0.10 for dmd 0.81 (linux) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andy Friesen | 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
|
March 10, 2004 Re: Announce: DUI 0.10 for dmd 0.81 (linux) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ant | 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 |
March 10, 2004 Re: Announce: DUI 0.10 for dmd 0.81 (linux) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andy Friesen | 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 |
Copyright © 1999-2021 by the D Language Foundation