Re: [JPP-Devel] wishlist
Hi Kevin, I had a look at your patch. It looks pretty good to me. Nice addition! regards, Larry On Thu, Sep 2, 2010 at 12:31 AM, Kevin Neufeld kneuf...@refractions.netwrote: Hi Stefan, You're right, I once did have write access to the old JUMP ... that was a long time ago. I'm surprised you remembered :) Sure, if you're willing, I wouldn't mind having access again. I'm not planning on any major core contributions, but in my spare time as I'm working on various plugins, I occasionally come across some minor things that could get cleaned up. I agree that commits to the core should first have the eyes of those that know the code inside and out. So, if you're willing, my account is kdneufeld. Have a good trip, Stefan! -- Kevin On 9/1/2010 8:58 PM, Stefan Steiniger wrote: 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=detailaid=3057748group_id=118054atid=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
Re: [JPP-Devel] wishlist
Kevin, If Stefan hasn't beat me to it, give me your Sourceforge user name and I'll get you write access to the SVN. Thanks for testing the patch Larry. Landon On Thu, Sep 2, 2010 at 6:37 AM, Larry Becker becker.la...@gmail.com wrote: Hi Kevin, I had a look at your patch. It looks pretty good to me. Nice addition! regards, Larry On Thu, Sep 2, 2010 at 12:31 AM, Kevin Neufeld kneuf...@refractions.net wrote: Hi Stefan, You're right, I once did have write access to the old JUMP ... that was a long time ago. I'm surprised you remembered :) Sure, if you're willing, I wouldn't mind having access again. I'm not planning on any major core contributions, but in my spare time as I'm working on various plugins, I occasionally come across some minor things that could get cleaned up. I agree that commits to the core should first have the eyes of those that know the code inside and out. So, if you're willing, my account is kdneufeld. Have a good trip, Stefan! -- Kevin On 9/1/2010 8:58 PM, Stefan Steiniger wrote: 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=detailaid=3057748group_id=118054atid=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
Re: [JPP-Devel] wishlist
Patch has been committed at r2034, no problems. Let me know if anyone has issues with the addition. Thanx all, -- Kevin On 9/2/2010 8:29 AM, Sunburned Surveyor wrote: Kevin, You've been added to the Jump Pilot Project on Sourceforge and now have write access to the SVN. You can commit your patch so we get the changes in our nightly build. If you have trouble with the commit, please let me know. The Sunburned Surveyor -- 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
Re: [JPP-Devel] [openjump-users] openjump.exe with ini
On 02.09.2010 18:28, edgar.sol...@web.de wrote: Launch4j looks even more promising, having one app that creates launchers for windows, linux, and osx. I take that back. It only creates windows launchers. So essentially it does, what WinRun4J does already. Hence back to apache's launcher. btw. I just stumbled accross the suns java runtime parameter -XX:+AggressiveHeap which according to http://docs.sun.com/app/docs/doc/819-2561/abeia?a=view makes the runtime use automatically all available memory. Shouldn't this be a default for memory consuming java gis apps like OJ? .. ede -- 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
