Everything good about Python except GUI IDE?

[Terry Reedy]

On 2/29/2016 3:20 AM, Chris Angelico wrote:

> Incidentally, HTML+CSS is another excellent example of code being used
> to create a visual effect. While there *are* WYSIWYG HTML editors, I'm
> not familiar with any WYISWYG HTML+CSS editors, and I much more often
> see a fast-turnaround code editing system such as codepen.io - you
> change the HTML in one box, or the CSS in another, and the result down
> below changes in real-time.

Does it change with each key stroke (if the keystroke leaves the text in 
a coherent, non-error state) or only on some special input?

> It wouldn't be too hard to create
> something like this for a GUI, and it'd remove some of that feeling of
> non-interactivity while still retaining all the benefits of code above
> drag-and-drop.

Keystroke auto-updates hardly make sense.  On-demand updates for tkinter 
are already possible.  By default, tk root windows, Python interpreter, 
Idle Shell, and IDLE Editors windows appear in the upper left of a 
screen.  Move either the tk or the python window(s) to the right.


1. REPL (python or IDLE): Possible updates are signaled by \n.  Tkinter 
visibly responds, when appropriate, on a statement by statement basis.

 >>> import tkinter as tk
 >>> root = tk.Tk()  # root window appears
 >>> b = tk.Button(root)  # text='', bg='white' are defaults
 >>> b.grid()  # button appears in root window
 >>> b['text'] = 'Hello World!'  # text appears in button
 >>> b['bg'] = 'red'  # background color changes

(Non-default options can also be set when a widget is created.)
One can even, I just discovered, setup timer events interactively.

 >>> root.after(500, lambda: b.config(bg='blue', text='done'))
# after 1/2 second (500 milliseconds), bg and text change

The disadvantage of this method is that the REPL record must be saved 
and processed to reuse it.


2. Editor (IDLE): Run with F5 to see the result of any changes.  The 
root window appears in a fraction of a second and population by widgets 
hardly takes much longer.  I think that this is close enough to 
interactive for most purposes.


3. Editor + REPL (IDLE): Since F5 simulates running the file with 
'python -i', this is automatic if the file in the editor does not run 
'root.mainloop()'.  If it does, the following in the file will allow one 
to end the blocking mainloop() call without also calling root.destroy 
and destroying the gui.

tk.Button(root, text='quit mainloop', command=root.quit).grid()


4. Integrated Editor and Display: your idea.  I think "It wouldn't be 
too hard" is wildly over-optimistic, as I will now explain>

The turtle demo (python -m turtledemo) has read-only text on the left, a 
turtle screen on the right, and a 'Start' button.  The text is read-only 
to avoid overwriting the supplied demo files.  People who want to edit 
them are supposed to copy and paste into an editor, such as IDLE's.)

The demo files must be and are (after failures) written in a special 
style to run properly within the demo framework, ... and to not disturb 
the buildbots when imported as part of test/test_all.  Top level code 
should only have definitions, including a 'def main' entry point, 
non-gui statements, and a '__main__'-guarded conditional statement for 
initiating gui actions.  They must also not bypass the turtle wrapping 
of tkinter to make direct tkinter calls that would disable the demo 
runner itself.  So even if turtledemo were turned into turtle-designer, 
by replacing the text pane with an editor, it could not be used for all 
legal turtle programs.

A GUI designer would replace the turtle screen also, with a gui frame. 
The special style would be something like the following template.

import tkinter as tk  # or "from tkinter import x, y, z, ..."
# define classes and functions

def main(parent):
     # call classes, passing parent
     # set up timers with parent.after
     # anything else requiring that root exist

if __name__ == '__main__':
     root = tk.Tk()
     main(root)
     root.mainloop()

The important point is that it must be possible to import the script 
without it creating a new root window or creating events. The app would 
run the user code with

user_gui = importlib.import_module(file_path)
user_gui.main(gui_frame)

Importing the code after saving, rather than using exec on the editor 
contents, isolates it somewhat from the app, but not enough.  Passing 
app's gui_frame into main and making that the parent of everything in 
the user gui ties the user gui into the app.  However, it also allows 
the app to inadvertently affect the app.  Non-interference between IDLE 
and user code, especially tkinter code, was the reason that IDLE was 
re-written, around a decade ago, to run user code in a separate process.

Another issue is handling user code errors.  Syntax errors can be marked 
in the editor, but tracebacks need a separate pane.  And it is also 
useful to be able to interact with the gui without altering the code in 
the editor.

Summary: if one starts with the idea of an interactive, unrestricted, 
code based, gui designer, especially one for tkinter using tkinter, and 
thinks carefully through the possible problems, one can easily end up 
with something similar to what we already have.

On the other hand, I think an interactive, restricted, gui-based, 
tkinter Frame or Canvas designer could be written and would be quite 
useful.  The generated code could easily be code that a human might 
write.  There may be something already available on pypi.

-- 
Terry Jan Reedy