From: Egon W. <ego...@gm...> - 2008-11-27 12:18:45
|
Hi all, The current ControllerHub nicely distributed mouse events over the used controller modules, but the editing events are still all located inside the Hub. This means that all dependencies, are hard coded too, resulting in a heavy weight controller hub. The modules need access to the editing API, but at the same time, the ControllerHub must not know about it at all, or not about the implementation at least. To solve this, I'd like to move the editing API to the controller modules, and would like discuss possible designs. Option 1 ------------ Keep the current monolitic interface IChemModelRelay, and have modules implement parts of that interface, possibly as external editing modules, so that modules do not duplicate method implemtations. Option 2 ------------ Have each editing method as a separate class, more like an action. IChemModelEditAction? Not sure yet of this interface would have any common methods... Any thoughts on this? Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: gilleain t. <gil...@gm...> - 2008-11-27 13:44:55
|
Hi, So the IChemModelRelay interface is really doing two (separate?) things: 1) Dispatching mouse events from the swing/swt relays 2) Interacting with the chemmodel by adding atoms, bonds, rings, etc So, for the options - Option 1 seems like a bad idea, as to have multiple classes implementing parts of one interface means a lot of blank implementations of methods. In fact, the ControllerModules already do this, with the IController interface (or rather, they did, until I made the Adapter base class). As for option 2 - doesn't the fact that they look like Actions, and quack like actions, suggest that ControllerModules really _are_ actions? I mean to say, they are actions that also can recieve mouse events. Talking of events, Stefan and I talked about Keyboard events. Could these also be reouted through the hub? gilleain On Thu, Nov 27, 2008 at 12:18 PM, Egon Willighagen <ego...@gm...> wrote: > Hi all, > > The current ControllerHub nicely distributed mouse events over the > used controller modules, but the editing events are still all located > inside the Hub. This means that all dependencies, are hard coded too, > resulting in a heavy weight controller hub. > > The modules need access to the editing API, but at the same time, the > ControllerHub must not know about it at all, or not about the > implementation at least. > > To solve this, I'd like to move the editing API to the controller > modules, and would like discuss possible designs. > > Option 1 > ------------ > Keep the current monolitic interface IChemModelRelay, and have modules > implement parts of that interface, possibly as external editing > modules, so that modules do not duplicate method implemtations. > > Option 2 > ------------ > Have each editing method as a separate class, more like an action. > IChemModelEditAction? Not sure yet of this interface would have any > common methods... > > Any thoughts on this? > > Egon > > -- > ---- > http://chem-bla-ics.blogspot.com/ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Cdk-jchempaint mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-jchempaint > |
From: Egon W. <ego...@gm...> - 2008-11-27 13:55:45
|
On Thu, Nov 27, 2008 at 2:44 PM, gilleain torrance <gil...@gm...> wrote: > Hi, > > So the IChemModelRelay interface is really doing two (separate?) things: > > 1) Dispatching mouse events from the swing/swt relays > 2) Interacting with the chemmodel by adding atoms, bonds, rings, etc > > So, for the options - Option 1 seems like a bad idea, as to have > multiple classes implementing parts of one interface means a lot of > blank implementations of methods. In fact, the ControllerModules > already do this, with the IController interface (or rather, they did, > until I made the Adapter base class). Right, I tend to agree with that. > As for option 2 - doesn't the fact that they look like Actions, and > quack like actions, suggest that ControllerModules really _are_ > actions? I mean to say, they are actions that also can recieve mouse > events. Mmm... maybe they are indeed... But, that does require that some controllers are active simultanously, while others exclude others... For example, highlight would typically be always on, while others like move and addAtom would likely exclude each other... but I thinkg the ControllerHub already supports that, right? > Talking of events, Stefan and I talked about Keyboard events. Could > these also be reouted through the hub? Yes, I think they should. Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: gilleain t. <gil...@gm...> - 2008-11-27 14:08:41
|
>> ControllerModules really _are_ >> actions? > Mmm... maybe they are indeed... > > But, that does require that some controllers are active simultanously, > while others exclude others... > For example, highlight would typically be always on, while others like > move and addAtom would likely exclude each other... but I thinkg the > ControllerHub already supports that, right? Yes, it does, with the generalModules. gilleain |
From: Egon W. <ego...@gm...> - 2008-11-27 14:10:43
|
On Thu, Nov 27, 2008 at 3:08 PM, gilleain torrance <gil...@gm...> wrote: >>> ControllerModules really _are_ >>> actions? >> Mmm... maybe they are indeed... >> >> But, that does require that some controllers are active simultanously, >> while others exclude others... >> For example, highlight would typically be always on, while others like >> move and addAtom would likely exclude each other... but I thinkg the >> ControllerHub already supports that, right? > > Yes, it does, with the generalModules. OK, good. Then I know where to start moving things. Now I only need to think about how to interface with the JavaScript console... Egon -- ---- http://chem-bla-ics.blogspot.com/ |