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 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
