Re: [JPP-Devel] About embedded help
--- Sunburned Surveyor [EMAIL PROTECTED] ha scritto: I have thought about this question of integrating help into OpenJUMP quite a bit. Here are some of my thoughts, if anyone is interested: [1] We could use the JavaHelp system. It seems fairly comprehensive, is being developed and maintained by Sun Microsystems, and offers a help system most users are familiar with. [2] We could simply open a PDF file as Peppe suggested. The only problem with this route is that the user will have to have a PDF reader installed and OpenJUMP will need to be able to find it. [3] I have considered putting together a simple help viewer for OpenJUMP. This help viewer displays plain text on its left pane, and images and image captions on its right. I thought of this help viewer because it separates text from images, which is important for ease of translation. Of all these, number [2] is likely the easiest. Number [1] is the option that offers the most functionality, but i think it is the most complex, and creates problems for translation because it combines text and images. The Sunburned Surveyor Hi SS there is a sample of [2]: MapMaker http://www.mapmaker.com/. People can download the software or the help pdf apart. If user put the pdf in a mapmaker folder, they can open it with an option on the help menu. I think that this way is the easiest sinche OJ users can download apart the help. More than this, if there is an embedded help, this will encourage users to discover new functionalities and to test the software peppe ___ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] @ Larry .. a question!
--- Larry Becker [EMAIL PROTECTED] ha scritto: Hi Peppe, I was just waiting for someone to ask! I'll be glad to. Are there any icons that you didn't find particularly helpful? I thought that perhaps I might have gotten a little over enthusiastic and ended up with icon clutter on the Layer Name right click menu. Larry Hi larry, this is a complex question, personally I find interesting to have a good qunatity of icons, even not really useful for me , for two reasons: a) it makes the software more attractive (in this Century of Fashion...) b) it helps to quicly find a tool of function for other people (like me on remove datasets) Regarding SkyJUMP, you're right there are many icons on Layer Menu which contribute to overweight the visibility of the menu. (Copy and paste style, for example or show metadata), but this is only a personal feeling. Regarding OJ I feel that all the icons connected to cut, copy, remove items and view/edit shema or attributes and remove layer will be fashonable and useful. I have an extra proposal: since all the fundamental functions connected to items are on the Layer View menu (Cut, copy, delete, ratate, group, etc), it would be useful to have also the move items (which is actually on the Editing toolbar) Peppe ___ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] bug(?) about Raster
Hi, I note this strange things about raster images on the last OJ NB (with ecw dll embedded): 1)I create a project with some raster ecw (topography) and some working shape layers. When I save the project, a warning message appears on the bottom bar: some layers were not saved to the project file:list of raster files. Of coarse, when I re-open the project file, rasters are not displayed in the layer list (and layer view). Is it a bug of OJ? 2) Again TIFFs are opened in Layer list but not displayed in Layer view Thanks peppe ___ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] OpenJUMP releases and bug management
Hi, Here are some thoughts about releases and bug management. I think we miss some rules to decide when a new version of OJ has to be released, and that lack of visibility may be a disadvantage for OJ's adoption. The release rules should be linked to bug reports and feature requests, but bug reports have to be sorted before they can be used as a base for release decision. A proposition is to let the default level 5 for bugs which have to be fixed before a stable release, to use level 1 and 2 for bugs which have to be fixed ASAP (before any release) and to set less important bugs to priority 6 or more... (any other suggestion is welcome). Any one having access to the bug tracker should be able to initiate this hierarchy, subsequent changes should be asked to the community. Major releases (version changes) could work the same way but based on feature requests (feature requests for version 1.2, for 1.3...) This way, may be we could focus on major bugs and try to release a stable version before the end of 2007. Michaël - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] OpenJUMP releases and bug management
@Michaël, I think that bug tracker level 1 is lowest and level 9 is highest. Looking through the list again, I don't see anything that I would classify as a major bug. To me, a major bug is a stability problem with OJ in general. You can break some cases of obscure features and 99% of users will never notice. @Sunburned, I would agree that many of the bugs listed in tracker and simply disguised feature requests. [1] Freeze all new contributions to the JPP SVN. I believe that this is the point that we create a new stable branch. regards, Larry On 9/3/07, Michaël Michaud [EMAIL PROTECTED] wrote: Hi, Here are some thoughts about releases and bug management. I think we miss some rules to decide when a new version of OJ has to be released, and that lack of visibility may be a disadvantage for OJ's adoption. The release rules should be linked to bug reports and feature requests, but bug reports have to be sorted before they can be used as a base for release decision. A proposition is to let the default level 5 for bugs which have to be fixed before a stable release, to use level 1 and 2 for bugs which have to be fixed ASAP (before any release) and to set less important bugs to priority 6 or more... (any other suggestion is welcome). Any one having access to the bug tracker should be able to initiate this hierarchy, subsequent changes should be asked to the community. Major releases (version changes) could work the same way but based on feature requests (feature requests for version 1.2, for 1.3...) This way, may be we could focus on major bugs and try to release a stable version before the end of 2007. Michaël - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- http://amusingprogrammer.blogspot.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] OpenJUMP releases and bug management
Hi SS, thanks for your answer, [1] It requires that someone sort and maintain the bug-tracker list. Just supervise priorities set to the bugs and feature requests, much less work than fixing bugs and adding features I think :-) [2] It requires some of us to quit working on out pet functionality improvements' and to start fixing bugs. I don't know what is more important : fixing bugs or adding 'pet functionnalities'. It depends... But I'd like to know before we go ahead for a new release. Sorting bugs and feature request could help. I don't think it is very fair to put the burden for either [1] or [2] on any single programmer. There is no need to put the burden on a single programmer. Fixing bug is a task one can easily share :-) I would suggest we choose two (2) weeks before the end of the year to do the following: [1] Freeze all new contributions to the JPP SVN. [2] Sort and prioritize the bugs in the bug tracker. [3] Ask for volunteers to tackle one or two bugs during the freeze. [4] Integrate bug fixes. I'm not sure we need to freeze anything, but yes, I am favourable to a clean bug tracker / release new version operation. If there is support for this, I would gladly take on a large chunk of the work required to sort the bug tracker, and I know there are one or two bugs that I have had my eyes on. Would the first two (2) weeks in October work? We could then shoot for another stable release by the first of November. Seems possible, but it depends on what we decide to fix and add for the next stable release. (We should really let Stefan have the final decision, since he has been taking care of the OpenJUMP releases. These are just some suggestions.) Of course, Stefan did most of the work for last releases, and I'm sure he already has considered these questions. Michael The Sunburned Surveyor P.S. - If I remember correctly from my last attempt at fixing three (3) items in the bug tracker only one (1) of the three (3) items was really a bug. The other problems were resolved or caused by other factors and didn't really belong in the bug tracker. I imagine we will discover more of this, which means we likely don't have the bug problem that we think we do. On 9/3/07, Michaël Michaud [EMAIL PROTECTED] wrote: Hi, Here are some thoughts about releases and bug management. I think we miss some rules to decide when a new version of OJ has to be released, and that lack of visibility may be a disadvantage for OJ's adoption. The release rules should be linked to bug reports and feature requests, but bug reports have to be sorted before they can be used as a base for release decision. A proposition is to let the default level 5 for bugs which have to be fixed before a stable release, to use level 1 and 2 for bugs which have to be fixed ASAP (before any release) and to set less important bugs to priority 6 or more... (any other suggestion is welcome). Any one having access to the bug tracker should be able to initiate this hierarchy, subsequent changes should be asked to the community. Major releases (version changes) could work the same way but based on feature requests (feature requests for version 1.2, for 1.3...) This way, may be we could focus on major bugs and try to release a stable version before the end of 2007. Michaël - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] OpenJUMP releases and bug management
Larry Becker a écrit : @Michaël, I think that bug tracker level 1 is lowest and level 9 is highest. Hey, maybe I inverted. If so, I'm a very bad candidate to sort the list ;-) Looking through the list again, I don't see anything that I would classify as a major bug. To me, a major bug is a stability problem with OJ in general. You can break some cases of obscure features and 99% of users will never notice. Right, there are bugs report to remove, bugs reports to move, bugs that some of us have already fixed and a few one still resisting... Michael @Sunburned, I would agree that many of the bugs listed in tracker and simply disguised feature requests. [1] Freeze all new contributions to the JPP SVN. I believe that this is the point that we create a new stable branch. regards, Larry On 9/3/07, Michaël Michaud [EMAIL PROTECTED] wrote: Hi, Here are some thoughts about releases and bug management. I think we miss some rules to decide when a new version of OJ has to be released, and that lack of visibility may be a disadvantage for OJ's adoption. The release rules should be linked to bug reports and feature requests, but bug reports have to be sorted before they can be used as a base for release decision. A proposition is to let the default level 5 for bugs which have to be fixed before a stable release, to use level 1 and 2 for bugs which have to be fixed ASAP (before any release) and to set less important bugs to priority 6 or more... (any other suggestion is welcome). Any one having access to the bug tracker should be able to initiate this hierarchy, subsequent changes should be asked to the community. Major releases (version changes) could work the same way but based on feature requests (feature requests for version 1.2, for 1.3...) This way, may be we could focus on major bugs and try to release a stable version before the end of 2007. Michaël - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ 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: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
