www.digitalmars.com         C & C++   DMDScript  

D - SWT port - first step

reply Brad Anderson <brad sankaty.dot.com> writes:
I'm starting a new thread so we can discuss the best way to do a 
proof-of-concept for a D port of SWT.  For reference, we were under "Active 
Projects" and "D gui" before this)

I would like to propose that we accomplish the following:

1.  Write enough code so that the following works

/+
  +	HelloWorldGUI.d
  +/

import dwt.widgets.Display;
import dwt.widgets.Shell;

int main (char[][] args) {

	Display display = new Display();
	Shell shell = new Shell(display);
	shell.open();
	while ( !shell.isDisposed() ) {
		if ( !display.readAndDispatch() ) {
			display.sleep();
		}
	}
	display.dispose();
}


2.  Demonstrate that it works on Win32 and Linux/GTK.

3.  Figure out a forum for the small team to exchange ideas and communicate 
(rather than loading up the DMD newsgroup.)  We will report back on feasibility.

This should give us enough of a look at the plumbing of SWT.  We can see where 
we will have to work hard to get around a feature in Java that D does not have, 
or that we want to improve because we have more capabilities in D.

For the moment, let's assume we're going to use listeners and try to stay as 
close to SWT as possible.  Optimizations can come much later...

What can we leave out for the proof-of-concept?  Unicode, threading,

Thoughts?  Volunteers?  Platform preferences?

I don't have dev access to a Linux box, so I'll probably hack around with
Win32. 
  I can, however, set up a forum using phpBB on a public site.

Brad
Jan 20 2004
next sibling parent reply John Reimer <jjreimer telus.net> writes:
I'll respond in more detail to this in a bit, but for now here are a
couple of links to the SWT toolkit so others can get familar with it:

Download and web viewable cvs:

http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/main.html

The Developer's SWT page:

http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/dev.html


Also, it probably be wise to get further information on the license of
this toolkit.  I know we would be modifying it in D, but I don't know what
our obligation would be for adopting the design. 

Notice also, in the above website, there are branches for win32 and Gtk in
place.  This is a good thing :).

Oh and watch out, the name "dwt" might not be so popular ;-).

Nice sample! 

Later,

John
Jan 20 2004
next sibling parent John Reimer <jjreimer telus.net> writes:
On Tue, 20 Jan 2004 21:48:38 -0800, John Reimer wrote:


 The Developer's SWT page:
 
 http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/dev.html
 


The CVS tree is actually in the above link, not the first one provided.
 

 Also, it probably be wise to get further information on the license of
 this toolkit.  I know we would be modifying it in D, but I don't know what
 our obligation would be for adopting the design.
 


From what I can see, the code is under the Mozilla Public License 1.1. 
I'm not familiar with the extent of it.  I guess I'll be doing some
reading.
Jan 20 2004
prev sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
In the code, links to Common Public License 1.0

http://www.eclipse.org/legal/cpl-v10.html

However, we'll be putting this into the public domain.  IANAL, but I would
guess 
that we could give some lip-service to Eclipse, SWT, and IBM in documentation 
(not source code), and then choose our own license.

BA

John Reimer wrote:


 I'll respond in more detail to this in a bit, but for now here are a
 couple of links to the SWT toolkit so others can get familar with it:
 
 Download and web viewable cvs:
 
 http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/main.html
 
 The Developer's SWT page:
 
 http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/dev.html
 
 
 Also, it probably be wise to get further information on the license of
 this toolkit.  I know we would be modifying it in D, but I don't know what
 our obligation would be for adopting the design. 
 
 Notice also, in the above website, there are branches for win32 and Gtk in
 place.  This is a good thing :).
 
 Oh and watch out, the name "dwt" might not be so popular ;-).
 
 Nice sample! 
 
 Later,
 
 John
Jan 20 2004
next sibling parent John Reimer <jjreimer telus.net> writes:
On Tue, 20 Jan 2004 23:54:46 -0600, Brad Anderson wrote:


 In the code, links to Common Public License 1.0
 
 http://www.eclipse.org/legal/cpl-v10.html
 


You're right.  For some strange reason I landed in a directory with a
source file using the "Mozilla Public License." Must have been just a few
files.


 However, we'll be putting this into the public domain.  IANAL, but


I

 would guess that we could give some lip-service to Eclipse, SWT, and IBM
 in documentation (not source code), and then choose our own license.
 


Ok, I don't know much about this. As long as we know what we're doing.

