[Idle-dev] Re: IDLE UI Suggestion

[Stephen M. Gava]

On Mon, 2002-08-05 at 04:44, unknown man wrote:
> >Actually a lot of the changes that end up in production idle seem to
> >come from patches submitted directly to python's (and thus idle's) own
> >sourceforge tracker; and I then end up applying them 'back' to idlefork
> >by tracking changes to python/idle cvs. This was the case for instance
> >with the menu changes for the shell window that I mentioned already
> >applying. So far only one or two minor bugfixes and no major features
> >have ever made it the other way, from idlefork into idle.

> If that is the case than what is the point of idlefork? it seams a bit 
> silly to have an experimental slightly unstable version of the
> software that is supposed to be used to add and test new features to
> the original program if very few of the changes ever become part of
> the original.

Hmm, I suggest you read the information on the idlefork site about the
history of the project, I don't really have the time to repeat it all
here. I guess I should have added 'so far' to the above. The short
version is that idlefork _is_ the official experimental version of idle;
but the two first major new features being developed in idlefork (new
configuration system, new separate process execution [rpc] model for
code run and debugged from idle) have not yet been completed and
stabilized to the point where they can be moved into stable idle. We are
heading for a series of alpha, then beta testing releases for those
major new features in the near future, and once they are stable in
idlefork Guido has indicated he is keen to move them into stable python
idle asap.

The point of my answer above was to let you know that minor changes and
bugfixes to idle (like the shell window menu ones) are more readily
resolved in a timely manner by submitting them directly to idle/python.
Major new features and restructuring of idle are the province of
idlefork. These changes are happening in a fork so that production idle
is never left in an unstable state as idlefork is much of the time.

> 
> If I were a better Python programmer (I'm fairly new at Python) I would 
> download the latest Python release to have the latest IDLE. Then I
> would download idle fork. I would then move the better idlefork
> features over to Idle. Then at last I would have the best version of
> idle/idlefork (perhaps I would call it IDLEspoon? :-) ). 

You would end up with idlefork. Idlefork is equivalent to the latest
python/idle from cvs plus all the major new idlefork features in
development.

> If you are
> wondering why I would not use idlefork directly is that it has been
> noted that is slightly unstable (and i would not want program problems
> messing up my program.)

It is not slightly unstable at the moment, it is very unstable. ;^) It
is development software and not recommended for day to day use except
for the tarball releases we announce as being stable enough for that
purpose. The last release in that condition was 0.8.1, available from
the sourceforge site. Many people have used that one as their regular
idle version, and the Vpython project adopted it as their standard idle.
There have been many drastic changes to idlefork since then though, and
for anyone interested we are currently maintaining a slightly more
stable (though I would advise still unsuitable for full-on production
use) cvs branch called DS_RPC_BRANCH, which has most of the new config
stuff in it but none of the recent major RPC code execution changes.

> What do you think the odds are that the Tk community would listen to 
> the suggestion of allowing the windows version of Tk to have a
> customizable icon?

I have no idea and I don't have the time to follow it up. Why don't you
ask them?

Some of the other questions you are asking have been answered many times
before on idle-dev and other python mailing lists. You should try
searching the list archives (there are links to them from the python
site) for information. If you have more questions/suggestions please
join idle-dev and float them there. That way the load of responding can
be shared among the other developers and list readers as well. One piece
of advice though, there is a strong preference for real names there.

Regards,
Stephen.  
-- 
Stephen M. Gava  <elguavas@users.sourceforge.net>
IDLEfork ( http://idlefork.sourceforge.net )  " just like IDLE, only crunchy "