[Idle-dev] walkthrough/snapshot of IDLE user interface improvements to date

[Mark Roseman]

Hi Chris, and thanks very much for the time and effort you put into sharing your thoughts and ideas.

The kind of “sliding panels” you describe can be accomplished easily enough with Tkinter (even the older versions, without too much hassle). The bigger issue  is teasing apart some of the monolithic pieces in IDLE now that assume each component has its own window, and how certain components have overly intimate knowledge of each other. Doing that would make it easier to experiment with putting things together in new and interesting ways. 

(I’ve spent a couple of days going through it and know how I’d like to see things broken up and reorganized, but it’s one of those things that is liable to break a lot of things before it eventually stabilizes, so I’m a bit stumped how best to proceed next.)

As for your drag and drop GUI builder addition - yes, that might well be a nice thing to have, but I think at this point you may be stepping beyond the realistic limitations of what might find its way into IDLE short-medium term. :-)  FWIW, there have been numerous GUI builder tools done for Tk (and hence Tkinter) in the past, so I’m not saying it’s not doable, and in fact it could be done as an add-on of some kind to start. So my hesitancy is not about the value and feasibility but that it is a substantial new direction of its own.

Thanks again
Mark



> On Sep 2, 2015, at 4:42 AM, Chris Roffey <chris at codingclub.co.uk> wrote:
> 
> Dear Mark
> 
> This is excellent! It is humbling to see how much work is done by a dedicated few on IDLE development.
> I have read  through the document you linked to and found it very interesting. Ensuring IDLE looks professional and natural on all platforms is very important for students (the biggest cohort of beginners) as they make first impressions very quickly. Getting rid of annoying bugs is also very important as it gives one less thing for students to moan about - remember, learning to program, requires a great deal of persistence and resilience - every unnecessary obstacle is a potential turn-off for possibly able students. So all the IDLE-dev team’s hard work on this is invaluable.
> 
> Keeping things simple appears to be a mantra of this group - and it is a good one. I am no longer convinced that having a complete panelled IDLE interface like I suggested before is necessary or even the best option. I now think that keeping any windowed apps (using tkinter or turtle modules) out of the interface simplifies and makes it more flexible as long as they appear on top when run. There was a time when turtle windows appeared behind the shell window and the script window meaning a lot of the turtle’s activity was missed while the window was found. This appears to be fixed and it appears front central now (on my Mac at least) – perfect!
> 
> I have been developing my thoughts further trying to produce my ideal IDE/text editor for teaching with. I have called it CREATE rather than IDLE so that it is easier to refer to (rather than Chris Roffey’s possible version of IDLE.) 
> 
> http://codingclub.co.uk/images/CREATE-overview.png
> 
> Feature wise, I am not sure that it is very challenging in terms of programming as I am not suggesting many feature requests (except major things like ‘Deploy' - that could be developed outside of this team and then linked to.) A lot of work would need to be done on documentation and aliases for error messages but this IS something I could help with. However, is tkinter up to the sort of sliding panels I am suggesting? Mark, please sit down for this next question - I am loath to make it as I know how much work people have already done and I am well aware I am new to the group but - would it be better to use a more sophisticated system for the graphical side of IDLE that implements platform native windowing facilities and allows for style sheets? This might take away some of the complexities of implementing tkinter features for the users whilst running tkinter in the IDE - I don’t know?
> 
> The reason I make such bold statements is I am aware of the trend in education recently is to produce fantastic drag and drop environments for students coding prior to learning a text based language like Python e.g. Scratch (fantastic), Kodu (not so sure). So to make a good impression, any IDE needs to compete at least in terms of looks and ease of use with these. Although I agree with others on this group that IDLE should not be trying to compete with professional IDEs currently available - I do think that students deserve something as sophisticated and professional as the developers, but written with them in mind.
> 
> The question is, should and could IDLE do this?
> 
> Best wishes
> Chris
> 
>> On 31 Aug 2015, at 20:44, Mark Roseman <mark at markroseman.com> wrote:
>> 
>> As I’ve been making changes to various pieces of IDLE’s user interface, I’ve been documenting the updates in the form of a case study. I hope that will be useful to others modernizing a Tk-based application. I’ve put a draft of that, as well as a snapshot of the current code, here:
>> 
>> 	http://www.tkdocs.com/tutorial/idle.html
>> 
>> I’m looking forward to helping do whatever I can to migrate some of these changes into IDLE’s official codebase. But in the meantime if anyone can take a read or try the code, that would be great!
>> 
>> Some of the deeper changes to allow (cleanly) for more of a single window model will probably have to wait until a few more of these preliminaries find their way in.
>> 
>> Mark
>> 
>> _______________________________________________
>> IDLE-dev mailing list
>> IDLE-dev at python.org
>> https://mail.python.org/mailman/listinfo/idle-dev
> 
>