I was browsing some of the Java code, and it's great! I think for the most
part, it will be pretty easy to convert.  The os dependent features are
clearly indicated with calls like OS.GetClassInfo(...) for win32.  It'll
be a snap to duplicate in place.  Gtk would be similar.  This just means
we have to work on class structure and members.  Most of it is pretty
similar to what D can do.

This looks promising!

Later,

John
Jan 20 2004
prev sibling next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
IANAL??

"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:bul4fv$2cg1$1 digitaldaemon.com...

 In the code, links to Common Public License 1.0

 http://www.eclipse.org/legal/cpl-v10.html

 However, we'll be putting this into the public domain.  IANAL, but I would


guess

 that we could give some lip-service to Eclipse, SWT, and IBM in


documentation

 (not source code), and then choose our own license.

 BA

 John Reimer wrote:


 I'll respond in more detail to this in a bit, but for now here are a
 couple of links to the SWT toolkit so others can get familar with it:

 Download and web viewable cvs:




http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/main.html

 The Developer's SWT page:




http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/dev.html

 Also, it probably be wise to get further information on the license of
 this toolkit.  I know we would be modifying it in D, but I don't know




what

 our obligation would be for adopting the design.

 Notice also, in the above website, there are branches for win32 and Gtk




in

 place.  This is a good thing :).

 Oh and watch out, the name "dwt" might not be so popular ;-).

 Nice sample!

 Later,

 John
Jan 20 2004
next sibling parent "davepermen" <davepermen hotmail.com> writes:
hehe, no comment:D

"Matthew" <matthew.hat stlsoft.dot.org> schrieb im Newsbeitrag
news:bul76l$2gku$1 digitaldaemon.com...

 IANAL??
Jan 20 2004
prev sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
I am not a lawyer


Matthew wrote:

 IANAL??
 
 "Brad Anderson" <brad sankaty.dot.com> wrote in message
 news:bul4fv$2cg1$1 digitaldaemon.com...
 

In the code, links to Common Public License 1.0

http://www.eclipse.org/legal/cpl-v10.html

However, we'll be putting this into the public domain.  IANAL, but I would


 
 guess
 

that we could give some lip-service to Eclipse, SWT, and IBM in


 
 documentation
 

(not source code), and then choose our own license.

BA

John Reimer wrote:



I'll respond in more detail to this in a bit, but for now here are a
couple of links to the SWT toolkit so others can get familar with it:

Download and web viewable cvs:




 
 http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/main.html
 

The Developer's SWT page:




 
 http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/dev.html
 

Also, it probably be wise to get further information on the license of
this toolkit.  I know we would be modifying it in D, but I don't know




 
 what
 

our obligation would be for adopting the design.

Notice also, in the above website, there are branches for win32 and Gtk




 
 in
 

place.  This is a good thing :).

Oh and watch out, the name "dwt" might not be so popular ;-).

Nice sample!

Later,

John
Jan 20 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
Ah ...

Well, better than a couple of the alternatives I'd postulated ... :)

"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:bul83n$2hlk$1 digitaldaemon.com...

 I am not a lawyer


 Matthew wrote:

 IANAL??

 "Brad Anderson" <brad sankaty.dot.com> wrote in message
 news:bul4fv$2cg1$1 digitaldaemon.com...


In the code, links to Common Public License 1.0

http://www.eclipse.org/legal/cpl-v10.html

However, we'll be putting this into the public domain.  IANAL, but I






would

 guess


that we could give some lip-service to Eclipse, SWT, and IBM in


 documentation


(not source code), and then choose our own license.

BA

John Reimer wrote:



I'll respond in more detail to this in a bit, but for now here are a
couple of links to the SWT toolkit so others can get familar with it:

Download and web viewable cvs:








http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/main.html

The Developer's SWT page:








http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform-swt-home/dev.html

Also, it probably be wise to get further information on the license of
this toolkit.  I know we would be modifying it in D, but I don't know




 what


our obligation would be for adopting the design.

Notice also, in the above website, there are branches for win32 and Gtk




 in


place.  This is a good thing :).

Oh and watch out, the name "dwt" might not be so popular ;-).

Nice sample!

Later,

John
Jan 21 2004
prev sibling next sibling parent reply Mark T <Mark_member pathlink.com> writes:
In article <bul4fv$2cg1$1 digitaldaemon.com>, Brad Anderson says...

In the code, links to Common Public License 1.0

