dsource.org - forums

dsource.org

Open Source Development for
the D Programming Language

FAQ

Memberlist

Usergroups

Profile

Delegatea and DWT
Goto page Previous 1, 2

This forum is locked: you cannot post, reply to, or edit topics.

This topic is locked: you cannot edit posts or make replies.

Forum Index -> DWT

View previous topic :: View next topic

Author

Message

JJR

Joined: 22 Feb 2004
Posts: 1104

Posted: Thu Apr 22, 2004 3:25 am Post subject:

Hmmm... Thread-safety will be very important in DWT.

Wienczny

Joined: 10 Apr 2004
Posts: 35

Posted: Fri Apr 23, 2004 5:25 am Post subject: automatic disconnect...

Have you read "Signal/Slot mechanism?" in the newsgroup? How will DWT handle disconnection of events?

JJR

Joined: 22 Feb 2004
Posts: 1104

Posted: Fri Apr 23, 2004 8:27 am Post subject:

I'll definitely study that topic carefully when I'm off work. DWT can easily do it the SWT way. That way makes a unhook method call in the EventTable() class. That seems to be how it does it internally. I think the application interface does this automatically on widget dispose. I've made some progress on how a simple solution will work. I'll discuss it later. I won't do anything fancy because it will make the project too hard to modify. People can change things later if they get the motivation. I just want it to work. Later, John

JJR

Joined: 22 Feb 2004
Posts: 1104

Posted: Fri Apr 23, 2004 4:25 pm Post subject:

JJR wrote:

I've made some progress on how a simple solution will work. I'll discuss it later. I won't do anything fancy because it will make the project too hard to modify. People can change things later if they get the motivation. I just want it to work.

The solution involves replacement of the multilayered listener classes with a delegate aliased as Eventhandler which the application programmer provides.

a call to ...

addListener(int eventType, Eventhandler handler);

will replace all occurrences of SWT's

addListener(int eventType, Listener listener);

Some insignificant modifications to the EventTable class are necessary. There are several other places to change the code also. But it seems it can be done rather easily. All classes defining the Listener interfaces and Adapter abstract classes are no longer necessary.

Specialized calls like...

addSelectionListener(Eventhandler handler) are easy to do in DWT also.

While this may not be the prettiest way, it's the simplest way I know of, integrates well, and allows immediate use of delegates.

All the delegates are stored in the present EventTable (slightly modified to store delegate handlers instead of Listener references) along with an associated DWT event number. These events are easily dispatched when the dispatch system is activated in the current Display object.

As I looked through some of the convoluted array manipulations in Java, I really started appreciating what D could do with its arrays. No method calls to arrayCopy necessary, that's for sure. The only issue is over-lapping arrays that need special attention in D. That's where a simplified DTL might work very well.

I haven't read the signal/slot posts yet. Will do shortly. I just wanted to explain the current considerations.

Later,

John

JJR

Joined: 22 Feb 2004
Posts: 1104

Posted: Fri Apr 23, 2004 10:31 pm Post subject:

JJR wrote:

I'll definitely study that topic carefully when I'm off work. DWT can easily do it the SWT way. That way makes a unhook method call in the EventTable() class. That seems to be how it does it internally. I think the application interface does this automatically on widget dispose.

I've made some progress on how a simple solution will work. I'll discuss it later. I won't do anything fancy because it will make the project too hard to modify. People can change things later if they get the motivation. I just want it to work.

To be a little more accurate:

Each Control inherits from a Widget. Every Widget contains an independent EventTable class that stores listeners (well, practically Eventhandlers for DWT) for that particular object. Events numbers are defined in module DWT and and can be added to an event table with there appropriate Eventhandler.

So you should be able to do something like this:

Code:

class foo {
...
...
void onButtonSelected(Event e) {
// using dsc.io as an example;
Stdout.put("something stupid").cr();
}

Button button1 = new Button(shell, DWT.PUSH);
button.addSelectionListener( &onButtonSelected );
...
}

What happens is that the Button (which inherits frm control and widget) will add a DWT.Selection event to the Button EventTable with "handler(Event e)" as the Eventhandler. At this point it is said to be "hooked" into the eventtable. Unhooking the event can either be done manually with a releaseSelectionListener(), etc. for specific types of events or releaseListenter(event e) for DWT event type selectable. This merely calls the EventTable.unhook() method to remove the delegate and associated event from the internal event table array. Not really all that complicated.

At some point, the dispatcher in Display (one instantiated per DWT session) will run and EventTable's will be searched and handlers executed within connected controls. Within individual widgets, posting an event involves an internal postEvent(event e). Events are either dispatched immediately by a call to the event table handler for an event directly or deferred by adding them to a queue which happens to be in the application Display object that it's connected to. All this is low level and transparent to the programmer, naturally (at least, I hope so Smile

)

