|
From: Jonny W. <jwr...@gm...> - 2007-09-11 17:08:24
|
Hi Rogan, I appreciate your consideration of my code when doing this refactoring. It'll make keeping the jide integration code in-sync with the main code-base easier. As for the need for the JideApplicationWindow, I'm not sure what you mean about different from standard behaviour. When I implemented the docking code there was no other example or standard, so I just did what made sense to me at the time. It seems that we may have a different view on the relative roles of application windows, application pages and perspectives. How do you see the roles of application window, application page and perspectives with respect to a docking implementation? I'll also look at the vldocking code when I get the chance, as I think it's worthwhile to have the docking implementation consistent in their concepts and the introduction of these refactorings seems like a good time to do that. Regarding the perspectives, the exposure of the JideApplicationWindow in the API, I'd say this a leaking of the implementation details into the API and so could be done better for sure, so I don't see a problem there. Jonny On 9/10/07, Rogan Dawes <ro...@da...> wrote: > > > Hi Jonny, > > Thanks for taking the time to take a look. I did consider your > implementation of the JIDE docking code when doing the refactoring. The > major difference that is not accounted for in the refactoring is the > JideApplicationWindow code. > > I must admit, I'm not entirely sure why this is needed. Any reason that > this has to be different to the standard behaviour? Can the JIDE > DockableHolder not be a property of the JideApplicationPage, rather? > > I absolutely do plan to make a ChangePerspectiveCommand. You may have > seen the PageDescriptorRegistry, ShowPageCommand and ShowPageMenu that I > added at the beginning of the year. I was previously implementing > Perspectives in their own Page. Unfortunately, this ends up requiring > unclean changes to support persistence of Views across Perspective > changes. > > Rogan > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Springframework-rcp-dev mailing list > Spr...@li... > https://lists.sourceforge.net/lists/listinfo/springframework-rcp-dev > |