http://www.eclipse.org/legal/cpl-v10.html

However, we'll be putting this into the public domain.  IANAL, but I would
guess 
that we could give some lip-service to Eclipse, SWT, and IBM in documentation 
(not source code), and then choose our own license.


Why not just use the Common Public License?  It is very open and acceptable to
SourceForge which would be a good place to put this project once it gets
rolling.
Jan 21 2004
parent Brad Anderson <brad sankaty.dot.com> writes:
No arguments here.


Mark T wrote:


 In article <bul4fv$2cg1$1 digitaldaemon.com>, Brad Anderson says...
 

In the code, links to Common Public License 1.0

http://www.eclipse.org/legal/cpl-v10.html

However, we'll be putting this into the public domain.  IANAL, but I would
guess 
that we could give some lip-service to Eclipse, SWT, and IBM in documentation 
(not source code), and then choose our own license.


 
 
 Why not just use the Common Public License?  It is very open and acceptable to
 SourceForge which would be a good place to put this project once it gets
 rolling.
Jan 21 2004
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:bul4fv$2cg1$1 digitaldaemon.com...

 In the code, links to Common Public License 1.0

 http://www.eclipse.org/legal/cpl-v10.html

 However, we'll be putting this into the public domain.  IANAL, but I would


guess

 that we could give some lip-service to Eclipse, SWT, and IBM in


documentation

 (not source code), and then choose our own license.


The license does not allow it to be placed into the public domain. However,
the license does appear to be compatible with our purposes, and I don't see
any problems with it.
Jan 22 2004
prev sibling next sibling parent reply "davepermen" <davepermen hotmail.com> writes:
I think thats a nice idea. I hope to have a forum since quite some while
anyways, hehe.

But i think there should be one change done right from the start: use
delegates, not listeners. This is NOT an optimisation, but such a general
design issue, i think it should be done right from the start. For all other
points, i fully agree.


"Brad Anderson" <brad sankaty.dot.com> schrieb im Newsbeitrag
news:bul1v1$281v$1 digitaldaemon.com...

 I'm starting a new thread so we can discuss the best way to do a
 proof-of-concept for a D port of SWT.  For reference, we were under


"Active

 Projects" and "D gui" before this)

 I would like to propose that we accomplish the following:

 1.  Write enough code so that the following works

 /+
   + HelloWorldGUI.d
   +/

 import dwt.widgets.Display;
 import dwt.widgets.Shell;

 int main (char[][] args) {

 Display display = new Display();
 Shell shell = new Shell(display);
 shell.open();
 while ( !shell.isDisposed() ) {
 if ( !display.readAndDispatch() ) {
 display.sleep();
 }
 }
 display.dispose();
 }


 2.  Demonstrate that it works on Win32 and Linux/GTK.

 3.  Figure out a forum for the small team to exchange ideas and


communicate

 (rather than loading up the DMD newsgroup.)  We will report back on


feasibility.

 This should give us enough of a look at the plumbing of SWT.  We can see


where

 we will have to work hard to get around a feature in Java that D does not


have,

 or that we want to improve because we have more capabilities in D.

 For the moment, let's assume we're going to use listeners and try to stay


as

 close to SWT as possible.  Optimizations can come much later...

 What can we leave out for the proof-of-concept?  Unicode, threading,

 Thoughts?  Volunteers?  Platform preferences?

 I don't have dev access to a Linux box, so I'll probably hack around with


Win32.

   I can, however, set up a forum using phpBB on a public site.

 Brad
Jan 20 2004
parent reply Georg Wrede <Georg_member pathlink.com> writes:
In article <bul743$2ggn$1 digitaldaemon.com>, davepermen says...

But i think there should be one change done right from the start: use
delegates, not listeners. This is NOT an optimisation, but such a general
design issue, i think it should be done right from the start.


Would it be possible to explain in a few lines of D how you would
implement the listener functionality with delegates?
Jan 21 2004
next sibling parent "davepermen" <davepermen hotmail.com> writes:
well.. something like this:

Window win = new Window("Title");
win.onClose = delegate void() {
    app.postQuitMessage();
}

not sure about the syntax again, i always mix delegate void() and void
delegate() :D

now, for the implementation, it would look like this:

class Window {
    /*....*/
    void delegate() onClose;
}

and in the event handler (win32 here)

case WM_CLOSE:
     if(curWin.onClose !== null) curWin.onClose();
     break;



