Hi Kevin All your propositions seem reasonnable and valuable for OpenJUMP.
As Stefan said, the main problem is development resources. I cannot evaluate precisely the work to do without a deeper look, but it concerns core classes and will need caution and tests. Are you volonteer to develop these features ? Michaël Le 01/09/2010 20:15, Kevin Neufeld a écrit : > Stefan mentioned that there isn't a road map for OJ, but is there a > place to jot down improvement ideas? > > Here are a couple on my wishlist: > > 1) The ability to specify which columns are editable in an layer's > attribute table. Right now, the FID and geometry column are hard-coded > as being the only columns that are not editable. I would like to see > this driven off the layer's FeatureSchema. Perhaps there could be a > "isAttributeReadOnly(int attributeIndex)" method added to the > FeatureSchema that could be used in LayerTableModel.isCellEditable(int > rowIndex, int columnIndex). > > Primary key attributes that belong to a DynamicFeatureCollection driven > off a database is one example of a non-editable column. > > > 2) The ability to customize the tooltips for previously installed > plugins on a layer's right click context menu. For example, I could > have a custom implementation of a Layer that is backed by a custom > FeatureCollection. If I mark the layer as readonly, the "Editable" menu > item is correctly greyed-out. The tooltip says something like "This > layer cannot be made editable." The menu item is greyed-out ... > obviously it's not editable. I would like to change the tooltip to > explain *why* the menu item is greyed-out ... which is particular to my > custom FeatureCollection. > > IE. > "No Primary Key found on the underlying database table" > "Adhoc queries cannot be made editable" > "SQL Server DataStores cannot currently be made editable" > > > 3) A new UpdatablePlugIn interface with methods like getPluginVersion(), > getPluginURL(). All implementations of the interface could be listed in > the extensions tag in the About window. A user could choose to update a > selected plugin where a new plugin jar and all the jar's dependencies > would automatically download, available upon application restart. I > know, I know. This would require a huge framework and lots of developer > time, but it sure would be nice to have. > > > Cheers, > -- Kevin > > ------------------------------------------------------------------------------ > This SF.net Dev2Dev email is sponsored by: > > Show off your parallel programming skills. > Enter the Intel(R) Threading Challenge 2010. > http://p.sf.net/sfu/intel-thread-sfd > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel