Why do you need to use widgets? And what part of widget functionality? If you are after checkboxes or other buttons, you can safely go for the model-view approach. A well written custom delegate will handle all that.
Why do you need to use widgets? And what part of widget functionality? If you are after checkboxes or other buttons, you can safely go for the model-view approach. A well written custom delegate will handle all that.
I did it once and it was not the Ideal solution in terms of performance but it works. Here is a screenshot:
http://gentoo-wiki.com/Image:Servant_nr3.jpg
So if you really don't want to use Interview, you can do that but the model/view approach is by far the best way to do these kind of things.
From a design standpoint on this application I chose to focus on the scrolling list, like the ipod/iphone would do.
So I looked the Qt Api:
QListWidget works with items.
Wouldn't that be great if we could just push back any widget into a list ? For example if I need an edit box in my list widget.
So I recoded my own settable layout based on widget that could be easily encapsulated with another so I wouldn't have to worry if I needed to fill it with an item or a widget.
Why would I emulate a QPushButton and then populate my list when I could simply add it to my list ? makes no sense, it's a hack to me.
If I need a specific QPushButton I'm just going to inherit that item an redeclare the repaint function, why would I want to hack the display of the original QPushButton ?
I'm very surprised that nobody even in the other thread seems interested by a list of widgets. Coupled with a settable widget layout class it's very convenient. A simple call and you change or add anything into your list.
I see my list as a layout of widgets where I can set and unset anything by a single call.
Actually you can. But you shouldn't if you want to avoid slowness.
You can easily achieve that using a custom delegate and making it return a proper widget from createEditor().For example if I need an edit box in my list widget.
Because it will be many times faster. 100 items means 100 buttons in your case, each of them needs to be repositioned, shown or hidden as necessary by the window system. Using itemview approach and only drawing the button (without ever creating the actual button) makes things much faster and much easier.Why would I emulate a QPushButton and then populate my list when I could simply add it to my list ? makes no sense, it's a hack to me.
Nobody says you should.If I need a specific QPushButton I'm just going to inherit that item an redeclare the repaint function, why would I want to hack the display of the original QPushButton ?
You must have looked not deeply enough. We discussed that many times here. The bottom line is - it's slow and it's easier to do it using itemviews, but if you can't live without widgets or you can accept the fact that your application will not be scalable, you can use setIndexWidget() or setItemWidget() depending on whether you use the model approach or the convenience classes.I'm very surprised that nobody even in the other thread seems interested by a list of widgets.
Yes, that's why you can do it using QScrollArea. But it will be slow and cubersome to manipulate from a central point (like having to connect each button's signals to a custom slot where you have to find out which button was clicked, etc.). Oh... and it's awfully slow. The situation will improve in 4.4, but I'm pretty sure item-view approach will still be easier to control if not faster.Coupled with a settable widget layout class it's very convenient. A simple call and you change or add anything into your list.
Yes and it works. But then you come here and say that your application is slow. And our advice to speed things up is to buy better hardware... eeem... sorry... get rid of unnecessary widgets.I see my list as a layout of widgets where I can set and unset anything by a single call.
EDIT:
Attached is a small and crude example of what I mean. Of course in a real app you'd need to handle mouse press events as well to make the button look sunken.
Try achieving the same speed using widgets.
Last edited by wysota; 28th September 2007 at 18:15. Reason: updated contents
I see your point.
Even though from my perspective Qt is supposed to be heavily widget based.
Otherwise I would use SDL or embedded Opengl.
I imagine your approach is faster.
But, if I want to be fast I'm using opengl and I'll achieve 500 fps.
My goal is : creating a scalable and easy to maintain desktop application.
From my point of view using widgets and only widgets makes more sense than delegating the painting. This should be done only to customize the appearance.
And beside, what about layouts in a delegate ?
I can't help but thinking it's a hack to make a painting area "look like" a widget and I don't like the idea. And that's not the direction I'd like Qt to evolve.
Why would rendering a given scene vary between a delegate and a widget ?Because it will be many times faster. 100 items means 100 buttons in your case, each of them needs to be repositioned, shown or hidden as necessary by the window system. Using itemview approach and only drawing the button (without ever creating the actual button) makes things much faster and much easier.
It should be as fast in a widget than in a delegate period.
If I'm displaying a button through a qwidget item or through a delegate, the only thing that should vary is the memory occupied by each instances not the rendering speed.
I guess that's what they're trying to achieve for the next Qt.
Depends why you use Qt. I don't use it because it has widgets (all toolkits do). I use it because it's portable, object oriented and it's very easy to develop using it both on lowlevel (like widgets) and highlevel (abstractions such as model-view, graphics view or databases).
And it'll take weeks to implement it.I imagine your approach is faster.
But, if I want to be fast I'm using opengl and I'll achieve 500 fps.
I don't think we understand each other.My goal is : creating a scalable and easy to maintain desktop application.
From my point of view using widgets and only widgets makes more sense than delegating the painting. This should be done only to customize the appearance.
What about them? You can implement a layout engine if you want...And beside, what about layouts in a delegate ?
Well... that's your point of view. Widgets themselves can be considered a hack as well... After all, they are separate objects that cheat by calling the same routines I'm calling in my delegate that draws on another widget.I can't help but thinking it's a hack to make a painting area "look like" a widget and I don't like the idea.
Of course it would be pretty to do everything without any cost. But I'm happy that I can call a single function and it will render a button in a platform independent way.And that's not the direction I'd like Qt to evolve.
Oh... I can answer that... Or maybe not, I'll point you to an article where it's explained.Why would rendering a given scene vary between a delegate and a widget ?
http://labs.trolltech.com/blogs/2007...f-all-flicker/
http://labs.trolltech.com/blogs/2007...-here-to-stay/
Yes, it should. But unfortunately due to the overhead of using native windows (see links above), it's not. Of course implementing non-window widgets is a hack as well, so we could loop to one of your previous sentences - making a not-widget behave like a widget (as QWidgets will not be real widgets in a strict meaning of this word anymore).It should be as fast in a widget than in a delegate period.
By the way... even with non-window widgets the item-view approach will be faster, because the layout won't have to reposition all the widgets.
Oh, and another thing. The advantage of using the item-views approach is not only the speed. The main advantage is that I can use models with it easily. And it's much more work to emulate it using non item-view approach (see my argument about connecting 1000 buttons to a slot). And an instant messenger application is a perfect candidate for using the model-view approach. But of course I'm not stopping you from doing it your way...
Last edited by wysota; 28th September 2007 at 19:49.
@bunjee:
Wysota has shown you the path towards best possible solution. I don't understand why you don't want to use the delegate approach. Its actually not hack and if you want good performance with listview kind of widget then its best you stick on to interview and delegate approach. After all that was why trolls added the delegate concept to interview.
I also don't understand one thing. When there is already a way(faster) to do what you want why do you don't want to adopt it and want to use the widget approach itself and tweak it so much to match the performance of delegate approach ?
Widgets consume more memory too other than disadvantages pointed out in the links given above.
Anyway i could be missing something and you might have specific reasons for that. If so I'm sorry.
The biggest difference between time and space is that you can't reuse time.
-- Merrick Furst
I think I can answer that. Using widgets is just simpler in that way that you don't have to write any code to handle things like positioning or interaction and I fully understand that regardless of problems it causes.
I think it is a very good idea to develop a delegate that would allow us to place and handle widget-like objects in the delegate. Maybe even Trolls ought to do that. We'd then have three different in approach but similar in handling frameworks - the widget system, the graphics view framework and the item delegate system - each allowing us to place objects on a canvas and interacting with them.
I think it's a nice subject for an academic project if sobebody is looking for one. But until someone actually writes it, we have to stick with a low level approach as suggested.
Qt posters,
Here are my latest thoughts about the widget vs delegate approach.
I'm coming from the opengl scene and from my point of view a polygon is a polygon, a mesh is a mesh, a 2d drawable surface is a 2d drawable surface.
Performance wise displaying something inside a widget paint event or a delegate paint function shouldn't dramaticaly change a thing.
I had difficulties understanding why having lots of widgets was causing such a performance hit.
http://labs.trolltech.com/blogs/2007...f-all-flicker/
http://labs.trolltech.com/blogs/2007...-here-to-stay/
As wysota pointed out in the above links it's mainly because in the current Qt stable release the window manager keeps track of every single widgets.
Every single time a widget is hidden / moved or whatever the window manager is notified and at some point screw the performance up.
I know what you're thinking : there is no point for the window manager to be aware of what's going on inside a window widget. Easy to say, according to the Qt dev, a portable solution for this problem was quite difficult to implement.
From what I've seen in Qt 4.4 latest snapshot, I'm glad to let you know that from a performance perspective, having a list of 1000 widgets is no longer science fiction.
In my case where I'm using a QScrollArea to display a list of widget the performance between 4.4 and 4.3 is like day and night.
I see the benefits of the model / view approach for most of the cases.
But, if you really need a QWidget list the 4.4 will grant you fairly good performance.
My program is based on a list and only a list. I took the bet that it will be possible to do everything inside a list of widgets. So it is crucial for me to have those widgets otherwise I'm trade-offing too much of the potential expandability of my software.
Now, the only concern I have with widgets is the fact that it's memory consuming. As a result even if the display is fast enough, creating and deleting widgets sometimes freezes the window.
Maybe a Threaded deletion approach would solve the problem.
I must agree with wysota and others - Qt 4.4 will fight with flickering not performance, the reason is not painting the widgets but lots of other stuff(events, communication ect.) that widgets do and You don't really need it in your application.
If you don't want to use model view with delegates, maybe consider overriding QListWidget with custom paintEvent.
I have QTreeWidget in my application with paintEvent that emulates matrix of pushButtons and it works fine for me...
Consider that the power of OpenGL comes from the fact that you actually stream commands into the GPU (in a specific order), which is sometimes tedious and prone to errors. We could say that this is Bad(TM) because it's low-level and doesn't allow much flexibility when writing the code. But it's just the way OpenGL works - it's optimized for performance and to get best performance, you need to stream commands into the processing unit.
Actually this is unfortunately not true. I've been talking to Trolls about this during DevDays and it looks like Aliens won't improve the speed of item-view index widgets. At least not in any significant way. Using delegates is still the preferred solution. I know that Trolltech is working on a better default delegate that would allow us to make some things in an easier fashion and they also work on a new generation item-views framework. So there is work around the subject, but it's hard to say when it will be available to public.I had difficulties understanding why having lots of widgets was causing such a performance hit.
http://labs.trolltech.com/blogs/2007...f-all-flicker/
http://labs.trolltech.com/blogs/2007...-here-to-stay/
As wysota pointed out in the above links it's mainly because in the current Qt stable release the window manager keeps track of every single widgets.
Every single time a widget is hidden / moved or whatever the window manager is notified and at some point screw the performance up.
I know what you're thinking : there is no point for the window manager to be aware of what's going on inside a window widget. Easy to say, according to the Qt dev, a portable solution for this problem was quite difficult to implement.
From what I've seen in Qt 4.4 latest snapshot, I'm glad to let you know that from a performance perspective, having a list of 1000 widgets is no longer science fiction.
Yes, in that situation the performance should be better.In my case where I'm using a QScrollArea to display a list of widget the performance between 4.4 and 4.3 is like day and night.
As the name says Itemviews is oriented around items, not widgets, so it's not optimized for your case. It's like you wanted to implement an image viewer using QTextDocument. Sure it's possible, but there are better ways to do this.I see the benefits of the model / view approach for most of the cases.
But, if you really need a QWidget list the 4.4 will grant you fairly good performance.
My program is based on a list and only a list. I took the bet that it will be possible to do everything inside a list of widgets. So it is crucial for me to have those widgets otherwise I'm trade-offing too much of the potential expandability of my software.
Memory consumption should decrease with 4.4 and Aliens. But I doubt your problem is memory consumption. I think the problem is positioning the widgets - if you create and show a widget (or hide it) the layout of all widgets needs to be recalculated and that takes time with a vast number of widgets.Now, the only concern I have with widgets is the fact that it's memory consuming. As a result even if the display is fast enough, creating and deleting widgets sometimes freezes the window.
No, it will crash your application.Maybe a Threaded deletion approach would solve the problem.
Exactly. According to Marius (one of the Trolls responsible for Itemviews) the slowndown is caused by actually moving the widgets in the view.
That won't change anything - you still have to fake the widgets and it's easier to do from within a delegate as you only care about one "widget" at a time. And if you really need the power of widgets and not items, I'd think about abandoning Itemviews - it's not meant for you.If you don't want to use model view with delegates, maybe consider overriding QListWidget with custom paintEvent.
I have QTreeWidget in my application with paintEvent that emulates matrix of pushButtons and it works fine for me...
I won't comment any further on this, we cannot really compare Opengl and Qt. What I was pointing out is the fact that what will make Opengl fast (or notConsider that the power of OpenGL comes from the fact that you actually stream commands into the GPU (in a specific order), which is sometimes tedious and prone to errors. We could say that this is Bad(TM) because it's low-level and doesn't allow much flexibility when writing the code. But it's just the way OpenGL works - it's optimized for performance and to get best performance, you need to stream commands into the processing unit.) is the number of triangles period. Not the fact that they're inside whatever signal based container.
You've got to accept that : if we admit that the performance of widgets was partly slow because of the interactions / updates with the window manager now that Qt 4.4 is using Alien windows/widgets it should definitely be faster. It's written on the blog you linked us to.Actually this is unfortunately not true. I've been talking to Trolls about this during DevDays and it looks like Aliens won't improve the speed of item-view index widgets. At least not in any significant way. Using delegates is still the preferred solution. I know that Trolltech is working on a better default delegate that would allow us to make some things in an easier fashion and they also work on a new generation item-views framework. So there is work around the subject, but it's hard to say when it will be available to public.
Why would it be way faster in my case and not with the item view approach ? Layouts ? Well I'm using layouts.Yes, in that situation the performance should be better.
Yeah that's definitely why I kept my approach. Delegates are not of any use in my case since my approach is to base everything on a layouted QScrollArea of widget.As the name says Itemviews is oriented around items, not widgets, so it's not optimized for your case. It's like you wanted to implement an image viewer using QTextDocument. Sure it's possible, but there are better ways to do this.
You make a point.Memory consumption should decrease with 4.4 and Aliens. But I doubt your problem is memory consumption. I think the problem is positioning the widgets - if you create and show a widget (or hide it) the layout of all widgets needs to be recalculated and that takes time with a vast number of widgets.
But, again, performance wise, if the QLayout was really optimized what would differenciate it from a listview of delegates ? If you insert / remove items you still have to recalculate the position of your painting area.
As we both agreed, I'm keeping my QScrollArea of QWidgets and I'm quite happy with it. When my widgets are loaded performance is good.No, it will crash your application.
Now I have to think about how to load/unload as fast as I can.
In my case I've come to the conclusion that since one user cannot see more than a given numbers of rows at a time, it makes sense to thread the adding / removing of widgets using signals. As a result I would be streaming populating and de-populating a list.
And no if it's written correctly it shouldn't crash anything. Still if you have better solutions I'm interested as I'm still brainstorming about this.
Again, if it's well written I see no reason for that.Exactly. According to Marius (one of the Trolls responsible for Itemviews) the slowndown is caused by actually moving the widgets in the view.
Maybe using QGraphicsView would be a middleway if the research going on around QGV-Layouts and QGV-Widgets bear fruit. I don't think this will be the case with Qt-4.4 but maybe Qt-4.5. Then we could have QPushButton clones with a similiar interface but made of standard QGraphicsItems providing both performance and ease of use, not to mention the eyecandy. The slides from Trolltech's DevDay were really interesting.
Bookmarks