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
--
https://mail.python.org/mailman/listinfo/python-list
