If you can't express what's wrong it will be even harder to find a solution.
Put in plain English it is like this. I write quite a lot of code that integrates various enterprise systems together. Things like EDI management, and 'brokers' between incompatible API's. It is usually a mixture of Python/Bash/SQL. It is not my full-time job to code, but I get things done. As complexity increased I learned about version-control, OOP, and unit-testing. I have some pretty complex stuff in production. So I can self-learn all of those things, but not Python GUI programming
The kind of thing I would happily launch from the command line, often needs a GUI when end users are involved. Even to have an app that takes an input>click OK>do some API stuff>return an answer seems absurdly complicated in Python and [insert whichever GUI framework]. In fact I find it simpler to add a web front end and a server than I do a desktop GUI. Qt was never on my list as I have enough battles to handle without negotiation with bosses for PyQt licensing costs. Hence my interest in this development.
I didn't have this trouble with VB6 or VB.NET. Draw a box>draw a button>double-click the button>add the code you want to run when the button is clicked.
When I do the same in Python I have dozens of lines of set-up code. I have a window with a text box and a button, surely that should be three lines of code (like in html)? Then I find that things are not running in the order I expected... Imagine for instance I want to put an alert box up that says "working", then call the function to do the work, then take the alert box away when the function exits...My Python head says this should look like this
def on_ok_clicked(event):
alert=framework.alertbox(text="working...")
do_important_blocking_stuff()
alert.destroy()
There doesn't seem to be a Pythonic or indeed simple way to handle these super straight-forward use cases. I have no aspiration to be a UX person, or learn a new paradigm just to have a button that says "GO!". I'm guessing from the other comments that Qt for Python is not going to be my savior.
No, that's not "your python head", sorry, that's your "VB head" at best. That's lack of knowledge of how desktop GUI paradigms actually work and what an event loop is and how it interacts with threads.
I do not disagree that VB (and Delphi) did a better job at hiding these concepts from the "just getting it done" crowd, but don't blame it on Python if you don't have a grasp of how C++ GUI toolkits actually work.
I'm not blaming it on Python, honestly. I'm just really surprised that there isn't a framework that will hide that stuff from me like VB did. You are a 100% correct in that I don't know anything about desktop GUI paradigms, or C++ GUI toolkits. I really don't have the bandwidth to find out either! I'm also surprised that I need to. I don't think that is even my VB head, I am a business systems person who has successful modeled a physical process in software. In a recent case I did all of the work negotiating with vendors/management/users, I found the bugs in the vendors API, and I did this to an absurd deadline (with almost zero budget) created by a a vendor withdrawing a product with no notice. That's the kind of absurd thing us plebs in the "just getting it done" crowd have to do all of the time. But I am finding that simple GUI launchers for my software are really complicated in Python with the frameworks I have found. I am shocked that this is the piece that is defeating me! As I said before, I could write a web front-end for this kind of thing relatively easily (in the above case it was a hardware requirement that lead me to try again at the desktop GUI). Perhaps this is why we see so many people looking at the web-app-on-the-desktop that is so derided on these pages?
Although I've heard good things about Lazarus IDE, probably your best bet for such projects. Pascal is not hard to learn, or re-learn.
I don't really like working in an IDE, or need to. I am happy to design GUI components in a markup language, for the kind of use cases I am talking about.
However would it not be possible to hide the complexities of managing a GUI in the framework/bindings so that the Python user just has to deal with "Someone clicked OK>Run this function" in as easy a way as VB did?
I mean I don't know much about how to send a http request in C++, but I can do it in 'requests' without much problem!
Thanks for the advice on Lazarus. Not FOSS and not desktop, but I have been looking at Anvil recently, which makes it really easy to code web app front ends, allowing me to concentrate on backend stuff.
If you don't want one, QML is what you are looking for.
Saw anvil and it looked interesting, aren't apps tied to its system however?
In other frameworks I just say "this frame (containing lots of widgets) is scrollable" by setting one property to true and it just works. Including vertical and horizontal scrolling, mouse-wheel support, and standard keyboard shortcuts like page-down etc.
In Tkinter this seems almost impossible. It takes dozens of lines of code; many events must be implemented manually, including low-level things like calculation of scroll offsets; good mouse-wheel support is very difficult; etc. It feels more like I'm _implementing_ (rather than _using_) the scrolling widget. And in the end it the UI flickers like crazy during scrolling.
Is there something I overlooked?
However I still find similar issues with Tkinter as I discussed above, I really didn't expect to have to learn how Tk event loops or whatever worked just to get my code to execute in the order it is written in! I guess I was just naive.
The blocking thing you can do in two ways. First, put your blocking stuff in another thread and do it there, and when it's done call back into the main thread to tear down the alert.
The other way, to play nice with the event loop, is to do something like:
makemydialog()
Tk.update_idletasks() # process events so that the dialog shows up
do_my_stuff
teardown
After you get a bit more experience with doing some GUI stuff, and if you want to have a more long-running GUI, it will become more natural to think of initiating everything in response to event handlers, as opposed to the batch model of running your program linearly from top to bottom.
I guess looking at it, having a process that is going to take a few seconds and must block the user from progressing until it completes is perhaps not the scenario most tutorials envisage. Thanks again