FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Delegatea and DWT
Goto page 1, 2  Next
 
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

PostPosted: Mon Apr 19, 2004 12:18 pm    Post subject: Delegatea and DWT Reply with quote

As I begin to convert the "events" directory, I realize that we should be thinking about how delegates are going to fit into the picture.

Right now in SWT, we have to figure out how to convert the Listener-Adaptor-Event system into something using delegates. This is a good time to start working on this.

My deductions:

-- Listeners are merely interfaces modelling how actions are to be performed when specific events occur.

-- Adapters implement the Listeners as an abstract class (empty default actions).

-- Events are just data containers with information about the current action.

Delegates will modify/simplify this system somewhat. Would be nice to have some ideas rolling... I could look at how DUI does it, in the meantime. I think there's another window library that does this too....

Suggestions?
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Tue Apr 20, 2004 12:33 pm    Post subject: Delegats and DWT Reply with quote

Just an update...

As I look at this issue a little deeper, I realize that we have to figure out a solution to this now because it will affect the structure of the classes significantly. It will both simplify the work in one area and complicate it in another. In simplifies it because it reduces the need to convert a whole wack of java source files (in the event directory: looks like most listener and adaptor files are unnecessary). It complicates the conversion because we would be departing significantly from the SWT projects way of doing things.

This means plenty of modifications all throughout the widget implementation code to adopt a delegate style. I've studied some of Ant's DUI code and have the general idea of how it should work. The problem is that when we convert to delegates, there will be so many changes in the dwt/widgets directory source code that we jump into new territory... ie. non-tested codebase. It may make for a decent challenge Wink. And another thing, we will need tables to allow multiple delegates for one control listener because SWT seems to allow multiple handles for a single event, if a programmer so desires it. A little more complicated, but no big deal, I guess.

I'm just trying to get the general feel of how it should work. I guess the best bet before actually doing anything is to post a detailed description of how the delegate tie-in is going to work... that way everyone that wants to work on DWT will know how to make implementation changes to the widget sets (I pretty big task, if you ask me). I'll probably need some help on this one. I don't want to make a faulty implementation here.

Later,

John
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Tue Apr 20, 2004 2:37 pm    Post subject: Reply with quote

Nobody wants to join in this discussion... I guess I'll chat with myself then Smile.

This is what I'll probably do about delegates in DWT. To start off, I'll design and implement a simple case of delegate funtion using a single simplified widget class from SWT. Once I have compiled and tested the simple example, making sure it works correctly, I'll start implementing the changes to the actual DWT skeleton.

We'll see how it goes. If I get anywhere with this, I'll post my sample creation here for some comments and advice.
Back to top
View user's profile Send private message
jcc7



Joined: 22 Feb 2004
Posts: 657
Location: Muskogee, OK, USA

PostPosted: Tue Apr 20, 2004 3:26 pm    Post subject: Reply with quote

JJR wrote:
Nobody wants to join in this discussion... I guess I'll chat with myself then Smile.
It sounds like you're on the right track to me. If you hit a speed bump, let us know. Smile
Back to top
View user's profile Send private message AIM Address
Wienczny



Joined: 10 Apr 2004
Posts: 35

PostPosted: Tue Apr 20, 2004 5:15 pm    Post subject: Reply with quote

JJR wrote:
Nobody wants to join in this discussion... I guess I'll chat with myself then Smile.

This is what I'll probably do about delegates in DWT. To start off, I'll design and implement a simple case of delegate funtion using a single simplified widget class from SWT. Once I have compiled and tested the simple example, making sure it works correctly, I'll start implementing the changes to the actual DWT skeleton.

We'll see how it goes. If I get anywhere with this, I'll post my sample creation here for some comments and advice.


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?
Back to top
View user's profile Send private message AIM Address MSN Messenger
csauls



Joined: 27 Mar 2004
Posts: 278

PostPosted: Tue Apr 20, 2004 10:14 pm    Post subject: Reply with quote

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 assume what you mean is something like:

Code:
class Foo {
  // . . .
  void handleBar(BarEvent event) { . . . }

  this() {
    // . . .
    SomeWidget sw = new SomeWidget();
    sw.onBar = &handleBar;
    // . . .
  }
}


If so... I say right-on.
_________________
Chris Nicholson-Sauls
Back to top
View user's profile Send private message AIM Address Yahoo Messenger
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Tue Apr 20, 2004 11:06 pm    Post subject: Reply with quote

That would be the general idea...

