Hi again,
Thanks for the response to the patch. Incidentally, the patch I
submitted is something I probably would never check-in myself if I
had write access. What I was most interested in is showing a rough
idea of my concept. In hindsight I think its not clear enough and
probably not the right way to go about evolving the software. oh
well... still learning :)
Specific responses are below:
>Can you please post a patch without tabs in it? One part of playing in OS is
>to maintain the code style that is present in the project. I personally am
>very against tabs because they make things like patches really hard to read
>since in email and web pages the indentation gets all messed up.
Yes, sorry, I thought I had removed them but I'll make sure none
exist in the future.
>
>If you are going to send in patches, lets do patches that actually work and
>or not questionable like that. Putting it in an if (false) block makes it
>questionable to me.
Sure. Close to a release, I would definitely not check this patch in.
Making changes via patches is very different from making changes with
write access. My typical mode of making changes is to make SMALL
isolated changes that concentrate on re-factoring the code in order
to accomplish my goal. But without write access this process could
take a week to make a substantive change. I will submit a few more
patches today that take things more slowly...
>Also, you name "Dialog" doesn't seem real clear to me. In fact, this whole
>patch doesn't seem really well explained and it is modifying some core code
>so I'm warry of it a bit. Could you please spend so more time on the exact
>reason why this patch is needed and why you think that the data is shown in
>the URL...I hate to be an idiot and a pain in the ass, but I have never seen
>the behavior you are talking about so it is foreign to me...
I'll clear this idea up in a separate message since the idea might be
a little more lengthy than would be suitable for this reply. Also, I
do have trouble duplicating the circumstances. The rewriting may be a
result of a bug in the browser I'm using (Netscape 4.6 on MacOS). I
can't consistently reproduce it so I'll work on that a bit more...
>
>I can see that you are stuffing the parameters into the session in order to
>maintain the state from the last request, but is that really needed?
Maybe not. I'll take another shot at explaining it (again, separate message).
>Ok...do it right the first time and send in that patch. ;-) I don't want to
>clutter the code up with things that need to be "future" changed...I want
>them changed now. Lots and lots of people depend on this code on a daily
>basis...if interfaces change or core code changes, I want to make sure that
>it is really solid.
Good idea.
Thanks again for taking a look at my patches!
Chris Meyer
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