NOTE: Display is the name SWT gives the general interface to the underlying operating system. One object of this type is used per program. A shell (or window/app frame) is connected to a single display. Multiple "shells" are possible. You put your displayable controls within shells.

I may have been inaccurate and incomplete in some details, but this gives the general idea of the event operations in DWT. Typed rather quickly so forgive me if I'm unclear.

JJR

Joined: 22 Feb 2004
Posts: 1104

Posted: Wed Apr 28, 2004 3:59 am Post subject:

Wienczny wrote:

I would make it like Object Pascal used to do it last time I used it. They have an on<Event> property for every event a class has.
You can set an eventhandler by assiging an function to it's property.

To Handle the problem of multiple receivers, the properties should be arrays or dynamic lists. Wait for DTL?

I'm just reading some of this over again. You made an interesting point here about dynamic arrays and DTL. The current Java method has a dynamic array of sorts to store events in (and handlers). Because it has an intrinsic dynamic array type with ranges, D could easily do the same thing more smoothly than Java with it's arrayCopy(). In fact that's how I started to convert the Java EventTable class internals -- with D dynamic arrays.

But then it occured to me that SWT might be having to remove events in a way entirely unsuitable for normal arrays: if an event was removed that wasn't at the end of the array, the whole array had to be shifted from [index+1..length] to [index..length-1] to fill the gap in the array. This isn't necessarily expensive for small arrays such as these, but it could be for large ones; and besides, the extra lines required to fix the array seemed distasteful.

If it weren't for the small size of these event arrays, a linked list would seem to be more suitable for this kind of thing because they don't require the shift down operation, just a re-link. (There would be no need for us to wait for DTL for such an operation, though, since such lists are pretty easy to implement.. I think a few people have already done them).

In summary, I kind of see why they stuck with dynamic arrays and the shift operation on removal. These event arrays are typically so small, it would be overkill to implement them with a bulkier list. The arrays are started out with 4 elements max, only resized when they are filled to that limit (increase by 4 more, I believe). Since the EventTables are local to each widget, instead of being stored in a global event table, the likelihood of the arrays growing very large is small.

Later,

John

Hohums

Joined: 08 Apr 2004
Posts: 71
Location: Western Australia

Posted: Wed Apr 28, 2004 10:54 am Post subject:

[quote="JJR"]

Wienczny wrote:

If it weren't for the small size of these event arrays, a linked list would seem to be more suitable for this kind of thing because they don't require the shift down operation, just a re-link. (There would be no need for us to wait for DTL for such an operation, though, since such lists are pretty easy to implement.. I think a few people have already done them).

In summary, I kind of see why they stuck with dynamic arrays and the shift operation on removal. These event arrays are typically so small, it would be overkill to implement them with a bulkier list. The arrays are started out with 4 elements max, only resized when they are filled to that limit (increase by 4 more, I believe). Since the EventTables are local to each widget, instead of being stored in a global event table, the likelihood of the arrays growing very large is small.

Later,

John

I wouldn't recommend link-lists for this application even with large arrays.

Now how often do you do an insertion/deletion in comparison to calling events? Events should occur much more frequently then insertion/deletion. Therefore link-lists would actually cause a slow down even in large arrays.

Link-lists can be much slower to access then arrays that are kept together because of how the computer caches. Particularly very large link-lists can cause many page swaps. Of course you can keep a second pre-allocated array to allocate memory from for the LL to solve this problem but in this case does order matter (because if not you might as well just have the one dynamic array)?

Link-lists are mostly good when you are doing many insertions/deletions when compared to access.

JJR

Joined: 22 Feb 2004
Posts: 1104

Posted: Wed Apr 28, 2004 1:22 pm Post subject:

Hohums wrote:

You are right, insertion/deletions would be quite rare indeed. This makes sense. Insertions/deletion will be done on widget creation/destruction for the most part. Events/handlers will be called much more often. I guess I failed to think this one through very deeply Razz

Hohums wrote:

Link-lists can be much slower to access then arrays that are kept together because of how the computer caches. Particularly very large link-lists can cause many page swaps. Of course you can keep a second pre-allocated array to allocate memory from for the LL to solve this problem but in this case does order matter (because if not you might as well just have the one dynamic array)?

Good point. I never thought of that.

Hohums wrote:

Link-lists are mostly good when you are doing many insertions/deletions when compared to access.

Makes sense. I see the choice of dynamic arrays for this was the right decision in the first place. Smile

Display posts from previous:

	Forum Index -> DWT	All times are GMT - 6 Hours Goto page Previous 1, 2
Page 2 of 2

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum