Re: [JPP-Devel] June OpenJUMP User Survey Results Released
Hello All, Just curious about the embedding Google Map or any other Web Map on OpenJump. Is there a possibility implement the same in the long shot using the OpenLayers API (web Api) and then introducing the same using this OpenLayers Interface as Implementation to the background layer. It would be really the best this thing to implement. As it would more over depend on the OpenLayers implementation than Google Map. It just a suggestion... ;) Rgds. Abhay. On Fri, Jul 4, 2008 at 11:39 PM, Paul Austin [EMAIL PROTECTED] wrote: The problem with the following proposal is not a technical one, it is a legal one. Google and the other providers typically only allow access to their tile layer using their web sites and web APIs. This is in part because they license the data from other parties for a specific purpose. Paul I like very much the feature proposal: Use Google, Yahoo, Microsoft, Mapquest, Open Street Maps map layer as background layer - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] TaskFrame and WorkbenchContext source code files for review before commit.
I must have forgot the attachments. They are at my computer at work. I'll resend them on Monday. I must clarify that the changes I want to commit to the core have nothing to do with the Docking Window Framework or any other GUI changes. There just some clean-up and improvements of the TaskFrame class. I did things like organize all of the public, private, and protected methods together, and added Javadoc comments for all of the public methods. Stefan wrote: sorry, I have not found the time yet to read all your emails on that subject The only real functional code changes I made are the following four (4) changes: - I removed the setTask method that was added by Paul. This seemed prudent because the only time to set a Task is during TaskFrame creation. Paul added the method so that he could use a plug-in to add Docking Windows support. I didn't think this would be necessary now that I have a task frame class that Paul can use with Docking Window support built in. I think the setTask method is a bad idea because it will throw an Exception if used and anytime other than during the creation of the TaskFrame. If we want to support custom TaskFrame creation we should use a true Factory Pattern. - I allowed the CursorTool.cancelGesture method to be called when a TaskFrame is being closed. As I mentioned previously, not calling this method could lead to bugs/memory leaks in future CursorTool implementations. - I added a member variable and an accessor method so that client code could determine if a TaskWindow was a clone of another TaskWindow. - I implemented InternalFrameListener instead of having a hidden InternalFrameAdapter class definition. I did this because it makes the code easier to read and understand. It has no effect on the operation of the program. Stefan wrote: So commit rules will be more strict in terms of agreement and outlining the absolutely necessity of those changes and the expected problems with backwards compatibility [e.g plugins]. I may refer here to emails by Sascha Teichmann. Up to now there is still the wise saying: never touch a running system. As long as everyone else has to play by the same rules. If I'm getting special treatment I should at least know the reason. (I'll gladly accept suggestions or recommendations that deal with technical issues in my source code.) Just to make it clear, I'm not adding the Docking Window Support to OpenJUMP with these changes. That will be done in my own fork. The Sunburned Surveyor On Fri, Jul 4, 2008 at 4:51 PM, Stefan Steiniger [EMAIL PROTECTED] wrote: Landon, before you commit such changes I would like to a) review it (sorry, I have not found the time yet to read all your emails on that subject), which may need some time. b) get an agreement by other programmers [Larry, Paul, Andreas, Michael] that these changes are of benefit. c) know which changes are absolutely necessary to get the docking framework to run [why did you chose the this framework?] d) know about expected compatibility issues. Note: this is a core-change and not just simply a new function or plugin (or am I wrong and you proposed an addition). So commit rules will be more strict in terms of agreement and outlining the absolutely necessity of those changes and the expected problems with backwards compatibility [e.g plugins]. I may refer here to emails by Sascha Teichmann. Up to now there is still the wise saying: never touch a running system. Btw: I miss your attached files and an additional description outlining the changes. stefan Sunburned Surveyor wrote: I've attached the two (2) source code files with some of my recent clean-up/changes. (This doesn't include any of the docking window framework or look-and-feel changes.) Please review my changes to these two (2) classes if you have concerns before I commit to the core. I'll commit next week if there are no strong objections to my changes. The Sunburned Surveyor - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net
Re: [JPP-Devel] Demo of OpenJUMP SBE 01.00.01 Available
Stefan wrote: I am not sure if I like the idea that you call your distribution OpenJUMP SBE since it is not a community product that we (as JPP) released. It can be any xxxJUMP but not OpenJUMP. Fair enough. I'll change the name. We should make this a clear policy that is applied to all forks. Stefan wrote: I thought SB is not for Small Business but for Sunburned Survey What about SunJump? The fork will be designed specifically for small businesses in the United States. This will mean little things like UI changes and support for regional coordinate systems. I hope (at some future time) to directly market this fork of OpenJUMP to local customers and to offer tech support for the fork as part of my small business. The fork will allow me to more quickly commit bugs and other improvements for my customers. I still go through the community process to get changes I feel are beneficial to OpenJUMP commited back to the common core. The Sunburned Surveyor I think I'll call the fork bizzJUMP. Let me know if that name will be a problem. On Fri, Jul 4, 2008 at 4:37 PM, Stefan Steiniger [EMAIL PROTECTED] wrote: Hei, I am not sure if I like the idea that you call your distribution OpenJUMP SBE since it is not a community product that we (as JPP) released. It can be any xxxJUMP but not OpenJUMP. So I suggest a larger name change. cheers, Stefan btw: I thought SB is not for Small Business but for Sunburned Survey What about SunJump? ;) - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] TaskFrame and WorkbenchContext source code files for review before commit.
Hi Sunburned, As long as everyone else has to play by the same rules. If I'm getting special treatment I should at least know the reason. (I'll gladly accept suggestions or recommendations that deal with technical issues in my source code.) As you know, I never mince words, so I would like to acknowledge that your programming skills have come a long way since you first started working on OJ (in 2005?). I haven't looked at your recent TaskFrame posts in detail, but they seem logical on the surface. It is not your changes that I object to, but the reason for them. For me, there are only a few reasons for changing code in a legacy project: to fix a bug, or to add needed functionality. On very rare occasions, it may be necessary to modify the core architecture such as was done with Threads, the rendering system, or Paul's recent Open dialog changes. Ideally, these changes should be done by a programmer with experience in this area. Even so, they almost always turn out to have unintended consequences. I guess I don't like the precedent of randomly modifying the core Classes just because they don't seem optimal. I could do that too, but I resist the temptation because I don't know where it would end. In fact I have made dozens of experimental modifications to core classes that I never proposed to OJ because I can't prove that they actually improve speed, reliability, or memory utilization, or that anyone would ever use them. So I don't like to support core Class changes, but exceptions should be made if someone feels strongly about them. So do you feel strongly that these changes will improve reliability and be worth the possible unintended side effects? If the answer is yes, then I think we owe it to you to support them. best regards, Larry On Sat, Jul 5, 2008 at 7:49 AM, Sunburned Surveyor [EMAIL PROTECTED] wrote: I must have forgot the attachments. They are at my computer at work. I'll resend them on Monday. I must clarify that the changes I want to commit to the core have nothing to do with the Docking Window Framework or any other GUI changes. There just some clean-up and improvements of the TaskFrame class. I did things like organize all of the public, private, and protected methods together, and added Javadoc comments for all of the public methods. Stefan wrote: sorry, I have not found the time yet to read all your emails on that subject The only real functional code changes I made are the following four (4) changes: - I removed the setTask method that was added by Paul. This seemed prudent because the only time to set a Task is during TaskFrame creation. Paul added the method so that he could use a plug-in to add Docking Windows support. I didn't think this would be necessary now that I have a task frame class that Paul can use with Docking Window support built in. I think the setTask method is a bad idea because it will throw an Exception if used and anytime other than during the creation of the TaskFrame. If we want to support custom TaskFrame creation we should use a true Factory Pattern. - I allowed the CursorTool.cancelGesture method to be called when a TaskFrame is being closed. As I mentioned previously, not calling this method could lead to bugs/memory leaks in future CursorTool implementations. - I added a member variable and an accessor method so that client code could determine if a TaskWindow was a clone of another TaskWindow. - I implemented InternalFrameListener instead of having a hidden InternalFrameAdapter class definition. I did this because it makes the code easier to read and understand. It has no effect on the operation of the program. Stefan wrote: So commit rules will be more strict in terms of agreement and outlining the absolutely necessity of those changes and the expected problems with backwards compatibility [e.g plugins]. I may refer here to emails by Sascha Teichmann. Up to now there is still the wise saying: never touch a running system. As long as everyone else has to play by the same rules. If I'm getting special treatment I should at least know the reason. (I'll gladly accept suggestions or recommendations that deal with technical issues in my source code.) Just to make it clear, I'm not adding the Docking Window Support to OpenJUMP with these changes. That will be done in my own fork. The Sunburned Surveyor On Fri, Jul 4, 2008 at 4:51 PM, Stefan Steiniger [EMAIL PROTECTED] wrote: Landon, before you commit such changes I would like to a) review it (sorry, I have not found the time yet to read all your emails on that subject), which may need some time. b) get an agreement by other programmers [Larry, Paul, Andreas, Michael] that these changes are of benefit. c) know which changes are absolutely necessary to get the docking framework to run [why did you chose the this framework?] d) know about expected compatibility issues. Note: this is a core-change and not
Re: [JPP-Devel] June OpenJUMP User Survey Results Released
Hi Larry.. If it is possible can you share the code to plugin of the google map plugin. I am actual writting one for a project of mine.. Rgds. Abhay. On Sat, Jul 5, 2008 at 10:54 PM, Larry Becker [EMAIL PROTECTED] wrote: @Stefan, SkyJUMP has only implemented KML write, although read should be fairly easy to add. We use WGS84 UTM exclusively, so the (limited) reprojection support was easy to implement. This is the reason that there will (IMIHO) always be a niche for specialized JUMP variants like SkyJUMP that can provide powerful (although less general) features by knowing the exact needs of their user base. @Nacho, I have an experimental Google Maps plugin, but stopped work on it due to the licensing issues that Paul pointed out. It is a lot of fun, though. @Abhay, using OpenLayers would not change the license for the map data. It would still need to be hosted on a web page. regards, Larry On Fri, Jul 4, 2008 at 3:42 PM, Stefan Steiniger [EMAIL PROTECTED] wrote: ok.. let me note another problem [which includes the nice kml proposal as well]: We don't have a implementation of projections. So everything that relies on that is not doable before we get this implemented Stefan PS: @Larry, did you also implement KML write or only read for SkyJUMP? Paul Austin wrote: The problem with the following proposal is not a technical one, it is a legal one. Google and the other providers typically only allow access to their tile layer using their web sites and web APIs. This is in part because they license the data from other parties for a specific purpose. Paul I like very much the feature proposal: Use Google, Yahoo, Microsoft, Mapquest, Open Street Maps map layer as background layer - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- http://amusingprogrammer.blogspot.com/ - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] TaskFrame and WorkbenchContext source code files for review before commit.
Larry Becker wrote: Hi, As long as everyone else has to play by the same rules. If I'm getting special treatment I should at least know the reason. (I'll gladly accept suggestions or recommendations that deal with technical issues in my source code.) As you know, I never mince words, so I would like to acknowledge that your programming skills have come a long way since you first started working on OJ (in 2005?). I haven't looked at your recent TaskFrame posts in detail, but they seem logical on the surface. It is not your changes that I object to, but the reason for them. For me, there are only a few reasons for changing code in a legacy project: to fix a bug, or to add needed functionality. On very rare occasions, it may be necessary to modify the core architecture such as was done with Threads, the rendering system, or Paul's recent Open dialog changes. Ideally, these changes should be done by a programmer with experience in this area. Even so, they almost always turn out to have unintended consequences. I guess I don't like the precedent of randomly modifying the core Classes just because they don't seem optimal. I could do that too, but I resist the temptation because I don't know where it would end. In fact I have made dozens of experimental modifications to core classes that I never proposed to OJ because I can't prove that they actually improve speed, reliability, or memory utilization, or that anyone would ever use them. So I don't like to support core Class changes, but exceptions should be made if someone feels strongly about them. So do you feel strongly that these changes will improve reliability and be worth the possible unintended side effects? If the answer is yes, then I think we owe it to you to support them. I can only second what you wrote, as it's exactly how I feel. Best regards, Andreas -- l a t / l o n GmbH Aennchenstrasse 19 53177 Bonn, Germany phone ++49 +228 18496-12 fax ++49 +228 1849629 http://www.lat-lon.dehttp://www.deegree.org signature.asc Description: Digital signature - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Multiple Ring Buffer Tool
I have finished porting over SkyJUMP's Multi-Ring Buffer tool. It is similar to the ESRI tool shown at: http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=multiple_ring_buffer_(analysis)http://webhelp.esri.com/arcgisdesktop/9.2/index.cfm?TopicName=multiple_ring_buffer_%28analysis%29although I it was only when I started porting the tool and was trying to decide on a standardized name that I learned that the same tool was already available in ArcGIS. Ring buffers are designed to divide space into zones of distance ranges. Unlike normal buffers, they do not overlap the inner areas. I think they could be particularly effective in point data proximity algorithms. When multiple features are selected, the equal distance Ring Buffers from each feature are unioned. The tool is presented in the hope that someone will find a general use for it. We use it for generating areas of standardized risk. @Stefan, I didn't add the tool to OpenJumpConfiguration since you are working on that right now. It would be an ideal candidate for the new workbench-properties.xml file, but I couldn't find one of those under SVN. Did I miss it? Anyhow here is the line to add if you want to try it out. I make the usual apologies for the hacked translations. plug-inorg.openjump.core.ui.plugin.tools.MultiRingBufferSelectedPlugIn/plug-in regards, Larry Becker -- http://amusingprogrammer.blogspot.com/ - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] June OpenJUMP User Survey Results Released
On Jul 5, 2008, at 7:49 AM, abhay menon wrote:Hello All,Just curious about the embedding Google Map or any other Web Map on OpenJump. Is there a possibility implement the same in the long shot using the OpenLayers API (web Api) and then introducing the same using this OpenLayers Interface as Implementation to the background layer. It would be really the best this thing to implement. As it would more over depend on the OpenLayers implementation than Google Map.this is how is see it too. google maps mixed in an openlayers mash-up is effectively running in a 'browser' and so why cannot openjump also be considered a 'browser' of sorts(safari, firefox, opera, etc.). users can run as localhost, applying for their google maps url api(localhost/127.0.0.1 or whatever). and of course, it is theresponsibilityof each user to dal with google maps in terms of 'commercial' licensing, should they so elect to do so. or am off base here?eric It just a suggestion... ;)Rgds.Abhay.On Fri, Jul 4, 2008 at 11:39 PM, Paul Austin [EMAIL PROTECTED] wrote: The problem with the following proposal is not a technical one, it is a legal one. Google and the other providers typically only allow access to their tile layer using their web sites and web APIs. This is in part because they license the data from other parties for a specific purpose. Paul I like very much the feature proposal:"Use Google, Yahoo, Microsoft, Mapquest, Open Street Maps map layer as background layer" - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!Studies have shown that voting for your favorite open source project,along with a healthy diet, reduces your potential for chronic lamenessand boredom. Vote Now at http://www.sourceforge.net/community/cca08___Jump-pilot-devel mailing listJump-pilot-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/jump-pilot-devel Eric Jarvies - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] June OpenJUMP User Survey Results Released
On Jul 5, 2008, at 5:24 PM, Larry Becker wrote:@Stefan, SkyJUMP has only implemented KML write, although read should be fairly easy to add. We use WGS84 UTM exclusively, so the (limited) reprojection support was easy to implement. This is the reason that there will (IMIHO) always be a niche for specialized JUMP variants like SkyJUMP that can provide powerful (although less general) features by knowing the exact needs of their user base. @Nacho, I have an experimental Google Maps plugin, but stopped work on it due to the licensing issues that Paul pointed out. It is a lot of fun, though.@Abhay, using OpenLayers would not change the license for the map data. It would still need to be hosted on a web page.i think the primary purpose/reason one would use google maps(or yahoo maps, openstreetmaps, et, al) as a background layer would be to prove/test their own maps/data during editing, thus making it easy andconvenient,without the user having to jump outside of oj to test with geo/map-server/openlayer each time. so, if it as running as localhost, users would be able to easily apply for their google api, using it in a devenvironmenton their local machine. or, users that have their gis server stack running on their dev computer, with their geo/map-server and opelayers configuration up and already running, then perhaps it would programatically be a question of having a google maps background load in udig as a webpage, one that is of course a background, with oj functionality that allows other layers to adapt the google maps projections for purposes of panning and zooming their foreground layers in the same manner as does google maps.with each month/year that passes, the google, yahoo, microsoft, penstreetmaps, et, al map sites will only grow, as will map maker's needs to conform their maps to be displayed atop the above-mentioned map sites via mash-up(openlayers, whatever). and so during the development/map making process, having the ability to switch between google, yahoo, etc., to display your maps atop, will serve greatly as an aid in preparing one's maps for use with these map sites via mash-up(openlayers, etc.). and, again, if one wishes to use it on a commercial level , then it is theresponsibilityof each user to contact google and negotiate terms for a commercial license. also, google has now introduced their new user-contributed map product that is currently being tested... so clearly they are moving in direction that essentially promotes the same type of use as does the feature we are discussing here.many existing desktop and handheld products use google maps(and google maps/map tiles) in a way that simply ALLOWS the user to add google mas to the mix, meaning placing the licensingresponsibilityin each own user's hands, where it rightly belongs imo.?regards,eric regards,LarryOn Fri, Jul 4, 2008 at 3:42 PM, Stefan Steiniger [EMAIL PROTECTED] wrote: ok.. let me note another problem [which includes the nice kml proposal as well]: We don't have a implementation of projections. So everything that relies on that is not doable before we get this implemented Stefan PS: @Larry, did you also implement KML write or only read for SkyJUMP? Paul Austin wrote: The problem with the following proposal is not a technical one, it is a legal one. Google and the other providers typically only allow access to their tile layer using their web sites and web APIs. This is in part because they license the data from other parties for a specific purpose. Paul I like very much the feature proposal:"Use Google, Yahoo, Microsoft, Mapquest, Open Street Maps map layeras background layer" - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- http://amusingprogrammer.blogspot.com/ -Sponsored by:
Re: [JPP-Devel] TaskFrame and WorkbenchContext source code files for review before commit.
On Jul 5, 2008, at 6:07 PM, Larry Becker wrote:Hi Sunburned,As long as everyone else has to play by the same rules. If I'm gettingspecial treatment I should at least know the reason. (I'll gladlyaccept suggestions or recommendations that deal with technical issues in my source code.) As you know, I never mince words, so I would like to acknowledge that your programming skills have come a long way since you first started working on OJ (in 2005?). I haven't looked at your recent TaskFrame posts in detail, but they seem logical on the surface. It is not your changes that I object to, but the reason for them. For me, there are only a few reasons for changing code in a legacy project: to fix a bug, or to add needed functionality. On very rare occasions, it may be necessary to modify the core architecture such as was done with Threads, the rendering system, or Paul's recent Open dialog changes. Ideally, these changes should be done by a programmer with experience in this area. Even so, they almost always turn out to have unintended consequences. I guess I don't like the precedent of randomly modifying the core Classes just because they don't seem optimal. I could do that too, but I resist the temptation because I don't know where it would end. In fact I have made dozens of experimental modifications to core classes that I never proposed to OJ because I can't prove that they actually improve speed, reliability, or memory utilization, or that anyone would ever use them. So I don't like to support core Class changes, but exceptions should be made if someone feels strongly about them. So do you feel strongly that these changes will improve reliability and be worth the possible unintended side effects? If the answer is yes, then I think we owe it to you to support them.i agree. i think it's clear to most projects that when certain aspects of the project, like core issues, start showing their age/faults/shortcomings, and beneficial changes are identified, and can be made to improve the core overall by someone willing to invest their time to do so, then that is a good thing. itcertainlystimulatespositivechange, even if initially these changes are met with opposition, or impact the core negatively as a result of 'chain reaction'consequence. but these consequences are the nature of the beast, and to be expected in any software development project. it seems ss has been investing a good portion of his time making oj a better application, for his own purposes, and for the benefit of others. providing os x friendly builds are made, i'll most certainly invest time testing an such changes, and reporting bugs accordingly.regards,eric best regards,LarryOn Sat, Jul 5, 2008 at 7:49 AM, Sunburned Surveyor [EMAIL PROTECTED] wrote: I must have forgot the attachments. They are at my computer at work. I'll resend them on Monday. I must clarify that the changes I want to commit to the core have nothing to do with the Docking Window Framework or any other GUI changes. There just some clean-up and improvements of the TaskFrame class. I did things like organize all of the public, private, and protected methods together, and added Javadoc comments for all of the public methods. Stefan wrote: "sorry, I have not found the time yet to read all your emails on that subject" The only real "functional code changes" I made are the following four (4) changes: - I removed the setTask method that was added by Paul. This seemed prudent because the only time to set a Task is during TaskFrame creation. Paul added the method so that he could use a plug-in to add Docking Windows support. I didn't think this would be necessary now that I have a task frame class that Paul can use with Docking Window support built in. I think the setTask method is a bad idea because it will throw an Exception if used and anytime other than during the creation of the TaskFrame. If we want to support custom TaskFrame creation we should use a true Factory Pattern. - I allowed the CursorTool.cancelGesture method to be called when a TaskFrame is being closed. As I mentioned previously, not calling this method could lead to bugs/memory leaks in future CursorTool implementations. - I added a member variable and an accessor method so that client code could determine if a TaskWindow was a clone of another TaskWindow. - I implemented InternalFrameListener instead of having a hidden InternalFrameAdapter class definition. I did this because it makes the code easier to read and understand. It has no effect on the operation of the program. Stefan wrote: "So commit rules will be more strict in terms of agreement and outlining the absolutely necessity of those changes and the expected problems with backwards compatibility [e.g plugins]. I may refer here to emails by Sascha Teichmann. Up to now there is still the wise saying: "never touch a running system." " As long as everyone else has to play by the same rules. If I'm getting special treatment I should at least know the reason.
Re: [JPP-Devel] June OpenJUMP User Survey Results Released
abhay, i too have a number of functionality and feature pre-visualizations that address the gui from a finished, end-user point of view. if you want to get a wiki page started regarding this, then i'd contribute the mock-ups and work-flows that would be associated with such a plug-in... and would be happy to modify them along the way as suggested features are proven undoable or not practical.regards,ericOn Jul 5, 2008, at 6:22 PM, abhay menon wrote:Hi Larry..If it is possible can you share the code to plugin of the google map plugin. I am actual writting one for a project of mine..Rgds.Abhay.On Sat, Jul 5, 2008 at 10:54 PM, Larry Becker [EMAIL PROTECTED] wrote: @Stefan, SkyJUMP has only implemented KML write, although read should be fairly easy to add. We use WGS84 UTM exclusively, so the (limited) reprojection support was easy to implement. This is the reason that there will (IMIHO) always be a niche for specialized JUMP variants like SkyJUMP that can provide powerful (although less general) features by knowing the exact needs of their user base. @Nacho, I have an experimental Google Maps plugin, but stopped work on it due to the licensing issues that Paul pointed out. It is a lot of fun, though.@Abhay, using OpenLayers would not change the license for the map data. It would still need to be hosted on a web page. regards,LarryOn Fri, Jul 4, 2008 at 3:42 PM, Stefan Steiniger [EMAIL PROTECTED] wrote: ok.. let me note another problem [which includes the nice kml proposal as well]: We don't have a implementation of projections. So everything that relies on that is not doable before we get this implemented Stefan PS: @Larry, did you also implement KML write or only read for SkyJUMP? Paul Austin wrote: The problem with the following proposal is not a technical one, it is a legal one. Google and the other providers typically only allow access to their tile layer using their web sites and web APIs. This is in part because they license the data from other parties for a specific purpose. Paul I like very much the feature proposal:"Use Google, Yahoo, Microsoft, Mapquest, Open Street Maps map layeras background layer" - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -- http://amusingprogrammer.blogspot.com/ - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel -Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!Studies have shown that voting for your favorite open source project,along with a healthy diet, reduces your potential for chronic lamenessand boredom. Vote Now at http://www.sourceforge.net/community/cca08___Jump-pilot-devel mailing listJump-pilot-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/jump-pilot-devel Eric Jarvies - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net
