It is out of scope for me but I would be glad to help with the design / review.
Here are my thoughts thus far: I was thinking that this could mostly be done when the global ApplicationGIS.getToolManager() method delegates to the tool manager provided by the current MapPart. This would allow a View or Editor to control what it advertises. Why is this needed? Right now the GEF Palette data structures are managed from ToolManager; if need to break that functionality out we would need a second implementation and the ability to allow ApplicationGIS to switch between them. With respect to just reusing Palette with a View: - the ToolManager already owns the MapEditDomain (used for the ToolPalette) so there is no need to grab code out of MapEditorWithPalette - a PaletteViewer is already available from GEF (if you wanted to place a palette beside your view) and you can grab the MapEditDomain from the ToolManager. I cannot remember if view can be marked as a palette provider; and thus wired up to the global Palette View (or if that interface is just available to editors?). I would also like to follow up on seeing if we can "disable" palette entries; I think our tools are already good at "not functioning" when they are disabled. We may be able to change their icon to a grayed out icon when they are disabled. -- Jody Garnett On Monday, 5 September 2011 at 5:11 PM, Jesse Eichar wrote: > I think frank has good points here. I think the solution is to do some > refactoring. The views could use some of the inner classes of MapEditor as > well so they can have the projection widget and so on. > > Jesse > > On Sat, Sep 3, 2011 at 2:51 AM, Jody Garnett <[email protected] > (mailto:[email protected])> wrote: > > > From my point of view as an integrator, who uses uDig within a already > > > running RCP application its a bit more complicated to be excited. Mostly > > > the interaction model for editors and views should be the same all over > > > an application. IMHO it was pretty easy to run uDig in a host RCP > > > application and have the same look and feel for all application editors > > > (all Actions were contributed on startup and enabled/disabled because of > > > the context, e.g. selection available, geometry type of layer resource > > > for edit-actions, etc) . > > > > > > The new GEF palette would be great in uDig as a standalone application, > > > integrated in an other RCP apllication its kind of "misfit". I guess some > > > projects that have uDig already integrated would not update to the new > > > version, if the new palette style would be the only available MapEditor, > > > because of mixed styled applications for end users. > > > > > > Up to 1.2.2 it was possible to run MapEditor without having dependencies > > > to GEF (printing module was never integrated). Right now GEF is required > > > for the core project.ui bundle which leads into a bigger footprint. > > > > > > IMHO it would be fantastic to have additional bundle(s) for the > > > MapEditor(s) based on an AbstractMapEditor, one which extends > > > GraphicalEditorWithFlyoutPalette and an other one (old classic style) > > > that extends EditorPart. So the host application could decide which > > > editor (extension point) to use. > > Please speak up next week on this one; Jesse asked us to combine the two > > classes we have there now. If we want to keep the MapEditor we will need > > more of a plan: > > a) to prevent code duplication (perhaps we can make a super class?) > > b) allow applications to control which one the use (there is already some > > control to allow you to supply a custom ToolManger - perhaps that could > > help?) > > > > But I will be a bit sad if we have to keep both as half of the point on > > this one was to minimise the amount of code we have to maintain so we could > > improve ToolManager over time. While I am more comfortable with ToolManager > > now - less code would be more easy to follow. > > > > The other thing that would really help Frank is this -- I cannot see what > > you are seeing as I do not have a good test RCP application to show me the > > problem you describe. > > > > Most of the sample application we have in the tutorials folder make use of > > a View (containing a MapViewer). I suppose the "Hello World" custom > > application can be a good example of what you mean? Not really as it is > > mostly a cut down version of uDig. > > > > Can you think of a good example application we could make that shows the > > problem; that we could keep in the tutorial folder (just so we can have a > > good conversation and have a reference point for this kind of use of the > > SDK in the future). > > > > Jody > > > > > > _______________________________________________ > > User-friendly Desktop Internet GIS (uDig) > > http://udig.refractions.net > > http://lists.refractions.net/mailman/listinfo/udig-devel > > > > _______________________________________________ > User-friendly Desktop Internet GIS (uDig) > http://udig.refractions.net > http://lists.refractions.net/mailman/listinfo/udig-devel
_______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
