Hei Kevin, do you want SVN write access? so this way we do not need to sent patches around, and I think you did already a couple of contributions (on the good old JUMP-cvs before it was gone. So there would be no concern about your skills ;)
However, if core features are concerned we usually have Larry or Michael testing it before a commit is done. (sorry guys, but indeed Larry and Michael are THOSE who know and have the skill ;) For giving you write access we (Michael, Landon or I) would need your SourceForge account login name - thats all. stefan Kevin Neufeld schrieb: > That is the thing with opensource development, eh? :) Development > resources are always tight. > > I just added a patch for review to the feature tracker for my primary issue. > http://sourceforge.net/tracker/index.php?func=detail&aid=3057748&group_id=118054&atid=679909 > > The patch > - adds a readonly attribute to a FeatureSchema attribute > - uses the attribute in the LayerTableModel to set if a cell is editable > - shades cells in the AttributeTablePanel that are non-editable to light > gray. > > I don't know what OJ uses for a testing harness, but preliminary testing > looks good. > I programmatically added a layer and set one of the schema attributes as > read-only. > > The other issues I mentioned are not a big concern for me at all (just a > wishlist) and I no plans to address them any time soon. > > -- Kevin > > > On 9/1/2010 1:34 PM, Michaël Michaud wrote: >> 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 >> > > ------------------------------------------------------------------------------ > 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