Thanks for the feedback. Smile The trick is fitting this seamlessly into the current code base. It involves ripping alot out of what's already there.
Back to top
View user's profile Send private message
Hohums



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

PostPosted: Wed Apr 21, 2004 1:27 pm    Post subject: Dig Reply with quote

Dig has a good Dispatcher class you may be interested in. I made a more flex-able version for dig-dug using templates. The work is already done for you. You can always change over later.
Back to top
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Wed Apr 21, 2004 1:45 pm    Post subject: Re: Dig Reply with quote

Hohums wrote:
Dig has a good Dispatcher class you may be interested in. I made a more flex-able version for dig-dug using templates. The work is already done for you. You can always change over later.


I'm interested. What I've been doing is looking at all the current methods of doing this that I could find (including DUI and dfbth). I had yet to look at dig. I'll definitely investigate that and see how much work it would be to get a "compatible" integration of it into dwt.

At first I was just going to do mass conversion of the Java classes, but then I realized that some immediate changes to the model (event dispatching) had to be started early on or else I would have been performing a lot of useless work.

Concerning the property method mentioned earlier, I'm not so sure now that's the best way for making things work with the current design, now that I think of it. It might be best just to addListener(DWT.event, delgate()) sort of thing and then for common events within the specific widgets provide specialized "add" calls to make things easier. Assigning to properties has been a somewhat debatable topic recently. Sad

But I have yet to look at Digs methods.

Later,

John
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Wed Apr 21, 2004 11:03 pm    Post subject: Reply with quote

Dig actually has a very nice way of implementing events and delegates. After looking at dig and then at SWT, I almost blanched. Dig is just plain simple, and it made me dislike some of the convolution of the SWT techniques. I'm still trying to understand how SWT does it all; the multi level complexities don't make it crystal clear. Thankfully, I'm understanding enough to see that deep down, despite listeners being used, SWT has directly analogous mechanics as compared to Dig.

That said, the DWT delegate example I gave above is not quite correct. Modelling it more like DIG would be preferable.
Back to top
View user's profile Send private message
jcc7



Joined: 22 Feb 2004
Posts: 657
Location: Muskogee, OK, USA

PostPosted: Thu Apr 22, 2004 12:10 am    Post subject: Reply with quote

JJR wrote:
Modelling it more like DIG would be preferable.
I always knew keeping dig around would come in handy. Smile Thank you, Burton, wherever you are.
Back to top
View user's profile Send private message AIM Address
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Thu Apr 22, 2004 2:32 am    Post subject: Reply with quote

Don't mind me if I seem like a lunitic and keep changing my mind... I'm just reading more SWT documentation and studying more SWT and DIG code... something I really should have started earlier.

So I have to be a little more cautious on this one... Once again, I'm vacillating, second-guessing, and re-analyzing... something I seem to be good at. Sad

Dig is great, but it's simplicity makes it a difficult candidate for DWT integration. After studying the SWT technique, I have to admit that it does work nicely if you understand it; it's just much more contrived than DIG, which makes it's code less obvious when giving it a passing glance. But the extra complexity translates directly to a very complete funtionality and adaptability in the system.

This is obvious if you look at SWT's event system. SWT has significantly more events than DIG that would need to be supported in order for the whole library to function properly. Also those events are neatly organized into method containers (my way of naming adapter/listener classes for events) that can be added or removed to selected widgets: MouseListener, MenuListener, ShellListener, KeyListener, etc. These containers are mainly what adds an extra level of complexity to SWT as compared to DIG.

DIG achieves the same thing by arranging all its event methods at a single level in the Control class instead of segregating and containing them. This makes DIG simpler to program with. Add to that the use of simple delegates interface, and we have a GUI library that appears to be a breeze to use.

My point, though, is that SWT is still more comprehensive, something we don't want to lose if we want a powerful GUI for D. I guess this comprehensiveness is one of the reasons why we are considering a SWT port in the first place. Splicing in DIG code, if it were possible, would severely handicap the project.

I'm still looking at ways to change it. D language features like delegates would doubtless ease a lot of the complexity involved in the listener system (not to say it's really that complicated, but after examining DIG...), so I still think it's a worthy goal to work towards. It's definitely not a matter of cutting and pasting DIG features into DWT, so far as I see now.

But then again I'm not the brightest guy to work on this project. Hopefully sheer stupid determination gets me through that handicap Wink.
Back to top
View user's profile Send private message
Hohums



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

PostPosted: Thu Apr 22, 2004 3:05 am    Post subject: Reply with quote

You can think of the dig dispatcher as a level above delegates, it's like wrapped up delgate. If you do end up using it please use the templated version from dig-dug as you'll find it easier. Even if you don't use it, it's worth looking into it as it might help explain how to get around some of DWT's problems with the listeners.

I know I'll post it here:

Code:

template DispatcherT(Event)
{
   /** A set of delegates that are notified when a @a Control event is activated. */
   struct Dispatcher
   {
      alias void delegate (Event event) Method; /**< The first-form method. */
      alias void delegate () MethodB; /**< The second-form method. */
   
      Method [] methods; /**< The list of methods called by notify. */
      MethodB [] methodbs; /**< No-argument-form methods. */
      Dispatcher *[] dispatchers; /**< Dispatcher pointers. */
   
      /** Add a method to the list.  Frees the previous list if append resulted in re-allocation. */
      void add(Method method)
      {
         methods ~= method;
      }
   
      /** Add a no-argument-form method to the list. */
      void add(MethodB method)
      {
         methodbs ~= method;
      }
   
      /** Add a dispatcher pointer to the list. */
      void add(Dispatcher *dispatcher)
      {
         dispatchers ~= dispatcher;
      }
      
      /** Remove a method from the list. */
      void remove (Method m)
      {
         for (int c; c < methods.length; c ++)
            if (m == methods [c])
            {
               for ( ; c < methods.length - 1; c ++)
                  methods [c] = methods [c + 1];
               methods.length = methods.length - 1;
            }
      }
      
      /** Remove a method from the list. */
      void remove (MethodB m)
      {
         for (int c; c < methodbs.length; c ++)
            if (m == methodbs [c])
            {
               for ( ; c < methodbs.length - 1; c ++)
                  methodbs [c] = methodbs [c + 1];
               methodbs.length = methodbs.length - 1;
            }
      }
   
      /** Remove a dispatcher from the list. */
      void remove (Dispatcher *d)
      {
         for (int c; c < dispatchers.length; c ++)
            if (d == dispatchers [c])
            {
               for ( ; c < dispatchers.length - 1; c ++)
                  dispatchers [c] = dispatchers [c + 1];
               dispatchers.length = dispatchers.length - 1;
            }
      }
   
      /** Notify the methods that an event has occured. */
      void notify (Event e)
      {
         for (Method *m = methods, n = m + methods.length; m < n; m ++)
            (*m) (e);
         for (MethodB *m = methodbs, n = m + methodbs.length; m < n; m ++)
            (*m) ();
         for (Dispatcher **m = dispatchers, n = m + dispatchers.length; m < n; m ++)
            (*m).notify (e);
      }
   
      /** Notify the methods with an empty event. */
      void notify () { Event e; notify (e); }
   
      /** Notify this dispatcher if non-empty, or the other dispatcher if this one is. */
      void notifyOrEmpty (Event e, Dispatcher *other)
      {
         if (methods.length)
            notify (e);
         else
            other.notify (e);
      }
   
      /** Notify this dispatcher if non-empty, or the other dispatcher if this one is. */
      void notifyOrEmpty (Dispatcher *other)
      {
         Event e;
   
         notifyOrEmpty (e, other);
      }
   
      /** Return whether there are no entries in this dispatcher. */
      bit isEmpty ()
      {
         return methods.length == 0 && methodbs.length == 0 && dispatchers.length == 0;
      }

      /** Notify the methods with an empty event. */
      void opCall() { notify();  }

      /** Notify the methods that an event has occured. */
      void opCall(Event e) { notify(e);  }

      /** Add a method to the list.  Frees the previous list if append resulted in re-allocation. */
      void opCall(Method method) { add(method);  }

      /** Add a no-argument-form method to the list. */
      void opCall(MethodB method)   { add(method); }
   
      /** Add a dispatcher pointer to the list. */
      void opCall(Dispatcher *dispatcher) { add(dispatcher); }

   }
}
Back to top
View user's profile Send private message AIM Address Yahoo Messenger MSN Messenger
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Thu Apr 22, 2004 3:21 am    Post subject: Reply with quote

Note that the above is not thread-safe; this is something you may need to consider for DWT.

- Kris
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Thu Apr 22, 2004 3:24 am    Post subject: Reply with quote

Yep... I came across that while I was looking at DIG stuff. Thanks for posting, since it clears up what exactly you were referring to before.

Don't worry, I'll definitely give it some attention since I'll need to analyze every angle I can in order to solve this problem.
Back to top
View user's profile Send private message
Display posts from previous:   
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 All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 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


Powered by phpBB © 2001, 2005 phpBB Group