You must tell me what this amazing compiler that you are using is then. Apparently it compiles in zero time :-)Originally Posted by lewis
Either that or you always code your GUIs exactly right first time :-) :-)
You must tell me what this amazing compiler that you are using is then. Apparently it compiles in zero time :-)Originally Posted by lewis
Either that or you always code your GUIs exactly right first time :-) :-)
Save yourself some pain. Learn C++ before learning Qt.
I propose a race. I create a screenshot of a simple dialog. When I say go, Chicken Blood Machine uses Designer to create the dialog, while Lewis hand codes the dialog. The winner gets all bragging rights.Originally Posted by lewis
He he! I'm game!Originally Posted by Brandybuck
Save yourself some pain. Learn C++ before learning Qt.
There are a couple of reasons I hand code instead of designer:
1) in Qt 4.x, the designer crashed on me with complex, multi page dialogs. I reported the bug and it is reportedly fixed in 4.x, but I am leery of relying on a tool that is potentially unstable.
2) IMHO, the code generated is rather ugly
3) I like to build on re-usable tools that make hand coding easier and faster
4) My app requires highly customized colors for everything and it is easier and better to build re-usable components by hand.
Which version? 4.2.2 is the most up to date...
Hmm... Why?2) IMHO, the code generated is rather ugly
Oh, I have to agree with you on that - me too. That's why I use designer to make hand coding easier and faster as I don't have to code all the widgets and layouts and their properties by hand.3) I like to build on re-usable tools that make hand coding easier and faster
Have you tried using stylesheets?4) My app requires highly customized colors for everything and it is easier and better to build re-usable components by hand.
BTW. Lewis, Chicken Blood Machine - what about the contest? Any winners?
I'm not sure I agree, but lets suppose this is true...Who cares? you shouldn't even have to look at auto-generated code (except when you're learning).2) IMHO, the code generated is rather ugly
No image was posted, no contest was started. But I would be happy to take up the challenge any time.BTW. Lewis, Chicken Blood Machine - what about the contest? Any winners?
Save yourself some pain. Learn C++ before learning Qt.
Regarding the designer crash:
Yes, this version as well as 4.1 were the versions that crashed on my complex multitab dialog. I submitted the problem to Trolltech and was told it was fixed in 4.3. But as I said, I am leary of relying on tools that could be unstable.
Well because, for one thing, for each widget, it creates a giant class holding members for everything. And it can be difficult to decipher what is mandatory and what isn't. I just find it hard to read. But I guess if your using the designer exclusively, this doesn't matter.Originally Posted by smacchia
But, I found it a bit painful to create my own re-usable widgets from within the designer. Its just faster and easier for me to do it by hand.Originally Posted by smacchia
Yes & no. I've used a combination where it makes sense. There are so many "company" colors for various states, etc, that I have created a singleton for the different palettes and colors. This is almost as easy to change as a style sheet. Then my custom widgets derivations, for say pushbuttons, set the palette depending on the state, calling on the singleton for the specific palette. I found when using the stylesheet for pushbuttons, I lost the platform specific style. And in combo boxes, using the palette didn't colorize the menu for all L/F, so a style sheet worked well there. Hence the combinatory (is that a word?) approach.
gfunk (6th March 2007)
If the problem was fixed then what's so unstable with it? Applications have bugs, you know... there is nothing unusual in it. Bugs get fixed (introducing new bugs of course.... ) and stability improves.
The class is private, so what difference does it make? How do you code your hierarchy of widgets? In a hierarchy of classes? How would you code a QWidget having a QGroupBox with three checkboxes and a push button (sibling to QGroupBox)?Well because, for one thing, for each widget, it creates a giant class holding members for everything. And it can be difficult to decipher what is mandatory and what isn't.
Why read it? You can incorporate every change you may require in the implementation class (derived from QWidget or one of its descendants) not even touching the ui class.I just find it hard to read. But I guess if your using the designer exclusively, this doesn't matter.
The disadvantage of such approach which you can't deny is that the UI has to be created by the programmer and not by a designer (meant as a person that sits all day and places buttons on forms) - every change to the design of the form has to be made by a programmer. This is not the case when using Designer. As long as you don't remove items which are referenced in the implementation class, the programmer doesn't have to do anything to have a working application.But, I found it a bit painful to create my own re-usable widgets from within the designer. Its just faster and easier for me to do it by hand.
It's like setting a stylesheet for the QApplication object.Yes & no. I've used a combination where it makes sense. There are so many "company" colors for various states, etc, that I have created a singleton for the different palettes and colors.
Yeah, almost Ever tried to get a coloured pushbutton on both WindowsXP style and Plastique with the use of palette? The same goes with many other widgets, like comboboxes - different styles use different palette roles to render the same parts of widgets.This is almost as easy to change as a style sheet.
Hmm... maybe you didn't use the sheet correctly? If you want a coloured pushbutton on WindowsXP or MacOS, you can't rely on the platform specific style and Qt handles that situation by itself. If you don't want the button to be coloured, the platform specific style should be maintained.Then my custom widgets derivations, for say pushbuttons, set the palette depending on the state, calling on the singleton for the specific palette. I found when using the stylesheet for pushbuttons, I lost the platform specific style.
Perhaps, but 4.3 is also not officially out (AFAIK). And since it was broke, I had to continue development, which meant switching to hand coding. Once I switched, I decided to stay. Many of the developers here have experience with other 3rd party ui design tools and none liked the result. So even if designer is good, there is a prejudice here. I'm not saying that I wouldn't try it again for certain purposes, but I can't speak for the rest of the team here. Time will tell, we are just starting this project and I am the primary/lead on it at this point.
It depends on how it would be used, how general purpose it is, and how long I'd have to maintain it.
True. I still prefer hand coding, what can I say?
Of course, but only developers/programmers are going to muck with it anyway (at least around here). And when I used the designer, I have to say I was SO bored Still, as with all tools, it can be useful and can be used when the situation fits IMHO.
Not quite, but almost. This is because, there are different colors for buttons, for example, not only in and of themselves, but depending on "where" they are in the application. The QApplication pallete isn't sufficient. And it needs to be swapped depending on the context. This is true for many other controls and areas of the application. The singleton contains all the palletes for all the contexts.Originally Posted by smacchia
No, I don't have access to WinXP style, but I did successfully get the same color in all the styles available on Linux. It was pretty easy. We're not porting to Windows anyway.Originally Posted by smacchia
I'm not quite sure what you mean when you say "and Qt handles that situation by itself". When I set the style for a pushbutton's background only, it was flat. I think I have to set all of the other attributes and then it isn't in the platform style, AFAIK. All I wanted was to change the color, but have it have the shape and feel of the style (be it plastique, windows, mac...). Frankly it was easier to use a palette...but you're right, perhaps my lack of experience here is showing
You could always use custom widgets to "hide" part of the form that causes trouble (I understand the problem was the complexity of the design).
Of course, but only developers/programmers are going to muck with it anyway (at least around here). And when I used the designer, I have to say I was SO bored Still, as with all tools, it can be useful and can be used when the situation fits IMHO.
AFAIK it changes the style of the button.I'm not quite sure what you mean when you say "and Qt handles that situation by itself".
Yes. this is also the reason why I don't use the designer. Ok, at first it looks like using the designer is faster. And it probably is for the pure gui design stuff. I am used to hand code my widgets, know how to use all the layout features, but I simply cannot beat drag and drop.
However, in the long run for more than small sized projects I think hand coding is much faster. I once tried to design a larger gui with the designer. A main window with a stacked widget, several actions, a couple of pages. I got a huge .h file, which I could subclass together with QMainWindow using the multiple inheritance method, which worked great. No complaint here.
Then I started to write the code. The .cpp got larger and larger. I got a super fat main window class. Of course I split the functionality in several classes, but they all depended on the designer generated .h file, with its interface blob. The whole code where such tightly coupled that it made not much difference, whether or not I left it in one single god class.
Then I pondered what would happen, it I had to add one single QLineEdit in one of the pages in the QStackedWidget. This was the moment when I deleted the whole code and swore never to touch the designer again.
I have yet to see a complex user interface, which is made with the designer and is still robust against changes, which involve more than a slight rearrangements of parts of the old design.
Maybe it is good for small things like message boxes and not too complicated dialogs. But for such small things the advantage the designer might have, isn't that convincing in my opinion.
Yes, thought of that. But this diminishes the usefulness of the designer a bit, and still does not really mitigate the robustness problems.
I think the designer generated code is only usable where it is absolute sure that the requirements don't change.
Suppose I have a widget with three buttons. I can connect each button with its own slot. When I add a fourth button, I have to write a new slot with all the changes in all clients, which are interested in the new buttons signal. This is more or less the way the designer code imposes.
If I hand code my widget I can use a QButtonGroup, have one signal, which identifies its button via its index. This is a little bit more flexible. I don't know whether there are tricks, which allow something simple like that with the designer.
But even if there is a way, I can go even further. Subclass a button using a specialised interface, design my widget that a factory method can easily add such a custom button dynamically during runtime. Other clients can register to query what buttons are actually there, and connect to the desired signal. If this is done correctly, only one class, the factory method, has to be changed, to add an additional button.
Ok, this might be overkill in many cases, and I don't code always that way. But I learned the hard way that especially user interfaces are bound to change. And of all things, especially the part of a program, which is most likely to change and to be enhanced over time, is produced by a tool, which produces the most rigid code possible.
What I believe is that it's easier to reorganise the GUI or add something to it using Designer, instead of changing the hand-written code. Moreover Designer doesn't make mistakes, of course you can still make some errors when you use Designer, but certainly they aren't hard to find, because of the visual nature of Designer's interface.
You can use QButtonGroup with Designer-generated code too --- the same way as if you were using in hand-written code.
You can create a custom widget (something like a QDialogButtonBox) and place it on the form, but of course you can always find such a complex situation when Designer isn't enough. It's just a tool, not the Ultimate Answer to the GUI Design Problems(tm), yet you should squeeze as much as you can from it and hand-code the rest.
On the contrary. I have worked on half a dozen commercial EDA applications; each composed of hundreds of thousands of lines of code; all in Qt and all with moderately complex GUIs. About 85-90% of the interface was in .ui files. The rest was hand coding and custom widgets.
Save yourself some pain. Learn C++ before learning Qt.
I think the only thing to remember when using Designer with really complex forms is that you can always use a custom widget - either a "real" custom widget or a "fake" custom widget which will "delegate" part of the complexity to another class. If some functionality is self contained, it is a perfect candidate for a custom widget. If you don't need to interact with it while designing, you can use a fake custom widget in a matter of seconds. If you do need to interact with it and see how it behaves, implementing a custom widget plugin is a matter of minutes. You'll waste more time correcting a single error in a hand written code.
Do you have a different designer? I mine I don't see 'Button Group' in the widget box. Of course, you can add all buttons manually into a QButtonGroup. But then the code has to change when you add another button. With QLineEdits it is even worse, there is no such thing like a QLineEditGroup.
But I might believe that for all my problems a workaround is possible. Only that if you constantly have think of workarounds for the shortcomings of the designer, the speed bonus is quickly gone.
But after the postings yesterday I thought a bit whether I could find a way to improve the designer. Just sent a feature wish to TT.
My idea:
A graphically designable parent/child tree like the QObject parent/child tree + some attachable meta informations. I call this designer meta objects. The designer would automatically generate a query method and a factory method. The query method gives you a list of meta objects. The factory method creates meta objects.
The meta objects contain pointers to the objects inside + the attached meta informations. Pointer to those created meta objects could be passed to clients.
So the gui 'kernel' code could be very small. It inherits only the designer generated classes. Multiple inheritance of QMainWidget, or QDialog or whatever would not be necessary anymore.
The kernel only contains mainly two methods: contains and a creator.
A client could ask the gui kernel if it contains a meta object for the third page in a QStackedWidget. If yes, it asks the kernel to create such an object and give it a pointer to it.
If this is done right, you could start your designer, add a couple of widgets like buttons or lineedits, and it would still work without a single line of code changed in your program.
Creating such a parent/child relationship would be as easy a putting objects on a layout tree.
QButtonGroup is not a widget.
When you don't use Designer you have to add these buttons to the buttongroup yourself anyway, so I don't see where the "hand code only" way is superior...Of course, you can add all buttons manually into a QButtonGroup. But then the code has to change when you add another button. With QLineEdits it is even worse, there is no such thing like a QLineEditGroup.
I think you're the one making workarounds... Query? Register? Factory? Aren't these workarounds?But I might believe that for all my problems a workaround is possible. Only that if you constantly have think of workarounds for the shortcomings of the designer, the speed bonus is quickly gone.
Could you suggest any other use than yours for such a feature? How is this related to a layout editor?A graphically designable parent/child tree like the QObject parent/child tree + some attachable meta informations. I call this designer meta objects. The designer would automatically generate a query method and a factory method. The query method gives you a list of meta objects. The factory method creates meta objects.
I don't see a problem with doing it without any changes to designer. Just like you have automatic signal-slot connections, you can make automatic "button group additions", for example based on object names, try this:If this is done right, you could start your designer, add a couple of widgets like buttons or lineedits, and it would still work without a single line of code changed in your program.
Qt Code:
rx.exactMatch(candidate->objectName()); buttongroup->addButton(candidate, rx.cap(1).toInt()); }To copy to clipboard, switch view to plain text mode
No need to change a single line of code outside Designer... You can do the same thing with other widgets as well... even making automatic connections for line edits or whatever you want.
What layout tree?Creating such a parent/child relationship would be as easy a putting objects on a layout tree.
Correct, but irrelevant. There is no way to create buttons in a QButtonGroup within the designer. At least none I know.
It is easier to do it by hand. With the designer you first have to think about the layout and then how to conveniently access all the stuff in the generated code. But this might be a matter of personal taste.
No. A workaround is something you need when you want to do things, which the designer cannot do naturally. Should my ideas be implemented, they would not be workarounds.
What other use? It is an additional abstraction of the designer created interface. There would be thousand uses. It would be an enhancement of the layout editor. You would not only layout the geometrical arrangements of the single widgets, but give them a logical structure.
Yes, and this is what I call a workaround.
You know how to put layouts inside layouts? This is a layout tree. You position object geometrically in it. The same way you could group
meta information of the objects in your designer generated code.
Name one.
No, this is not a workaround - this is a general way of doing things based on object names. Using it to put buttons into a button group is just one of the use cases. You might use the same approach to... I don't know... for example apply event filters, modify properties on multiple objects or do anything else you like if you don't have pointers to objects but know their name pattern. Remember that a button group doesn't have anything to do with the layout of objects, so you can't put a QButtonGroup object on a form and assign buttons as children to it.Yes, and this is what I call a workaround.
But what is the point of "grouping meta information of objects"? Would you like to use them in Designer or in the hand coded class making use of an ui file? I can imagine having a separate mode for Designer for such things but I don't see any benefit for a larger group of people (which is the only thing capable of making Trolls implement this).You know how to put layouts inside layouts? This is a layout tree. You position object geometrically in it. The same way you could group
meta information of the objects in your designer generated code.
Bookmarks