GeoCities and the Qt Designer
In a review of my book, Practical Maya Programming with Python, reviewer W Boudville suggests my advice of avoiding the Qt Designer is backwards-looking and obsolete, such as writing assembler instead of C for better performance, or using a text file to design a circuit instead of a WYSIWYG editor. I am quite sure he (assuming it is a he) isn’t the only person with such reservations.
Unfortunately, the comparison is not at all fair. Here’s a more relevant allegory:
Hey, did you hear about this awesome thing called geocities? You can build a website by just dragging and dropping stuff, no programming required!
We’ve had WYSIWYG editors for the web for about two decades (or longer?), yet I’ve never run into a professional who works that way. I think WYSIWYG editors are great for people new to GUI programming or a GUI framework, or for mock-ups, but it’s much more effective to do production GUI work through code. Likewise, we’ve had visual programming systems for even longer, but we’ve not seen one that produces a result anyone would consider maintainable. Sure, we’ve had some luck creating state machine tools, but we are nowhere close for the more general purpose logic required in a UI. And even these state machine tools are only really useful when they have custom nodes written in code.
Finally, WYSIWYG editors can be useful in extremely verbose frameworks or languages. I wouldn’t want to use WinForms in C# without the Visual Studio Designer. Fortunately for Pythonistas, PySide and PyQt are not WinForms!
I have no doubt that at some point WYSIWYG editors will become useful for GUI programming. Perhaps it will require 3D displays or massively better libraries. I don’t know. But for today and the foreseeable future, I absolutely discourage the use of the Qt Designer for creating production GUIs with Python.
This remind me of a discussion i recently started regarding visual scripting tools in Unity vs code: http://forum.unity3d.com/threads/visual-scripting-vs-writing-code.263858/#post-1744919
Almost all people favored writing code (if you know how to) vs. using visual tools (i was actually looking for reasons/scenario to use visual scripting tools, instead of reasons NOT to use them).
Interesting view. Mine is quite the opposite. After coding UIs manually first, I really enjoy working with QDesigner. (because I believe you should learn how to do things manually first, before you take shortcuts or automate).
Unlike pages of Qt UI code I find especially maintenance to be easier, as long as people know how to use Designer. It is a very powerful tool once you know the ins and outs. (of course, bad tool usage can often be worse than not using a tool at all!) I like that I can quickly open UIs from other developers and get a preview of the UI, and I can easily adjust and modify it, without digging through pages of code.
Often I also trust its reliability more than in-house code, especially programmed by junior developers, who may not know the best practices regarding Qt UIs. Who may not have proper testing in place, etc. After all, Designer itself has been tested and so has the code that it produces – so there is a certain level of reliability to it right from the beginning.
Speed: never been an issue, at least not on I could trace back to Designer. In that regard the C vs assembler analogy doesn’t quite hold up for me.
I can understand why some people are hesitant – even I was. There is the learning curve of the tool. You may be an awesome Python/C#/Qt/whatever dev, but in this tool you are still a beginner again. And initially you want to go back writing things by hand because you think it’s faster, more reliable (in the beginning it may just as well be) and more convenient. But that thinking is the same that currently holds our artists back from learning Gen4 tools: It’s just more convenient to stick with what you know and not take the plunge to learn something new, because the short term gain of not learning is more important to you than any long term gains.
In general, at a certain complexity level, I would not advise people to hand code Qt UIs. But I know there are often justifiable exceptions. But otherwise I would urge people to learn Designer, and learn it well.
(I have the same issue with Unity. I prefer to do things in code, but often there are more powerful and faster ways to do things via the GUI settings)
Robert, I absolutely disagree. Anyway, if you don’t mind, I’ll use this as fodder for a future blog post (2 weeks probably). Thanks as always for your feedback though!
would be boring if everyone would always agree. I’m looking forward to hear more why you think differently, especially when it comes to maintenance and sharing code. …and for the record, I’m not one of those maniacs who use .ui files directly in their code. let’s not even go there ;)
While I can understand the logic behind this, comparision to wysiwyg HTML or visual coding tools is not fair when it comes to UI. I’d compare this to node/hypershade editor vs building rigs by pure code – which is best? The answer is, depends on the situation. For most medium-to-complex stuff, in experienced hands – code is irreplaceable. But there are many situations, not only limited to prototyping or initial impelementation, where you can get the job done faster with wysiwyg tools. I’m more than comfortable with building UI via code, but sometimes I wish there was a good way to build maya UI visually – mainly because sometimes you don’t need that much control offered by code, e.g. arranging simple dialog boxes, about screens, panels… I do not use QT designer, as I really want to stick with cmds-based widgets, and other visual tools I’ve seen aren’t quite up to the task – unless someone wrote something smarter after the last time I’ve searched.
Viktoras Brings up building rigs in code vs using visual editors. In my experience with rigging, being able to do it via code (which I then create custom UI for) creates repeatable customized operations that are much faster and more reliable than doing it by hand via Out-of-the-Box Visual tools. I think , carrying the idea back to Visual GUI Tools, the custom needs of individual situations will often elude the capacity of the Visual Tool. If you have a snippet that builds a UI widget it’s always faster.
Hi Viktoras. I think that HTML tools are without a doubt the most direct comparison to the Qt designer. Both are for “view” functionality and unable to tap into underlying business logic directly.
Node networks (such as hypershade), on the other hand, represent complete state machines and are a natural fit for GUI tools. This can be thought of a specific type of data binding, which is pretty much the simplest form of UI imaginable.
Unfortunately a reason the Designer falls down in Maya in particular is data binding works well for tabular (database) data, or 1-1 relationships (node editor), but cannot be used where you have more complex interactions from a GUI (such as performing complex operations on a node network, which is basically what all Maya GUIs do).
On the other end of the spectrum are the trivial cases- about screens, dialog boxes, etc. In this case, the amount of overhead the designer generates is *enormous*. It is far simpler to just use code. An about screen becomes one class and a couple lines, rather than several classes and several hundred lines.
The Designer should be limited to prototyping and exploration and that’s about it.
Again, thanks for the feedback, this will all make it in to a good followup :)
@rob:
“On the other end of the spectrum are the trivial cases- about screens, dialog boxes, etc. In this case, the amount of overhead the designer generates is *enormous*. It is far simpler to just use code.”
I’d love if you’d give some examples, Rob, e.g. for how the overhead causes you problems.
I’ve been recently working on a management interface for our QA-Tools, which is tabbed and has many widgets for user management, checklist creation, project management, report generation, etc. I haven’t noticed any disadvantages of using Designer. Yes, the .py files created by it are long, but they exist as separate files. They don’t clutter and there’s little reason to work with them. They perform reasonably fast, and it’s not like what is being done is performance critical. (*)
About state machines – I think your expectations are a bit too high for poor old QDesigner (although I do like your idea!). I think it’s okay at what it does (not perfect, or else people wouldn’t care for QML as much!), but if you ask too much from it, you’ll be in for disappointment. But apart from not offering better workflow and/or features, I don’t quite see the criticism – or maybe I just didn’t run into the problems you expected. I think an example would help to illustrate your point.
(*) I have to add that I’m not a fan of Layout managers – not in code and much less in Designer! Could that be related to your criticism?
QT Designer, I find it infinitely helpful in creating top notch UIs very quickly, embedding logic in them that I don’t need to code, signals/slots, etc.. Just the simplicity of it’s layout management, we aren’t talking saving a few minutes here, with complex UIs, we are talking about a metric crapton of time.
The ability to dramatically change the UI and dynamically have it built on load by parsing the UI file is just so helpful. It also doesn’t rape my files with thousands of lines of boilerplate UI code. I do set my connections on the python side, not in Designer. Don’t think of QT Designer as a ‘visual programming language’, it’s a place where you make the 2D elements your code will use. Would you ever code an icon instead of using photoshop? (I have a friend who does this!)
Often the guys I know that are averse to Designer are just making super simplistic UIs. I try to get my guys making UIs with movable panes, resizing properly, etc. There is no limit to usability, because there’s no frustration in setup. I will ask them to make the UI tighter, and resize properly and this is a 10 second job in Designer, but not so easy at all in code. (you have to have some things expand, some be pinned, some never change width, etc etc)
The only catch is code-generation of dynamic UI, where you then have to either dynamically load UI file stubs into a widget like a list or so, or have code in python that is generating UI, but this is pretty rare.
I find it interesting that you are so against something as useful as QT Designer, but are a big PyMEL evangelist. IMO PyMEL is just way too much crap layered on Maya to be useful for anything high performance, which most of our work needs to be in animation with per-frame operations, batching, etc.
Thanks for the replies everyone. I now have a much better understanding of why people still use and support WYSIWYG UI building tools like the Qt Designer. I will definitely try to incorporate all this feedback in one or two upcoming posts.
I would suggest phmel is a favorite because it makes my code read easier. Qt designer makes my code intelligible.
Through clear code I can reason about edge cases as I follow the logic in all it’s branches. From this I can write clear tests*. And I can fix bugs clearly, in a way other reviewers can verify what I’ve done in a single atomic changelist.
I’m not anti qt designer on principle. I’ll happily give anyone a chance to argue for its use and I’ll do my best to give it a fair shot if and when such arguments come up in my work life. But my initial impressions do not correspond well to my preferences for elegant code.
* well, GUI testing is difficult. Here I’m referring to the term in its most general, even if it just ends up being custom data for running manual inspection tests.
@Rob
I’d be interested in hearing you thoughts on a workflow like the WPF/YAML editor in Visual Studio?
Here it seems you have both high convenience (whether that to you means coding or dag and drop), high discoverable and full control.