A GUI for beginners and experts alike
Python has dropped the GUI ball, at least for beginners (in my opinion) While the Python language is awesomely compact, the GUI code is far from compact. Tkinter will create a nice looking GUI, but you've got to be skilled to use it. A student in their first week of Python programming is not going to be working with tkinter. It would be nice if beginners could double click a .py file and have it launch straight into a GUI, like most of the programs people are used to using. I think I've stumbled onto a framework that could work very well for creating fairly complex custom-layout GUIs. A package was released recently that uses this framework. It's called PySimpleGUI<https://github.com/MikeTheWatchGuy/PySimpleGUI>. It is a wrapper for tkinter so that it'll run on almost any system Python will run on. There are no other dependencies and it's a single file so that it can be easily dropped into someone's project folder for immediate use without messing with pip installs. You can read more: PySimpleGUI Tutorial<https://pysimplegui.readthedocs.io/en/latest/tutorial/> PySimpleGUI Cookbook<https://pysimplegui.readthedocs.io/en/latest/cookbook/> PySimpleGUI Reverence Document<https://pysimplegui.readthedocs.io/en/latest/> A bunch of screenshots<https://github.com/MikeTheWatchGuy/PySimpleGUI/issues/1> I am not seeking fame, recognition, or any other personal gain. I could care less if my name is associated with this design. My goal is to get Python off the command line and onto the screen. I am, however, making a serious in my attempt to get serious Python community members to weigh in on the best approach for getting acceptance. A sizeable user-base is likely a requirement. Interest has been brisk over the past few weeks with the basic GitHub<https://github.com/MikeTheWatchGuy/PySimpleGUI> stats having made great strides toward the EasyGUI<https://github.com/robertlugg/easygui> values. It's not a competition, but rather a benchmark to check progress. Comments, suggestions, pointers in new directions are all welcomed. Thank you very much for your time. I have not been a part of this mailing list in the past, so I hope I'm using it within the guidelines. Someone pointed me in this direction to get feedback and into the process. @mike<mailto:mike_barnett@hotmail.com>
Hi Mike Thank you for your message. I agree, in broad terms, with your statement of goals, and welcome their being discussed here. Python has important roots are in education. We benefit from taking care of them. Here is what I take to be your statement of goals.
My preferred approach to solve this problem is to use a web browser as the GUI platform, and communicate with it using a simple local server. I've been learning about http://elm-lang.org/. It impresses me. Here's some URLs. http://elm-lang.org/ https://guide.elm-lang.org/ https://ellie-app.com/37gXN5G4T2sa1 http://elm-lang.org/blog/time-travel-made-easy However, I don't want to have this thread turn into a discussion of elm. Rather, I'm putting forward using HTML5 in a browser as the GUI platform, rather than tkinter. And elm is one of several examples we can learn from. Thank you for your work on PySimpleGUI, and for your statement of goals. with best regards Jonathan
Maybe we're on different planes? I'm talking about 5 lines of Python code to get a custom layout GUI on the screen: import PySimpleGUI as sg form = sg.FlexForm('Simple data entry form') # begin with a blank form layout = [ [sg.Text('Please enter your Name, Address, Phone')], [sg.Text('Name', size=(15, 1)), sg.InputText('1', key='name')], [sg.Text('Address', size=(15, 1)), sg.InputText('2', key='address')], [sg.Text('Phone', size=(15, 1)), sg.InputText('3', key='phone')], [sg.Submit(), sg.Cancel()] ] button, values = form.LayoutAndRead(layout) gets you this window: https://user-images.githubusercontent.com/13696193/43934091-8100e29a-9c1b-11... @mike -----Original Message----- From: Jonathan Fine <jfine2358@gmail.com> Sent: Thursday, August 23, 2018 4:14 PM To: Mike Barnett <mike_barnett@hotmail.com> Cc: python-ideas@python.org Subject: Re: [Python-ideas] A GUI for beginners and experts alike Hi Mike Thank you for your message. I agree, in broad terms, with your statement of goals, and welcome their being discussed here. Python has important roots are in education. We benefit from taking care of them. Here is what I take to be your statement of goals.
My preferred approach to solve this problem is to use a web browser as the GUI platform, and communicate with it using a simple local server. I've been learning about https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Felm-lang.or.... It impresses me. Here's some URLs. https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Felm-lang.or... https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fguide.elm-... https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fellie-app.... https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Felm-lang.or... However, I don't want to have this thread turn into a discussion of elm. Rather, I'm putting forward using HTML5 in a browser as the GUI platform, rather than tkinter. And elm is one of several examples we can learn from. Thank you for your work on PySimpleGUI, and for your statement of goals. with best regards Jonathan
Maybe we're on different planes?
I'm talking about 5 lines of Python code to get a custom layout GUI on
Hi Mike Thank you for your prompt response. You wrote the screen:
key='address')],
[sg.Text('Phone', size=(15, 1)), sg.InputText('3',
key='phone')],
The execution of this code, depends on PySimpleGUI, which in turn depends on tkinter, which is in turn a thin layer on top of Tcl/Tk. And Tcl/Tk provides the GUI layer. (See https://docs.python.org/3/library/tk.html.) I'm suggest that sometimes it may be better to use HTML5 to provide the GUI layer. I pointed to Elm, to show how powerful HTML5 has become. Put another way, I'm suggesting that instead of
import PySimpleGUI as sg
we are able to use
import HtmlSimpleGUI as sg
for a module HtmlSimpleGUI that, sadly, hasn't been written yet! However, mine is just one voice, and I have little more to say. If you don't mind, I'll leave this conversation now. with best regards Jonathan
For me, it would even make more sense to split the project into two parts: - the description library, which could roughly enable the syntax you propose (but with another import) to define what your interface should look like. - rendering plugins to display the form in specific formats/type of displays. So you would have a tkinter (or whatever) plugin for a simple GUI, an bottle/html plugin (for example) to display your interface in a web browser, a plugin with a mix of those two to display the html form in a webview component, a plugin to display the form on a tiny touch enabled screen attached to your raspberry pi's GPIO pins or to your micropython module, etc. And if it makes sense (you didn't use any form element that is not compatible with a text-only display), a plugin to display your form in the CLI. This would allow to detach the content from the presentation, and allow to make a project evolve depending on the needs without having to rewrite everything. -Brice
On Thursday, August 23, 2018, Jonathan Fine <jfine2358@gmail.com> wrote:
BeeWare uses Toga (a widget toolkit) and Briefcase (a build tool) to build native GUIs and SPA web apps
Briefcase can build Django apps. https://pybee.org https://pybee.org/project/using/ https://briefcase.readthedocs.io/en/latest/tutorial/tutorial-0.html https://toga.readthedocs.io/en/latest/tutorial/tutorial-0.html It's definitely not a single file module, though. Bottle is a single file web framework ('microframework'); but it doesn't have a widget toolkit. Web development is not as easy to learn as a simple GUI api for beginners (and then learning what to avoid in terms of websec is a lot to learn). There was a thread about deprecating Tk awhile back. There also I think I mentioned that asyncio event loop support would be great for real world apps.
https://docs.python-guide.org/scenarios/gui/ lists a bunch of great GUI projects for Python. https://github.com/realpython/python-guide/blob/master/docs/scenarios/gui.rs... On Friday, August 24, 2018, Wes Turner <wes.turner@gmail.com> wrote:
I saw this list prior to writing PySimpleGUI. My goal is for this architecture to be on that list down the road. Don’t care if it’s this package, only that something similar exist and is known in the community. There is a gaping hole between command line and a simple GUI on the screen. It’s a huge chasm. Here’s a fun Python-like way of using the package. You can collapse a custom form down to a single line of (readable) code. button, (filename,) = sg.FlexForm('Get filename example'). LayoutAndRead([[sg.Text('Filename')], [sg.Input(), sg.FileBrowse()], [sg.OK(), sg.Cancel()] ]) Or maybe break it up: button, (filename,) = sg.FlexForm('Get filename example').LayoutAndRead( [[sg.Text('Filename')], [sg.Input(), sg.FileBrowse()], [sg.OK(), sg.Cancel()]]) Can a few of you with the vast amount of GUI experience you have, spend 5 minutes and run one of the examples? This will get you started: pip install PySimpleGUI Then copy and paste a Recipe from the Cookbook. https://pysimplegui.readthedocs.io/en/latest/cookbook/ For someone with a dev environment running, it’s a 2 minute exercise. It will make for more focused comments. I’m asking that it actually be tried because I don’t think anything like it has been proposed as a GUI framework. @mike<mailto:mike_barnett@hotmail.com> From: Wes Turner <wes.turner@gmail.com> Sent: Friday, August 24, 2018 4:17 AM To: Jonathan Fine <jfine2358@gmail.com> Cc: Mike Barnett <mike_barnett@hotmail.com>; python-ideas@python.org Subject: Re: [Python-ideas] A GUI for beginners and experts alike https://docs.python-guide.org/scenarios/gui/<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.python-guide.org%2Fscenarios%2Fgui%2F&data=02%7C01%7C%7C64cf0742a0df40c53a1e08d6099a03a8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636706954428482346&sdata=UX1htv%2B%2FcsIXQh4IQvVzY8zcYAl6ZmpVt7m7cwZ0QR4%3D&reserved=0> lists a bunch of great GUI projects for Python. https://github.com/realpython/python-guide/blob/master/docs/scenarios/gui.rst<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frealpython%2Fpython-guide%2Fblob%2Fmaster%2Fdocs%2Fscenarios%2Fgui.rst&data=02%7C01%7C%7C64cf0742a0df40c53a1e08d6099a03a8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636706954428482346&sdata=pOImlRCDPs58hu%2FfqzTkVrG%2FxexLeps2u9YG3rtOckw%3D&reserved=0>
On Fri, 24 Aug 2018 at 15:53, Mike Barnett <mike_barnett@hotmail.com> wrote:
Can a few of you with the vast amount of GUI experience you have, spend 5 minutes and run one of the examples?
I don't have a "vast" amount of GUI experience. But nevertheless I gave it a go. It took less than 5 minutes (which is good).
This will get you started:
pip install PySimpleGUI
Worked.
Then copy and paste a Recipe from the Cookbook.
I went for the simple GUI form. It worked pretty much as expected. The code looks quite nice.
For someone with a dev environment running, it’s a 2 minute exercise. It will make for more focused comments. I’m asking that it actually be tried
Agreed, it was simple to use, and pick up a canned example.
because I don’t think anything like it has been proposed as a GUI framework.
I don't know if that's true, there's a lot of GUI frameworks and I certainly can't say I've tried all of them. This looks nice for simple usages, and would certainly be useful as a project on PyPI (like it is at the moment). I doubt it's mature enough for the stdlib, and I'm certain it's not stable enough (yet) for the stdlib - you'll want to make changes, add features, etc, and once it's in the stdlib that's going to be a lot harder. What's the rush? As far as things I think I'd like to see (and these are just off the top of my head, I've done nothing more than I said above): 1. More documentation - reference docs specifically. I don't see documentation of the call signature for sg.Text, for example. 2. Advanced features - how would I extend it if I have a need that it doesn't cover? For example, a canvas object or an image? 3. It doesn't seem to use native widgets (the buttons have a non-standard look on my Windows PC). Don't feel like you need to do anything about these comments - I rarely if ever use a GUI library, and I've no idea if I'd use this one in future, but if you want "focused comments" beyond "it looks neat and seems like a fine project to go onto PyPI, but I don't think it's necessarily something that should go in the stdlib", then those were what I thought of off the cuff. Hope this is useful, Paul
Liking the comments Paul! Backing up to the beginning, I know I'm far far far away from attempting to become a part of stdlib. However, that does not mean I can't set that as the target and begin to understand the path to get there. My initial post was an attempt to understand this path. I've been getting lots of good information on how to get there, what happens where you do get there, etc. I like it!! Thank you for taking the time to both try it and write your thoughts. Answering a couple of specific questions / remarks: 1. More documentation - reference docs specifically. I don't see documentation of the call signature for sg.Text, for example. A little confused by this one. There are quite a bit of documentation. Did you see the readme on the GitHub and here: https://pysimplegui.readthedocs.io/en/latest/ It has the call information about the Text widget and all the others. Is this what you mean by a Signature? Text(Text, scale=(None, None), size=(None, None), auto_size_text=None, font=None, text_color=None, justification=None) . Text - The text that's displayed size - Element's size auto_size_text - Bool. Change width to match size of text font - Font name and size to use text_color - text color justification - Justification for the text. String - 'left', 'right', 'center' I don't have all of the newest features in there, like the Update method because the doc is for version 2.9 on PyPI. I don't yet have the latest GitHub release in there just yet. You'll find that information instead on the Wiki: https://github.com/MikeTheWatchGuy/PySimpleGUI/wiki/PySimpleGUI-Wiki 2. Advanced features - how would I extend it if I have a need that it doesn't cover? For example, a canvas object or an image? I have Images. Don't have Canvas. Any particular operations desired for the Canvas Element should I have one? 3. It doesn't seem to use native widgets (the buttons have a non-standard look on my Windows PC). The defaults can be easily changed. The default buttons are the one widget that I modify from the system default. The reason was that the system default is a gray button. It pretty much matches the background. If you want your buttons to all look like the system default, slip this line of code at the top: sg.SetOptions(button_color=sg.COLOR_SYSTEM_DEFAULT) Thank you again Paul... I learn something new from every reply 😊 @mike -----Original Message----- From: Paul Moore <p.f.moore@gmail.com> Sent: Friday, August 24, 2018 11:13 AM To: mike_barnett@hotmail.com Cc: Wes Turner <wes.turner@gmail.com>; Jonathan Fine <jfine2358@gmail.com>; Python-Ideas <python-ideas@python.org> Subject: Re: [Python-ideas] A GUI for beginners and experts alike On Fri, 24 Aug 2018 at 15:53, Mike Barnett <mike_barnett@hotmail.com> wrote:
Can a few of you with the vast amount of GUI experience you have, spend 5 minutes and run one of the examples?
I don't have a "vast" amount of GUI experience. But nevertheless I gave it a go. It took less than 5 minutes (which is good).
This will get you started:
pip install PySimpleGUI
Worked.
I went for the simple GUI form. It worked pretty much as expected. The code looks quite nice.
Agreed, it was simple to use, and pick up a canned example.
because I don’t think anything like it has been proposed as a GUI framework.
I don't know if that's true, there's a lot of GUI frameworks and I certainly can't say I've tried all of them. This looks nice for simple usages, and would certainly be useful as a project on PyPI (like it is at the moment). I doubt it's mature enough for the stdlib, and I'm certain it's not stable enough (yet) for the stdlib - you'll want to make changes, add features, etc, and once it's in the stdlib that's going to be a lot harder. What's the rush? As far as things I think I'd like to see (and these are just off the top of my head, I've done nothing more than I said above): 1. More documentation - reference docs specifically. I don't see documentation of the call signature for sg.Text, for example. 2. Advanced features - how would I extend it if I have a need that it doesn't cover? For example, a canvas object or an image? 3. It doesn't seem to use native widgets (the buttons have a non-standard look on my Windows PC). Don't feel like you need to do anything about these comments - I rarely if ever use a GUI library, and I've no idea if I'd use this one in future, but if you want "focused comments" beyond "it looks neat and seems like a fine project to go onto PyPI, but I don't think it's necessarily something that should go in the stdlib", then those were what I thought of off the cuff. Hope this is useful, Paul
On Fri, 24 Aug 2018 at 16:27, Mike Barnett <mike_barnett@hotmail.com> wrote:
Yes, I saw that. It has the call information about the Text widget and all the others. If it does, I didn't spot it. I did say I was skimming - and there's certainly a good amount of documentation. To some extent, I'm being picky here because while I like examples, I have found projects in the past that provide plenty of narrative and examples, but then when you start to want to do something more complicated, the details and specifics are missing.
Yes, precisely. Apologies that I missed it. I don't have all of the newest features in there, like the Update method
Nope. I don't even have a need for a canvas. But what I have found in the past is that *anything* which is a "simple wrapper over X" always ends up in a situation where you need some feature from X that the simple wrapper doesn't cover, and you're left with the unpalatable choice of whether to omit functionality you want to provide, or rewrite your code to use X directly. So my question is more about "if you hit a need for something PySimpleGUI doesn't cover, what are your options?
OK. Personally, I'd argue quite strongly that "match the OS default" is the right default for a GUI library, but that's a hugely subjective area, and you're never going to please everyone. So do whatever works for you. Thank you again Paul... I learn something new from every reply 😊 No problem - glad it helped. Paul
A couple thoughts: You're essentially writing a new API on top of tkINter, you could probably have multiple "back-ends" -- i.e. be able to use the same code with wxPython or PySide behind it. In fact, there was an effort along these lines a few years back: http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ I don't know that it's seen much development lately. Nope. I don't even have a need for a canvas. But what I have found in the
This is key -- and one of the real issues around wrapping multiple GUI back-ends -- you end up having to do a lot of re-implementation of details. In fact, I always thought Pyton_guiu above really suffered from that conceptually. For example, if you used pyton-gui with a wxPython back end, you had: A python wrapper around a python wrapper around a C++ wrapper around each native toolkit. That's a lot of layers! So it's probably better to have a simpler stack -- and at the bottom, you probably need something with at least some C/C++ in it. And there are two options there: 1) re-implement widgets with native basic drawing and event handling. - this is what QT GTK, and TK do 2) Wrap the native widgets - this is what wxWidgets does The advantage of (1) is that most of your code is the same on all platform, widgets behave the same on all platforms, and there is less code to write to support a new platform. The advantage of (2) is that you get more native results -- the widgets ARE native. And it's easier to support the first platform -- you aren't writing a while GUI toolkit. But there is a lot more wrapper code to write for each new platform. And the results ARE going to be a bit platform-dependent in some places (though I've found that I need to write very little platform dependent code with wx) TK is essentially (1), though AIUI, it was originally written for X-windows, and the other platform have an X-windows emulation layer, and then all the TK code works with that. But the issue with TK is that it's really pretty old and krufty. It's great that it comes with the standard library, but now that yu can pip install pySide and wxPython, I'd consider working with one of those. I'd also make sure that you CAN "drop down" into the lower level toolkit fairly smoothly, if you do need something more complex that the basics. Finally -- I'm not sure the desktop is dead, but there is a heck of a lot going on in the browser. And if someone could write a simple GUI for a desktop app, and then easily prt that to a WebApp -- that would be great. I'm sure there are toolkits that do maybe it possible to write pure-python, and have all the javascript pre-written (Or generated) for you. While its not a complete solution, Jupyter Widgets does this within the Jupyter framework, for instance. -CHB
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Yea, software evolves. Things get layered on top of other things. It’s kind of how software works. Perhaps the point is getting lost here on my request to comment on the overall construct and simplicity. Let’s try a different approach… How about a quick example that you code up in your favorite GUI? Try and make it simple enough for a beginner to grasp as much as possible. Here we go: Take 3 numbers as input (A, B, C). Add them together. Display the result in a simple pop-up window. That’s a pretty typical kind of problem for the first few weeks of beginning programming. Maybe first few days. Let’s say I want my program to look and work like other windows programs. I want to show my friends, mom and dad that I can write software too. In this example, I would expect that kind of reasoning that would drive a desire for a GUI. @mike<mailto:mike_barnett@hotmail.com> From: Chris Barker <chris.barker@noaa.gov> Sent: Friday, August 24, 2018 1:39 PM To: Paul Moore <p.f.moore@gmail.com> Cc: Mike Barnett <mike_barnett@hotmail.com>; Python-Ideas <python-ideas@python.org> Subject: Re: [Python-ideas] A GUI for beginners and experts alike A couple thoughts: You're essentially writing a new API on top of tkINter, you could probably have multiple "back-ends" -- i.e. be able to use the same code with wxPython or PySide behind it. In fact, there was an effort along these lines a few years back: http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cosc.canterbury.ac.nz%2Fgreg.ewing%2Fpython_gui%2F&data=02%7C01%7C%7C7c6bd9bc319e45a33d8f08d609e89e3f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636707292023975025&sdata=iPZUt3MlLOPPpwAUHdYbXuV3g8iG2JSDgtzd1W9iCyc%3D&reserved=0> I don't know that it's seen much development lately. Nope. I don't even have a need for a canvas. But what I have found in the past is that *anything* which is a "simple wrapper over X" always ends up in a situation where you need some feature from X that the simple wrapper doesn't cover, and you're left with the unpalatable choice of whether to omit functionality you want to provide, or rewrite your code to use X directly. So my question is more about "if you hit a need for something PySimpleGUI doesn't cover, what are your options? This is key -- and one of the real issues around wrapping multiple GUI back-ends -- you end up having to do a lot of re-implementation of details. In fact, I always thought Pyton_guiu above really suffered from that conceptually. For example, if you used pyton-gui with a wxPython back end, you had: A python wrapper around a python wrapper around a C++ wrapper around each native toolkit. That's a lot of layers! So it's probably better to have a simpler stack -- and at the bottom, you probably need something with at least some C/C++ in it. And there are two options there: 1) re-implement widgets with native basic drawing and event handling. - this is what QT GTK, and TK do 2) Wrap the native widgets - this is what wxWidgets does The advantage of (1) is that most of your code is the same on all platform, widgets behave the same on all platforms, and there is less code to write to support a new platform. The advantage of (2) is that you get more native results -- the widgets ARE native. And it's easier to support the first platform -- you aren't writing a while GUI toolkit. But there is a lot more wrapper code to write for each new platform. And the results ARE going to be a bit platform-dependent in some places (though I've found that I need to write very little platform dependent code with wx) TK is essentially (1), though AIUI, it was originally written for X-windows, and the other platform have an X-windows emulation layer, and then all the TK code works with that. But the issue with TK is that it's really pretty old and krufty. It's great that it comes with the standard library, but now that yu can pip install pySide and wxPython, I'd consider working with one of those. I'd also make sure that you CAN "drop down" into the lower level toolkit fairly smoothly, if you do need something more complex that the basics. Finally -- I'm not sure the desktop is dead, but there is a heck of a lot going on in the browser. And if someone could write a simple GUI for a desktop app, and then easily prt that to a WebApp -- that would be great. I'm sure there are toolkits that do maybe it possible to write pure-python, and have all the javascript pre-written (Or generated) for you. While its not a complete solution, Jupyter Widgets does this within the Jupyter framework, for instance. -CHB 3. It doesn't seem to use native widgets (the buttons have a non-standard look on my Windows PC). The defaults can be easily changed. The default buttons are the one widget that I modify from the system default. The reason was that the system default is a gray button. It pretty much matches the background. If you want your buttons to all look like the system default, slip this line of code at the top: sg.SetOptions(button_color=sg.COLOR_SYSTEM_DEFAULT) OK. Personally, I'd argue quite strongly that "match the OS default" is the right default for a GUI library, but that's a hugely subjective area, and you're never going to please everyone. So do whatever works for you. Thank you again Paul... I learn something new from every reply 😊 No problem - glad it helped. Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org<mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-ideas&data=02%7C01%7C%7C7c6bd9bc319e45a33d8f08d609e89e3f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636707292023975025&sdata=EPc7GJIUUUGJ6WKLuHA1Pd2a0NWg7srxxB3KXxStDyo%3D&reserved=0> Code of Conduct: http://python.org/psf/codeofconduct/<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpython.org%2Fpsf%2Fcodeofconduct%2F&data=02%7C01%7C%7C7c6bd9bc319e45a33d8f08d609e89e3f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636707292023975025&sdata=%2FyRXdyWNKldw3HIHuH805QoHAjedAp5CCV91cntZzpE%3D&reserved=0> -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov<mailto:Chris.Barker@noaa.gov>
On Sat, Aug 25, 2018 at 5:13 AM, Mike Barnett <mike_barnett@hotmail.com> wrote:
Do you mean "beginning GUI programming", or are you saying that this kind of thing should be in someone's first few days of programming overall? I disagree with the latter; for the first days of a programmer's basic training, the REPL is ample. No GUI needed, don't even need input() at that stage. While I would generally teach input() before any GUI toolkit, the opposite decision is also valid, but definitely neither is needed right off the bat. For someone's earliest forays into GUI programming, I would actually *still* not word the challenge that way. I would keep everything in a SINGLE window, because that showcases a major strength of a GUI - that you can interact with it multiple times, rather than being forced into a linear workflow. So here's my alternative challenge: Take two numbers as inputs. Add them together and display them in a third field. Whenever either input is changed, recalculate the output. This requires proper event handling, so it's less likely to create a useless one-liner that has no bearing on real-world code. ChrisA
So here's my alternative challenge: Take two numbers as inputs. Add them together and display them in a third field. Whenever either input is changed, recalculate the output. This requires proper event handling, so it's less likely to create a useless one-liner that has no bearing on real-world code. ------------------------------------ Sure thing... post yours. I'll go ahead and post mine first. Here's the window this code produces. https://user-images.githubusercontent.com/13696193/44604157-02a2ac00-a7b3-11... And here's the code in a more readable form since the email formatting sucks. https://user-images.githubusercontent.com/13696193/44604220-2cf46980-a7b3-11... It's rather, uhm, simple to do.... import PySimpleGUI as gui output = gui.Text('') layout = [ [gui.Text('Enter 2 numbers')], [gui.Text('A'), gui.InputText()], [gui.Text('B'), gui.InputText()], [gui.Text('Answer = '), output], ] form = gui.FlexForm('Realtime Updates', return_keyboard_events=True) form.LayoutAndRead(layout) while True: button, (a,b) = form.Read() try: answer = int(a) + int(b) output.Update(answer) except: pass @mike
I should have mentioned that you need the GitHub version of the code in order to get the keyboard events. Rather than do a pip install you can download this file and put it in your project folder: https://github.com/MikeTheWatchGuy/PySimpleGUI/blob/master/PySimpleGUI.py Sorry for any confusion. I also got a question if this code blocks or is in a spin-loop. The answer is that the posted version blocks until some kind of form input. Should you want to turn the program into one that polls instead of blocks, the loop changes slightly to enable form close detection. It's basically the same with the Read call being replaced by ReadNonBlocking. while True: button, values = form.ReadNonBlocking() if button is None and values is None: break a, b = values try: output.Update(int(a) + int(b)) except: pass @mike -----Original Message----- From: Mike Barnett <mike_barnett@hotmail.com> Sent: Friday, August 24, 2018 3:36 PM To: Chris Angelico <rosuav@gmail.com>; Python-Ideas <python-ideas@python.org> Subject: RE: [Python-ideas] A GUI for beginners and experts alike So here's my alternative challenge: Take two numbers as inputs. Add them together and display them in a third field. Whenever either input is changed, recalculate the output. This requires proper event handling, so it's less likely to create a useless one-liner that has no bearing on real-world code. ------------------------------------ Sure thing... post yours. I'll go ahead and post mine first. Here's the window this code produces. https://user-images.githubusercontent.com/13696193/44604157-02a2ac00-a7b3-11... And here's the code in a more readable form since the email formatting sucks. https://user-images.githubusercontent.com/13696193/44604220-2cf46980-a7b3-11... It's rather, uhm, simple to do.... import PySimpleGUI as gui output = gui.Text('') layout = [ [gui.Text('Enter 2 numbers')], [gui.Text('A'), gui.InputText()], [gui.Text('B'), gui.InputText()], [gui.Text('Answer = '), output], ] form = gui.FlexForm('Realtime Updates', return_keyboard_events=True) form.LayoutAndRead(layout) while True: button, (a,b) = form.Read() try: answer = int(a) + int(b) output.Update(answer) except: pass @mike
Hi Mike, Thanks, this code is nice and short. Is adding 'if button is None: break' to the 'Read' version of your code the right way to make it exit when the main window is closed? (On my machine it enters an infinite loop after I close the main window). For comparison, I tried doing this with PyGObject. I created the UI with glade, which auto-generated the attached XML file. Then I had to write the following code (I had never used Glade or PyGObject before, so apologies if there are mistakes in the following): import gi gi.require_version('Gtk', '3.0') from gi.repository import Gtk def main(): builder = Gtk.Builder() builder.add_from_file("sum.glade") get = builder.get_object a, b, answer, window = get("a"), get("b"), get("answer"), get("window") def update_sum(_entry): try: tanswer = int(a.get_text()) + int(b.get_text()) answer.set_text(str(tanswer)) except ValueError: pass a.connect("changed", update_sum) b.connect("changed", update_sum) window.connect("destroy", Gtk.main_quit) window.show_all() Gtk.main() if __name__ == '__main__': main() Having a visual editor for the UI feels like a plus, and I find the resulting XML verbose but acceptably readable. On the other hand, I like the conciseness of your UI specs. Cheers, Clément. On 2018-08-24 16:38, Mike Barnett wrote:
Hi Mike I'm not sure this thread is python-ideas appropriate, but since the challenge is out, here it is using Kivy. The code and result is at https://gist.github.com/matham/45c4f1fbd8c3fccf6557b3b48356cd50 (image https://gist.githubusercontent.com/matham/45c4f1fbd8c3fccf6557b3b48356cd50/r...). The code is also inlined below. I wrote it to be one file so I used the string version (load_string) for defining the GUI, but the GUI definition could have been written as a separate kv file. I could also have written it using pure python, but that is more verbose and less intuitive. Also, Kivy works on pretty much all platforms (windows, linux, osx, android, ios) and is written in pure python (and cython) on top of opengl. All the best, Matt P.S. here's the inlined code: from kivy.lang import Builder from kivy.app import runTouchApp runTouchApp(Builder.load_string(''' #:import Factory kivy.factory.Factory BoxLayout: orientation: 'vertical' padding: "12dp" spacing: "12dp" Label: text: "Please enter 3 numbers" BoxLayout: spacing: "10dp" Entry: id: a hint_text: "A" Entry: id: b hint_text: "B" Entry: id: c hint_text: "C" Label: text: "The sum is {}".format(a.val + b.val + c.val) <Entry@TextInput>: input_filter: "float" val: float(self.text) if self.text else 0 ''')) On Fri, Aug 24, 2018 at 5:28 PM Clément Pit-Claudel <cpitclaudel@gmail.com> wrote:
Nice Matt! Thanks for taking the time to code it up! It’s great to see examples like these. @mike<mailto:mike_barnett@hotmail.com> From: Python-ideas <python-ideas-bounces+mike_barnett=hotmail.com@python.org> On Behalf Of Matthew Einhorn Sent: Friday, August 24, 2018 7:51 PM To: python-ideas@python.org Subject: Re: [Python-ideas] A GUI for beginners and experts alike Hi Mike I'm not sure this thread is python-ideas appropriate, but since the challenge is out, here it is using Kivy. The code and result is at https://gist.github.com/matham/45c4f1fbd8c3fccf6557b3b48356cd50<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fmatham%2F45c4f1fbd8c3fccf6557b3b48356cd50&data=02%7C01%7C%7Ce79abd06c77544c33e7008d60a1c9d95%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636707515345906031&sdata=Uwr%2FzUCh17hCHSpIsTzA36iVmFpkE%2FgWb7i8DeABhik%3D&reserved=0> (image https://gist.githubusercontent.com/matham/45c4f1fbd8c3fccf6557b3b48356cd50/raw/dbbf74f17ad4beab49f022bbf43fcc72ff725084/kivy_gui.png<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.githubusercontent.com%2Fmatham%2F45c4f1fbd8c3fccf6557b3b48356cd50%2Fraw%2Fdbbf74f17ad4beab49f022bbf43fcc72ff725084%2Fkivy_gui.png&data=02%7C01%7C%7Ce79abd06c77544c33e7008d60a1c9d95%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636707515345916042&sdata=s22vKrCMVzvL76RNm%2FQtU9sJMafFp%2By3i1ZQqD3167E%3D&reserved=0>). The code is also inlined below. I wrote it to be one file so I used the string version (load_string) for defining the GUI, but the GUI definition could have been written as a separate kv file. I could also have written it using pure python, but that is more verbose and less intuitive. Also, Kivy works on pretty much all platforms (windows, linux, osx, android, ios) and is written in pure python (and cython) on top of opengl. All the best, Matt P.S. here's the inlined code: from kivy.lang import Builder from kivy.app import runTouchApp runTouchApp(Builder.load_string(''' #:import Factory kivy.factory.Factory BoxLayout: orientation: 'vertical' padding: "12dp" spacing: "12dp" Label: text: "Please enter 3 numbers" BoxLayout: spacing: "10dp" Entry: id: a hint_text: "A" Entry: id: b hint_text: "B" Entry: id: c hint_text: "C" Label: text: "The sum is {}".format(a.val + b.val + c.val) <Entry@TextInput>: input_filter: "float" val: float(self.text) if self.text else 0 ''')) On Fri, Aug 24, 2018 at 5:28 PM Clément Pit-Claudel <cpitclaudel@gmail.com<mailto:cpitclaudel@gmail.com>> wrote: Hi Mike, Thanks, this code is nice and short. Is adding 'if button is None: break' to the 'Read' version of your code the right way to make it exit when the main window is closed? (On my machine it enters an infinite loop after I close the main window). For comparison, I tried doing this with PyGObject. I created the UI with glade, which auto-generated the attached XML file. Then I had to write the following code (I had never used Glade or PyGObject before, so apologies if there are mistakes in the following): import gi gi.require_version('Gtk', '3.0') from gi.repository import Gtk def main(): builder = Gtk.Builder() builder.add_from_file("sum.glade") get = builder.get_object a, b, answer, window = get("a"), get("b"), get("answer"), get("window") def update_sum(_entry): try: tanswer = int(a.get_text()) + int(b.get_text()) answer.set_text(str(tanswer)) except ValueError: pass a.connect("changed", update_sum) b.connect("changed", update_sum) window.connect("destroy", Gtk.main_quit) window.show_all() Gtk.main() if __name__ == '__main__': main() Having a visual editor for the UI feels like a plus, and I find the resulting XML verbose but acceptably readable. On the other hand, I like the conciseness of your UI specs. Cheers, Clément. On 2018-08-24 16:38, Mike Barnett wrote:
_______________________________________________ Python-ideas mailing list Python-ideas@python.org<mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-ideas&data=02%7C01%7C%7Ce79abd06c77544c33e7008d60a1c9d95%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636707515345986107&sdata=l0h7XMzPGMOBsm%2F7XOzlPkPgCgKHPJLY9iJDam1KhAk%3D&reserved=0> Code of Conduct: http://python.org/psf/codeofconduct/<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpython.org%2Fpsf%2Fcodeofconduct%2F&data=02%7C01%7C%7Ce79abd06c77544c33e7008d60a1c9d95%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636707515345996112&sdata=34iqzRJ7AfpiElm07U9HGv8sqvgzkwOuOxDj6tDQztk%3D&reserved=0>
while True: button, (a,b) = form.Read() try: answer = int(a) + int(b) output.Update(answer) except: pass Whoa! You really want people to write their own event loop? That seems like a bad idea to me. If you want people to not have to think about events much, maybe look at traitsui for ideas. http://docs.enthought.com/traitsui/ -CHB
Here are some PyGUI versions of the ABC Challenge. #---------------- Modal -------------------- from GUI import ModalDialog, Label, TextField, Row, Column, Grid from GUI.StdButtons import DefaultButton, CancelButton from GUI.Alerts import note_alert a = TextField(width = 100) b = TextField(width = 100) c = TextField(width = 100) buttons = Row([DefaultButton(), CancelButton()]) dlog = ModalDialog(title = "ABC Challenge") dlog.add(Column([ Grid([ [Label("A"), a], [Label("B"), b], [Label("C"), c], ]), buttons], padding = (10, 10))) dlog.shrink_wrap() if dlog.present(): note_alert("Sum = %s" % (int(a.text) + int(b.text) + int(c.text))) #---------------- Non-Modal ------------------ from GUI import Window, Label, TextField, Grid, application def update(): try: c.text = str(int(a.text) + int(b.text)) except ValueError: c.text = "" a = TextField(width = 100, text_changed_action = update) b = TextField(width = 100, text_changed_action = update) c = TextField(width = 100, editable = False) win = Window(title = "ABC Challenge") win.add( Grid([ [Label("A"), a], [Label("B"), b], [Label("A + B"), c], ], padding = (10, 10))) win.shrink_wrap() win.show() application().run() -- Greg
Chris Barker via Python-ideas wrote:
It hasn't, sorry to say. Turns out that writing and maintaining what is effectively 3 complete GUI toolkits takes a more copious supply of round tuits than I have at the moment. :-(
If you're talking about my PyGUI project, using it with wPython doesn't really make sense. I specifically wanted to avoid the multiple-wrapper problem, so I decided *not* to wrap any existing cross-platform GUI toolkit. The goal is to provide exactly one high-quality implementation for each platform, with as few layers as practicable between the Python API and the platform's native GUI facilities. One result of that is that PyGUI is not really structured as a "front end" and "back end" with a defined interface between them. There is generic code and platform-specific code, but they're fairly closely intertwined. Implementations on top of wxPython, Qt etc. could probably be created, but I won't be doing it myself, because it would take a lot of work and I don't think it would be necessary or desirable.
PyGUI does (2).
Yeah, X Windows is a bit special, because there is no such thing os a "native" look and feel for widgets on X -- there have been multiple GUI toolkits for X from the beginning, each with its own style. So Tk inventing a new one all of its own wasn't really a bad thing at the time.
I'd also make sure that you CAN "drop down" into the lower level toolkit fairly smoothly, if you do need something more complex that the basics.
PyGUI provides everything you need to create a custom widget, without needing to go down to a lower level. You could also create a wrapper for a native widget that PyGUI doesn't already provide, but the techniques for doing so are currently undocumented and might change between releases.
Pyjamas seems to be something like that: https://pypi.org/project/Pyjamas/ -- Greg
If you're talking about my PyGUI project, using it with wPython doesn't really make sense.
Now that you say that, I think I’m mingling memories — there was another project that attempted to wrap TKInter, wxPython, QT .. I always thought that was ill advised.
So kinda like wxWidgets but in Python — which would be nice. wxPython definitely suffers from its C++ underpinnings.
Implementations on top of wxPython, Qt etc. could probably be created,
QT might make some sense— you need something on top of X, don’t you?
In that context, I was thinking about the OP’s concept— very high level, pretty much declarative. It’s going to run into limitations fast. So there should be s way to customize user interaction. Too bad all the cool kids are doing web dev these days — hard to get help with a desktop GUI project :-(
Pyjamas seems to be something like that:
Or it was 6 years ago :-( -CHB
Op za 25 aug. 2018 02:28 schreef Chris Barker - NOAA Federal via Python-ideas <python-ideas@python.org>:
Too bad all the cool kids are doing web dev these days — hard to get help with a desktop GUI project :-(
Pywebview seems interesting, uses a platform webview to put up the UI; https://github.com/r0x0r/pywebview But not so newbie-friendly I am afraid... Stephan
It’s fascinating just how many packages are being dragged out for examination or clobbering other than the one that I asked for assistance/help on. I see the code of conduct link in the thread. Perhaps a review would be helpful. Unsubscribing from this mess. “Python Ideas” ? @mike<mailto:mike_barnett@hotmail.com> From: Python-ideas <python-ideas-bounces+mike_barnett=hotmail.com@python.org> On Behalf Of Stephan Houben Sent: Friday, August 24, 2018 9:07 PM To: Chris Barker <chris.barker@noaa.gov> Cc: Python-Ideas <python-ideas@python.org> Subject: Re: [Python-ideas] A GUI for beginners and experts alike Op za 25 aug. 2018 02:28 schreef Chris Barker - NOAA Federal via Python-ideas <python-ideas@python.org<mailto:python-ideas@python.org>>: Too bad all the cool kids are doing web dev these days — hard to get help with a desktop GUI project :-( Pywebview seems interesting, uses a platform webview to put up the UI; https://github.com/r0x0r/pywebview<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fr0x0r%2Fpywebview&data=02%7C01%7C%7C612446e8a7ed454f7fdf08d60a273632%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636707560853860413&sdata=%2FkLW%2FZ%2FAxu8X5j9bq3KKoHn%2F6oU3pNjlyDkbo%2B2Mk7E%3D&reserved=0> But not so newbie-friendly I am afraid... Stephan
Pyjamas seems to be something like that:
Or it was 6 years ago :-( -CHB _______________________________________________ Python-ideas mailing list Python-ideas@python.org<mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-ideas&data=02%7C01%7C%7C612446e8a7ed454f7fdf08d60a273632%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636707560853860413&sdata=jHvQjyD%2FSyzob%2BNwRY77jqXEnwVZ%2FDov3btwggonjyk%3D&reserved=0> Code of Conduct: http://python.org/psf/codeofconduct/<https://eur04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpython.org%2Fpsf%2Fcodeofconduct%2F&data=02%7C01%7C%7C612446e8a7ed454f7fdf08d60a273632%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636707560853860413&sdata=j2HJc7JhWU9KIyBbGgO1lBXNLrvMiEhMN8nB%2Fxu%2FkSA%3D&reserved=0>
Mike Barnett wrote:
Unsubscribing from this mess. “Python Ideas” ?
We didn't mean to drive you away! Python discussions have a tendency to roam far and wide. It doesn't mean we're not interested in what you have to say. Any new package is naturally going to invite comparisons with similar things that have been done before. That's not a bad thing -- it's always good to see what others have done in the same field. Although your package is unlikely to be put into the stdlib any time soon, it would be a fine thing to have on PyPI, and I'm sure there are people here willing to help you develop it. You may just need to be prepared to ignore some digressions. -- Greg
On Fri, 24 Aug 2018 at 18:18 Mike Barnett <mike_barnett@hotmail.com> wrote:
Unsubscribing from this mess. “Python Ideas” ?
So I code of conduct review of this thread would suggest that your opening email was inappropriate by being misleading thanks to sounding like you were a neutral third-party to your library (luckily you admit to this later, but it shouldn't have been done to begin with). The tone was okay, but you state a lot of opinions as if they are fact, e.g. "GUI code is far from compact", "you've got to be skilled to use it", etc. Those are all opinions expressed as facts which can be misleading and potentially insulting depending on who you're talking to (i.e. some of the people who have worked very hard to make tkinter even work are on this mailing list). Your initial email was also off-topic. This mailing list is about ideas to changing Python, not announcements. Once again you later mention you wanted to start a discussion about getting PySimpleGUI into the stdlib, but it would have been nicer to mention that from the beginning as people would have pointed you at https://devguide.python.org/stdlibchanges/#adding-a-new-module and that would have answered your question. But as part of getting a module into the stdlib, alternatives will be considered (especially GUI libraries as this topic is not a new one and there are many options available, all with their own approaches). So if you actual intent was to get PySimpleGUI into the stdlib some day then discussing other libraries isn't off-topic at all as you will eventually need to address why your library is better than others. Being upset that people are doing their due diligence by bringing up alternatives as part of your request about talking about eventually adding PySimpleGUI to the stdlib is not a CoC violation at all and honestly your tone in your last email is a much bigger concern and deserves the warning --which I am giving -- more than how anyone else has behaved. -Brett
Didn't see the Qt version of the adding together with GUI yet, so here I have a minimalist version: import sys from PyQt5.QtWidgets import QWidget, QSpinBox, QLabel, QApplication, QHBoxLayout app = QApplication(sys.argv) w = QWidget() w.setLayout(QHBoxLayout()) spinOne = QSpinBox(w) spinTwo = QSpinBox(w) output = QLabel(w) def add(): output.setText(str(spinOne.value() + spinTwo.value())) spinOne.valueChanged.connect(add) spinTwo.valueChanged.connect(add) w.layout().addWidget(spinOne) w.layout().addWidget(spinTwo) w.layout().addWidget(output) w.show() app.exec() And here a version how I'd actually like to see it if written seriously: import sys from PyQt5.QtCore import pyqtSignal, pyqtSlot from PyQt5.QtWidgets import QWidget, QSpinBox, QLabel, QApplication, QHBoxLayout class AddWidget(QWidget): newValue = pyqtSignal(str) def __init__(self, parent=None): super().__init__(parent) self.setLayout(QHBoxLayout(self)) self.firstInput = QSpinBox(self) self.layout().addWidget(self.firstInput) self.firstInput.valueChanged.connect(self.addTogether) self.secondInput = QSpinBox(self) self.layout().addWidget(self.secondInput) self.secondInput.valueChanged.connect(self.addTogether) self.output = QLabel(self) self.layout().addWidget(self.output) self.newValue.connect(self.output.setText) @pyqtSlot(int) def addTogether(self, arg): self.newValue.emit(str(self.firstInput.value() + self.secondInput.value())) if __name__ == "__main__": app = QApplication(sys.argv) w = AddWidget() w.show() app.exec() I'll fully admit it takes a few lines more code to actually do it right compared to the other mentioned GUI frameworks, but it shows nicely how it's really a toolbox full of stuff you can use to assemble what you need.
Chris Barker - NOAA Federal wrote:
You're probably thinking of "anygui" (named in the spirit of "anydbm"). As far as I remember, it never really got off the ground.
QT might make some sense— you need something on top of X, don’t you?
Linux is currently covered by a Gtk implementation, which seems to be about as close as you get to a "native" GUI toolkit on Linux. X-based systems without Gtk are currently out ofscope -- but contributions are always welcome! -- Greg
On 2018-08-24 16:27, Mike Barnett wrote:
Liking the comments Paul!
[snip]
Static text is usually called a "label" in the GUIs I've used, including tkinter. [snip]
A canvas can contain images, lines and shapes, which is useful for diagrams and drawings.
Looking at the page on PyPI, those coloured buttons do look odd to me. I think the default should be the system default. Also, I think those buttons labelled "Submit" should be labelled "OK".
On Fri, Aug 24, 2018 at 10:07 AM, MRAB <python@mrabarnett.plus.com> wrote:
A canvas can contain images, lines and shapes, which is useful for diagrams and drawings.
And the TK Canvas is kinda the "killer app" of TK. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On 8/24/2018 4:12 AM, Wes Turner wrote:
There was a thread about deprecating Tk awhile back.
That was an intentionally annoying troll post, not a serious proposal. Please don't refer to it as if it were.
asyncio event loop support would be great for real world apps.
This is unclear. Any app that wants to use asyncio can import it. Easily using async and await *without* using asyncio is a different matter. -- Terry Jan Reedy
On Friday, August 24, 2018, Terry Reedy <tjreedy@udel.edu> wrote:
stdlib inclusion entails years of support commitment, backwards incompatibility, waiting for a Python release to occur, and withstanding phd-level challenges.
asyncio event loop support would be great for real world apps.
This is unclear. Any app that wants to use asyncio can import it.
Easily using async and await *without* using asyncio is a different matter.
asyncio support is only so useful when the GUI widget toolkit blocks (doesn't use async or await
ipywidgets and toga* implementations of the ABC demo: | source: https://github.com/westurner/guidemo # ipywidgetsdemo/ipywidgets_abc_demo.py (.ipynb) # # ipywidgets ABC demo # - Update an output widget with the sum of two input widgets when the 'change' event fires # In[1]: # https://ipywidgets.readthedocs.io/en/latest/examples/Using%20Interact.html # https://ipywidgets.readthedocs.io/en/latest/examples/Widget%20List.html from ipywidgets import interact import ipywidgets as widgets def add(x, y): return sum((x,y)) widget_x = widgets.IntText(value=0, description='#1') widget_y = widgets.IntText(value=0, description='#2') interact(add, x=widget_x, y=widget_y) # In[2]: # https://ipywidgets.readthedocs.io/en/latest/examples/Widget%20Events.html#Re... from IPython.display import display from ipywidgets import interact import ipywidgets as widgets widget_x = widgets.IntText(value=0, description='#1') widget_y = widgets.IntText(value=0, description='#2') widget_sigma = widgets.IntText(value=0, description='sum') def add_event(event): widget_sigma.value = sum((widget_x.value, widget_y.value)) widget_x.observe(add_event, names='value') widget_y.observe(add_event, names='value') display(widgets.HBox([widget_x, widget_y, widget_sigma])) # togaabcdemo/app.py import toga from toga.style import Pack from toga.style.pack import COLUMN, ROW class TogaAbcDemo(toga.App): def add_numbers(self, widget): # TODO: validate that n*_input.value are numbers n1, n2 = self.n1_input.value, self.n2_input.value n3 = sum(n1, n2) if ((n1 is not None) and (n2 is not None)) else None print("%r + %r = %r" % (n1, n2, n3)) self.n3_input.value = n3 def startup(self): # Create a main window with a name matching the app self.main_window = toga.MainWindow(title=self.name) # Create a main content box main_box = toga.Box() self.n1_input = toga.TextInput( placeholder='#1', on_change=self.add_numbers) self.n2_input = toga.TextInput( placeholder='#2', on_change=self.add_numbers) self.n3_input = toga.TextInput( placeholder='Sum', readonly=True) main_box.add(self.n1_input) main_box.add(self.n2_input) main_box.add(self.n3_input) # Add the content on the main window self.main_window.content = main_box # Show the main window self.main_window.show() def main(): return TogaAbcDemo('Toga ABC Demo', 'org.westurner.togaabcdemo.togaabcdemo') On Fri, Aug 24, 2018 at 4:12 AM Wes Turner <wes.turner@gmail.com> wrote:
Hi Mike, and welcome! On Thu, Aug 23, 2018 at 06:49:48PM +0000, Mike Barnett wrote:
Python has dropped the GUI ball, at least for beginners (in my opinion)
Sadly I think that GUIs is one area where Python has not excelled.
I've been using Python for 20 years, and I'm still intimidated by Tkinter's learning curve, let alone products like wxPython.
Provided they have tkinter.
I am not seeking fame, recognition, or any other personal gain.
Good, because you won't get it :-)
Acceptance for *what* precisely? I appreciate your enthusiasm, but I think you forgot to actually make a proposal. Is this an attempt to draw people's attention to PySimpleGUI? To start a dialog about finding something better? Do you want PySimpleGUI to be added to the Python standard library? (If so, then I don't understand the comment about pip install and dropping the PySimpleGUI into people's project folder -- that isn't necessary if its a std lib module.) If this is about adding PySimpleGUI to the std lib, then there's a few things to keep in mind: * We don't conscript library authors; they have to volunteer, or at least agree, to donate their library to the Python std lib. Have you approached the author of PySimpleGUI to see what he or she has to think about this idea? * Even if they are agreeable, we don't take software until it has proven itself, both that there is a need for it and that it is the right solution. Being in the std lib is not for every project. It means following Python's release cycle, which is too slow for some projects and too fast for others. It also means being limited by some rather hard backwards- compatibility constraints, and a cultural reluctance to grow libraries beyond a certain size. Sometimes even adding a single function to a library can be controversial. Projects in their early days that are still experimenting with their interfaces, or intending to add new functionality, are generally not a good fit to the std lib. There's a saying that the standard library is where good libraries go to die. While that's somewhat of an exaggeration (there's plenty of life left in the std lib) it is true that libraries in the std lib should offer a stable interface and functionality. -- Steve
Wow, Thank you Steve! This is exactly the kind of information I was hoping for!!
Acceptance for *what* precisely?
That is a great question... you're right shoulda asked a specific question. I would like to see if become something official so that it gets out to people automatically. Perhaps a stdlib module. I should have also mentioned I'm the author. That 3rd person thing didn't sound right. Definitely want to stress that the current implementation is a prototype for something official. It would need to be rewritten should it be submitted. As it is now it likely needs refactoring to get the interface to be PEP8 compliant. If it's possible to look past some of those blemishes and more at what the interface accomplishes and how it goes about doing it. There are a number of Python-like aspects of the project that fit within a learning environment. These concepts are all touched upon in a natural way: * The use of Lists, Dictionaries for return values. * The window/form is specified using a List layout that visibly resembles the GUI layout. * Widgets are configured in place by using optional parameters. * The calls collapse down into a single-line of Python code for a custom GUI should you want to write it that way. The other questions: Is this an attempt to draw people's attention to PySimpleGUI? To start a dialog about finding something better? Yes - I want to begin the process of getting some attention... get some ideas on how I can get in front of audiences that may be interested. I don't want to spam the Python world, but I do want to help people add a nice front-end to their programs. (.... then I don't understand the comment about pip install and dropping the PySimpleGUI into people's project folder -- that isn't necessary if its a std lib module.) The single-file aspect is a detail about today's implementation. Thank you for asking helpful questions. @mike
On 24/08/2018 02:04, Mike Barnett wrote:
Mike, A couple of points: 1. If you were to package PySimpleGUI into a pip installable library then this allows anybody who pip installs it to import and use it without copying it anywhere, (just like it being in the stdlib other than the pip step). 2. You can add a package to pypi, and improve on it & its documentation, without needing a PEP or any of the rigmarole needed to get it into the stdlib. 3. Once a pypi package gets a) stable & b) the traction for mass use it may be considered to inclusion into the standard lib, (or go there to die as any changes become very slow & constrained. 4. Python Ideas is probably not the best channel to publicise such a package. So all in all I would suggest concentrating on that initially. There are already 2 ways of turning a python program that uses argparse into a GUI, (Gooey for wx & Quicken for QT IIRC), with minimal modification. There are a lot of good arguments for teaching people to use argparse and to write their code to be able to run from the command line but there is not a mechanism that I am aware of for turning argparse based code into a TK GUI this might be a fruitful area to look at. It might even be a really great idea to get in touch with the authors of the two package mentioned to see if it might not be possible to come up with a unified library that allowed something like: ``` import pyUniGUI as gui gui.set_backend(tk) # or qt or wx (maybe others) @gui.from_argparse def parse_args(): """ Parse command line arguments (also defines GUI). """ ... ``` Can I also suggest taking a look at the Enthought Traits & TraitsUI (https://github.com/enthought/traitsui) packages to see what can be done for automating GUI generation. TraitsUI can use wx or QT (via various bindings) as GUI backends, (I know that is an unusual turn of phrase), but adding a TK backend would be a great move. -- Steve (Gadget) Barnes Any opinions in this message are my personal opinions and do not reflect those of my employer. --- This email has been checked for viruses by AVG. https://www.avg.com
On Thu, Aug 23, 2018 at 11:59 PM Steve Barnes <gadgetsteve@live.co.uk> wrote:
I started working on a project that does that a few years ago. It requires that you provide a function that takes an argparse.Namespace, and then it can make a GUI using tkinter. The code is on GitHub: https://github.com/codypiersall/cligui. The license is MIT. Example script using cligui: ``` # Makes a GUI appear. How fortunate! import argparse import cligui def get_parser(): """Create a parser that does all the best things.""" p = argparse.ArgumentParser(description='such a good program') p.add_argument('infile') p.add_argument('outfile') return p def do_the_best_things(args): """This does the best things. Note: "args" is an argparse.Namespace -- the thing you get back whenever you call argparse.ArgumentParser().parse_args(). """ print('got args', args) def main(): """This incredible function will make a GUI appear. Remarkable!""" p = get_parser() # call cligui.CliGui with the parser, and a function that takes an # argparse.Namespace as its argument. cligui.CliGui(p, do_the_best_things) if __name__ == '__main__': main() ``` For background: the goal was to be able to let my less-technical coworkers use scripts that I had written; but then I got a job elsewhere and stopped working on this. Cody
I think that this is a very interesting project. Having a simple way to do GUI's is great for beginners and experienced people. What I'd suggest is that this would be better if you could extent beyond the simple using the underlying toolkit. But I'd not use tk as the base I'd use PyQt, IMHO, its the best toolkit for building GUIs with python. I'd love to start with the simple and build on top the complex stuff only when I need it. Barry
On Fri, Aug 24, 2018 at 12:42 PM Barry Scott <barry@barrys-emacs.org> wrote:
While I agree that PyQt is better than tkinter, and I even wrote a simple interface for it (https://github.com/aroberge/easygui_qt), I think that any "single install, easy to use" GUI toolkit should be based on what's in the standard library and, for better or for worse, that is tkinter. So I think that the right choice was made for PySimpleGUI. André
Hi Mike Thank you for your message. I agree, in broad terms, with your statement of goals, and welcome their being discussed here. Python has important roots are in education. We benefit from taking care of them. Here is what I take to be your statement of goals.
My preferred approach to solve this problem is to use a web browser as the GUI platform, and communicate with it using a simple local server. I've been learning about http://elm-lang.org/. It impresses me. Here's some URLs. http://elm-lang.org/ https://guide.elm-lang.org/ https://ellie-app.com/37gXN5G4T2sa1 http://elm-lang.org/blog/time-travel-made-easy However, I don't want to have this thread turn into a discussion of elm. Rather, I'm putting forward using HTML5 in a browser as the GUI platform, rather than tkinter. And elm is one of several examples we can learn from. Thank you for your work on PySimpleGUI, and for your statement of goals. with best regards Jonathan
Maybe we're on different planes? I'm talking about 5 lines of Python code to get a custom layout GUI on the screen: import PySimpleGUI as sg form = sg.FlexForm('Simple data entry form') # begin with a blank form layout = [ [sg.Text('Please enter your Name, Address, Phone')], [sg.Text('Name', size=(15, 1)), sg.InputText('1', key='name')], [sg.Text('Address', size=(15, 1)), sg.InputText('2', key='address')], [sg.Text('Phone', size=(15, 1)), sg.InputText('3', key='phone')], [sg.Submit(), sg.Cancel()] ] button, values = form.LayoutAndRead(layout) gets you this window: https://user-images.githubusercontent.com/13696193/43934091-8100e29a-9c1b-11... @mike -----Original Message----- From: Jonathan Fine <jfine2358@gmail.com> Sent: Thursday, August 23, 2018 4:14 PM To: Mike Barnett <mike_barnett@hotmail.com> Cc: python-ideas@python.org Subject: Re: [Python-ideas] A GUI for beginners and experts alike Hi Mike Thank you for your message. I agree, in broad terms, with your statement of goals, and welcome their being discussed here. Python has important roots are in education. We benefit from taking care of them. Here is what I take to be your statement of goals.
My preferred approach to solve this problem is to use a web browser as the GUI platform, and communicate with it using a simple local server. I've been learning about https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Felm-lang.or.... It impresses me. Here's some URLs. https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Felm-lang.or... https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fguide.elm-... https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fellie-app.... https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Felm-lang.or... However, I don't want to have this thread turn into a discussion of elm. Rather, I'm putting forward using HTML5 in a browser as the GUI platform, rather than tkinter. And elm is one of several examples we can learn from. Thank you for your work on PySimpleGUI, and for your statement of goals. with best regards Jonathan
Maybe we're on different planes?
I'm talking about 5 lines of Python code to get a custom layout GUI on
Hi Mike Thank you for your prompt response. You wrote the screen:
key='address')],
[sg.Text('Phone', size=(15, 1)), sg.InputText('3',
key='phone')],
The execution of this code, depends on PySimpleGUI, which in turn depends on tkinter, which is in turn a thin layer on top of Tcl/Tk. And Tcl/Tk provides the GUI layer. (See https://docs.python.org/3/library/tk.html.) I'm suggest that sometimes it may be better to use HTML5 to provide the GUI layer. I pointed to Elm, to show how powerful HTML5 has become. Put another way, I'm suggesting that instead of
import PySimpleGUI as sg
we are able to use
import HtmlSimpleGUI as sg
for a module HtmlSimpleGUI that, sadly, hasn't been written yet! However, mine is just one voice, and I have little more to say. If you don't mind, I'll leave this conversation now. with best regards Jonathan
For me, it would even make more sense to split the project into two parts: - the description library, which could roughly enable the syntax you propose (but with another import) to define what your interface should look like. - rendering plugins to display the form in specific formats/type of displays. So you would have a tkinter (or whatever) plugin for a simple GUI, an bottle/html plugin (for example) to display your interface in a web browser, a plugin with a mix of those two to display the html form in a webview component, a plugin to display the form on a tiny touch enabled screen attached to your raspberry pi's GPIO pins or to your micropython module, etc. And if it makes sense (you didn't use any form element that is not compatible with a text-only display), a plugin to display your form in the CLI. This would allow to detach the content from the presentation, and allow to make a project evolve depending on the needs without having to rewrite everything. -Brice
On Thursday, August 23, 2018, Jonathan Fine <jfine2358@gmail.com> wrote:
BeeWare uses Toga (a widget toolkit) and Briefcase (a build tool) to build native GUIs and SPA web apps
Briefcase can build Django apps. https://pybee.org https://pybee.org/project/using/ https://briefcase.readthedocs.io/en/latest/tutorial/tutorial-0.html https://toga.readthedocs.io/en/latest/tutorial/tutorial-0.html It's definitely not a single file module, though. Bottle is a single file web framework ('microframework'); but it doesn't have a widget toolkit. Web development is not as easy to learn as a simple GUI api for beginners (and then learning what to avoid in terms of websec is a lot to learn). There was a thread about deprecating Tk awhile back. There also I think I mentioned that asyncio event loop support would be great for real world apps.
https://docs.python-guide.org/scenarios/gui/ lists a bunch of great GUI projects for Python. https://github.com/realpython/python-guide/blob/master/docs/scenarios/gui.rs... On Friday, August 24, 2018, Wes Turner <wes.turner@gmail.com> wrote:
I saw this list prior to writing PySimpleGUI. My goal is for this architecture to be on that list down the road. Don’t care if it’s this package, only that something similar exist and is known in the community. There is a gaping hole between command line and a simple GUI on the screen. It’s a huge chasm. Here’s a fun Python-like way of using the package. You can collapse a custom form down to a single line of (readable) code. button, (filename,) = sg.FlexForm('Get filename example'). LayoutAndRead([[sg.Text('Filename')], [sg.Input(), sg.FileBrowse()], [sg.OK(), sg.Cancel()] ]) Or maybe break it up: button, (filename,) = sg.FlexForm('Get filename example').LayoutAndRead( [[sg.Text('Filename')], [sg.Input(), sg.FileBrowse()], [sg.OK(), sg.Cancel()]]) Can a few of you with the vast amount of GUI experience you have, spend 5 minutes and run one of the examples? This will get you started: pip install PySimpleGUI Then copy and paste a Recipe from the Cookbook. https://pysimplegui.readthedocs.io/en/latest/cookbook/ For someone with a dev environment running, it’s a 2 minute exercise. It will make for more focused comments. I’m asking that it actually be tried because I don’t think anything like it has been proposed as a GUI framework. @mike<mailto:mike_barnett@hotmail.com> From: Wes Turner <wes.turner@gmail.com> Sent: Friday, August 24, 2018 4:17 AM To: Jonathan Fine <jfine2358@gmail.com> Cc: Mike Barnett <mike_barnett@hotmail.com>; python-ideas@python.org Subject: Re: [Python-ideas] A GUI for beginners and experts alike https://docs.python-guide.org/scenarios/gui/<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.python-guide.org%2Fscenarios%2Fgui%2F&data=02%7C01%7C%7C64cf0742a0df40c53a1e08d6099a03a8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636706954428482346&sdata=UX1htv%2B%2FcsIXQh4IQvVzY8zcYAl6ZmpVt7m7cwZ0QR4%3D&reserved=0> lists a bunch of great GUI projects for Python. https://github.com/realpython/python-guide/blob/master/docs/scenarios/gui.rst<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frealpython%2Fpython-guide%2Fblob%2Fmaster%2Fdocs%2Fscenarios%2Fgui.rst&data=02%7C01%7C%7C64cf0742a0df40c53a1e08d6099a03a8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636706954428482346&sdata=pOImlRCDPs58hu%2FfqzTkVrG%2FxexLeps2u9YG3rtOckw%3D&reserved=0>
On Fri, 24 Aug 2018 at 15:53, Mike Barnett <mike_barnett@hotmail.com> wrote:
Can a few of you with the vast amount of GUI experience you have, spend 5 minutes and run one of the examples?
I don't have a "vast" amount of GUI experience. But nevertheless I gave it a go. It took less than 5 minutes (which is good).
This will get you started:
pip install PySimpleGUI
Worked.
Then copy and paste a Recipe from the Cookbook.
I went for the simple GUI form. It worked pretty much as expected. The code looks quite nice.
For someone with a dev environment running, it’s a 2 minute exercise. It will make for more focused comments. I’m asking that it actually be tried
Agreed, it was simple to use, and pick up a canned example.
because I don’t think anything like it has been proposed as a GUI framework.
I don't know if that's true, there's a lot of GUI frameworks and I certainly can't say I've tried all of them. This looks nice for simple usages, and would certainly be useful as a project on PyPI (like it is at the moment). I doubt it's mature enough for the stdlib, and I'm certain it's not stable enough (yet) for the stdlib - you'll want to make changes, add features, etc, and once it's in the stdlib that's going to be a lot harder. What's the rush? As far as things I think I'd like to see (and these are just off the top of my head, I've done nothing more than I said above): 1. More documentation - reference docs specifically. I don't see documentation of the call signature for sg.Text, for example. 2. Advanced features - how would I extend it if I have a need that it doesn't cover? For example, a canvas object or an image? 3. It doesn't seem to use native widgets (the buttons have a non-standard look on my Windows PC). Don't feel like you need to do anything about these comments - I rarely if ever use a GUI library, and I've no idea if I'd use this one in future, but if you want "focused comments" beyond "it looks neat and seems like a fine project to go onto PyPI, but I don't think it's necessarily something that should go in the stdlib", then those were what I thought of off the cuff. Hope this is useful, Paul
Liking the comments Paul! Backing up to the beginning, I know I'm far far far away from attempting to become a part of stdlib. However, that does not mean I can't set that as the target and begin to understand the path to get there. My initial post was an attempt to understand this path. I've been getting lots of good information on how to get there, what happens where you do get there, etc. I like it!! Thank you for taking the time to both try it and write your thoughts. Answering a couple of specific questions / remarks: 1. More documentation - reference docs specifically. I don't see documentation of the call signature for sg.Text, for example. A little confused by this one. There are quite a bit of documentation. Did you see the readme on the GitHub and here: https://pysimplegui.readthedocs.io/en/latest/ It has the call information about the Text widget and all the others. Is this what you mean by a Signature? Text(Text, scale=(None, None), size=(None, None), auto_size_text=None, font=None, text_color=None, justification=None) . Text - The text that's displayed size - Element's size auto_size_text - Bool. Change width to match size of text font - Font name and size to use text_color - text color justification - Justification for the text. String - 'left', 'right', 'center' I don't have all of the newest features in there, like the Update method because the doc is for version 2.9 on PyPI. I don't yet have the latest GitHub release in there just yet. You'll find that information instead on the Wiki: https://github.com/MikeTheWatchGuy/PySimpleGUI/wiki/PySimpleGUI-Wiki 2. Advanced features - how would I extend it if I have a need that it doesn't cover? For example, a canvas object or an image? I have Images. Don't have Canvas. Any particular operations desired for the Canvas Element should I have one? 3. It doesn't seem to use native widgets (the buttons have a non-standard look on my Windows PC). The defaults can be easily changed. The default buttons are the one widget that I modify from the system default. The reason was that the system default is a gray button. It pretty much matches the background. If you want your buttons to all look like the system default, slip this line of code at the top: sg.SetOptions(button_color=sg.COLOR_SYSTEM_DEFAULT) Thank you again Paul... I learn something new from every reply 😊 @mike -----Original Message----- From: Paul Moore <p.f.moore@gmail.com> Sent: Friday, August 24, 2018 11:13 AM To: mike_barnett@hotmail.com Cc: Wes Turner <wes.turner@gmail.com>; Jonathan Fine <jfine2358@gmail.com>; Python-Ideas <python-ideas@python.org> Subject: Re: [Python-ideas] A GUI for beginners and experts alike On Fri, 24 Aug 2018 at 15:53, Mike Barnett <mike_barnett@hotmail.com> wrote:
Can a few of you with the vast amount of GUI experience you have, spend 5 minutes and run one of the examples?
I don't have a "vast" amount of GUI experience. But nevertheless I gave it a go. It took less than 5 minutes (which is good).
This will get you started:
pip install PySimpleGUI
Worked.
I went for the simple GUI form. It worked pretty much as expected. The code looks quite nice.
Agreed, it was simple to use, and pick up a canned example.
because I don’t think anything like it has been proposed as a GUI framework.
I don't know if that's true, there's a lot of GUI frameworks and I certainly can't say I've tried all of them. This looks nice for simple usages, and would certainly be useful as a project on PyPI (like it is at the moment). I doubt it's mature enough for the stdlib, and I'm certain it's not stable enough (yet) for the stdlib - you'll want to make changes, add features, etc, and once it's in the stdlib that's going to be a lot harder. What's the rush? As far as things I think I'd like to see (and these are just off the top of my head, I've done nothing more than I said above): 1. More documentation - reference docs specifically. I don't see documentation of the call signature for sg.Text, for example. 2. Advanced features - how would I extend it if I have a need that it doesn't cover? For example, a canvas object or an image? 3. It doesn't seem to use native widgets (the buttons have a non-standard look on my Windows PC). Don't feel like you need to do anything about these comments - I rarely if ever use a GUI library, and I've no idea if I'd use this one in future, but if you want "focused comments" beyond "it looks neat and seems like a fine project to go onto PyPI, but I don't think it's necessarily something that should go in the stdlib", then those were what I thought of off the cuff. Hope this is useful, Paul
On Fri, 24 Aug 2018 at 16:27, Mike Barnett <mike_barnett@hotmail.com> wrote:
Yes, I saw that. It has the call information about the Text widget and all the others. If it does, I didn't spot it. I did say I was skimming - and there's certainly a good amount of documentation. To some extent, I'm being picky here because while I like examples, I have found projects in the past that provide plenty of narrative and examples, but then when you start to want to do something more complicated, the details and specifics are missing.
Yes, precisely. Apologies that I missed it. I don't have all of the newest features in there, like the Update method
Nope. I don't even have a need for a canvas. But what I have found in the past is that *anything* which is a "simple wrapper over X" always ends up in a situation where you need some feature from X that the simple wrapper doesn't cover, and you're left with the unpalatable choice of whether to omit functionality you want to provide, or rewrite your code to use X directly. So my question is more about "if you hit a need for something PySimpleGUI doesn't cover, what are your options?
OK. Personally, I'd argue quite strongly that "match the OS default" is the right default for a GUI library, but that's a hugely subjective area, and you're never going to please everyone. So do whatever works for you. Thank you again Paul... I learn something new from every reply 😊 No problem - glad it helped. Paul
A couple thoughts: You're essentially writing a new API on top of tkINter, you could probably have multiple "back-ends" -- i.e. be able to use the same code with wxPython or PySide behind it. In fact, there was an effort along these lines a few years back: http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/ I don't know that it's seen much development lately. Nope. I don't even have a need for a canvas. But what I have found in the
This is key -- and one of the real issues around wrapping multiple GUI back-ends -- you end up having to do a lot of re-implementation of details. In fact, I always thought Pyton_guiu above really suffered from that conceptually. For example, if you used pyton-gui with a wxPython back end, you had: A python wrapper around a python wrapper around a C++ wrapper around each native toolkit. That's a lot of layers! So it's probably better to have a simpler stack -- and at the bottom, you probably need something with at least some C/C++ in it. And there are two options there: 1) re-implement widgets with native basic drawing and event handling. - this is what QT GTK, and TK do 2) Wrap the native widgets - this is what wxWidgets does The advantage of (1) is that most of your code is the same on all platform, widgets behave the same on all platforms, and there is less code to write to support a new platform. The advantage of (2) is that you get more native results -- the widgets ARE native. And it's easier to support the first platform -- you aren't writing a while GUI toolkit. But there is a lot more wrapper code to write for each new platform. And the results ARE going to be a bit platform-dependent in some places (though I've found that I need to write very little platform dependent code with wx) TK is essentially (1), though AIUI, it was originally written for X-windows, and the other platform have an X-windows emulation layer, and then all the TK code works with that. But the issue with TK is that it's really pretty old and krufty. It's great that it comes with the standard library, but now that yu can pip install pySide and wxPython, I'd consider working with one of those. I'd also make sure that you CAN "drop down" into the lower level toolkit fairly smoothly, if you do need something more complex that the basics. Finally -- I'm not sure the desktop is dead, but there is a heck of a lot going on in the browser. And if someone could write a simple GUI for a desktop app, and then easily prt that to a WebApp -- that would be great. I'm sure there are toolkits that do maybe it possible to write pure-python, and have all the javascript pre-written (Or generated) for you. While its not a complete solution, Jupyter Widgets does this within the Jupyter framework, for instance. -CHB
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
Yea, software evolves. Things get layered on top of other things. It’s kind of how software works. Perhaps the point is getting lost here on my request to comment on the overall construct and simplicity. Let’s try a different approach… How about a quick example that you code up in your favorite GUI? Try and make it simple enough for a beginner to grasp as much as possible. Here we go: Take 3 numbers as input (A, B, C). Add them together. Display the result in a simple pop-up window. That’s a pretty typical kind of problem for the first few weeks of beginning programming. Maybe first few days. Let’s say I want my program to look and work like other windows programs. I want to show my friends, mom and dad that I can write software too. In this example, I would expect that kind of reasoning that would drive a desire for a GUI. @mike<mailto:mike_barnett@hotmail.com> From: Chris Barker <chris.barker@noaa.gov> Sent: Friday, August 24, 2018 1:39 PM To: Paul Moore <p.f.moore@gmail.com> Cc: Mike Barnett <mike_barnett@hotmail.com>; Python-Ideas <python-ideas@python.org> Subject: Re: [Python-ideas] A GUI for beginners and experts alike A couple thoughts: You're essentially writing a new API on top of tkINter, you could probably have multiple "back-ends" -- i.e. be able to use the same code with wxPython or PySide behind it. In fact, there was an effort along these lines a few years back: http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cosc.canterbury.ac.nz%2Fgreg.ewing%2Fpython_gui%2F&data=02%7C01%7C%7C7c6bd9bc319e45a33d8f08d609e89e3f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636707292023975025&sdata=iPZUt3MlLOPPpwAUHdYbXuV3g8iG2JSDgtzd1W9iCyc%3D&reserved=0> I don't know that it's seen much development lately. Nope. I don't even have a need for a canvas. But what I have found in the past is that *anything* which is a "simple wrapper over X" always ends up in a situation where you need some feature from X that the simple wrapper doesn't cover, and you're left with the unpalatable choice of whether to omit functionality you want to provide, or rewrite your code to use X directly. So my question is more about "if you hit a need for something PySimpleGUI doesn't cover, what are your options? This is key -- and one of the real issues around wrapping multiple GUI back-ends -- you end up having to do a lot of re-implementation of details. In fact, I always thought Pyton_guiu above really suffered from that conceptually. For example, if you used pyton-gui with a wxPython back end, you had: A python wrapper around a python wrapper around a C++ wrapper around each native toolkit. That's a lot of layers! So it's probably better to have a simpler stack -- and at the bottom, you probably need something with at least some C/C++ in it. And there are two options there: 1) re-implement widgets with native basic drawing and event handling. - this is what QT GTK, and TK do 2) Wrap the native widgets - this is what wxWidgets does The advantage of (1) is that most of your code is the same on all platform, widgets behave the same on all platforms, and there is less code to write to support a new platform. The advantage of (2) is that you get more native results -- the widgets ARE native. And it's easier to support the first platform -- you aren't writing a while GUI toolkit. But there is a lot more wrapper code to write for each new platform. And the results ARE going to be a bit platform-dependent in some places (though I've found that I need to write very little platform dependent code with wx) TK is essentially (1), though AIUI, it was originally written for X-windows, and the other platform have an X-windows emulation layer, and then all the TK code works with that. But the issue with TK is that it's really pretty old and krufty. It's great that it comes with the standard library, but now that yu can pip install pySide and wxPython, I'd consider working with one of those. I'd also make sure that you CAN "drop down" into the lower level toolkit fairly smoothly, if you do need something more complex that the basics. Finally -- I'm not sure the desktop is dead, but there is a heck of a lot going on in the browser. And if someone could write a simple GUI for a desktop app, and then easily prt that to a WebApp -- that would be great. I'm sure there are toolkits that do maybe it possible to write pure-python, and have all the javascript pre-written (Or generated) for you. While its not a complete solution, Jupyter Widgets does this within the Jupyter framework, for instance. -CHB 3. It doesn't seem to use native widgets (the buttons have a non-standard look on my Windows PC). The defaults can be easily changed. The default buttons are the one widget that I modify from the system default. The reason was that the system default is a gray button. It pretty much matches the background. If you want your buttons to all look like the system default, slip this line of code at the top: sg.SetOptions(button_color=sg.COLOR_SYSTEM_DEFAULT) OK. Personally, I'd argue quite strongly that "match the OS default" is the right default for a GUI library, but that's a hugely subjective area, and you're never going to please everyone. So do whatever works for you. Thank you again Paul... I learn something new from every reply 😊 No problem - glad it helped. Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org<mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-ideas&data=02%7C01%7C%7C7c6bd9bc319e45a33d8f08d609e89e3f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636707292023975025&sdata=EPc7GJIUUUGJ6WKLuHA1Pd2a0NWg7srxxB3KXxStDyo%3D&reserved=0> Code of Conduct: http://python.org/psf/codeofconduct/<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpython.org%2Fpsf%2Fcodeofconduct%2F&data=02%7C01%7C%7C7c6bd9bc319e45a33d8f08d609e89e3f%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636707292023975025&sdata=%2FyRXdyWNKldw3HIHuH805QoHAjedAp5CCV91cntZzpE%3D&reserved=0> -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov<mailto:Chris.Barker@noaa.gov>
On Sat, Aug 25, 2018 at 5:13 AM, Mike Barnett <mike_barnett@hotmail.com> wrote:
Do you mean "beginning GUI programming", or are you saying that this kind of thing should be in someone's first few days of programming overall? I disagree with the latter; for the first days of a programmer's basic training, the REPL is ample. No GUI needed, don't even need input() at that stage. While I would generally teach input() before any GUI toolkit, the opposite decision is also valid, but definitely neither is needed right off the bat. For someone's earliest forays into GUI programming, I would actually *still* not word the challenge that way. I would keep everything in a SINGLE window, because that showcases a major strength of a GUI - that you can interact with it multiple times, rather than being forced into a linear workflow. So here's my alternative challenge: Take two numbers as inputs. Add them together and display them in a third field. Whenever either input is changed, recalculate the output. This requires proper event handling, so it's less likely to create a useless one-liner that has no bearing on real-world code. ChrisA
So here's my alternative challenge: Take two numbers as inputs. Add them together and display them in a third field. Whenever either input is changed, recalculate the output. This requires proper event handling, so it's less likely to create a useless one-liner that has no bearing on real-world code. ------------------------------------ Sure thing... post yours. I'll go ahead and post mine first. Here's the window this code produces. https://user-images.githubusercontent.com/13696193/44604157-02a2ac00-a7b3-11... And here's the code in a more readable form since the email formatting sucks. https://user-images.githubusercontent.com/13696193/44604220-2cf46980-a7b3-11... It's rather, uhm, simple to do.... import PySimpleGUI as gui output = gui.Text('') layout = [ [gui.Text('Enter 2 numbers')], [gui.Text('A'), gui.InputText()], [gui.Text('B'), gui.InputText()], [gui.Text('Answer = '), output], ] form = gui.FlexForm('Realtime Updates', return_keyboard_events=True) form.LayoutAndRead(layout) while True: button, (a,b) = form.Read() try: answer = int(a) + int(b) output.Update(answer) except: pass @mike
I should have mentioned that you need the GitHub version of the code in order to get the keyboard events. Rather than do a pip install you can download this file and put it in your project folder: https://github.com/MikeTheWatchGuy/PySimpleGUI/blob/master/PySimpleGUI.py Sorry for any confusion. I also got a question if this code blocks or is in a spin-loop. The answer is that the posted version blocks until some kind of form input. Should you want to turn the program into one that polls instead of blocks, the loop changes slightly to enable form close detection. It's basically the same with the Read call being replaced by ReadNonBlocking. while True: button, values = form.ReadNonBlocking() if button is None and values is None: break a, b = values try: output.Update(int(a) + int(b)) except: pass @mike -----Original Message----- From: Mike Barnett <mike_barnett@hotmail.com> Sent: Friday, August 24, 2018 3:36 PM To: Chris Angelico <rosuav@gmail.com>; Python-Ideas <python-ideas@python.org> Subject: RE: [Python-ideas] A GUI for beginners and experts alike So here's my alternative challenge: Take two numbers as inputs. Add them together and display them in a third field. Whenever either input is changed, recalculate the output. This requires proper event handling, so it's less likely to create a useless one-liner that has no bearing on real-world code. ------------------------------------ Sure thing... post yours. I'll go ahead and post mine first. Here's the window this code produces. https://user-images.githubusercontent.com/13696193/44604157-02a2ac00-a7b3-11... And here's the code in a more readable form since the email formatting sucks. https://user-images.githubusercontent.com/13696193/44604220-2cf46980-a7b3-11... It's rather, uhm, simple to do.... import PySimpleGUI as gui output = gui.Text('') layout = [ [gui.Text('Enter 2 numbers')], [gui.Text('A'), gui.InputText()], [gui.Text('B'), gui.InputText()], [gui.Text('Answer = '), output], ] form = gui.FlexForm('Realtime Updates', return_keyboard_events=True) form.LayoutAndRead(layout) while True: button, (a,b) = form.Read() try: answer = int(a) + int(b) output.Update(answer) except: pass @mike
Hi Mike, Thanks, this code is nice and short. Is adding 'if button is None: break' to the 'Read' version of your code the right way to make it exit when the main window is closed? (On my machine it enters an infinite loop after I close the main window). For comparison, I tried doing this with PyGObject. I created the UI with glade, which auto-generated the attached XML file. Then I had to write the following code (I had never used Glade or PyGObject before, so apologies if there are mistakes in the following): import gi gi.require_version('Gtk', '3.0') from gi.repository import Gtk def main(): builder = Gtk.Builder() builder.add_from_file("sum.glade") get = builder.get_object a, b, answer, window = get("a"), get("b"), get("answer"), get("window") def update_sum(_entry): try: tanswer = int(a.get_text()) + int(b.get_text()) answer.set_text(str(tanswer)) except ValueError: pass a.connect("changed", update_sum) b.connect("changed", update_sum) window.connect("destroy", Gtk.main_quit) window.show_all() Gtk.main() if __name__ == '__main__': main() Having a visual editor for the UI feels like a plus, and I find the resulting XML verbose but acceptably readable. On the other hand, I like the conciseness of your UI specs. Cheers, Clément. On 2018-08-24 16:38, Mike Barnett wrote:
Hi Mike I'm not sure this thread is python-ideas appropriate, but since the challenge is out, here it is using Kivy. The code and result is at https://gist.github.com/matham/45c4f1fbd8c3fccf6557b3b48356cd50 (image https://gist.githubusercontent.com/matham/45c4f1fbd8c3fccf6557b3b48356cd50/r...). The code is also inlined below. I wrote it to be one file so I used the string version (load_string) for defining the GUI, but the GUI definition could have been written as a separate kv file. I could also have written it using pure python, but that is more verbose and less intuitive. Also, Kivy works on pretty much all platforms (windows, linux, osx, android, ios) and is written in pure python (and cython) on top of opengl. All the best, Matt P.S. here's the inlined code: from kivy.lang import Builder from kivy.app import runTouchApp runTouchApp(Builder.load_string(''' #:import Factory kivy.factory.Factory BoxLayout: orientation: 'vertical' padding: "12dp" spacing: "12dp" Label: text: "Please enter 3 numbers" BoxLayout: spacing: "10dp" Entry: id: a hint_text: "A" Entry: id: b hint_text: "B" Entry: id: c hint_text: "C" Label: text: "The sum is {}".format(a.val + b.val + c.val) <Entry@TextInput>: input_filter: "float" val: float(self.text) if self.text else 0 ''')) On Fri, Aug 24, 2018 at 5:28 PM Clément Pit-Claudel <cpitclaudel@gmail.com> wrote:
Nice Matt! Thanks for taking the time to code it up! It’s great to see examples like these. @mike<mailto:mike_barnett@hotmail.com> From: Python-ideas <python-ideas-bounces+mike_barnett=hotmail.com@python.org> On Behalf Of Matthew Einhorn Sent: Friday, August 24, 2018 7:51 PM To: python-ideas@python.org Subject: Re: [Python-ideas] A GUI for beginners and experts alike Hi Mike I'm not sure this thread is python-ideas appropriate, but since the challenge is out, here it is using Kivy. The code and result is at https://gist.github.com/matham/45c4f1fbd8c3fccf6557b3b48356cd50<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.github.com%2Fmatham%2F45c4f1fbd8c3fccf6557b3b48356cd50&data=02%7C01%7C%7Ce79abd06c77544c33e7008d60a1c9d95%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636707515345906031&sdata=Uwr%2FzUCh17hCHSpIsTzA36iVmFpkE%2FgWb7i8DeABhik%3D&reserved=0> (image https://gist.githubusercontent.com/matham/45c4f1fbd8c3fccf6557b3b48356cd50/raw/dbbf74f17ad4beab49f022bbf43fcc72ff725084/kivy_gui.png<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgist.githubusercontent.com%2Fmatham%2F45c4f1fbd8c3fccf6557b3b48356cd50%2Fraw%2Fdbbf74f17ad4beab49f022bbf43fcc72ff725084%2Fkivy_gui.png&data=02%7C01%7C%7Ce79abd06c77544c33e7008d60a1c9d95%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636707515345916042&sdata=s22vKrCMVzvL76RNm%2FQtU9sJMafFp%2By3i1ZQqD3167E%3D&reserved=0>). The code is also inlined below. I wrote it to be one file so I used the string version (load_string) for defining the GUI, but the GUI definition could have been written as a separate kv file. I could also have written it using pure python, but that is more verbose and less intuitive. Also, Kivy works on pretty much all platforms (windows, linux, osx, android, ios) and is written in pure python (and cython) on top of opengl. All the best, Matt P.S. here's the inlined code: from kivy.lang import Builder from kivy.app import runTouchApp runTouchApp(Builder.load_string(''' #:import Factory kivy.factory.Factory BoxLayout: orientation: 'vertical' padding: "12dp" spacing: "12dp" Label: text: "Please enter 3 numbers" BoxLayout: spacing: "10dp" Entry: id: a hint_text: "A" Entry: id: b hint_text: "B" Entry: id: c hint_text: "C" Label: text: "The sum is {}".format(a.val + b.val + c.val) <Entry@TextInput>: input_filter: "float" val: float(self.text) if self.text else 0 ''')) On Fri, Aug 24, 2018 at 5:28 PM Clément Pit-Claudel <cpitclaudel@gmail.com<mailto:cpitclaudel@gmail.com>> wrote: Hi Mike, Thanks, this code is nice and short. Is adding 'if button is None: break' to the 'Read' version of your code the right way to make it exit when the main window is closed? (On my machine it enters an infinite loop after I close the main window). For comparison, I tried doing this with PyGObject. I created the UI with glade, which auto-generated the attached XML file. Then I had to write the following code (I had never used Glade or PyGObject before, so apologies if there are mistakes in the following): import gi gi.require_version('Gtk', '3.0') from gi.repository import Gtk def main(): builder = Gtk.Builder() builder.add_from_file("sum.glade") get = builder.get_object a, b, answer, window = get("a"), get("b"), get("answer"), get("window") def update_sum(_entry): try: tanswer = int(a.get_text()) + int(b.get_text()) answer.set_text(str(tanswer)) except ValueError: pass a.connect("changed", update_sum) b.connect("changed", update_sum) window.connect("destroy", Gtk.main_quit) window.show_all() Gtk.main() if __name__ == '__main__': main() Having a visual editor for the UI feels like a plus, and I find the resulting XML verbose but acceptably readable. On the other hand, I like the conciseness of your UI specs. Cheers, Clément. On 2018-08-24 16:38, Mike Barnett wrote:
_______________________________________________ Python-ideas mailing list Python-ideas@python.org<mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-ideas&data=02%7C01%7C%7Ce79abd06c77544c33e7008d60a1c9d95%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636707515345986107&sdata=l0h7XMzPGMOBsm%2F7XOzlPkPgCgKHPJLY9iJDam1KhAk%3D&reserved=0> Code of Conduct: http://python.org/psf/codeofconduct/<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpython.org%2Fpsf%2Fcodeofconduct%2F&data=02%7C01%7C%7Ce79abd06c77544c33e7008d60a1c9d95%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636707515345996112&sdata=34iqzRJ7AfpiElm07U9HGv8sqvgzkwOuOxDj6tDQztk%3D&reserved=0>
while True: button, (a,b) = form.Read() try: answer = int(a) + int(b) output.Update(answer) except: pass Whoa! You really want people to write their own event loop? That seems like a bad idea to me. If you want people to not have to think about events much, maybe look at traitsui for ideas. http://docs.enthought.com/traitsui/ -CHB
Here are some PyGUI versions of the ABC Challenge. #---------------- Modal -------------------- from GUI import ModalDialog, Label, TextField, Row, Column, Grid from GUI.StdButtons import DefaultButton, CancelButton from GUI.Alerts import note_alert a = TextField(width = 100) b = TextField(width = 100) c = TextField(width = 100) buttons = Row([DefaultButton(), CancelButton()]) dlog = ModalDialog(title = "ABC Challenge") dlog.add(Column([ Grid([ [Label("A"), a], [Label("B"), b], [Label("C"), c], ]), buttons], padding = (10, 10))) dlog.shrink_wrap() if dlog.present(): note_alert("Sum = %s" % (int(a.text) + int(b.text) + int(c.text))) #---------------- Non-Modal ------------------ from GUI import Window, Label, TextField, Grid, application def update(): try: c.text = str(int(a.text) + int(b.text)) except ValueError: c.text = "" a = TextField(width = 100, text_changed_action = update) b = TextField(width = 100, text_changed_action = update) c = TextField(width = 100, editable = False) win = Window(title = "ABC Challenge") win.add( Grid([ [Label("A"), a], [Label("B"), b], [Label("A + B"), c], ], padding = (10, 10))) win.shrink_wrap() win.show() application().run() -- Greg
Chris Barker via Python-ideas wrote:
It hasn't, sorry to say. Turns out that writing and maintaining what is effectively 3 complete GUI toolkits takes a more copious supply of round tuits than I have at the moment. :-(
If you're talking about my PyGUI project, using it with wPython doesn't really make sense. I specifically wanted to avoid the multiple-wrapper problem, so I decided *not* to wrap any existing cross-platform GUI toolkit. The goal is to provide exactly one high-quality implementation for each platform, with as few layers as practicable between the Python API and the platform's native GUI facilities. One result of that is that PyGUI is not really structured as a "front end" and "back end" with a defined interface between them. There is generic code and platform-specific code, but they're fairly closely intertwined. Implementations on top of wxPython, Qt etc. could probably be created, but I won't be doing it myself, because it would take a lot of work and I don't think it would be necessary or desirable.
PyGUI does (2).
Yeah, X Windows is a bit special, because there is no such thing os a "native" look and feel for widgets on X -- there have been multiple GUI toolkits for X from the beginning, each with its own style. So Tk inventing a new one all of its own wasn't really a bad thing at the time.
I'd also make sure that you CAN "drop down" into the lower level toolkit fairly smoothly, if you do need something more complex that the basics.
PyGUI provides everything you need to create a custom widget, without needing to go down to a lower level. You could also create a wrapper for a native widget that PyGUI doesn't already provide, but the techniques for doing so are currently undocumented and might change between releases.
Pyjamas seems to be something like that: https://pypi.org/project/Pyjamas/ -- Greg
If you're talking about my PyGUI project, using it with wPython doesn't really make sense.
Now that you say that, I think I’m mingling memories — there was another project that attempted to wrap TKInter, wxPython, QT .. I always thought that was ill advised.
So kinda like wxWidgets but in Python — which would be nice. wxPython definitely suffers from its C++ underpinnings.
Implementations on top of wxPython, Qt etc. could probably be created,
QT might make some sense— you need something on top of X, don’t you?
In that context, I was thinking about the OP’s concept— very high level, pretty much declarative. It’s going to run into limitations fast. So there should be s way to customize user interaction. Too bad all the cool kids are doing web dev these days — hard to get help with a desktop GUI project :-(
Pyjamas seems to be something like that:
Or it was 6 years ago :-( -CHB
Op za 25 aug. 2018 02:28 schreef Chris Barker - NOAA Federal via Python-ideas <python-ideas@python.org>:
Too bad all the cool kids are doing web dev these days — hard to get help with a desktop GUI project :-(
Pywebview seems interesting, uses a platform webview to put up the UI; https://github.com/r0x0r/pywebview But not so newbie-friendly I am afraid... Stephan
It’s fascinating just how many packages are being dragged out for examination or clobbering other than the one that I asked for assistance/help on. I see the code of conduct link in the thread. Perhaps a review would be helpful. Unsubscribing from this mess. “Python Ideas” ? @mike<mailto:mike_barnett@hotmail.com> From: Python-ideas <python-ideas-bounces+mike_barnett=hotmail.com@python.org> On Behalf Of Stephan Houben Sent: Friday, August 24, 2018 9:07 PM To: Chris Barker <chris.barker@noaa.gov> Cc: Python-Ideas <python-ideas@python.org> Subject: Re: [Python-ideas] A GUI for beginners and experts alike Op za 25 aug. 2018 02:28 schreef Chris Barker - NOAA Federal via Python-ideas <python-ideas@python.org<mailto:python-ideas@python.org>>: Too bad all the cool kids are doing web dev these days — hard to get help with a desktop GUI project :-( Pywebview seems interesting, uses a platform webview to put up the UI; https://github.com/r0x0r/pywebview<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fr0x0r%2Fpywebview&data=02%7C01%7C%7C612446e8a7ed454f7fdf08d60a273632%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636707560853860413&sdata=%2FkLW%2FZ%2FAxu8X5j9bq3KKoHn%2F6oU3pNjlyDkbo%2B2Mk7E%3D&reserved=0> But not so newbie-friendly I am afraid... Stephan
Pyjamas seems to be something like that:
Or it was 6 years ago :-( -CHB _______________________________________________ Python-ideas mailing list Python-ideas@python.org<mailto:Python-ideas@python.org> https://mail.python.org/mailman/listinfo/python-ideas<https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-ideas&data=02%7C01%7C%7C612446e8a7ed454f7fdf08d60a273632%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636707560853860413&sdata=jHvQjyD%2FSyzob%2BNwRY77jqXEnwVZ%2FDov3btwggonjyk%3D&reserved=0> Code of Conduct: http://python.org/psf/codeofconduct/<https://eur04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpython.org%2Fpsf%2Fcodeofconduct%2F&data=02%7C01%7C%7C612446e8a7ed454f7fdf08d60a273632%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636707560853860413&sdata=j2HJc7JhWU9KIyBbGgO1lBXNLrvMiEhMN8nB%2Fxu%2FkSA%3D&reserved=0>
Mike Barnett wrote:
Unsubscribing from this mess. “Python Ideas” ?
We didn't mean to drive you away! Python discussions have a tendency to roam far and wide. It doesn't mean we're not interested in what you have to say. Any new package is naturally going to invite comparisons with similar things that have been done before. That's not a bad thing -- it's always good to see what others have done in the same field. Although your package is unlikely to be put into the stdlib any time soon, it would be a fine thing to have on PyPI, and I'm sure there are people here willing to help you develop it. You may just need to be prepared to ignore some digressions. -- Greg
On Fri, 24 Aug 2018 at 18:18 Mike Barnett <mike_barnett@hotmail.com> wrote:
Unsubscribing from this mess. “Python Ideas” ?
So I code of conduct review of this thread would suggest that your opening email was inappropriate by being misleading thanks to sounding like you were a neutral third-party to your library (luckily you admit to this later, but it shouldn't have been done to begin with). The tone was okay, but you state a lot of opinions as if they are fact, e.g. "GUI code is far from compact", "you've got to be skilled to use it", etc. Those are all opinions expressed as facts which can be misleading and potentially insulting depending on who you're talking to (i.e. some of the people who have worked very hard to make tkinter even work are on this mailing list). Your initial email was also off-topic. This mailing list is about ideas to changing Python, not announcements. Once again you later mention you wanted to start a discussion about getting PySimpleGUI into the stdlib, but it would have been nicer to mention that from the beginning as people would have pointed you at https://devguide.python.org/stdlibchanges/#adding-a-new-module and that would have answered your question. But as part of getting a module into the stdlib, alternatives will be considered (especially GUI libraries as this topic is not a new one and there are many options available, all with their own approaches). So if you actual intent was to get PySimpleGUI into the stdlib some day then discussing other libraries isn't off-topic at all as you will eventually need to address why your library is better than others. Being upset that people are doing their due diligence by bringing up alternatives as part of your request about talking about eventually adding PySimpleGUI to the stdlib is not a CoC violation at all and honestly your tone in your last email is a much bigger concern and deserves the warning --which I am giving -- more than how anyone else has behaved. -Brett
Didn't see the Qt version of the adding together with GUI yet, so here I have a minimalist version: import sys from PyQt5.QtWidgets import QWidget, QSpinBox, QLabel, QApplication, QHBoxLayout app = QApplication(sys.argv) w = QWidget() w.setLayout(QHBoxLayout()) spinOne = QSpinBox(w) spinTwo = QSpinBox(w) output = QLabel(w) def add(): output.setText(str(spinOne.value() + spinTwo.value())) spinOne.valueChanged.connect(add) spinTwo.valueChanged.connect(add) w.layout().addWidget(spinOne) w.layout().addWidget(spinTwo) w.layout().addWidget(output) w.show() app.exec() And here a version how I'd actually like to see it if written seriously: import sys from PyQt5.QtCore import pyqtSignal, pyqtSlot from PyQt5.QtWidgets import QWidget, QSpinBox, QLabel, QApplication, QHBoxLayout class AddWidget(QWidget): newValue = pyqtSignal(str) def __init__(self, parent=None): super().__init__(parent) self.setLayout(QHBoxLayout(self)) self.firstInput = QSpinBox(self) self.layout().addWidget(self.firstInput) self.firstInput.valueChanged.connect(self.addTogether) self.secondInput = QSpinBox(self) self.layout().addWidget(self.secondInput) self.secondInput.valueChanged.connect(self.addTogether) self.output = QLabel(self) self.layout().addWidget(self.output) self.newValue.connect(self.output.setText) @pyqtSlot(int) def addTogether(self, arg): self.newValue.emit(str(self.firstInput.value() + self.secondInput.value())) if __name__ == "__main__": app = QApplication(sys.argv) w = AddWidget() w.show() app.exec() I'll fully admit it takes a few lines more code to actually do it right compared to the other mentioned GUI frameworks, but it shows nicely how it's really a toolbox full of stuff you can use to assemble what you need.
Chris Barker - NOAA Federal wrote:
You're probably thinking of "anygui" (named in the spirit of "anydbm"). As far as I remember, it never really got off the ground.
QT might make some sense— you need something on top of X, don’t you?
Linux is currently covered by a Gtk implementation, which seems to be about as close as you get to a "native" GUI toolkit on Linux. X-based systems without Gtk are currently out ofscope -- but contributions are always welcome! -- Greg
On 2018-08-24 16:27, Mike Barnett wrote:
Liking the comments Paul!
[snip]
Static text is usually called a "label" in the GUIs I've used, including tkinter. [snip]
A canvas can contain images, lines and shapes, which is useful for diagrams and drawings.
Looking at the page on PyPI, those coloured buttons do look odd to me. I think the default should be the system default. Also, I think those buttons labelled "Submit" should be labelled "OK".
On Fri, Aug 24, 2018 at 10:07 AM, MRAB <python@mrabarnett.plus.com> wrote:
A canvas can contain images, lines and shapes, which is useful for diagrams and drawings.
And the TK Canvas is kinda the "killer app" of TK. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On 8/24/2018 4:12 AM, Wes Turner wrote:
There was a thread about deprecating Tk awhile back.
That was an intentionally annoying troll post, not a serious proposal. Please don't refer to it as if it were.
asyncio event loop support would be great for real world apps.
This is unclear. Any app that wants to use asyncio can import it. Easily using async and await *without* using asyncio is a different matter. -- Terry Jan Reedy
On Friday, August 24, 2018, Terry Reedy <tjreedy@udel.edu> wrote:
stdlib inclusion entails years of support commitment, backwards incompatibility, waiting for a Python release to occur, and withstanding phd-level challenges.
asyncio event loop support would be great for real world apps.
This is unclear. Any app that wants to use asyncio can import it.
Easily using async and await *without* using asyncio is a different matter.
asyncio support is only so useful when the GUI widget toolkit blocks (doesn't use async or await
ipywidgets and toga* implementations of the ABC demo: | source: https://github.com/westurner/guidemo # ipywidgetsdemo/ipywidgets_abc_demo.py (.ipynb) # # ipywidgets ABC demo # - Update an output widget with the sum of two input widgets when the 'change' event fires # In[1]: # https://ipywidgets.readthedocs.io/en/latest/examples/Using%20Interact.html # https://ipywidgets.readthedocs.io/en/latest/examples/Widget%20List.html from ipywidgets import interact import ipywidgets as widgets def add(x, y): return sum((x,y)) widget_x = widgets.IntText(value=0, description='#1') widget_y = widgets.IntText(value=0, description='#2') interact(add, x=widget_x, y=widget_y) # In[2]: # https://ipywidgets.readthedocs.io/en/latest/examples/Widget%20Events.html#Re... from IPython.display import display from ipywidgets import interact import ipywidgets as widgets widget_x = widgets.IntText(value=0, description='#1') widget_y = widgets.IntText(value=0, description='#2') widget_sigma = widgets.IntText(value=0, description='sum') def add_event(event): widget_sigma.value = sum((widget_x.value, widget_y.value)) widget_x.observe(add_event, names='value') widget_y.observe(add_event, names='value') display(widgets.HBox([widget_x, widget_y, widget_sigma])) # togaabcdemo/app.py import toga from toga.style import Pack from toga.style.pack import COLUMN, ROW class TogaAbcDemo(toga.App): def add_numbers(self, widget): # TODO: validate that n*_input.value are numbers n1, n2 = self.n1_input.value, self.n2_input.value n3 = sum(n1, n2) if ((n1 is not None) and (n2 is not None)) else None print("%r + %r = %r" % (n1, n2, n3)) self.n3_input.value = n3 def startup(self): # Create a main window with a name matching the app self.main_window = toga.MainWindow(title=self.name) # Create a main content box main_box = toga.Box() self.n1_input = toga.TextInput( placeholder='#1', on_change=self.add_numbers) self.n2_input = toga.TextInput( placeholder='#2', on_change=self.add_numbers) self.n3_input = toga.TextInput( placeholder='Sum', readonly=True) main_box.add(self.n1_input) main_box.add(self.n2_input) main_box.add(self.n3_input) # Add the content on the main window self.main_window.content = main_box # Show the main window self.main_window.show() def main(): return TogaAbcDemo('Toga ABC Demo', 'org.westurner.togaabcdemo.togaabcdemo') On Fri, Aug 24, 2018 at 4:12 AM Wes Turner <wes.turner@gmail.com> wrote:
Hi Mike, and welcome! On Thu, Aug 23, 2018 at 06:49:48PM +0000, Mike Barnett wrote:
Python has dropped the GUI ball, at least for beginners (in my opinion)
Sadly I think that GUIs is one area where Python has not excelled.
I've been using Python for 20 years, and I'm still intimidated by Tkinter's learning curve, let alone products like wxPython.
Provided they have tkinter.
I am not seeking fame, recognition, or any other personal gain.
Good, because you won't get it :-)
Acceptance for *what* precisely? I appreciate your enthusiasm, but I think you forgot to actually make a proposal. Is this an attempt to draw people's attention to PySimpleGUI? To start a dialog about finding something better? Do you want PySimpleGUI to be added to the Python standard library? (If so, then I don't understand the comment about pip install and dropping the PySimpleGUI into people's project folder -- that isn't necessary if its a std lib module.) If this is about adding PySimpleGUI to the std lib, then there's a few things to keep in mind: * We don't conscript library authors; they have to volunteer, or at least agree, to donate their library to the Python std lib. Have you approached the author of PySimpleGUI to see what he or she has to think about this idea? * Even if they are agreeable, we don't take software until it has proven itself, both that there is a need for it and that it is the right solution. Being in the std lib is not for every project. It means following Python's release cycle, which is too slow for some projects and too fast for others. It also means being limited by some rather hard backwards- compatibility constraints, and a cultural reluctance to grow libraries beyond a certain size. Sometimes even adding a single function to a library can be controversial. Projects in their early days that are still experimenting with their interfaces, or intending to add new functionality, are generally not a good fit to the std lib. There's a saying that the standard library is where good libraries go to die. While that's somewhat of an exaggeration (there's plenty of life left in the std lib) it is true that libraries in the std lib should offer a stable interface and functionality. -- Steve
Wow, Thank you Steve! This is exactly the kind of information I was hoping for!!
Acceptance for *what* precisely?
That is a great question... you're right shoulda asked a specific question. I would like to see if become something official so that it gets out to people automatically. Perhaps a stdlib module. I should have also mentioned I'm the author. That 3rd person thing didn't sound right. Definitely want to stress that the current implementation is a prototype for something official. It would need to be rewritten should it be submitted. As it is now it likely needs refactoring to get the interface to be PEP8 compliant. If it's possible to look past some of those blemishes and more at what the interface accomplishes and how it goes about doing it. There are a number of Python-like aspects of the project that fit within a learning environment. These concepts are all touched upon in a natural way: * The use of Lists, Dictionaries for return values. * The window/form is specified using a List layout that visibly resembles the GUI layout. * Widgets are configured in place by using optional parameters. * The calls collapse down into a single-line of Python code for a custom GUI should you want to write it that way. The other questions: Is this an attempt to draw people's attention to PySimpleGUI? To start a dialog about finding something better? Yes - I want to begin the process of getting some attention... get some ideas on how I can get in front of audiences that may be interested. I don't want to spam the Python world, but I do want to help people add a nice front-end to their programs. (.... then I don't understand the comment about pip install and dropping the PySimpleGUI into people's project folder -- that isn't necessary if its a std lib module.) The single-file aspect is a detail about today's implementation. Thank you for asking helpful questions. @mike
On 24/08/2018 02:04, Mike Barnett wrote:
Mike, A couple of points: 1. If you were to package PySimpleGUI into a pip installable library then this allows anybody who pip installs it to import and use it without copying it anywhere, (just like it being in the stdlib other than the pip step). 2. You can add a package to pypi, and improve on it & its documentation, without needing a PEP or any of the rigmarole needed to get it into the stdlib. 3. Once a pypi package gets a) stable & b) the traction for mass use it may be considered to inclusion into the standard lib, (or go there to die as any changes become very slow & constrained. 4. Python Ideas is probably not the best channel to publicise such a package. So all in all I would suggest concentrating on that initially. There are already 2 ways of turning a python program that uses argparse into a GUI, (Gooey for wx & Quicken for QT IIRC), with minimal modification. There are a lot of good arguments for teaching people to use argparse and to write their code to be able to run from the command line but there is not a mechanism that I am aware of for turning argparse based code into a TK GUI this might be a fruitful area to look at. It might even be a really great idea to get in touch with the authors of the two package mentioned to see if it might not be possible to come up with a unified library that allowed something like: ``` import pyUniGUI as gui gui.set_backend(tk) # or qt or wx (maybe others) @gui.from_argparse def parse_args(): """ Parse command line arguments (also defines GUI). """ ... ``` Can I also suggest taking a look at the Enthought Traits & TraitsUI (https://github.com/enthought/traitsui) packages to see what can be done for automating GUI generation. TraitsUI can use wx or QT (via various bindings) as GUI backends, (I know that is an unusual turn of phrase), but adding a TK backend would be a great move. -- Steve (Gadget) Barnes Any opinions in this message are my personal opinions and do not reflect those of my employer. --- This email has been checked for viruses by AVG. https://www.avg.com
On Thu, Aug 23, 2018 at 11:59 PM Steve Barnes <gadgetsteve@live.co.uk> wrote:
I started working on a project that does that a few years ago. It requires that you provide a function that takes an argparse.Namespace, and then it can make a GUI using tkinter. The code is on GitHub: https://github.com/codypiersall/cligui. The license is MIT. Example script using cligui: ``` # Makes a GUI appear. How fortunate! import argparse import cligui def get_parser(): """Create a parser that does all the best things.""" p = argparse.ArgumentParser(description='such a good program') p.add_argument('infile') p.add_argument('outfile') return p def do_the_best_things(args): """This does the best things. Note: "args" is an argparse.Namespace -- the thing you get back whenever you call argparse.ArgumentParser().parse_args(). """ print('got args', args) def main(): """This incredible function will make a GUI appear. Remarkable!""" p = get_parser() # call cligui.CliGui with the parser, and a function that takes an # argparse.Namespace as its argument. cligui.CliGui(p, do_the_best_things) if __name__ == '__main__': main() ``` For background: the goal was to be able to let my less-technical coworkers use scripts that I had written; but then I got a job elsewhere and stopped working on this. Cody
I think that this is a very interesting project. Having a simple way to do GUI's is great for beginners and experienced people. What I'd suggest is that this would be better if you could extent beyond the simple using the underlying toolkit. But I'd not use tk as the base I'd use PyQt, IMHO, its the best toolkit for building GUIs with python. I'd love to start with the simple and build on top the complex stuff only when I need it. Barry
On Fri, Aug 24, 2018 at 12:42 PM Barry Scott <barry@barrys-emacs.org> wrote:
While I agree that PyQt is better than tkinter, and I even wrote a simple interface for it (https://github.com/aroberge/easygui_qt), I think that any "single install, easy to use" GUI toolkit should be based on what's in the standard library and, for better or for worse, that is tkinter. So I think that the right choice was made for PySimpleGUI. André
participants (21)
-
Andre Roberge -
Barry Scott -
Brett Cannon -
Brice Parent -
Chris Angelico -
Chris Barker -
Chris Barker - NOAA Federal
-
Clément Pit-Claudel -
Cody Piersall -
Greg Ewing -
Jacco van Dorp -
Jonathan Fine -
Matthew Einhorn -
Mike Barnett -
MRAB -
Paul Moore -
Stephan Houben -
Steve Barnes -
Steven D'Aprano -
Terry Reedy -
Wes Turner