Printable View
Do you people use QT Designer?
Or are you coding ur entire interface by hand?
Euh, there was supposed to be a poll here, but i got an error message:
You can only add a poll 2 mins after posting the thread...
:confused:
Check the other thread.... Ill try to type faster!
Do you use QT Designer?
Or do you prefer good old coding?
It depends on :Personally I use Qt Designer only for complex dialogs and I never tried to use it for anything else because most of the time I subclass widgets to fit particular purposes. In such a case, using designer would be an overkill, unless your custom widgets is reusable which justify the creation of a designer plugin...
- the complexity of the interface
- the time you give yourself to create the interface
- the complexity of the program
- the type of interface
P.S: Double threading is a bad practice but maybe the poll-error is a decent excuse... ;)
well, I suppose its stupid to only allow 2mins to create a poll... What if you really have to go to the bathroom!?:eek:
thx for removing the other thread...
Usually people create polls when opening the thread and not after a meditation in a bathroom...Quote:
Originally Posted by lewis
Do it before opening a thread with a poll...Quote:
What if you really have to go to the bathroom!?:eek:
About the issue with Designer. I think Designer is there for you to use it. It generates a very good code, you won't be able to write a better one yourself. And using it doesn't mean you don't know how to code a widget manually, but saves a lot of time.
Maybe my opinion will sound a bit too strong, but I think that lame people are not the ones using Designer (because "real programmers code everything themselves"), but the ones not using it. Otherwise we'd be all stuck with binary code, perforated cards or in the best case assembly.
To be honest I am thinking of writing a set of macros which would relieve me of writing the same standard things all the time (what a waste of time it is), like:
Code:
It'd be better to write for example:
There are many things like the one above... Qt already has some nice things like forever() or foreach() and of course Tulip (although real h4x0rs would say they always implement their own vectors or lists... :cool: because using COTS solutions is lame ).
Back in the 1.x days, I used Qt Architect. But as I got used to Qt I started doing all my layouts by hand. In 2.x I tried using Designer, but I didn't like it, and so stuck with hand coding. I improved enough in 3.x that I started using it. But I only used it to generate boilerplate code, which I would cut-n-paste into my own code.
In 4.x, however, I'm using Designer for all my layout, even my menus. I'll still hand code tiny layouts, however.
When I started with Qt, I always used Designer, because I thought coding a GUI by hand would be very difficult. The bad part was that every time I wanted to subclass a widget to add some functionality, I had to do a lot of work to make it play well with Designer. That's when I started reading the GUI code in the Qt examples and I noticed it wasn't that difficult. Also, I noticed that the GUI behaves more the way I want it when I code "by hand". With the arrival of Qt4 it has become even easier, because they simplified the layout classes.
So maybe it takes me a bit more time, but I prefer coding by hand.
I started very recently using the designer for main windows as well. With Qt4 and the auto connection mechanism, the code you need to write for making a usable application is much smaller. This leads to less mistakes and clearer code.
Are there people that don't use it? If there are, I think they should get a hobby or something... and not spend the time sitting and code things by hand.
According to this poll 25% of the votes so far say that they don't use it. But I can't see any replies that states why. So I suppose that they're joking... I would really want to understand why they don't like Designer. I've always hated writing GUI code and it's the most important part of the program if you want the user to like you. It doesn't matter if your program is the best around if it's impossible to use. Without programs like Designer I would produce really bad programs, only because they would have a really crappy GUI.
But at the moment I use Designer to make the widgets and then inserts them by hand. But that is not because I think that it's better. It's just because I don't really know how to make a nice workflow when using a lot of custom widgets and the fact that I don't have Designer for Qt4...
So I insert a dummy widget instead of the custom widget in Designer and replaces it later by hand with my custom one. It's not optimal, but even by working this way I save a LOT of time and get far better results than doing everything by hand.
But there seems to be a lot better to use those ui files directly, makes it a lot easier to make changes later on if I've understood it correctly.
so there are people don't using the designer..Quote:
Originally Posted by cristianbdg
i am using the designer.
first to have a concept: how will the program look like and how do you use it.. it is easier to think about the program when you see the gui. you know which elements you need etc..
second it's much easier to start coding for me.
regards..
aman..
When I was new to Qt I got sent to a training seminar where they suggested that Qt was going away from the designer and going more towards hard-coding everything. A coworker told me the same thing. I guess that didn't happen?
A problem I have with hard-coding is that tweaking the sizeHint, min / max size stuff can be very tedious and slow-going. Designer makes it look good. Not "good-looking" like Apple computer good looking, but nice.
One of my friends only hard codes and his basic argument is that it's macho (but he uses eclipse to do Java ... hmm ...). IMHO there's nothing wrong with being macho (I prefer vi as an example), but laziness pays off now ;)
I think they meant the change that happened between Qt3 and Qt4 -- the idea of writing code inside Designer was dropped and the tool evolved to become only a GUI layout editor which is meant to be integrated with real IDE software.Quote:
Originally Posted by mhoover
I prefer being 'smart' (h4x0r1sh?) over 'macho'...Quote:
One of my friends only hard codes and his basic argument is that it's macho (but he uses eclipse to do Java ... hmm ...). IMHO there's nothing wrong with being macho (I prefer vi as an example), but laziness pays off now ;)
Hi
I can not second you about "no better code yourself" : there are unuseful and annoying lines especially for SizePolicy's and fonts where the default are better than explicit settings that, more often than never, are unwelcome.Quote:
Originally Posted by wysota
I don't want to tag myself as reactionnary, so I have to say that even if you have to get used to QtDesigner before you can feel how to do what you want, it is better than many gui designer I've used so far.
Still, I am suspectful towards "clickodroms" for such things,
I prefer powerful layouts that permit "straightforward" tweaking (they achieve flexibility with as few (orthogonal) parameters as possible, for example).
But for some sub-parts specialized of a rich panel QtDesigner can be ok. But integration of parts is easier for me by hand.
By the way, the possibility to change a "common" property among a multiple selection would be convenient : selecting several widget that are not all in the same "containers" and are not all the children of the topmost widget and being able to set the font boldness at once, these kind of thing, would be very practical. To be constructive ;)
My2c.
Yes, hopefully it will work soon: http://www.trolltech.com/developer/t...entry&id=87181Quote:
Originally Posted by lauranger
And this is a good idea! But it would be even better i f the Trolls have given more docs about Designer integration and not restricted it to M$VCQuote:
Originally Posted by wysota
Do you? I thought it was the last adjectives millionaires giving a tiny part of their fortunes chose to describe themselves... I wouldn't like to be a 'smart' guy! I fit better in something like 'neo-baba'... :DQuote:
Originally Posted by wysota
In Polish too? ;)Quote:
Originally Posted by fullmetalcoder
Coding by hand makes shorter, more straight forward, easier to understand and better code. Also, it helps understand how QT really works.
I do use QTdesigner sometimes, when I really cant visualize the final result because its a huge interface, but only to figure out how I will layout the objects.
Not really. With the exception of iterative constructs, the generated code from UI files is about as straightforward and easy to understand as you can get.Quote:
Originally Posted by lewis
I agree that handcoding helps you understand how to do that code, but once you understand the principles, you're just wasting you time with hand-coding where it can be better employed elsewhere. With handcoding, the design loop is code->compile->test->tweak->compile->test ... etc.
Using designer, you can tweak and test to your hearts content in a fraction of the time.
This is vital for complicated layouts and enhances productivity immensely.
nowadays, I just drop into hand-coding when I have something that Designer can't do (runtime changes to UI, layout changes, etc).
Coding by hand is about as fast for me... except when I forget many functions name and have to look them up all the time.
You must tell me what this amazing compiler that you are using is then. Apparently it compiles in zero time :-)Quote:
Originally Posted by lewis
Either that or you always code your GUIs exactly right first time :-) :-)
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.Quote:
Originally Posted by lewis
He he! I'm game!Quote:
Originally Posted by Brandybuck
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...Quote:
Originally Posted by smacchia
Hmm... Why?Quote:
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.Quote:
3) I like to build on re-usable tools that make hand coding easier and faster
Have you tried using stylesheets?Quote:
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).Quote:
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.Quote:
BTW. Lewis, Chicken Blood Machine - what about the contest? Any winners?
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.Quote:
Originally Posted by wysota
Quote:
Originally Posted by smacchia
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.Quote:
Originally Posted by wysota
Quote:
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.Quote:
Originally Posted by wysota
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.Quote:
Originally Posted by wysota
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.... :cool: ) and stability improves.Quote:
Originally Posted by smacchia
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)?Quote:
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.Quote:
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.Quote:
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.Quote:
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.Quote:
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.Quote:
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.Quote:
Originally Posted by wysota
It depends on how it would be used, how general purpose it is, and how long I'd have to maintain it.Quote:
Originally Posted by wysota
True. I still prefer hand coding, what can I say?Quote:
Originally Posted by wysota
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.Quote:
Originally Posted by wysota
Quote:
Originally Posted by smacchia
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.Quote:
Originally Posted by wysota
Quote:
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. :DQuote:
Originally Posted by wysota
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 ;)Quote:
Originally Posted by wysota
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).Quote:
Originally Posted by smacchia
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.Quote:
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.Quote:
Originally Posted by smacchia
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.
Then maybe you should create each page as a separate .ui file?Quote:
Originally Posted by Kumosan
Yes, thought of that. But this diminishes the usefulness of the designer a bit, and still does not really mitigate the robustness problems.Quote:
Originally Posted by jacek
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.Quote:
Originally Posted by Kumosan
You can use QButtonGroup with Designer-generated code too --- the same way as if you were using in hand-written code.Quote:
Originally Posted by Kumosan
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.Quote:
Originally Posted by Kumosan
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.Quote:
Originally Posted by Kumosan
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.Quote:
Originally Posted by jacek
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.Quote:
Originally Posted by Kumosan
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...Quote:
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?Quote:
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?Quote:
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:Quote:
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.
Code:
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?Quote:
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.Quote:
Originally Posted by wysota
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.Quote:
Originally Posted by wysota
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. :pQuote:
Originally Posted by wysota
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.Quote:
Originally Posted by wysota
Yes, and this is what I call a workaround. :)Quote:
Originally Posted by wysota
You know how to put layouts inside layouts? This is a layout tree. You position object geometrically in it. The same way you could groupQuote:
Originally Posted by wysota
meta information of the objects in your designer generated code.
Name one.Quote:
Originally Posted by Kumosan
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.Quote:
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).Quote:
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.
And I think this is a terrible hack like way. I some sense you do hand coding within the designer. You have to think of a naming scheme. You have to use regexp to use it. Your naming scheme can easily break, when you layout changes too much.Quote:
Originally Posted by wysota
Please don't take me literally. And please be a bit more observant when I use examples, e.g. when I try to explain a possible feature in terms of already exiting ones.Quote:
Originally Posted by wysota
And I can very well put a QButtonGroup on a form. At least in theory, it is just not implemented. It could be implemented as dropping a rectangle on the form, giving it a name, dropping buttons in it. Later on the uic compiler creates a QButtonGroup which is populated with the buttons I dropped in. There is no universal law that the designer can handle only layouts.
Btw. my idea of a designer meta object consists of several parts. The first part is not that different from that what you are doing. It could even be implemented using the object name (though I would not do so). You create an meta object tree just like you create a layout tree (Attention Example, it is not a layout. It is just used the same way by dropping boxes in boxes.). You drop your widgets in those meta object boxes, name those boxes, and this way your object names are created automatically in a well defined naming schema.
This would be cramming all meta information in this single string. Ugly, but possible.
This would be the second part of my idea. I would use them outside the designer. You create a naming schema manually and parse them in the subclassed object, e.g. you create a QButtonGroup, search all children of the ui class for a certain name to add it to the button group. Finally you then can pass a pointer of the button group to the object, which actually handles the buttons. Next you search for other parts in the ui class, dispatch gui parts to the correct handler, etc.Quote:
Originally Posted by wysota
As I said, this is ugly, you have to remember your naming schema and if it changes, your regexps might have to change, too. Furthermore you enter your object names manually, which is error prone. One typo and the debugging starts.
With my idea you generate your object names (or other meta info) graphically. Effectively grouping your objects, e.g. you create a meta box and give it the name 'page_1' in this box you drop a second meta box and give it the name 'group_1'. Now you drop a button in the second box and it is automatically named page_1.group_1.button_1. No, this has nothing to do with layout. I just uses the same user interface to create a tree.
This is something you could do manually. The way you do it, you now would create some loops, some regexps, which parse the object names.
I'd like to have an auto generated query method where I can ask 'contains("page_1"). If the answer is true, I'd like to have a method
"QDesignerObject *getDesignerObect("page_1")",
This returned QDesignerObject should contain references to group_1 + all children + meta information. Now I can pass this object, which encapsulates a small logical part of the whole gui to a client class, which handles the stuff inside this object, e.g. group_1 and its buttons.
The problem is QButtonGroup doesn't change the parent-child relation, meaning that you can have buttons with different parents inside a single button group. So I don't see a way of "dropping" buttons on the button group - you couldn't drop them on a button group AND parent widget at the same time. I can imagine the thing you want to be implemented as a separate working mode for Designer where you could somehow "associate" buttons into groups. But, let's face it, it would be really rarely used.Quote:
Originally Posted by Kumosan
Actually... I'd argue with that. Qt4 Designer is meant to be strictly a layout editor.Quote:
There is no universal law that the designer can handle only layouts.
Are the "meta-objects" you refer to related to QMetaObject? If not, please try to use a different name as we may be confusing each other here...Quote:
Btw. my idea of a designer meta object consists of several parts. The first part is not that different from that what you are doing. It could even be implemented using the object name (though I would not do so). You create an meta object tree just like you create a layout tree (Attention Example, it is not a layout. It is just used the same way by dropping boxes in boxes.). You drop your widgets in those meta object boxes, name those boxes, and this way your object names are created automatically in a well defined naming schema.
Actually, not necessarily. And even if this is the case, I don't really see a problem with it.Quote:
you have to remember your naming schema and if it changes, your regexps might have to change, too.
In general it applies to all things you actually do. I tend to assume some sanity of the developer doing the job. If you make a typo, you'll widget will not make it into the button group. This is really easy to track.Quote:
Furthermore you enter your object names manually, which is error prone. One typo and the debugging starts.
In what way is it different than qFindChild()? You could make the same typo with both approaches...Quote:
I'd like to have an auto generated query method where I can ask 'contains("page_1").
Again, qFindChild() does that...Quote:
If the answer is true, I'd like to have a method
"QDesignerObject *getDesignerObect("page_1")",
So you'd like to maintain a virtually unlimited trees of object hierarchies indexed by names, right? So you'd like to have parent-child relations simmilar to the ones maintained by QObject and it's parent-child relation indexed by objectName property, correct? This is fine with me, although I believe it would increase resource usage and object deletion time significantly. But I don't see why Designer should handle such grouppings as they are not related to its functionality... Please notice, that you'd have to first redesign QObject - without it Designer wouldn't be able to do anything. So I think the issue is not in Designer itself here anyway.Quote:
This returned QDesignerObject should contain references to group_1 + all children + meta information. Now I can pass this object, which encapsulates a small logical part of the whole gui to a client class, which handles the stuff inside this object, e.g. group_1 and its buttons.
BTW. I remember something about Designer being able to handle "user properties" since 4.3 (I'm not sure if this was exactly what I think). If that was the case, you could create a user property "in button group 1" and set it to true for all buttons you wanted in the button group and then only iterate over all buttons and check the property value, adding them to a particular group. Of course you'd still have to add buttons to the group from within code.
Ok, this is a weak point in my idea. However, in all my years of development with Qt, it never ever had a QButtonGroup with buttons with different parents.Quote:
Originally Posted by wysota
Perhaps because noone seriously though about it how to improve it and to make it better beyond pure layout design?Quote:
Originally Posted by wysota
Not in code, but in the idea. But you are right, let's define:Quote:
Originally Posted by wysota
With a QDesigerObject I mean an object, which can be created by generated code from the designer, which contains a part of the user interface hierarchy.
With QDesignerMetaObject I mean an Object, which is located within a QDesignerObject, which might carry additional informations for all objects (references/pointers) within this QDesignerObject.
I don't think I can agree here. Of course you are right that it applies to all things we do, and that bugs can be found. But if the compiler or some tool can help prevent bugs like that in the first place, it should be used.Quote:
Originally Posted by wysota
But this is only a small part of what I want. And it handles a concrete object. My idea was not to find a concrete child, but a certain node in a tree.Quote:
Originally Posted by wysota
I am not sure about that. The QDesignerObject tree, which, according to my proposal, in the designer should be created like a layout tree, would have to be kept in the resources. Temporarily an at best medium sized xml structure. This information is only needed to build the QDesignerObjects. Once the gui is created, this info could be unloaded/deleted. I would have a small influence on the gui creation, but none on object deletion.Quote:
Originally Posted by wysota
I'd say they are related to good code design.Quote:
Originally Posted by wysota
I don't think so. I think it could roughly work like this:Quote:
Originally Posted by wysota
When you call my getDesignerObject method with the parameter "group_1", it creates a container object, for the sake of the example, suppose it is a simple QList<QObject *>. Then it traverses the above mentioned QDesignerObject tree, which is an XML structure, and adds all object pointers, which belong to the "group_1" branch to the list.
Finally it returns a pointer to this list.
I reality it would not be a simple QList<Object *> since it should also carry the QDesignerMetaObjects and retain the hierarchy informations, but it still would be some sort of container.
This is just an example, that this could be added without changing QObject. The QDesignerObject would also be only a temporary transfer object to pass their content around.
Even the QDesignerObject resource tree could be deleted once the gui is built.
It might cost a little bit more time and resources to build and initialise the gui, but I don't think this would be too costly.
But it doesn't mean it can't be used this way. If you wanted to provide support for that in Designer, it would need to handle such a situation as well.Quote:
Originally Posted by Kumosan
No. Before Qt4 Designer was a tool that was able to do many more things than just lay out widgets. But then Trolls decided to make Designer only a layout editor which can be embedded into real IDEs.Quote:
Perhaps because noone seriously though about it how to improve it and to make it better beyond pure layout design?
I agree but I don't think Designer should be the tool.Quote:
But if the compiler or some tool can help prevent bugs like that in the first place, it should be used.
...based on the name. That's exactly what qFindChild does.Quote:
But this is only a small part of what I want. And it handles a concrete object. My idea was not to find a concrete child, but a certain node in a tree.
Resources are compiled into the binary and occupy the memory all the time.Quote:
I am not sure about that. The QDesignerObject tree, which, according to my proposal, in the designer should be created like a layout tree, would have to be kept in the resources.
Hmm... so how do you want to access the data from code if it is only to be available to the automated code? Or maybe I don't understand what you mean by "gui creation" - for me setupUi() does that.Quote:
Once the gui is created, this info could be unloaded/deleted. I would have a small influence on the gui creation, but none on object deletion.
So it does the same qFindChildren() does, only on the separate object hierarchy, right?Quote:
When you call my getDesignerObject method with the parameter "group_1", it creates a container object, for the sake of the example, suppose it is a simple QList<QObject *>. Then it traverses the above mentioned QDesignerObject tree, which is an XML structure, and adds all object pointers, which belong to the "group_1" branch to the list.
Finally it returns a pointer to this list.
But then you could only use it in a class generated by Designer.Quote:
This is just an example, that this could be added without changing QObject. The QDesignerObject would also be only a temporary transfer object to pass their content around.
According to me the thing you want is a nice candidate for a completely separate component that can be implemented using Qt but not necessarily inside Qt.
Really? I thought there is a way to unload them and free the memory. Q_CLEANUP_RESOURCE()? I never tried that.Quote:
Originally Posted by wysota
Ah yes, I really don't meant gui creation, but hmm, how do I call it...interface dispatch? All in all I am trying to find a better way to give classes a better way to access the designer generated objects. The designer is a fine tool, I just think the way its code has to be connected to the main program code sucks.Quote:
Originally Posted by wysota
Actually yes, the returned object should be different. Else if you want to keep the method to encode hierarchy informations in the object name, you probably could even use qFindChildren the way it is now. But I don't think this 'reuse' would be good.Quote:
Originally Posted by wysota
This I don't understand. Why?Quote:
Originally Posted by wysota
I am thinking how I could create such a component. I think I could create a wrapper around designer generated classes, which implements parts of the interface I described. But all depends on hierarchy information somewhere in the designer created objects. I might be willing to swallow the bitter pill and parse the object names, but then I had to set them manually. And this makes IMHO all the work pointless.Quote:
Originally Posted by wysota
This won't work for resources compiled into the application as they are part of application memory space. This macro only applies to plugins.Quote:
Originally Posted by Kumosan
How would you define when "interface dispatch" ends? IMO there is no way to do that, especially if you allow subclassing.Quote:
Ah yes, I really don't meant gui creation, but hmm, how do I call it...interface dispatch?
Because it wouldn't be supported by Qt core, only by the code Designer generates (just like you don't use "setupUi" with hand written classes).Quote:
This I don't understand. Why?
IMO it should be completely separate from Designer with a separate tool (or two - "designer" and "compiler") handing it. Then you could incorporate it into QMake.Quote:
I am thinking how I could create such a component. I think I could create a wrapper around designer generated classes, which implements parts of the interface I described. But all depends on hierarchy information somewhere in the designer created objects. I might be willing to swallow the bitter pill and parse the object names, but then I had to set them manually. And this makes IMHO all the work pointless.
After you wrote this I had to check in the Qt 4.3 designer. You are right. right clicking the property editor opens a popup, which allows you to add a 'dynamic propery'. This handles most of the parts, which I named QDesignerMetaObject. :)Quote:
Originally Posted by wysota
Unfortunately I cannot use the 4.3 designer. In 4.3.0beta the preview window has no window decorations. I cannot close a preview window and have to brutally kill the program. :(
Good to know.Quote:
Originally Posted by wysota
Yeah, probably only through evil hacks. But I don't like to think about code with never will be too deeply now. :)Quote:
Originally Posted by wysota
The QDesignerObject I meant is a simple container class, which is generated by designer generated code. All it has to do is implement a well defined interface. It could even be a subclass of QObject, though this would be overkill. But even if it is nowhere else supported in Qt, I would only need the header file of the interface. Maybe I am a bit blockheaded at the moment, but I cannot follow you here.Quote:
Originally Posted by wysota