something in that idea..

"Georg Wrede" <Georg_member pathlink.com> schrieb im Newsbeitrag
news:bulgt3$30s1$1 digitaldaemon.com...

 In article <bul743$2ggn$1 digitaldaemon.com>, davepermen says...

But i think there should be one change done right from the start: use
delegates, not listeners. This is NOT an optimisation, but such a general
design issue, i think it should be done right from the start.


 Would it be possible to explain in a few lines of D how you would
 implement the listener functionality with delegates?
Jan 21 2004
prev sibling next sibling parent reply Ant <Ant_member pathlink.com> writes:
In article <bulgt3$30s1$1 digitaldaemon.com>, Georg Wrede says...

In article <bul743$2ggn$1 digitaldaemon.com>, davepermen says...

But i think there should be one change done right from the start: use
delegates, not listeners. This is NOT an optimisation, but such a general
design issue, i think it should be done right from the start.


Would it be possible to explain in a few lines of D how you would
implement the listener functionality with delegates? 


Try to look at Andy's dfbth.
I just browse it but looks quite simple and to the point.
I'm going to change DUI to a very similar scheme.

We should decide on listener(no) versus delegates(yes)
from the begining.

Ant
Jan 21 2004
parent reply Georg Wrede <Georg_member pathlink.com> writes:
In article <buls8d$gdi$1 digitaldaemon.com>, Ant says...

We should decide on listener(no) versus delegates(yes)
from the begining.


Ok, so have I missed the main tradeoffs?
Jan 21 2004
next sibling parent "davepermen" <davepermen hotmail.com> writes:
delegates are actually simply the language feature that replace listeners.


there is no use in anything else. it's much less typing effort, espencially
for the one defining the interface.

btw, Ant, i know dbfkgdfklösdf. i like it. i just hate the name:D

"Georg Wrede" <Georg_member pathlink.com> schrieb im Newsbeitrag
news:bum2da$pp7$1 digitaldaemon.com...

 In article <buls8d$gdi$1 digitaldaemon.com>, Ant says...

We should decide on listener(no) versus delegates(yes)
from the begining.


 Ok, so have I missed the main tradeoffs?
Jan 21 2004
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
Georg Wrede wrote:


 In article <buls8d$gdi$1 digitaldaemon.com>, Ant says...
 

We should decide on listener(no) versus delegates(yes)


 

from the begining.


 
 Ok, so have I missed the main tradeoffs?
 


I'm not certain of any really notable advantages of using listener 
interfaces over delegates; SWT uses the former because Java simply does 
not offer any other way to accomplish the observer pattern.

Listeners are very poorly suited to D primarily one reason: D does not 
support Java's notion of inner classes.  This means that, to write a 
handler for any button, one must manually write a class that implements 
ButtonClickedListener (or whatever), accepts and stores a reference to 
its parent class, (if it needs it, which is very frequently the case) 
and responds to the event.

A delegate can just be stuffed inside a collection without regard for 
the inheritance heirarchy. (sure sounds sloppy when you phrase it like 
that)  D also supports function literals, which makes it very easy to 
attach a trivial little handler to a button.

button.onClick ~= delegate(ClickEvent event) { printf("Hello!\n"); };
button.onClick ~= &this.exitApp;

  -- andy
Jan 21 2004
next sibling parent Georg Wrede <Georg_member pathlink.com> writes:
In article <bum409$sbp$1 digitaldaemon.com>, Andy Friesen says...

A delegate can just be stuffed inside a collection without regard for 
the inheritance heirarchy. (sure sounds sloppy when you phrase it like 


:-)


that)  D also supports function literals, which makes it very easy to 
attach a trivial little handler to a button.

button.onClick ~= delegate(ClickEvent event) { printf("Hello!\n"); };
button.onClick ~= &this.exitApp;


Thanks, Dave, Ant, and Andy! 
This is really cool!
Jan 21 2004
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"Andy Friesen" <andy ikagames.com> wrote in message
news:bum409$sbp$1 digitaldaemon.com...

 Listeners are very poorly suited to D primarily one reason: D does not
 support Java's notion of inner classes.  This means that, to write a
 handler for any button, one must manually write a class that implements
 ButtonClickedListener (or whatever), accepts and stores a reference to
 its parent class, (if it needs it, which is very frequently the case)
 and responds to the event.

 A delegate can just be stuffed inside a collection without regard for
 the inheritance heirarchy. (sure sounds sloppy when you phrase it like
 that)  D also supports function literals, which makes it very easy to
 attach a trivial little handler to a button.

 button.onClick ~= delegate(ClickEvent event) { printf("Hello!\n"); };
 button.onClick ~= &this.exitApp;


