This is so timely! I am teaching CS to some high-schoolers and they just got introduced to Python, I want to hook them by getting them to make something that they can play around with. Could use this there :D
Somehow, it feels like, CS education is getting both easier as new low friction tools are being made available each day and getting harder because the sheer complexity and number of things to know to really understand anything at all the levels of abstractions is getting more complicated.
As a former high-school student who has done many little projects with tkinter at that time, I would recommend against dumping tkinter altogether for several reasons:
- with higher complexity comes higher versatility. I liked how it enabled me to be creative
- there are two well-written reference websites for learning it easily despite complexity (and that's important if you want your students to like/learn to read the docs)
- the tkinter being shipped with Python meant quite a lot to me
However, the reason I did that many projects is that part of my class wasn't really into programming, so if you think that learning and using this will be significantly easier than tkinter basics, go with it, but I would recommend leaving tkinter at least as an option for "those who want to know more", i.e. students who are considering studying CS.
Honestly I would advise against this for beginning coders. It's very "magical" -- there's no easy way to see how the text translates into a UI. It gives them no additional understanding of GUIs at all, really.
Whenever you encounter a new programming topic for the first time, it helps a lot if you encounter it in a fairly universal format.
I'm not sure about Python, but in most languages, there are simple GUI libraries that accomplish both of your goals: exciting students with interactive programs and helping them more deeply understand how GUIs are usually built and maintained.
I would advise to use processing.org in python mode. You can draw shapes like lines and rectangles on your own and use it to visualise the programming flow (e.g. draw many lines at different positions with a for loop, but change the color on every fifth to red).
Stuff like this is IMO the best way to learn programming for average people, because the first two blockers are usually:
* you don't understand what problem you are trying to solve
* it is all to abstract and you don't know what the thing you are doing actually is
Seeing what you do is a good way to deal with these points, because then programming can feel more like drawing a doodle instead of doing your taxes. Once they got the basics you could still dive into the rest.
IMO this would be the best way to start learning any programming language, because there is an simple IDE with examples, it is very visual and helps to convey basic programming structures just by doodling around.
If I (as a open source python dev) had to teach teenagers I would start with this
Yes, I was inspired by PySimpleGUI (and say as much in the introduction: https://guietta.readthedocs.io/en/latest/intro.html ). But I felt that PySimpleGUI did not go far enough in making things simple. It also supports multiple backends, so that may be a reason to keep things more structured. Guietta is just a thin wrapper over QT.
Well done. Both Guietta and PySimpleGUI surprised me by implementing an Internal DSL for Python. Both leverage Python's List literals to define a GUI grid layout. PySimpleGUI uses nested Lists to define the grid with a .WidgetType() style method used in each slot.
Guietta starts with a Builder Factory method with List literal varargs (one List arg per grid row). Instead of .WidgetType() wrappers, Guietta infers widget type based on List element type and string formatting rules. The resulting column aligned code has the visual look and feel of a grid/table and makes it very readable. The choice of Qt-only seems reasonable.
There is probably a category of DSLs that try to mimic a grid/table layout rather than a natural language DSL (many Ruby style Internal DSLs). This is definitely the style I use for SQL DDL, using a strict grid-like layout for the column constraints and moving the verbose parts (like CHECK constraints) to the table constraints section at the end.
I am not looking forward to taking over projects using that framework abusing underscore and double underscore magic variables.
The underscore "_" is a pseudo reserved variable in python. It is used in assignments like year,month,_ = readdate() to discard the return value and disable the lint warning about it.
It's worse than that actually, as in some cases the single underscore is actually meaningful (see the SO question linked in [1]). My recommendation is always to use a double underscore for throwaway variables, particularly since dropping into an interactive terminal can be really useful in some particularly hairy debugging situations (there's a great pycon talk about when it's a good idea to do gross things like that during debugging [2]).
Guietta looks interesting, but at a certain point if you're going to go with a visual representation of your gui to automatically generate it, you might as well go the whole docopt-style way and just have the whole gui defined in a docstring. That give you flexibility to have your own DSL as well (or jinja2 templates, or whatever), if you so decide, instead of needing to shoehorn python lists into the job. Plus that way you could actually modify the layout spacing, without much increase in complexity.
That being said, my usual recommendation for "I need a simple python GUI" is Toga [3]. The only downside is that Windows support is lagging behind MacOS and Linux, but it's not that far behind, so for simple stuff that should be reasonably acceptable.
After spending inordinate amounts of time debugging obscure side effect caused by "import as" and "from import". I'd reject that "from import as" on sight in code review.
Let's say you write a module httpclient doing this:
from ssl import sslsocket
import httplib as hlib
You can think of the code above as remapping and/or duplicating the whole library it's importing. Python imports involve complex local and global states (I don't pretend to understand most of it).
One direct effect on usage is that users of the library can call "httpclient.sslsocket" and "httpclient.hlib" as if they were provided by the library (the author certainly didn't mean to). This creates problem down the line when the author try to change the internal dependency, and this extends to other code also doing "import httpclient.sslsocket as sslsocket", creating problematic hidden dependencies.
More generally, this affects all import dependent features, like reload(module), mock, sys content, etc... imports are looked up and tracked by full path which doesn't always work as expected when paths are hot patched as above.
I used to work in a python shop (millions of line in total across the organization). Regularly had the problem with interns and new graduates abusing imports as above (sometimes even trying to change the existing imports because they though this was the better syntax). Then they couldn't pass their own tests (every new module must have a test) and asked for help after few hours of trying. Changing to a normal "import xxx" solved the problem. It's not always clear what was the exact issue, except side effects due to imports.
Let me take the opposite standpoint here and play the devil's advocate.
> users of the library can call "httpclient.sslsocket" and "httpclient.hlib" as if they were provided by the library
Well, they obviously shouldn't. And maybe they also shouldn't write Python code to begin with because, clearly, they're not able to adhere to Python conventions. Besides, why do you as the library developer care so much about what the users of the library do? If they don't follow your API specifications (proper API documentation should tell the users what they should and shouldn't do), it's their fault. I mean, people can and will shoot themselves in the foot all the time and in various ways. There's is nothing you can do about it.
> which doesn't always work as expected when paths are hot patched as above.
There is a reason why hot patching (and, by implication, mocking) needs to be done with care and only if you fully understand the consequences.
Regarding issues with mocking specifically, I suppose you're referring to nasty questions like https://stackoverflow.com/questions/14341689/how-to-mock-usi... ? Again, these things need to be done with care. (And of course the code also needs to be written in a testable way – no surprise here – and mocking should be done only if you've exhausted all other options.)
> It's not always clear what was the exact issue, except side effects due to imports.
Like you I am a Pythonista but I have honestly never run into any problems with selective imports (`from X import Y`) or import renaming (`import X as Y`) and much less even know what problems you're talking about. Overall, I find Python's way of importing modules rather straight-forward. (That is, as long as PYTHONPATH and __name__ are set correctly. From my POV, this is the only seriously annoying caveat.)
Anyway, I'm very open to changing my opinion but I'm afraid you'll have to be more specific about the issues you're encountering so often. (If you really did encounter them so often, I would think you would have noticed a pattern by now? No offense.)
Actually I started to develop Guietta exactly because using the QT GUI builder (Qt designer) was often too time consuming for simple applications.
Designer works great for GUIs with complex layouts. Having an intermediate XML representation puts a lot of distance between your code and your GUI. Sometimes this is good, other times is not. I rant a bit about this at the start of the introduction: https://guietta.readthedocs.io/en/latest/intro.html
I like the concept. I spent nearly a decade with Visual Basic, and got sick of building GUI's on the screen. It was a lot of repetitive manual labor when I didn't all that much care what my layouts looked like. Most of my programs are for limited use -- glorified scripts. I'd rather just sling a few lines of code and have it generate an ugly but functional layout for me.
1) tools like Delphi, VisualBasic (the classic version, not .net), and to some extent, HyperCard
2) GUI builders, which were popularized by Visual C++
#1 doesn't have (visible) layers or abstractions. It's a different way to represent your program. You place a few controls, tie them to actions (code), and that's your system.
#2 is like onions, with lots of messy layers, and tend to be way more cumbersome to deal with than the code itself.
I don't know of modern-day graphical programming systems. I haven't kept up with Delphi, but people who have claim the last useful version is Version 7 from 2002. After that, it went through some messy transition.
There is one GUI builder in Java I forgot the name, a plugin for Eclipse from Google, that allows to build GUI by drag and drop and jump into the code. It works directly by reading and writing any java code file, there are no extra files and layers of abstraction. It could understand Swing, SWT and a couple other major UI frameworks.
That's the only thing I know that's really seamless like old times.
It's been a while (I've never done autolayout and up) but I found Xcode Interface Builder to work in the fashion you describe. Probably not an accident as it descends from NeXT devtools which inspired e.g. VB (not sure about Delphi).
How well would these tools have worked with source control? Interface builder effectively uses XML files, but they are not meant to be edited/understood by humans. This effectively hides a layer of the "onion", but it makes it tricky to follow changes checked into VCS...
radio buttons still basically unsupported - no way of grouping them.
Add optional astropy units for values, maybe extending the tuple syntax: ('__a__', u.km). More difficult than it seems, because one needs to parse input strings. But very useful in a scientific environment.
'with' syntax still very limited, in particular locals() and globals() refer to the Gui class scope so for example anything imported at the beginning of the script is not available inside the with block.
Unit tests almost completely missing, also I have no idea how to properly test GUI code.
It takes many years and many people to build tools of that quality. Practically speaking it is way more easy to learn new language instead. I have no problem using Delphi and Lazarus for desktop applications. Saves me big amount of time.
For Free Pascal (which is used in Lazarus), you can use almost all of the native libraries (linked dynamically, and in many cases even statically). It is not as straightforward and easy as using _pip_ or _npm_, and maybe not as organised, but you can translate the headers to Pascal and get it working. You are not stuck with what comes with Lazarus or Free Pascal, or libraries that are exclusively written in Free Pascal.
I guess that depends on what you do. I've never felt that I do not have enough ecosystem in Delphi/FreePascal but I know there are areas where I would not be lucky if I ever went there. Then again on few occasions I had no problems creating pascal headers from C libraries I wanted to use. There are tools that depending on particulars can make it almost automatic.
Python4Delphi project has been around for around twenty years now, allows using Python from within a Delphi/Lazarus GUI framework:
https://github.com/pyscripter/python4delphi
Delphi and Lazarus compile to all the major phone, desktop web, targets but I only use it for desktop GUI projects as its the right tool for the right job.
I am lucky to work for myself and have non-technical clients so dont really have to worry about the latest and greatest just what works well for me :-)
For personal projects. For engineering managers, popularity of a language or a framework is a significant consideration from resourcing perspective. It is the driving force behind many migrations off Perl, i.e. inability to hire Perl developers in sufficient quantity to continue supporting Perl-based backends.
In my other life I used to manage bunch of developers while still developing myself. My criteria for hiring them generally was not their proficiency in particular tool but ability to grasp programming concepts in general and ability to grok any particular tool in short time. Practical experience in particular areas of course was a big plus.
Over the time this strategy proved beneficial. My team ended up having the highest salaries and bonuses in the company along with being given most interesting projects (developing new products from scratch as a rule).
I still went on my own after some time as I could not really tolerate that employer/employee style of interaction.
>My criteria for hiring them generally was not their proficiency in particular tool but ability to grasp programming concepts in general and ability to grok any particular tool in short time.
I'm curious how did you test candidates for this? Did you give them any specific tasks to accomplish and then evaluate their ability to learn?
I asked them what did they do (projects) and how exactly and what particular parts they were responsible for. After that if I still feel interested I would proceed to delve into details like how they handled this problem/that problem/etc. Sometimes would check references. This would give pretty good picture of what the candidate is capable of. I do not remember being disappointed.
I always used to agree with this. But I've been listening to an audiobook that discusses this very topic and it seems there are good reasons for going with the most popular option in situations where you're aiming for the least downside rather than the biggest upside.
One example given is that if you're booking a flight for an executive "to New York" you should pick JFK, not because it's the best option, but because it's the most popular.
The reason is that if you pick Newark, say, and it all goes swimmingly, the best you can hope for is a "thanks!" .. whereas if there's a delay or some other problem, the person is likely to blame you for picking "a weird airport" (this story comes from a British perspective – I'm sure Newark is better known amongst Americans.. to reverse the story, it'd be like an American flying into Gatwick instead of Heathrow). If they got delayed at JFK, they're more likely to blame the airline, etc.
I'm thinking of digging into this a bit further as I think some of this explains why certain programming languages, tools, and services grow in popularity while others don't. AWS feels like the JFK of clouds, for instance. There's also the old "no-one gets fired for buying IBM" adage at play.
People pick AWS or JFK not because it's the best option but because it's guaranteed by popularity to not be the worst.
>There's also the old "no-one gets fired for buying IBM" adage at play.
You seem to be mostly concerned with CYA here and in the JFK example.
>People pick AWS or JFK not because it's the best option but because it's guaranteed by popularity to not be the worst.
But this doesn't follow from CYA. It might be the best outcome for you, because your boss doesn't blame you. But it doesn't mean it's overall the best option.
I never had a great experience with IBM tools. They're the first example that comes to mind of software which gets bought because buyers aren't users in big corporations and buyers not having a personal incentive to choose better software.
In a large company with 100.000 employees where everybody loses 1h a week due to bad UX, slow UI and server restarts, you're losing multiple millions of dollars a week to protect your position.
If Newark is on average better than JFK, you're losing your executives time to protect your position.
I'm not saying protecting yourself isn't worthwhile, but it's a bad reason to pick tools from the company's perspective.
It might be the best outcome for you, because your boss doesn't blame you. But it doesn't mean it's overall the best option.
Absolutely, and that's the real point. I don't think I disagree with any of your points, but perhaps I am more resigned to the fact that people act how people act. I'm not super experienced in this area (which is why I was enjoying the book in question) but I believe this is all related to the phenomenon of "ambiguity aversion" (https://en.wikipedia.org/wiki/Ambiguity_aversion). I'm interested in how to engineer around (or cheat) these biases rather than present a purely logical argument for one technology (or airport!) over another.
Now I'm wondering if the best way to deal with this is to give the decision to the person who would suffer the consequences. If they make an informed decision for, e.g. Newark, that would maybe lessen the blaming if it goes wrong.
Why not? I mean, it shouldn’t be _the_ deciding factor but it certainly should contribute greatly to the decision.
Tools get popular for a reason. You get community support and a test-of-time guarantee that whatever you invest in today is more likely to last compared to the niche choice.
Sometimes/often for completely wrong reason. And even if the reason was good in particular context then suddenly the tool gets dragged to be used well beyond the original intent.
Glade was the best. Drag&Drop, creates a language-independent XML file, which your program loads and populates with events.
* Don't have to change the program to change the UI
* Don't have to change the UI to change the program behaviour
* Easy to include in version control
It was almost akin to HTML and progressive JS.
I wish there was a GUI toolkit where you would specify what kind of interaction you need, and it builds the right GUI elements with the right workflow following best practices by itself. Sort of like what Ruby/ActiveRecord does for databases.
Perhaps I'm missing something, but why the past tense for "Glade"? I thought that was still a completely viable thing to use these days, but I confess I haven't done any Linux GUI dev in several years.
Ah I came to comment this. Loved the GUI builder in Delphi, it's where I cut my teeth learning to program as a teenager.
Since then, I've seen .NET within Visual Studio almost get to the same quality we had with Delphi in 1995, but still way off.
Now that everything's a web app wrapped in something like Electron, it should be so much easier to have tooling like this, but yet we're all still building hugely complicated HTML rendering pipelines for something that was a solved problem a couple of decades ago.
I personally think the real reason those types of tools seem less common and popular today is that people remember for example the reputation that Visual Basic programmers got (by the way, I was one). Basically, any really convenient RAD/GUI tool has an association with beginner programmers or even users. The last thing programmers want to be identified with is a user.
Programming is manipulating cryptic colorful text. That sadly seems to be the definition we are stuck with. You start to get into anything that involves drag & drop, you are inviting other programmers to assume you are not good enough with cryptic text.
Its just a stupid psychological thing. And I think it holds back software engineering.
Have you tried QtCreator? If so, have you also tried QtDeclarative?
Having used QtCreator to build a medium sized GUI, it was a pain. The XML it produces is too unwieldy to manually edit, so that's out (though I did edit it a few times to overcome bugs in QtCreator)
The QtCreator GUI itself is very robust but if you want to do something that's off the beaten path good luck, you're gonna be doing a lot of trial/error clicking and iteration. There were times when everything was "right" in QtCreator, and the result didn't work...
I would much prefer to use something like QtDeclarative if I do it again. It's easier to tell the computer exactly what I want, and then get exactly what I want, when the language for expressing what I want is concise and small.
> You start to get into anything that involves drag & drop, you are inviting other programmers to assume you are not good enough with cryptic text.
It's more that drag and drop isn't really good for much when it comes to programming. You can build GUIs with it and some extremely simple tasks like email joruneys, but for anything else visual programming has proven to be pretty poor.
I believe that reframing the matter in terms of user empowerment might be the way forward. To create tools that help casual users accomplish tasks they might otherwise have needed a programmer for is to empower users. Excel is a classic example of user empowering software, as it allows people with the self-image of "user, not programmer" to effectively write programs, even if they may not recognize it as such. I think this reframing might help because scoffing at "user empowerment" would make somebody look like a jerk.
If your point is that some tools should be kept from people because they might cut themselves, then I think it's worth mentioning that scalpels are not generally sharper than other knifes that are available to the public. (Joerg Sprave has decent video debunking many scalpel myths: https://www.youtube.com/watch?v=vHTHqWcDaQ8) Furthermore scalpels are generally available to the public too: https://www.amazon.com/s/?field-keywords=scalpel
Analogously, the tools already available to computer users are tools that could harm the user if used improperly. To not empower users because they might harm themselves isn't progressive, it's paternalistic.
It kind of popped up out of nowhere, fully-formed, or at least I became aware of it when it was pretty mature. It's basically Visual Basic for Python, and worked really well. I have no idea why it wasn't more popular.
I played around with Boa Constructor and WxWidgets back in the day, in fact it was the first cross platform GUI library I seriously looked at for Python, but in the end settled on PyQt. It's a lot more complete and capable, with excellent documentation.
I have always preferred to code my UIs though, rather than use a GUI designer. I just find the back-and-forth between graphical designer and code an annoying extra context switch every time. Also in code I can position elements exactly, or use sizers very fluidly where GUI designers are fiddly and imprecise. They can be useful to do an initial mockup, but not much more so than pencil and paper. YMMV, we all have different visual and mental cognitive models for these things.
There are some disadvantages, though. If you're looking at WinForms or VB UI with two buttons, e.g. yes/no, there are things you can't easily and naturally see at a glance.
* What's the tab order? (Usually whatever order they happened to be created in, which is often wrong after the UI has gone through some changes.)
* Are they really exactly the same size or only almost the same?
* How do they behave when the window is resized?
* Does one button have one of its many properties set slightly differently from the other one? (Have fun inspecting them all and make sure to not accidentally change anything while doing so.)
* Did you just accidentally move one of the buttons one pixel while inspecting things?
I prefer doing the UI in code, so that everything is clearly spelled out and not hidden in some properties panel. In WinForms it works pretty well with TableLayoutPanel.
It's not just the drag and drop, it's the drag and drop and edit (single) callback. Like drag a button in the middle, resize it, change the text and then right-click and start coding what pushing it does. Now a days it's not push button but mouse over, mouse down, mouse up, press, long press, triggered, etc. etc. and I have to manually find or create the right source code file linking itself to the GUI form file.
Qt and it's designer is great until you try to deploy to mobile devices. That aside, I find the non-visual components of delphi/lazarus the easiest to use when doing GUI work for the desktop. You drag a data connection, a datasource, give it a table, some filtering, connect it to a grid and the grid handles all the CRUD operations for you. Even at design time! Hard to find that ease in Qt.
PS: I really love Qt. It lets me do things no other framework can easily do. I love building performant, graphically heavy and fast user interfaces. It just wasn't built for mass-producing desktop forms that are connected to a DB.
Second this! I was soo excited about the Google App Maker as the cloud equivalent, but of course, they shelved the product and will turn it of Jan 19th 2021. The alternative they are touting, "AppSheets", isn't really the same and geared towards "no code".
You don't even have to go back that far. XAML and C# developed with Visual Studio and Expression Blend is a fantastic experience, it almost makes me wish Silverlight was still around.
WinForms in Visual Studio is fast enough, but working with WPF and XAML certainly used to be painfully, painfully slow! Visual Studio would grind to a halt and memory usage would go through the roof.
In fairness, I haven't done any Windows desktop development for some time, so the XAML designer might be less crap nowadays.
As the author of another open source GUI builder tool (https://github.com/zubairq/pilot) I think that the simplicity of tools like Guietta really make it easy to play around and build things fast, so I like it
Someone once told that that is the way to do it and so I always do (this is not how I normally operate ;)). There is no practical use though I think. But, it looks nice :)
Kind of like a phonebook starting with companies like AAAGarden, now you want your module name to be short to get to the top ;)
black sorts alphabetically, with standard lib first, then 3rd party imports, and user/local imports last. Blocks are separated by a blank line. `from ..` imports come after `import ..`.
Especially the alphabetic ordering is important in my view. Makes parsing/reading and spotting duplicates much easier. It is also PEP8 style [0].
For all these reasons, I think the pyramid style is awful in comparison.
And PEP 8 doesn't mention sorting the imports. There are even counterexamples which aren't alphabetically sorted. It does mention grouping though.
Since Python imports can have side effects, the order can matter. But to the extent that it doesn't break anything, alphabetically sorted groups seems deterministic and readable.
This looks great. I have previously written a small GUI application with Qt where it's just a slider and a text label, and when the value of the slider is changed, a command is ran and the label updated. In quickly hacked together Python/Qt, it's 71 lines. It seems like I can cut that down quite a lot by using this. I will have to test it. Thanks!
I once made a simple little GUI generator based on effbot's "Generating Tkinter User Interfaces from XML"[1][2]. I added a tiny parser (written with SPARK[3]) that converted a simple DSL to XML (technically an ElementTree object, the actual XML isn't serialized/emitted at any point) which is then "realized" as a tree of Tkinter widgets with event callbacks.
In the example, there is the button called 'Calculate' and then action define in "gui.Calculate" block. But what if the name of the button was 'Calculate it'(with the space between words)? The action header would be gui.'Calculate it'?
Hello, Guietta author here. For most widgets, the name is derived from the widget text removing all non-alphanumeric characters. So in your example it would become gui.Calculateit
It is also possible to set a custom name using a tuple syntax (widget, 'name'). Like this: (['Calculate'], 'myname')
Slightly off topic: Does somebody have a recommendation of a toolkit or library for simple data entry and display with Python? Basically I want to replace Excel/Calc for mostly tabular data, because I hate the programming and data access model (e.g. instead of writing B$8 or sum(A9:A23) I would like to have map/reduce function with reasonable variable names). But the presentation and entry speed is much better with spreadsheet software, than when using some ad-hoc plain text format for simple parsing with python.
It is possible in Excel to have named cells and to use python. Personally, I think this is better than what you propose unless you want to spend the next couple years trying to make a business out of it.
No, you have to manually update widgets assigning them their new value (strings, and for labels also lists and dicts). I will think about such a feature but I have no experience with such dynamic frameworks :)
Then your central state is assigned to a Subject and all widgets have an reference to an observer. As soon as the central state value changes, the callback in the observer is triggered and you can fire the update method for the widget using the central state value.
_ is typically used to i18n strings with gettext, it seems like poor naming for a layout-related function like a spacer.
Apart from that, this seems to be a wrapper on top of PySide/QT to speed up development of basic forms. I don't find it particularly attractive, I have a feeling one will have to drop into QT as soon as requirements get slightly complex. Then again, if it gets more people to approach QT and desktop GUIs in general, it's welcome.
I realized too late that _ is used for i18n. Well, 10 minutes late maybe, but I had already completed the first test GUI and it looked so nice that I could not turn back :) If you have ideas for an alternative syntax, I am all ears.
If you look in the tutorial, there is also a ___ (three underscores) magic widget for special layouts :) I can see the difference between one and three, but between two and three it becomes difficult :)
Guietta author here. In fact I am Italian, but the name is just a diminutive of "GUI" - in Italian it sounds something like "small and cute GUI".
I have a friend called Giulia and she initially thought that it was dedicated to her :)
AFAIK a library that uses LGPL3 modules without any modification is allowed to be licensed differently, provided that the final product allows the LGPL3 modules to be recompiled and/or swapped for others and that the source for the LGPL3 modules is provided.
You can follow whatever terms you desire for your application as long as you fulfill the requirements of the licenses of all modules that you use. In case of MIT, it is attribution; in case of LGPL3, you need to make the source of the LGPL3 module available and you need to make it possible for the user to swap the compiled module you ship for their own version of that module.
Thanks for the heads up. I confess that I did not look deeply into library licenses while setting up the project. I will add a note about PySide2 being LGPL in the readme.
Is including arbitrary Qt widgets doable (whether now or in the future)? A lot of my use cases for PyQt5 revolve around QWebEngineView; would be great to be able to throw that widget into a Guietta layout with the extra buttons and such I'd be using around it.
Yes, any QWidget instance can be used directly in the layout. If then you want to reference it, the best option is to use the tuple syntax to assign it a name: (widget, 'name'). Check the slider example out (slider.py), it does exactly this.
Quit is a built-in class, because is very common. There are also Yes, No, Ok and Cancel builtins. You could do the same writing ['Quit'] and binding it a function that quits the program.
Binding is done using QT's signals/slots mechanism under the hood, and can be done in several ways:
- using the 'with' statement as in the example, but this is often limited
- using an events layer, that is, a replica of the GUI layout, with a callable for each widget that you want to bind.
- using the @gui.auto decorator on a function: it will try to guess.
This is just what I was looking for! I developed a very simple (and slightly similar) TUI library, but I need to at some point move to a GUI, and this is perfect for it. Thank you!
Hello, author here. I have tested Guietta on two different macs (mine and a coworker's) and it worked in both cases. There is no variable called 'loader' in Guietta's source code. Are you trying the example in the github readme, or a custom script? Which MacOS version? If you wrote your own script.py, could you please copy it into a github issue?
'result' and 'Enter numbers:' are exactly the same thing - two QT labels. The example code just changes the first one's text. If you run the code, you'll see it by yourself.
PyQt is not really difficult, just boring. And a bit of magic was indeed the intended effect :)
I don't want to shit on anyone's work but there are so many wrappers around qt, gtk and the others. I wish more people were writing guis frm scratch as opposed to wrapped the same old shit.
This project explores an extreme niche in original ways, which is the whole point of adding to the existing "so many wrappers".
And regarding the "same old shit", you'll be entitled to spit on mature frameworks when your GUI from scratch supports screen readers, 3D acceleration and printing with the same API on Windows, Linux and OSX.
Somehow, it feels like, CS education is getting both easier as new low friction tools are being made available each day and getting harder because the sheer complexity and number of things to know to really understand anything at all the levels of abstractions is getting more complicated.