Re: [JPP-Devel] TaskFrame and WorkbenchContext source code files for review before commit.

[Eric Jarvies]

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 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 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.  it certainly stimulates positive change, 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, 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 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 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 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