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