QtWidgets should learn from ExtJS.
Not used ExtJs, but 've used GXT (ExtJS for GWT). Cannot say that it was easier in use than Qt. Of course I'm saying as developer, not as user (for user default widgets of ExtJS are more prettier, but in Qt all can be done via styles and stylesheets).
I'm not talking about styles. I'm talking about usability.
Supporting fully customizable toolbars and status bar for List, Tree and Table Views.
Asynchronous model/view data loading.
Toolbars and statusbars can be added by adding other widgets to layout.
Async data loading can be done via fetchMore().
Not sure about groups, but maybe there are some third party widgets for such functionality.
I think the examples you link to are nice. Really. But the item view stuff can be done with Qt just as well. The grouping can be done using a QTreeView with a modified item delegate. QxtTreeView and QxtItemDelegate provide a similar look, for instance.
I know these things can be done with Qt. If Qt wouldn't have a QTreeView, it could be done by any of us with Qt.
What I'm saying is that it would be cool if this functionality were integrated in Qt. For instance, "the grouping example":http://dev.sencha.com/deploy/dev/examples/grid/grouping.html. Did you noticed that records can be grouped by whatever column the user choses? Just click at the popup menu in a column header and see for yourself. This functionality is USEFULL to almost every app. Some projects don't justify spending time creating a MyTreeView widget just to have this grouping thing. But every qt app would be enriched if Qt has it. And developers could just set tree.setGroping(true); one line of code.
Same goes for buttons. Today we have a Toolbar widget, but it is specifically made to dock with a MainWindow. What if I want a toolbar in my own widget? I have to repeat code, tweak the Qt Toolbar or make my own. But if we could have a Toolbar widget that works like a widget, I mean.. you can put it anywhere.. it wouldn't be necessary to repeat anything.
The same goes for status bars. What if I want a status bar to show messages relative only to a ListView? things like "Loading.." or even add widgets to jump to next page. showing "Page X of N" message.
Sorry for my english again...
Why do we have QToolButton instead of a flexible QPushButton?
I remember times when I tryed to add an Action to a PushButton.. and then found out I couldn't. I had to connect signals instead. And set the same Text, and Icon manually. Why would toolbutton let you addActions and pushbutton doesn't?
Same for the rest of the functionality.. these 2 classes should be the same, and even more flexible (let you chose icon alignment and arrow alignment). That's another widget that should learn from ExtJS :)
"SUPER FLEXIBLE PUSH BUTTON in ExtJS":http://dev.sencha.com/deploy/dev/examples/button/buttons.html
"Buttons with actions in ExtJS":http://dev.sencha.com/deploy/dev/examples/menu/actions.html
I am trying to make constructive suggestions.. because of my lack of vocabulary maybe I sound a little rude.. because of that i apologize.
About alignments and other such things. As for me stylization (via QStyle and stylesheets) is flexible enough. Just simply can't say what you cannot do with them and what is presented in ExtJS.
(About alignments and other such things)
As I said before, I know this functionalities can be accomplished with Qt reimplementing QStyle and such things. I just don't see why can't it be simplier: by setting a property.
And what about the rest?
I'm not a troll, so I can't say about the reasons, but as from my point of view a lot of properties (for this, for that, for something else) can destabilize the API. API will be huge and near to not-understandable and it can lead to a lot of errors inside the framework. Just keeping things simplier and divided from each other helps in this two cases a lot.
About pushbutton and toolbutton (again from my point of view). Action is something from menu/toolbar/context menu/shortcutted macro and so on that changes current view. Pushbutton is something that switches to another view.
Also for full flexibility you can look into Quick and future Components.
Making QPushButton and QToolButton the same would decrease API size. Instead of 2 different classes you would have only one, with both functionalities. And would be even more usefull.
A button is a button. Whether it is on a Toolbar or not. The functionality is the same, or at least it should be.
Yes, I'm aware of QtQuick and I think it is a great project. But still it's not the best for Desktop applications where you want your App to integrate with the OS Look & Feel.
I am currently working on a project using Qt. I will provide my applications with the things I said before. I just think that if QtWidgets were more flexible I wouln't have to reimplement most of the widgets. I mean, I know a Toolbar is suposed to be on a MainWindow, but why restrict it? Same for Status bar. Same for buttons, and tool buttons. It just seems like a huge amount of Qt wasted.
For instance, look at this thread: "I want make custom List Item":http://developer.qt.nokia.com/forums/viewthread/1478/
Someone replied, I quote:
bq. Well, forget QListView.
It’s the last thing you want..
All you have to do is to create a new widget class. Then you create a layout class to layout the widgets in vertical or whatever you want.
Why??? It seems like Widget are programed to be used in a specific way. And if you want to do something else you need to create your own widget.
I find QtCore a very solid framework, but if it were up to me I'll chose ExtJS for the UI. Of course, not every project can be a Web Application. When it comes to C++ Qt is the best UI framework, but it doesn't mean it is perfect. I still miss most of ExtJS functionalities.
Well, anyway.. I was just making a suggestion. It is ment for the people who made QtWidgets and the people who are constantly trying to improve them. And it is a suggestion from a developer who has worked with different UI APIs and who have seen and experienced different features that could improve this particular API. It's up to those people to do something or not.
If you can make good proposal (with strict descriptions how do you see these things or other) it will be good to push it to bugreports. Of course, you will not see it in Qt4 (because of ABI compatibility), but all can be in case of Qt5. If you will do it, post a link here, please.
Well, I am working on a project that will have most of this features, eventually. But right now we are working on the backend. When the time is right I will post the first version of this new List+Tree+Grid view.
As of the PushButton and ToolButton, just found this in the BugTracker:
"Allow QAction to take over a QAbstractButon":http://bugreports.qt.nokia.com/browse/QTBUG-7994 that someone else created.
Should I create a new ticked? Just take a look to what I commented.
Ok, I made a bugreport regardling QPushButton and QToolButton.
I leave the link here for future references "Remove QToolButton and Improve QPushButton instead.":http://bugreports.qt.nokia.com/browse/QTBUG-14785
If anyone else is interested in this please vote.
Looking forward to see trolls answer.
[quote author="kkrzewniak" date="1288252339"]QPushButton and QToolButton are totally different scope. Leave them as they are. In my opinion the power of Qt is that You can always write your own widget that will have some custom behaviour. I just think that your idea would lead to API bloating. [/quote]
You'll end up having one class, and less repeated code. AND that class will be more powerfull as it is now.
So no, I don't think it would lead to API bloating. In fact, exactly the opposite. But that's not the point. The point is satisfying a need: Let QPushButton bind with QActions. AND improve the personalization of a QPushButton instance. Maybe it's not YOUR need specifically, but it would make a lot of people's code simplier.
Besides, Qt has always been taking advantage of Web application's style of doing things. For instance, Widgets stylesheets.. or QML. So.. 8-)
Do You know of a thing called sub-classing. Both QPushButton and QToolButton are subclasses of QAbstractButton(not a lot of duplicated code now is there). If it makes Your code simpler just write your own QAbstractButton subclass. And I personally think it would be a waste of Trollpower, when you should be capable of implementing such a class your self.
Don't get me wrong I'm not against taking some good things from other worlds. But your idea of merging QPushButton and QToolButton, because you think they duplicate each others code, come on.
The thing that got me going the most was actually your thread title.
Today QPushButton and QToolButton don't have too many duplicated lines of code, that's because they aren't complex classes. The only functionality I can think of being repeated is setMenu() and menu() and that's what I meant by saying less repeated code.
But if QToolButton were merged into QPushButton (and QAbstractButton),
You will be able to bind a QAction to a QPushButton (or any QAbstractButton if that functionality is implemented into the abstract class). That would be a good improvement to QPushButton (and another reason to merge classes).
I don't know why QActions aren capable of taking over a QAbstractButton today, I think that's something that the Trolls have missed.
I see now it's no use to suggest something. I only meant to suggest something to improve Qt, cause I like Qt. I know there are more urgent fixes.. but still.
I'm not entirely sure what You mean by merging. If you mean that the Trolls need to drop QToolButton and QPushButton and add a new class than that simply would be braking backward compatibility. But If You mean adding a new class that would have the functionality of both, than I can see this being some thing that could be added to Qt. But than why don't you write it your self and try making a contribution to Qt.