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]> 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
