Re: [JPP-Devel] Language files
Hi Stefan, I saw the other entries too (eg, The Pirol's Moveup/down categories). Below there is a partial list: - Zoomrealtime (menu bar) - Paste Items to the point (layer menu) - SetCategoryvisibilityPlugin (Category menu) - MoveCategoryTo theTop (Category menu) - MoveCategoryToOneUp(Category menu) - MoveCategoryToOneDownCategory menu) - MoveCategoryTo theBottom (Category menu) - Cut Polygon (on Tools-Edit Geometry) - I suggest to change the name in "Cut Polygon with a line" - Create cookie cut (on Editing toolbar) - Beanshell Consolle - on "Open Project" window, under the voice "Open Project" there is a string "Instruction" which can't be translate in other languages Stefan, I use a software called Babelfish, in java, which I also used to translate Kosmo in Italian. It is pribabily similar to prbeditor. When you say "be aware that you are not changing the key, only the translations", Do you mean not to translate the file "jump.properties" but only the language files (jump_it.properties, jump_en.properties, etc)? Peppe Stefan Steiniger <[EMAIL PROTECTED]> ha scritto: Hei Peppe, Giuseppe Aruta wrote: > I am working around the Italian Language file to fix the latest > modification. > I am also giving a review to the main (English) Jump.properties files. > > 1) There are some items which lack of interntionalization (?): > "ZoomRealtime" and "Paste items to point" yep.. I saw this as well (there may be some more things open: e.g. some checks are left) > > 2) I wander if it is possible to modify the description of some items: > a) "Transform layer style into SLD" to "Export symbology to SLD file" > b) "Import SLD" to "Import symbology from SLD file" no problem. but be aware that you are not changing the key, only the translations. I actually I found the prbeditor quite handsome for the editing of the entries. You only need to load all files together. Then it shows you on the left the key entry and on the right all translations (I can also send a screen shot). stefan > > > I think in the nect days I will go on working on Italian files and check > other Internat/modify on main language file. If you agree with the > proposal 2) I will try to modify also Spanish, French and Portuguese > files. For point 1) I probabily need a complete Jump.properties > > Peppe > > > Scopri il Blog di Yahoo! Mail > : > trucchi, novità, consigli... e la tua opinione! > > > > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > > > > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - Scopri il Blog di Yahoo! Mail: trucchi, novità, consigli... e la tua opinione!- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Language files
Hi Stefan, I saw the other entries too (eg, The Pirol's Moveup/down categories). Below there is a partial list: - Zoomrealtime (menu bar) - Paste Items to the point (layer menu) - SetCategoryvisibilityPlugin (Category menu) - MoveCategoryTo theTop (Category menu) - MoveCategoryToOneUp(Category menu) - MoveCategoryToOneDownCategory menu) - MoveCategoryTo theBottom (Category menu) - Cut Polygon (on Tools-Edit Geometry) - I suggest to change the name in "Cut Polygon with a line" - Create cookie cut (on Editing toolbar) - Beanshell Consolle - on "Open Project" window, under the voice "Open Project" there is a string "Instruction" which can't be translate in other languages Stefan, I use a software called Babelfish, in java, which I also used to translate Kosmo in Italian. It is pribabily similar to prbeditor. When you say "be aware that you are not changing the key, only the translations", Do you mean not to translate the file "jump.properties" but only the language files (jump_it.properties, jump_en.properties, etc)? Peppe Stefan Steiniger <[EMAIL PROTECTED]> ha scritto: Hei Peppe, Giuseppe Aruta wrote: > I am working around the Italian Language file to fix the latest > modification. > I am also giving a review to the main (English) Jump.properties files. > > 1) There are some items which lack of interntionalization (?): > "ZoomRealtime" and "Paste items to point" yep.. I saw this as well (there may be some more things open: e.g. some checks are left) > > 2) I wander if it is possible to modify the description of some items: > a) "Transform layer style into SLD" to "Export symbology to SLD file" > b) "Import SLD" to "Import symbology from SLD file" no problem. but be aware that you are not changing the key, only the translations. I actually I found the prbeditor quite handsome for the editing of the entries. You only need to load all files together. Then it shows you on the left the key entry and on the right all translations (I can also send a screen shot). stefan > > > I think in the nect days I will go on working on Italian files and check > other Internat/modify on main language file. If you agree with the > proposal 2) I will try to modify also Spanish, French and Portuguese > files. For point 1) I probabily need a complete Jump.properties > > Peppe > > > Scopri il Blog di Yahoo! Mail > : > trucchi, novità, consigli... e la tua opinione! > > > > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > > > > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - Scopri il Blog di Yahoo! Mail: trucchi, novità, consigli... e la tua opinione!- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Kosmo and OpenJUMP common area of interests
Hi. 1) Kosmo plugin model vs OpenJUMP We can also consider other two ways to share tools between OpenJUMP and Kosmo. Please correct me if I am wrong as I am not a developer a) OpenJUMP introduced the Beanshell Consolle which, I think, it is still under estimate between the users. Nevertheless it probabily could be a good tool integrate in Kosmo, too. Then OpenJUMPm and Kosmo can share some plugin as Beanshell script b) Another interesting area could be the Jython (Python) consolle, realized by Larry for SkyJUMP and JUMP. Probabily only Larry has the basic knowlegment in Jython to develop tools (expecially CAD like) in this language ( I am still in ol' basic dos :-)). But even Python could be another area of common interest. The question is: does Kosmo can use beanshell script written for OJ? How easy is to traslate in beanshell script OJ tools to use in Kosmo. Of coarse the question could be posted even also on the opposite direction (Kosmo vs. OpenJUMP) 2) Save as Project file We probabily could not loose the idea to find an exchange project format. Not only for Kosmo and OpenJUMP but this would be an interest for all the Opensource comunity (thinking about only how many Java GIS project could be involved: JGRASS, GvSIG, UDIG). If Styled Layer descriptor works between Kosmo and UDig, Opensource cimunity could think about a Styled Project Descriptor. Not a common file project but a way to exchenge project sharing at least the style, without loosing each own project specificity (hyoerlink, 3D, etc). This is a much more a needle proposal than a project 3) SLD Antonio (and Saig Lista) wrote "..OJ SLD import plugin has a problem when reading the color values..". We probabily ask Andreas what he think about and check if there is a solution. SAIG - Listas <[EMAIL PROTECTED]> ha scritto: Hi to all. I'll shed a little bit light on the issues from a developer point of view (both proposals from Giuseppe and another one that Sunburned Surveyor mentioned): 1) Kosmo plug-in model I'll start with a little bit of history to clarify some ideas: Kosmo started on August 2005. Our starting seed was the JUMP 1.0 fork implemented by the Agiles group (the two starting developers of Kosmo were part of the founders of this group). This fork implemented an on-demmand framework to the existing JUMP datasource framework. Why don't we use the 1.1.2 JUMP version that was already present at that date? When we implemented the on-demmand framework on the last version, the results that we obtained were worse that those obtained with the 1.0 fork. So we decided to start with it and added to this version some of the improvements that were made to JUMP from the 1.0 to the 1.1.2 version. As we were advancing in the development of Kosmo, we have added some of the improvements made to JUMP and also to OpenJUMP. The plugin model that Kosmo uses is basically the same: we have added some methods to the interfaces and the abstract classes, but they haven't been changed heavily. There is no plugín dependency system implemented. The extension model have been also improved, but is almost the same too. 2) Save as - project file format I think that a common project file format won't be a good choice: currently each application uses its own project saving framework and it'll be difficult for each one to change it to a common one. I think that a better choice would be to implement a import/export OpenJUMP project option in Kosmo and an import/export Kosmo project option in OpenJUMP. We share some common objects (Task, Category, Layer, FeatureCollections, DataSourceQuery, JUMP Styles, ...) that can be recovered from the project XML file and loaded into each one. 3) SLD Import/Export Kosmo only supports SLD export so far (the import plugin is planned but it's not implemented yet). As Giuseppe says, this format can be used to export/import the layer simbology between the two projects, as SLD is a standard and it's not binded to a determinate application. Kosmo also allows to save its own simbology format because we use some improvements that are not present in the SLD standard. But most of the Kosmo simbology can be exported to a SLD file without problem. Each application could accept the parts of the standard supported, and the rest of the file could be ignored. I think the SLD format it's a good choice. Regards, PD: We've tested the Kosmo SLD export against UDIG 1.1 rc14 and all of the tests have succeded. I've also test against the last OpenJump nightly build with some sld files generated by Kosmo and the OJ SLD import plugin has a problem when reading the color values: it seems to read the color value string with a lot of spaces before and after it, and the Color.decode() function fails (this could be corrected by calling to the method colorString.trim()). Giuseppe Aruta escribió: > Hi Antonio, > let me resume the two i(my) proposal
Re: [JPP-Devel] Kosmo and OpenJUMP common area of interests
Of coarse I invite (if they want to partecipate to this discussion) Michael Michaud and Larry Baker to say their opinion since they worked a lot on Beanshell and Jython consolles peppe Giuseppe Aruta <[EMAIL PROTECTED]> ha scritto: Hi. 1) Kosmo plugin model vs OpenJUMP We can also consider other two ways to share tools between OpenJUMP and Kosmo. Please correct me if I am wrong as I am not a developer a) OpenJUMP introduced the Beanshell Consolle which, I think, it is still under estimate between the users. Nevertheless it probabily could be a good tool integrate in Kosmo, too. Then OpenJUMPm and Kosmo can share some plugin as Beanshell script b) Another interesting area could be the Jython (Python) consolle, realized by Larry for SkyJUMP and JUMP. Probabily only Larry has the basic knowlegment in Jython to develop tools (expecially CAD like) in this language ( I am still in ol' basic dos :-)). But even Python could be another area of common interest. The question is: does Kosmo can use beanshell script written for OJ? How easy is to traslate in beanshell script OJ tools to use in Kosmo. Of coarse the question could be posted even also on the opposite direction (Kosmo vs. OpenJUMP) 2) Save as Project file We probabily could not loose the idea to find an exchange project format. Not only for Kosmo and OpenJUMP but this would be an interest for all the Opensource comunity (thinking about only how many Java GIS project could be involved: JGRASS, GvSIG, UDIG). If Styled Layer descriptor works between Kosmo and UDig, Opensource cimunity could think about a Styled Project Descriptor. Not a common file project but a way to exchenge project sharing at least the style, without loosing each own project specificity (hyoerlink, 3D, etc). This is a much more a needle proposal than a project 3) SLD Antonio (and Saig Lista) wrote "..OJ SLD import plugin has a problem when reading the color values..". We probabily ask Andreas what he think about and check if there is a solution. SAIG - Listas <[EMAIL PROTECTED]> ha scritto: Hi to all. I'll shed a little bit light on the issues from a developer point of view (both proposals from Giuseppe and another one that Sunburned Surveyor mentioned): 1) Kosmo plug-in model I'll start with a little bit of history to clarify some ideas: Kosmo started on August 2005. Our starting seed was the JUMP 1.0 fork implemented by the Agiles group (the two starting developers of Kosmo were part of the founders of this group). This fork implemented an on-demmand framework to the existing JUMP datasource framework. Why don't we use the 1.1.2 JUMP version that was already present at that date? When we implemented the on-demmand framework on the last version, the results that we obtained were worse that those obtained with the 1.0 fork. So we decided to start with it and added to this version some of the improvements that were made to JUMP from the 1.0 to the 1.1.2 version. As we were advancing in the development of Kosmo, we have added some of the improvements made to JUMP and also to OpenJUMP. The plugin model that Kosmo uses is basically the same: we have added some methods to the interfaces and the abstract classes, but they haven't been changed heavily. There is no plugín dependency system implemented. The extension model have been also improved, but is almost the same too. 2) Save as - project file format I think that a common project file format won't be a good choice: currently each application uses its own project saving framework and it'll be difficult for each one to change it to a common one. I think that a better choice would be to implement a import/export OpenJUMP project option in Kosmo and an import/export Kosmo project option in OpenJUMP. We share some common objects (Task, Category, Layer, FeatureCollections, DataSourceQuery, JUMP Styles, ...) that can be recovered from the project XML file and loaded into each one. 3) SLD Import/Export Kosmo only supports SLD export so far (the import plugin is planned but it's not implemented yet). As Giuseppe says, this format can be used to export/import the layer simbology between the two projects, as SLD is a standard and it's not binded to a determinate application. Kosmo also allows to save its own simbology format because we use some improvements that are not present in the SLD standard. But most of the Kosmo simbology can be exported to a SLD file without problem. Each application could accept the parts of the standard supported, and the rest of the file could be ignored. I think the SLD format it's a good choice. Regards, PD: We've tested the Kosmo SLD export against UDIG 1.1 rc14 and all of the tests have succeded. I've also test against the last OpenJump nightly build with some sld files generated by Kosmo and the OJ SLD import plugin has a problem when reading the color values: it seems to read the color v
Re: [JPP-Devel] Kosmo and OpenJUMP common area of interests
Sergio, You wrote: "The plugin model that Kosmo uses is basically the same: we have added some methods to the interfaces and the abstract classes, but they haven't been changed heavily. There is no plugín dependency system implemented. The extension model have been also improved, but is almost the same too." This is good news. I'm not sure how much the guts of Kosmo has changed in comparision to OpenJUMP, but this means that at least the plug-in framework may be close to being compatible. I'll have to figure out how to download the Kosmo source code so I can look at the methods that were added. What are the chances that a plug-in written for OpenJUMP could run in Kosmo without major modifications? Are the basic data structures within the cores of both programs essentially the same? You wrote: "think that a common project file format won't be a good choice: currently each application uses its own project saving framework and it'll be difficult for each one to change it to a common one." We should remember that migration to a common project file format could be an long-term goal, and not something that would need to be done immediately. We could determine what a common project file format might look like, and then work towards using that format over the next couple of years as we make other changes. You wrote: "I think that a better choice would be to implement a import/export OpenJUMP project option in Kosmo and an import/export Kosmo project option in OpenJUMP. We share some common objects (Task, Category, Layer, FeatureCollections, DataSourceQuery, JUMP Styles, ...) that can be recovered from the project XML file and loaded into each one." This is an excellent idea. I should add it as one of my future projects, at least until another programmer decides to tackle it. :] The Sunburned Surveyor On Wed, Mar 26, 2008 at 12:42 PM, SAIG - Listas <[EMAIL PROTECTED]> wrote: > Hi to all. > > I'll shed a little bit light on the issues from a developer point of > view (both proposals from Giuseppe and another one that Sunburned > Surveyor mentioned): > > 1) Kosmo plug-in model > > I'll start with a little bit of history to clarify some ideas: > > Kosmo started on August 2005. Our starting seed was the JUMP 1.0 fork > implemented by the Agiles group (the two starting developers of Kosmo > were part of the founders of this group). This fork implemented an > on-demmand framework to the existing JUMP datasource framework. Why > don't we use the 1.1.2 JUMP version that was already present at that > date? When we implemented the on-demmand framework on the last version, > the results that we obtained were worse that those obtained with the 1.0 > fork. So we decided to start with it and added to this version some of > the improvements that were made to JUMP from the 1.0 to the 1.1.2 > version. As we were advancing in the development of Kosmo, we have added > some of the improvements made to JUMP and also to OpenJUMP. > > The plugin model that Kosmo uses is basically the same: we have added > some methods to the interfaces and the abstract classes, but they > haven't been changed heavily. There is no plugín dependency system > implemented. The extension model have been also improved, but is almost > the same too. > > > 2) Save as - project file format > > I think that a common project file format won't be a good choice: > currently each application uses its own project saving framework and > it'll be difficult for each one to change it to a common one. I think > that a better choice would be to implement a import/export OpenJUMP > project option in Kosmo and an import/export Kosmo project option in > OpenJUMP. We share some common objects (Task, Category, Layer, > FeatureCollections, DataSourceQuery, JUMP Styles, ...) that can be > recovered from the project XML file and loaded into each one. > > > 3) SLD Import/Export > > Kosmo only supports SLD export so far (the import plugin is planned but > it's not implemented yet). As Giuseppe says, this format can be used to > export/import the layer simbology between the two projects, as SLD is a > standard and it's not binded to a determinate application. Kosmo also > allows to save its own simbology format because we use some improvements > that are not present in the SLD standard. But most of the Kosmo > simbology can be exported to a SLD file without problem. Each > application could accept the parts of the standard supported, and the > rest of the file could be ignored. I think the SLD format it's a good > choice. > > Regards, > > PD: We've tested the Kosmo SLD export against UDIG 1.1 rc14 and all of > the tests have succeded. I've also test against the last OpenJump > nightly build with some sld files generated by Kosmo and the OJ SLD > import plugin has a problem when reading the color values: it seems to > read the color value string with a lot of spaces before and after it, > and the Color.decode() function fails (this could be corrected by > calling to the m
[JPP-Devel] [General Java] Indexed CSV Files
Does anyone have source code that allows indexed and random access to each line in a text file, like a CSV file for example? I thought I would ask before I wrote something from scratch. The Sunburned Surveyor - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] [General Java] Indexed CSV Files
H2 has some code to support CSV that looks pretty good. Larry On Thu, Mar 27, 2008 at 3:11 PM, Sunburned Surveyor < [EMAIL PROTECTED]> wrote: > Does anyone have source code that allows indexed and random access to > each line in a text file, like a CSV file for example? I thought I > would ask before I wrote something from scratch. > > The Sunburned Surveyor > > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > -- http://amusingprogrammer.blogspot.com/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] [General Java] Indexed CSV Files
Thanks for the suggestion Larry. I will check it out. Landon On Thu, Mar 27, 2008 at 1:18 PM, Larry Becker <[EMAIL PROTECTED]> wrote: > H2 has some code to support CSV that looks pretty good. > > Larry > > > > On Thu, Mar 27, 2008 at 3:11 PM, Sunburned Surveyor > <[EMAIL PROTECTED]> wrote: > > > > > > > > Does anyone have source code that allows indexed and random access to > > each line in a text file, like a CSV file for example? I thought I > > would ask before I wrote something from scratch. > > > > The Sunburned Surveyor > > > > - > > Check out the new SourceForge.net Marketplace. > > It's the best place to buy or sell services for > > just about anything Open Source. > > > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > > ___ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > -- > http://amusingprogrammer.blogspot.com/ > - > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Kosmo and OpenJUMP common area of interests
Giuseppe Aruta a écrit : > Of coarse I invite (if they want to partecipate to this discussion) > Michael Michaud and Larry Baker to say their opinion since they worked > a lot on Beanshell and Jython consolles Hi Giuseppe, and thanks to your efforts to improve collaboration. Sharing beanshell scripts is about the same problem as sharing plugins. It is ok as far as the script rely on the common part of the API (ex. JTS for geometry processing) but will be broken if the script try to use a class or a method which is only available in one of the application. That said, scripting with beanshell may be a pleasant way to explore api and to see where the common part of the api stops and where the specific part starts. Michaël > > peppe > */Giuseppe Aruta <[EMAIL PROTECTED]>/* ha scritto: > > Hi. > > 1) Kosmo plugin model vs OpenJUMP > > We can also consider other two ways to share tools between > OpenJUMP and Kosmo. Please correct me if I am wrong as I am not a > developer > a) OpenJUMP introduced the Beanshell Consolle which, I think, it > is still under estimate between the users. Nevertheless it > probabily could be a good tool integrate in Kosmo, too. Then > OpenJUMPm and Kosmo can share some plugin as Beanshell script > b) Another interesting area could be the Jython (Python) consolle, > realized by Larry for SkyJUMP and JUMP. Probabily only Larry has > the basic knowlegment in Jython to develop tools (expecially CAD > like) in this language ( I am still in ol' basic dos :-)). But > even Python could be another area of common interest. > > The question is: does Kosmo can use beanshell script written for > OJ? How easy is to traslate in beanshell script OJ tools to use in > Kosmo. Of coarse the question could be posted even also on the > opposite direction (Kosmo vs. OpenJUMP) > > 2) Save as Project file > We probabily could not loose the idea to find an exchange project > format. Not only for Kosmo and OpenJUMP but this would be an > interest for all the Opensource comunity (thinking about only how > many Java GIS project could be involved: JGRASS, GvSIG, UDIG). > If Styled Layer descriptor works between Kosmo and UDig, > Opensource cimunity could think about a Styled Project Descriptor. > Not a common file project but a way to exchenge project sharing at > least the style, without loosing each own project specificity > (hyoerlink, 3D, etc). This is a much more a needle proposal than a > project > > 3) SLD > Antonio (and Saig Lista) wrote "..OJ SLD import plugin has a > problem when reading the color values..". We probabily ask Andreas > what he think about and check if there is a solution. > > > */SAIG - Listas <[EMAIL PROTECTED]>/* ha scritto: > > Hi to all. > > I'll shed a little bit light on the issues from a developer > point of > view (both proposals from Giuseppe and another one that Sunburned > Surveyor mentioned): > > 1) Kosmo plug-in model > > I'll start with a little bit of history to clarify some ideas: > > Kosmo started on August 2005. Our starting seed was the JUMP > 1.0 fork > implemented by the Agiles group (the two starting developers > of Kosmo > were part of the founders of this group). This fork > implemented an > on-demmand framework to the existing JUMP datasource > framework. Why > don't we use the 1.1.2 JUMP version that was already present > at that > date? When we implemented the on-demmand framework on the last > version, > the results that we obtained were worse that those obtained > with the 1.0 > fork. So we decided to start with it and added to this version > some of > the improvements that were made to JUMP from the 1.0 to the 1.1.2 > version. As we were advancing in the development of Kosmo, we > have added > some of the improvements made to JUMP and also to OpenJUMP. > > The plugin model that Kosmo uses is basically the same: we > have added > some methods to the interfaces and the abstract classes, but they > haven't been changed heavily. There is no plugín dependency > system > implemented. The extension model have been also improved, but > is almost > the same too. > > > 2) Save as - project file format > > I think that a common project file format won't be a good choice: > currently each application uses its own project saving > framework and > it'll be difficult for each one to change it to a common one. > I think > that a better choice would be to implement a import/export > OpenJUMP > project option in Kosmo and an import/export Kosmo project >
[JPP-Devel] renaming of functions?
Hei Since "Spatial Join of Geometries..." and "Transfer Attributes" do the same, while the first has more functionality I propose the following: a) removal of the Transfer Attributes b) moving Spatial Join of Geometries to the tools\attribute menu... c) renaming of the latter to Transfer Attributes, as it does not spatially join geometries (i.e. does a merging) PS: I am going to reverse the spatial criteria for "Spatial Join of Geometries..." as it seems to be implemented the other way around when the boxes are read from top to bottom stefan - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Feature Info Tool with pictures and text
Hi, is there a plugIn to show pictures, textinformation and web-pages (URLs) with the Feature Info Tool? Regards Uwe - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
