Digital Mars - digitalmars.D.dwt

↑ ↓ ← → bobef <bobef abv-nospam.bg> writes:

I have used DWT for some days and here are my thoughts:

"" must be the same as null . Feels more natural in D.

Adding listeners is unnatural too. addListener(...,new class Listener(void
handleEvent(Event e){..}})); .... come on.. I have brought this up about
Tioport too. I think DwtShawn's way is the right one. I can contribute some
code. Multi handlers would be general handler for multiple type of events (ie
Event). SingleHandlers could be used for non-general events that are used in
some places:

class MultiHandlers(EVENTYPE=uint,RETURNTYPE=bool,DELEGATE...)
{
	struct HANDLER
	{
		RETURNTYPE delegate(DELEGATE,Object) dg;
		Object param;
	}

	bool add(EVENTYPE event,RETURNTYPE delegate(DELEGATE,Object) dg,Object
param=null)
	{
		if(!dg) return false;
		auto a=event in handlers;
		if(a) *a~=HANDLER(dg,param);
		else handlers[event]=[HANDLER(dg,param)];
		return true;
	}

	void del(EVENTYPE event){handlers.remove(event);}

	bool del(EVENTYPE event,RETURNTYPE delegate(DELEGATE,Object) dg)
	{
		if(!dg) return false;
		auto a=event in handlers;
		if(a)
		{
			foreach(i,d;*a)
			{
				if(d.dg is dg)
				{
					if((*a).length==1) handlers.remove(event);
					else
					{
						if(i==0) *a=(*a)[1..$];
						else if(i==(*a).length-1) *a=(*a)[0..i];
						else *a=(*a)[0..i]~(*a)[i+1..$];
						return true;
					}
				}
			}
		}
		return false;
	}

	bool toggle(EVENTYPE event,RETURNTYPE delegate(DELEGATE,Object) dg)
	{
		if(!del(event,dg)) return add(event,dg);
	}

	bool call(EVENTYPE event,DELEGATE data)
	{
		auto a=event in handlers;
		if(a)
		{
			static if(is(RETURNTYPE == void)) foreach(d;*a)
			{
				static if(data.length)
				{
					data[0].param=d.param;
					scope(exit) data[0].param=null;
				}
				d.dg(data);
			}
			else foreach(d;*a)
			{
				static if(data.length)
				{
					data[0].param=d.param;
					scope(exit) data[0].param=null;
				}
				if(d.dg(data)) return true;
			}
		}
		return false;
	}

	bool canHandle(EVENTYPE event){return (event in handlers) !is null;}

//protected:
	HANDLER[][EVENTYPE] handlers;
}

class SingleHandlers(RETURNTYPE=bool,DATA...)
{
	struct HANDLER
	{
		RETURNTYPE delegate(DATA) dg;
		Object param;
	}

	bool add(RETURNTYPE delegate(DATA) dg,Object param=null)
	{
		if(!dg) return false;
		handlers~=HANDLER(dg,param);
		return true;
	}

	void del(){delete handlers; handlers=null;}

	bool del(RETURNTYPE delegate(DATA) dg)
	{
		if(!dg) return false;
		tango.core.Array.removeIf(/*pseudo code*/ {foreach(h;handlers) h.dg is dg;} )
	}

	bool toggle(RETURNTYPE delegate(DATA) dg)
	{
		if(!del(dg)) return add(dg);
	}

	bool call(DATA data)
	{
		static if(is(RETURNTYPE == void)) foreach(d;handlers)
		{
			static if(data.length)
			{
				data[0].param=d.param;
				scope(exit) data[0].param=null;
			}
			d.dg(data);
		}
		else foreach(d;handlers)
		{
			static if(data.length)
			{
				data[0].param=d.param;
				scope(exit) data[0].param=null;
			}
			if(d.dg(data)) return true;
		}
		return false;
	}

//protected:
	HANDLER[] handlers;
}

add something like in Widget (and where appropriate)

MultiHandlers!(int,void,Event) mHandlers;

bool handleEvent(void delegate(Event) dg,Object param=null)
{
	if(mHandlers is null) mHandlers=new MultiHandlers!(int,void,Event);
	return mHandlers.add(dg,param);
}

bool unhandleEvent(void delegate(Event) dg)
{
	if(mHandlers) return mHandlers.del(dg);
	return false;
}

These things (or something similar) could be mixed in to keep the changes from
SWT minimal and be easier to port and share the stuff between linux/windows.

The rest is to mess with the code where event comes add do something like
if(mHandlers && mHandlers.canHandle(type)) mHandlers.call(type);

The easy way is to add filter in the display but this is kind of ugly... 

Anyway this is just a suggestion.

Mar 03 2008

↑ ↓ ← → bobef <bobef abv-nospam.bg> writes:

Frank Benoit Wrote:

 Yes i think you are right,
 i was trying to get around that for some time :)
 
 Can we make use of tango.core.Signal here ?
 


I don't know what that is.

 Are you interested in doing the implementation in dwt-win & dwt-linux ?


I would like to, but I don't have the time right now. Right now, for me, it is
faster to use the standard SWT syntax than implementing a new one. Maybe in the
future if this is still not implemented...

Mar 04 2008

↑ ↓ ← → Bjoern <nanali nospam-wanadoo.fr> writes:

Frank Benoit schrieb:
 Yes i think you are right,
 i was trying to get around that for some time :)
 
 Can we make use of tango.core.Signal here ?


I think it is doable.

A win specific snippet follows, hopefully good enough as example.

Bobef :
Signals & Slots are a means of broadcasting an event to multiple listeners.
( So I wonder : does it really make sense ? )

snippet :
import tango.core.Signal;

struct MultiDispatch(Key)
{
     alias void delegate() Dg;

     void attach( Key k, Dg dg )
     {
         m_map[k] = dg;
     }

     void opCall( Key k )
     {
         auto dg = k in m_map;
         if( dg !is null )
             (*dg)();
     }
private:
     Dg[Key] m_map;
}

class MyClass
{
     void onClose()
     {

     }

     MultiDispatch!(int) signal;

     this()
     {
         signal.attach( WM_CLOSE, &onClose );
     }
}

...

auto c = new MyClass;
c.signal( WM_CLOSE );

The forum thread at :
http://www.dsource.org/projects/tango/forums/topic/221

Frank :
Bobef's HTMLayout implementation/wrapper is similar to Eclipse forms. 
(More flexible, but unfortunately Win only.)

HTH Bjoern

Mar 09 2008

digitalmars.D.dwt - Few thoughts