[Idle-dev] IDLEfork / Docs / Startup etc.

[StephenM.Gava]

> > But in any case the point is,
> > wouldn't having the startup state configurable through a gui (and in the
> > default config file) address that concern for those users you mention?
>
> Yes. I was just inserting a general point, that one shouldn't automatically
> assume that users are working from a command line (or for that matter
> automatically assume that they aren't!).

I've tried to avoid both those assumptions in my work on idlefork so far.  
Actually I wouldn't be surprised if a lot of users/programmers are, like 
myself, using python on a variety of platforms (or certainly more than one) 
on a pretty regular basis these days. I see this in itself as a good argument 
for idle's existence in its attempt to be simillarly useful on a range of the 
platforms that python runs on.

> It is true that the Python community has been heavily oriented toward
> Unix/Linux. But I'm very attracted to Guido's vision of "Computer
> Programming for Everyone" and have been pushing this vision with physics
> students whose first exposure to programming is VPython.
>
> Python in general and VPython in particular represent a marvelous entree to
> programming. And most of these novice users have had and will have no
> contact with a command line interface. If we can propagate Python for
> everyone, the number of nonexpert users of Python could be much larger than
> the number of expert users.

Surely. I got involved in working on idlefork in the first place as a result 
of teaching my youngest son and daughter programming using python, and in 
thinking about how I could make idle a nicer environment for them as newbies 
to both python and programming.

> Having ranted, I should also say that it is impossible to do a fully
> acceptable job for both experts and novices without configurability, so the
> path you're taking is the right one.
>
> As for F1 for Python help, it's no big deal, though I still feel that IDLE
> isn't an application, it's a Python environmental component. After all,
> IDLE most definitely isn't an "application" in the technical sense; it's
> not an executable binary.

Neither is any other python program or application an executable binary, yet! 
But while I can see what you mean about idle being 'tied' to python, so is 
every other commercial or non-commercial ide for python out there.  Of course 
they're applications, they're applications for integrated program development 
using the python programming language. In many non windows or mac python 
distributions idle isn't even installed as a default part of python. If you 
want an ide to use with python you can optionally install the IDLE package. 
That said, however, on the subject of 'F1' , idle does need its own help 
(however simple), things like the object browser, the interactive shell, the 
debugger (although it seems this is broken/unused in vpython), could all do 
with some basic pointers available on their constructive use, especially for 
beginners.  If this idle interface help, and eventually also language 
construct help in the editor window, are to eventually become context 
sensitive (which is also on the idlefork todo list), then it makes even more 
sense for the F1 (or other configured app help key) to be context help for 
using idle, and another related key (like shift-F1  for instance) to be the 
language context help key. If you want or need to poke around in the help 
indicies they are of course all still available on the help menu of any 
window. These kinds of behaviours are standard and acceptable and and to my 
mind therefore non confusing to neophytes.

Anyway the bottom line really is that anyone who wants to standardise on 
different behaviour will be able to easily via the default config files if 
they wish.
-- 
Stephen M. Gava  <elguavas@users.sourceforge.net>
IDLEfork ( http://idlefork.sourceforge.net )  " just like IDLE, only crunchy "