4 ms·

How would javascript reduce the code necessary for a gui or help you cross platform? UIs are very different between phone / desktop so even if you stayed with

by pfranz 9y ago

How would javascript reduce the code necessary for a gui or help you cross platform? UIs are very different between phone / desktop so even if you stayed with javascript you'd be learning different libraries or rewriting everything to conform to the other platform. Personally, I tend to use QtDesigner to layout apps and Qt for implementation (this applies for PyQt/PySide or C++). It tends to reduce the code necessary to get something up and going and helps keep things more MVC. Tkinter is the standard UI library for Python, but I haven't used Tk in close to 15 years. Tk worked well enough for smaller Perl or Tcl apps, but when I first moved to Python professionally (around 2005) I bounced between WxWidgets, PyGTK, and PyQt. Qt was always ahead of the rest, but had licensing concerns at the time. I feel like there's a bit of roughness conceptually between Qt and Python that are just fundamental, but I think that's more on Python and asynchronous needs of UIs. I was trying to figure out when this decision was made. I see references of tkinter dating back to 1999 (tk is from 1991), but it looks like it was officially included along with Python starting in 2008. If true, I would think it would be obvious it wouldn't be the best general choice going forward by that time. But I can see the reasoning behind choosing it due to licensing, size, volatility of api.

jimnotgym 9y ago
PyQt is really difficult for me to use because of the license, I'm afraid. In all of the comparisons I found on different frameworks the criticisms of Tk all seem to be about the looks (in that it didn't take on native styles), but that seems to have been resolved. It doesn't affect my in house use case either. The other thing mentioned is that Qt has more widgets. I don;t need those right now. Therefore it would seem that for simple in house software Tkinter was a pretty fair choice. > I feel like there's a bit of roughness conceptually between Qt and Python that are just fundamental, but I think that's more on Python and asynchronous needs of UIs. I can't get over this. I am not a good enough scientist to explain what the problem is but there is something that just doesn't feel right with Python GUI programming.
- pfranz 9y ago
  Yeah, Tk just looks and behaves (as a gui) very crudely, but my preference for other gui libraries was always ease of use, organization, and troubleshooting. Verbosity would go under ease of use and organization. I think Gtk and/or Wx had a gui to layout widgets, but it was so far behind Qt. I still don't have a preferred way to organize Qt code, but it offers almost too many options. The main book on PyQt, Rapid GUI Programming with Python and Qt, doesn't use Designer and all the guis are done programatically. It's a great way to learn the library, but horrible for maintenance. Most of the guis Ive needed just use basic widgets. I've poked at the browser and opengl widget, but never really used them. I have had to add custom behaviors to widgets to match other apps and it seemed pretty well suited. Funny enough, the Qt organization has stopped development on Widgets over 5 years ago (which is all I've ever really used). They consider Widgets feature complete and are focusing on QML. > there is something that just doesn't feel right with Python GUI programming. I think it's because GUIs, by their nature, are event driven and require parallel execution. Python doesn't do this very well so there's awkward syntax, a few competing paradigms, and unexpected behaviors (with memory, code flow, etc). I can see an argument for Javascript in this regard.

by pfranz 9y ago

jimnotgym 9y ago

PyQt is really difficult for me to use because of the license, I'm afraid. In all of the comparisons I found on different frameworks the criticisms of Tk all seem to be about the looks (in that it didn't take on native styles), but that seems to have been resolved. It doesn't affect my in house use case either. The other thing mentioned is that Qt has more widgets. I don;t need those right now. Therefore it would seem that for simple in house software Tkinter was a pretty fair choice. > I feel like there's a bit of roughness conceptually between Qt and Python that are just fundamental, but I think that's more on Python and asynchronous needs of UIs. I can't get over this. I am not a good enough scientist to explain what the problem is but there is something that just doesn't feel right with Python GUI programming.

pfranz 9y ago
Yeah, Tk just looks and behaves (as a gui) very crudely, but my preference for other gui libraries was always ease of use, organization, and troubleshooting. Verbosity would go under ease of use and organization. I think Gtk and/or Wx had a gui to layout widgets, but it was so far behind Qt. I still don't have a preferred way to organize Qt code, but it offers almost too many options. The main book on PyQt, Rapid GUI Programming with Python and Qt, doesn't use Designer and all the guis are done programatically. It's a great way to learn the library, but horrible for maintenance. Most of the guis Ive needed just use basic widgets. I've poked at the browser and opengl widget, but never really used them. I have had to add custom behaviors to widgets to match other apps and it seemed pretty well suited. Funny enough, the Qt organization has stopped development on Widgets over 5 years ago (which is all I've ever really used). They consider Widgets feature complete and are focusing on QML. > there is something that just doesn't feel right with Python GUI programming. I think it's because GUIs, by their nature, are event driven and require parallel execution. Python doesn't do this very well so there's awkward syntax, a few competing paradigms, and unexpected behaviors (with memory, code flow, etc). I can see an argument for Javascript in this regard.