Paul, Paul wrote: "As much as possible I'm trying to do things as plugins, there are some things where there are not extension points. In these cases I'm trying to come up with some additional solutions to make the core more extensible."
This is great Paul. If I can assist you in any way with this effort please let me know. You might try developing an independent GUI component for the management of Layer Themes. This panel could allow the user to choose a Layer and then create, delete, and manage themes for that Layer. This would also allow the user to "filter" the Layers to choose from so that only Layers with themes, or that support themes, were displayed. Paul wrote: "The other concept I'm going to be working on is how to plug-in components to existing panels (e.g. my new feature detail panel on the InfoFrame)." Interesting. <Deep in thought.> I had thought about this myself a while back. I noticed that AutoCAD allowed you to "dock" panels along the sides of the model space view or map view. What if we modified the LayerViewPanel to allow an "invisible" dockable panel on one of its sides? If a component needed to be shown in this area the JPanel that serves as the map drawing service could be shrunk and a second JPanel shown. If the components did not need to be shown we could remove the second JPanel. Just a thought. The Sunburned Surveyor P.S. - I checked out a cool sight this week. It was called SwingLabs. I wonder if we might tap into their JXPanel? Might be something to consider if we are going to be tweaking with the JPanel extended by LayerViewPanel anyways. On 6/27/07, Paul Austin <[EMAIL PROTECTED]> wrote: > As much as possible I'm trying to do things as plugins, there are some > things where there are not extension points. In these cases I'm trying > to come up with some additional solutions to make the core more extensible > > We'll see if anyone has any other suggestions on how to extend the Tree > model in a plugin. > > The other concept I'm going to be working on is how to plug-in > components to existing panels (e.g. my new feature detail panel on the > InfoFrame). > > Paul > > Sunburned Surveyor wrote: > > Paul, > > > > I have some quick comments. First let me say that I think the concept > > you propose is an intersting one, and that I'm not dismissing it > > entirely. However, I have a couple of conerns and/or questions. > > > > My first concern is about simplicity. I know we are adding some great > > styling functionality here, but we are also adding more complexity for > > the end user. I think this is caused in part by some confusion among > > our project about the purpose of a Layer or Layerable object. > > > > For example, the Javadoc for the Layer object contains this > > description: "Adds colour, line-width, and other stylistic information > > to a Feature Collection." This indicates to me that the main purpose > > of a Layer is to control the style and appearance of Features > > contained in the Layer. If we want to stick to this principle I would > > say that, drawing from your example, that Churches should be put on > > their own Layer, and Schools on their own Layer, instead of sharing a > > Layer. I realize this places a limitation on design, because Churches > > and Schools really share a common set of attributes defined as a > > "building". To me the solution is to relate Features in the Schools > > and Churches Layer to a non-spatial table called GenericBuildings or > > something similar. > > > > I think we all need to get together to decide what the purpose of a > > Layer will be and what restraints we want to place on messing with the > > Layer classes in the core. I blogged about this not to long ago: > > > > http://openjump.blogspot.com/2007/06/organizing-features-in-openjump.html > > > > This is a very important question because it will determine where our > > particular project will strike the balance between simplicity and > > functionality. > > > > Can you give us a couple of days to discuss your changes? I'm not > > saying that it shouldn't go in the core, I'm just saying we need to > > think carefully about it. Will we continue to allow these types of > > changes with a murky definition of a Layer object and its purpose? How > > complex do we want OpenJUMP to get? It is not my place to lay down > > laws in this regard, I'd like us all to make a decision on this > > together. > > > > I also would like you to strongly consider including this > > functionality in a plug-in, instead of using modifications to the > > core. I believe this would be technically possible based on the > > description you provided. Can you take a look at your design and see > > how it might be implemented as a plug-in? If everyone loves how your > > plug-in works we can then modify the core. > > > > Still, I will strongly encourage you and any other OpenJUMP developer > > to use plug-ins whenever possible. In my humble opion we should only > > modify the core to enable more extendability, not to add > > functionality. Additional functionality should be implemented with > > plug-ins. > > > > Let's see what the other developers say. Most of them will usually > > disagree with me. :] > > > > Please keep up the good work. I realize some of the challenges you > > face in OpenJUMP development are caused by our lack of a firm vision > > for what OpenJUMP should be. Please exercise patience with us. > > > > The Sunburned Surveyor > > > > On 6/27/07, Paul Austin <[EMAIL PROTECTED]> wrote: > > > >> At the moment the Task frame has two levels, Category and Layer. I would > >> like to propose a third Theme. > >> > >> What is a theme? A theme identifies a sub set of features in a Layer > >> which have their own style, a label and you can show/hide the layer. > >> > >> For feature layers an example would be a building you may have schools > >> and churches that are rendered using different symbols. This corresponds > >> to the ColorThemingStyle. > >> > >> For WMS layers you could use themes to represent each layer from the > >> server, with the icon being the legend graphic from the server. Here > >> when you show/hide a layer it would add or remove that layer from the > >> WMS request and update the layer. > >> > >> To support this we would need to add a new Theme interface to the > >> workbench.model, which describes the theme. Different type of Layerable > >> would use their own implementations of this interface. > >> > >> public interface Theme { > >> String getLabel(); > >> > >> void setLabel(String label); > >> > >> BasicStyle getStyle(); > >> > >> void setStyle(BasicStyle style); > >> > >> boolean isVisible(); > >> > >> void setVisible(boolean visible); > >> } > >> > >> I would also propose a ThemedLayerable interface that would allow you to > >> get the themes for the layer, Layerables that support themes would > >> implement this interface. > >> > >> public interface ThemedLayerable extends Layerable { > >> public List getThemes(); > >> } > >> > >> Would would then need to modify the LayerTreeModel and the > >> TreeLayerPanel to support this new kind of item in the tree. > >> > >> For Layers I would delegate getting the Themes from the Styles, and my > >> new FilterTheming style would use this. > >> > >> I almost have this code ready to checkin, I'll post a diff so that > >> people can have a look at what I've done and decide if this is something > >> we should add to the core. > >> > >> Paul > >> > >> ------------------------------------------------------------------------- > >> This SF.net email is sponsored by DB2 Express > >> Download DB2 Express C - the FREE version of DB2 express and take > >> control of your XML. No limits. Just data. Click to get it now. > >> http://sourceforge.net/powerbar/db2/ > >> _______________________________________________ > >> Jump-pilot-devel mailing list > >> Jump-pilot-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > >> > >> > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