That's why D doesn't do inner classes - delegates are a much nicer solution
for the same problem.
Jan 22 2004
parent Ant <duitoolkit yahoo.ca> writes:
On Thu, 22 Jan 2004 10:08:13 -0800, Walter wrote:


 
 "Andy Friesen" <andy ikagames.com> wrote in message
 news:bum409$sbp$1 digitaldaemon.com...

 Listeners are very poorly suited to D primarily one reason: D does not
 support Java's notion of inner classes.  This means that, to write a
 handler for any button, one must manually write a class that implements
 ButtonClickedListener (or whatever), accepts and stores a reference to
 its parent class, (if it needs it, which is very frequently the case)
 and responds to the event.

 A delegate can just be stuffed inside a collection without regard for
 the inheritance heirarchy. (sure sounds sloppy when you phrase it like
 that)  D also supports function literals, which makes it very easy to
 attach a trivial little handler to a button.

 button.onClick ~= delegate(ClickEvent event) { printf("Hello!\n"); };
 button.onClick ~= &this.exitApp;


 
 That's why D doesn't do inner classes - delegates are a much nicer solution
 for the same problem.


What! that's not a valid reason.
Inner classes solve other problems.

How difficult are they to implement?
(In my ignorance) you just a need a pointer to the outer
class it's very simple to do...

please add them before 1.0

for instance they are useful to build GUIs.

leds file browser contains a nested class to hold the
file tree - it would benefit from the nested class being inner,
nothing to do with events.
leds project browser (some thing)...

leds addToProject functions (not released yet)
contain nested classes create the user interfaces - they
would benefit if we have inner classes.

In all these 3 examples I have to pass extra parameters
to the nested classes ctors to have access to the outer
class members.

Ant
Feb 03 2004
prev sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Andy Friesen wrote:

 Listeners are very poorly suited to D primarily one reason: D does not 
 support Java's notion of inner classes.


That leads me to an idea: if we would write an automatic Java->D 
converter, running over an inner class could automatically convert it 
into a delegates, no?

-eye
Jan 23 2004
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
Georg Wrede wrote:

 In article <bul743$2ggn$1 digitaldaemon.com>, davepermen says...
 

But i think there should be one change done right from the start: use
delegates, not listeners. This is NOT an optimisation, but such a general
design issue, i think it should be done right from the start.


 
 
 Would it be possible to explain in a few lines of D how you would
 implement the listener functionality with delegates? 
 


I've written a nifty little template class that wraps a collection of 
delegates into a single callable entity. 
<http://ikagames.com/andy/d/Listener.d>

Right now it's a struct. (because I didn't want to bother new'ing it) 
It would have to become a class, and implement the proper SWT listener 
interface. (maybe as another template argument)

Then it just becomes a matter of adding an instance of the listener to 
some place in the existing SWT class, and attaching it to SWT's existing 
listener infrastructure via the usual addXXXXXXListener method.

There are other ways to do it, naturally, but I think this might be 
best, as it requires almost no alteration of the underlying SWT 
semantics.  Less thinking is good. :)

  -- andy
Jan 21 2004
next sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
 From this and the above examples, I'm sold on delegates instead of rote
copying 
of listeners already in SWT.  This falls into the category of taking advantage 
of a feature in D that isn't in Java.  Hopefully a bunch of you will be 
available to assist.

Andy Friesen wrote:


 Georg Wrede wrote:
 

 In article <bul743$2ggn$1 digitaldaemon.com>, davepermen says...


 But i think there should be one change done right from the start: use
 delegates, not listeners. This is NOT an optimisation, but such a 
 general
 design issue, i think it should be done right from the start.




 Would it be possible to explain in a few lines of D how you would
 implement the listener functionality with delegates?


 
 
 I've written a nifty little template class that wraps a collection of 
 delegates into a single callable entity. 
 <http://ikagames.com/andy/d/Listener.d>
 
 Right now it's a struct. (because I didn't want to bother new'ing it) It 
 would have to become a class, and implement the proper SWT listener 
 interface. (maybe as another template argument)
 
 Then it just becomes a matter of adding an instance of the listener to 
 some place in the existing SWT class, and attaching it to SWT's existing 
 listener infrastructure via the usual addXXXXXXListener method.
 
 There are other ways to do it, naturally, but I think this might be 
 best, as it requires almost no alteration of the underlying SWT 
 semantics.  Less thinking is good. :)
 
  -- andy
