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
One thing to add is a graph.
or were you thinking of something else?
There'a a gap a mile wide between
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.
That's the only thing I know that's really seamless like old times.
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.
Meta-level: add this list to github :)
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 :-)
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.
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?
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.
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.
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.
He's in lots of videos, TED talks, etc. if you want to get the cut of his jib for free, e.g. https://www.youtube.com/watch?v=iueVZJVEmEs
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.
* 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.
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.
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.
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.
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.
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 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 was just something so natural about the way you could quickly throw together a UI and then hook everything up to it.
* 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.
Petzold wrote about this approach: http://charlespetzold.com/etc/DoesVisualStudioRotTheMind.htm...
Never quite a polished as Borland's offering of yesteryear (the GUI editor always felt clunky) but it's perfectly do-able.
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.
Same applies to C++ Builder, which MS still hasn't been able to match. C++/CX was the closest we got on VS, but then politics killed it.
In fairness, I haven't done any Windows desktop development for some time, so the XAML designer might be less crap nowadays.