Jan 21 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <bumbl7$17ft$3 digitaldaemon.com>, Brad Anderson says...

 From this and the above examples, I'm sold on delegates instead of rote
copying 
of listeners already in SWT.  This falls into the category of taking advantage 
of a feature in D that isn't in Java.  Hopefully a bunch of you will be 
available to assist.


The thing I don't like on the SWT project is that the way to 
make to linux is through GTK.
Been there, done that...

:(

well, maybe the SWT has some excelente ideas on how to do it...
might be interesting to learn how SWT APIs are converted to 
GTK calls...

Ant
Jan 21 2004
parent John Reimer <jjreimer telus.net> writes:
 The thing I don't like on the SWT project is that the way to make to linux
 is through GTK.
 Been there, done that...
 
 :(
 
 well, maybe the SWT has some excelente ideas on how to do it... might be
 interesting to learn how SWT APIs are converted to GTK calls...
 
 Ant


It shouldn't be as hard or as bad, since the SWT has the internal.gtk type
calls already mapped out.  At least we know what will be used.  We can use
that section of the java source to map out a D gtk module with extern(C)
calls (similar to how you did it in DUI). From there we just need to make
calls similar to the java OS.foo calls.  Of course, it's easy to talk
about it. :)  As a first project, I guess I could try making a gtk module
based on the JNI.  I can use DUI as a guidline :).  The harder part may be
the whole modification process of changing from listeners to delegates.  I
don't know how that will go.

Later,

John
Jan 21 2004
prev sibling parent reply John Reimer <jjreimer telus.net> writes:
 I've written a nifty little template class that wraps a collection of
 delegates into a single callable entity.
 <http://ikagames.com/andy/d/Listener.d>


Thanks for this. I've studied it and it looks quite promising. As you
say, it is quite nifty :-).  That's an interesting use of associative
arrays you've got in there. Just have to change the "instance" keyword to
the "!" symbol, I think.


 Right now it's a struct. (because I didn't want to bother new'ing it) It
 would have to become a class, and implement the proper SWT listener
 interface. (maybe as another template argument)


We should be able to do that.
 

 Then it just becomes a matter of adding an instance of the listener to
 some place in the existing SWT class, and attaching it to SWT's existing
 listener infrastructure via the usual addXXXXXXListener method.


OK


 There are other ways to do it, naturally, but I think this might be
 best, as it requires almost no alteration of the underlying SWT
 semantics.  Less thinking is good. :)
 
   -- andy


It's a great start.  Thanks!

John
Jan 21 2004
parent Andy Friesen <andy ikagames.com> writes:
John Reimer wrote:

 Thanks for this. I've studied it and it looks quite promising. As you
 say, it is quite nifty :-).  That's an interesting use of associative
 arrays you've got in there. Just have to change the "instance" keyword to
 the "!" symbol, I think.


Whoops.  I've updated it with the newest version.  (I use that template 
in a bunch of places.  It's only a matter of time before they start to 
fall out of sync)

  -- andy
Jan 21 2004
prev sibling next sibling parent "Carlos Santander B." <carlos8294 msn.com> writes:
"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:bul1v1$281v$1 digitaldaemon.com...
| ...
|   I can, however, set up a forum using phpBB on a public site.
|
| Brad
|

If you wish, you can send me a line and I'll a category for it in
http://s3.invisionfree.com/ln5yrestgv/index.php.
And if anyone is interested, I haven't made any progress in Delphi4D due to
(guess, guess) lack of time. I hope I can get back to it soon.
Although I remember Walter saying he didn't like the need to distribute an
application with a dll. Delphi4D apps will work like that. Should I keep it
on? Mmm, time for a poll. You know where to vote ;).

-----------------------
Carlos Santander Bernal
Jan 21 2004
prev sibling parent reply Mark T <Mark_member pathlink.com> writes:
any update?
Feb 01 2004
parent Brad Anderson <brad sankaty.dot.com> writes:
I'm afraid real work is rearing its ugly head and time is scarce.  We've 
made some progress, and I'll have more time next week, but it's slow 
going.  We'll post when we have something.

Cheers,
Brad


Mark T wrote:

 any update?
Feb 01 2004