Re: [Development] Notes from the QWidget session
On Fri, 29 Jun 2012 11:57:58 ext Olivier Goffart wrote: On Friday 29 June 2012 11:50:55 Alan Alpert wrote: On Tue, 26 Jun 2012 12:56:06 ext Harri Porten wrote: - Converter of .ui files to QML? That's a good idea, and actually pretty close to useful already. All you really need to do is to register all the QWidget types into a QtWidgets import, they're already QObjects and I think all designable attributes are already marked as properties. Write a plugin that's all qmlRegisterType lines, and a utility that turns XML into QML (trivial, and I think I still have one lying around from ye olde days ;) ) and it should be pretty simple. Mind you, there's a big difference between QML and .ui2 - this is one reason why there's a QtQuick module instead of just using the Qt Widgets in QML. Without signals on the properties, bindings won't work. Also without a default children property, the hierarchy doesn't build up naturally (or at all, the plugin of just qmlRegisterTypes might only work for single widget scenes). Neither the property set nor the property implementation is geared towards animation in widgets, so I doubt you'd get good results from trying to animate it using QML animations (worth a test though). All are fixable, but would require significant work on the widget set. All these issues are also reaching beyond features that are provided by .ui files, so go past the issue of porting from Qt 4. I thought I had an ancient example which exposed QWidget in 4.6, but I can't find it. For the reasons described, it wasn't very useful anyway. The key point is that you can have any tree of QObjects described in QML, and it would be trivial to create a wrapper that places the root item as the central widget in a QMainWindow, as opposed to the current wrapper which places the root item into a QQuickItem scene. The idea was more to do a mapping to get it works with the desktop components: QPushButton - Button text - text default - defaultButton icon - iconSource ... QLineEdit - TextField text - text readOnly- readOnly displayText - placeHolderText ... There is a lot of properties to map. Not every property can be mapped, and there may be some trick required for some types (such as QIcon) The idea is that you would run such a script once over all your .ui files. when you port your application to QML. That may save you a lot of time if you have several handreds of forms to port (qt-creator has 207 .ui files) The script may leave comments in the code about stuff it could not port. Once the script is run, you are only half done. You still need to ajust the C++ part. Is it worth the effort to implement such a tool? Or will the developer will anyway re-write their entire UI from scratch (including all the dialogs) if they want to move away from QtWidgets? (Or maybe there is really no reason to move away from QtWidgets, and one should continue to use it for dialogs) Right now I'd say it's not worth the effort, because there's no reason to move existing UIs away from QtWidgets yet. QtQuick and QWidgets will coexist initially because they're designed for different UI usecases. Existing QWidget style UIs shouldn't rewrite with QML unless they want to change their style as well (which means a rewrite anyways). Continue using QtWidgets for your dialogs; they're only marked done because they're really, really good at their job :) . When Desktop Components are complete they'll be a good choice for new projects, but I'm not sure that they'll ever be much better than QWidgets for the widget style of user interfaces. I certainly wouldn't make such a call until they're more complete and widely used, perhaps this tool can be considered then. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
On Jun 29, 2012, at 3:50 AM, ext Alan Alpert wrote: On Tue, 26 Jun 2012 12:56:06 ext Harri Porten wrote: Here are my notes from the QWidgets session on June 22th, 2012, 11:30 o'clock: http://qt-project.org/groups/qt-contributors-summit-2012/wiki/QtWidgets ,,, Help with migration from Qt 3/4 to 5 - Desktop QML components (using QStyle) - Wrap QWidgets in QML container element That's not going to be quite as easy as the inverse. While I think QML needs to be embeddable inside a QWidget scene for 5.0, there are a couple problems with the inverse so it will probably be a while until that works. See examples/declarative/cppextensions/qwidgets (Qt 4.x) for an example, it requires a QGraphicsProxyWidget equivalent (QGPW was almost 2k LoC, a lot more complex than the 103 line QWindowContainer WIP) and it requires a custom class to expose widget properties to QML. So even a complex container element is not enough, you also have to make every widget QML compatible (not actually that hard, most of them use Q_PROPERTY already). Not to mention the performance wreck it will turn into... QGraphicsProxyWidget was horrible for performance if you had more than one or two. One reason for this is that the styles need to be rendered with raster (or possibly native) paint engines because of its ease of integration with native style APIs and its superior quality compared to the OpenGL engine. This results in each widget having to be uploaded as a texture afterwards, so whenever something changes, we get rendering hickups. There are good usecases for such a class, embedding one or two toplevel widgets into an otherwise QML scene would probably be ok for performance. Embedding a proxied QPushButton for every button in the keyboard not so much... I see a people having a certain technology, say charting, which is encapsulated in a QWidget, and it should be possible to integrate those technologies into QtQuick 2.0. Just make it really hard so it is not the obvious choice :) cheers, Gunnar ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
Not to mention the performance wreck it will turn into... QGraphicsProxyWidget was horrible for performance if you had more than one or two. One reason for this is that the styles need to be rendered with raster (or possibly native) paint engines because of its ease of integration with native style APIs and its superior quality compared to the OpenGL engine. This results in each widget having to be uploaded as a texture afterwards, so whenever something changes, we get rendering hickups. The other problem is all the painting setup that happens behind the scenes inside QWidget::render() before actually getting to the QWidget::paintEvent() (http://labs.qt.nokia.com/2009/12/16/qt-graphics-and-performance-an-overview/). That also costs quite a bit in many cases.. There are good usecases for such a class, embedding one or two toplevel widgets into an otherwise QML scene would probably be ok for performance. Embedding a proxied QPushButton for every button in the keyboard not so much... I see a people having a certain technology, say charting, which is encapsulated in a QWidget, and it should be possible to integrate those technologies into QtQuick 2.0. Just make it really hard so it is not the obvious choice :) cheers, Gunnar ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
So, what should i do to create a new playground project for new widgets? According to http://qt-project.org/wiki/Creating-a-new-module-or-tool-for-Qti need to discuss module on a mailing list first:) I prefer to have work in a QtWidget's module (to have access for private classes), so i think, i need somehow clone qt to a separate repo. How should i do that? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
On Friday 29 June 2012 12:52:23 Иван Комиссаров wrote: So, what should i do to create a new playground project for new widgets? According to http://qt-project.org/wiki/Creating-a-new-module-or-tool-for-Qti need to discuss module on a mailing list first:) I prefer to have work in a QtWidget's module (to have access for private classes), so i think, i need somehow clone qt to a separate repo. How should i do that? You can either ask the gerrit admins (on IRC for example) for a feature branch. Or you can simply start making your branch elsewhere, on a gitorious clone (or github, ...) My personal recommendation: start on a clone, and once you have something worth reviewing, it can be merged in a branch on gerrit. -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
Ok, i'll do that on a gitorious. 2012/6/29 Olivier Goffart oliv...@woboq.com On Friday 29 June 2012 12:52:23 Иван Комиссаров wrote: So, what should i do to create a new playground project for new widgets? According to http://qt-project.org/wiki/Creating-a-new-module-or-tool-for-Qti need to discuss module on a mailing list first:) I prefer to have work in a QtWidget's module (to have access for private classes), so i think, i need somehow clone qt to a separate repo. How should i do that? You can either ask the gerrit admins (on IRC for example) for a feature branch. Or you can simply start making your branch elsewhere, on a gitorious clone (or github, ...) My personal recommendation: start on a clone, and once you have something worth reviewing, it can be merged in a branch on gerrit. -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
On 06/29/2012 09:04 AM, gunnar.sle...@nokia.com wrote: I see a people having a certain technology, say charting, which is encapsulated in a QWidget, and it should be possible to integrate those technologies into QtQuick 2.0. In fact this is not a good example as the code for displaying charts is usually QPainter ( or QGView ) based - and doesn't rely on QWidget much. As long as there is the bridge between QPainter and the scene graph there is not much code that would be lost. Binding this code to QML is a different story, but why should someone do this ? Much more important is all the code, that has been written to modify the standard Qt widgets by overloading/reimplementing virtual methods or extending/tailoring the API for the specific requirements of the project. Any larger project I have seen implements such widget libraries. Just make it really hard so it is not the obvious choice :) Even if meant ironic: when you believe in a new technology let it compete by making it possible to co-exist. Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
Op 27-6-2012 22:17, Иван Комиссаров schreef: Hm... What about adding new (maybe rather simple) widgets? QtCreator has QtColorButton class, QtFontButton, lineedit for editing shortcuts (i have my own modified copy). Browser example has ModelMenu and ModelToolBar classes (rather useful in some cases). Recently, I implemented Windows menu (popup menu with list of top-level windows and actions to minimize/maximize/change current window). I can add these classes to QtWidgets, if needed. IMHO, it's nice to have color button in Designer, for example. I'd like to suggest that additional widgets, unless they represent a very important addition so that Qt can support a now-common UI design pattern, are not added to QtWidgets but to an addon module. With the lack of a maintainer (let alone a set of them), I think it does not make sense to complicate the module even more. I think the widgets you mention may be useful in some applications, but it is not like they will be used all over the place. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
Everyone i know copy such small widgets in each application they develop... As for WindowsMenu - on Mac it is built in designer form, you don't even need to add it manually. IMHO, each multiple-window app needs it. And what you suggest? To have QtWidgets and QtWidgets2 module? Why do we need this fragmentation? As for me, QtWidgets is very small module, compared to mac os native widget set. And KDE guys have inherited class from almost every qt widget class, which means that Qt doesn't provide enough functionality. 2012/6/28 Andre Somers an...@familiesomers.nl Op 27-6-2012 22:17, Иван Комиссаров schreef: Hm... What about adding new (maybe rather simple) widgets? QtCreator has QtColorButton class, QtFontButton, lineedit for editing shortcuts (i have my own modified copy). Browser example has ModelMenu and ModelToolBar classes (rather useful in some cases). Recently, I implemented Windows menu (popup menu with list of top-level windows and actions to minimize/maximize/change current window). I can add these classes to QtWidgets, if needed. IMHO, it's nice to have color button in Designer, for example. I'd like to suggest that additional widgets, unless they represent a very important addition so that Qt can support a now-common UI design pattern, are not added to QtWidgets but to an addon module. With the lack of a maintainer (let alone a set of them), I think it does not make sense to complicate the module even more. I think the widgets you mention may be useful in some applications, but it is not like they will be used all over the place. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
*@*Harri *Yes. And to be realistic: a single maintainer won't be enough* Agreed. There should be five QtWidgets maintainers like in the list ( http://qt-project.org/wiki/Maintainers), but Stephen Kelly is the only one. After that is said - one more maintainer would certainly improve the situation a lot. *Nice to hear.* I plan to optimize (/refactor) it further since I now know the QHeaderView code very well - but beside that I have a lot of ideas. Just to state a few of them: * Drag and drop with option to like being next to a Widget and with a sticky option that a kind of connects the widgets (when one of the widgets is moved the other is too. This is not something I plan to do - at least not in the near future) * A multiline QLineEdit * Put in a checkbox in QMessageBox - so that it could state something like: Do not show this message again - or I know this implies (It would need an option to prevent certain answer - e.g before this option is checked ...) Ideas to improve QtWidiget is not something that we lack - but we need more people in every level (contributes, approves and maintainers). For me - improving Qt is just a hoppy. I cannot put a full time job into this (if I want to keep my family ... which I currently want to ... :) ) @Иван I do think that your idea on more Widgets in the designer is good - and maybe we also need some function ported from KDE to Qt. Doing something with QtWidgets can clearly show that it is still very much alive :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
On quinta-feira, 28 de junho de 2012 09.07.55, Thorbjørn Martsum wrote: * A multiline QLineEdit That's called a QTextEdit -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
Btw, it would be great if someone will implement multi-line label. Right now, it is impossible to wrap text in a QLabel using non-whitespace symbols. For example, i want to wrap file path using '/' as a wrapper. However, i prefer not to deal with text( I took a small look into a KDE classes. 1) http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKIntSpinBox.htmlbase; property can be added to QSpinBox. 2) http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKFontRequester.htmlcan be added as a separate qtwidget instead of FontButton mentioned eariler (i personally prefer widget). 3) http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKColorPatch.htmli prefer QtCreator's QtColorButton here (it has some API, at least) 4) http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKDualAction.htmlnice, but i don't like API (duplicated active/inactive methods plus QAction own setText/Icon/etc methods). Need more discussion here 5) http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKLineEdit.htmli won't deal with QLineEdit, but it needs following features - clear button, custom menus (Creator's FancyLineEdit functionality) and ability to draw placeholder text even if QLineEdit has focus 6) http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKTabBar.htmli would like to add mouseMiddleClick(int index) signal, mouseDoubleClick(int index), mouseDoubleClick() or newTabRequest() signal (i prefer first name - more flexible) to QTabBar and QTabWidget. Reasoning - people need to subclass QTabBar/set event filter to track double clicking on an empty space. Also i would like to see property that allows to set if QTabBar should switch tabs while user drags mimedata over it (common FileManager/browser functionality). I would like to see prop for autohiding tabbar when there's only 1 tab. Same is for close button - most tabbed apps do not allow to close last tab. Plus widgets i mentioned earlier. Should i create a playground project, or i can start adding widgets as a separate commits on top of current master (yes, qt5 is frozen, but i will simply rebase commits when there will be 5.1 branch)? 2012/6/28 Thiago Macieira thiago.macie...@intel.com On quinta-feira, 28 de junho de 2012 09.07.55, Thorbjørn Martsum wrote: * A multiline QLineEdit That's called a QTextEdit -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
On quinta-feira, 28 de junho de 2012 12.03.16, Иван Комиссаров wrote: Should i create a playground project, or i can start adding widgets as a separate commits on top of current master (yes, qt5 is frozen, but i will simply rebase commits when there will be 5.1 branch)? Playground project, unless the maintainer says otherwise. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
On Thursday, June 28, 2012 12:03:16 Иван Комиссаров wrote: I took a small look into a KDE classes. http://community.kde.org/Frameworks/Epics/Qt_5.1_Merging If you're interested to work on this stuff, it might make sense to coordinate on a kde list: https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
On Tue, 26 Jun 2012 12:56:06 ext Harri Porten wrote: Here are my notes from the QWidgets session on June 22th, 2012, 11:30 o'clock: http://qt-project.org/groups/qt-contributors-summit-2012/wiki/QtWidgets ,,, Help with migration from Qt 3/4 to 5 - Desktop QML components (using QStyle) - Wrap QWidgets in QML container element That's not going to be quite as easy as the inverse. While I think QML needs to be embeddable inside a QWidget scene for 5.0, there are a couple problems with the inverse so it will probably be a while until that works. See examples/declarative/cppextensions/qwidgets (Qt 4.x) for an example, it requires a QGraphicsProxyWidget equivalent (QGPW was almost 2k LoC, a lot more complex than the 103 line QWindowContainer WIP) and it requires a custom class to expose widget properties to QML. So even a complex container element is not enough, you also have to make every widget QML compatible (not actually that hard, most of them use Q_PROPERTY already). - Educate developers about UI/backend separation - Converter of .ui files to QML? That's a good idea, and actually pretty close to useful already. All you really need to do is to register all the QWidget types into a QtWidgets import, they're already QObjects and I think all designable attributes are already marked as properties. Write a plugin that's all qmlRegisterType lines, and a utility that turns XML into QML (trivial, and I think I still have one lying around from ye olde days ;) ) and it should be pretty simple. Mind you, there's a big difference between QML and .ui2 - this is one reason why there's a QtQuick module instead of just using the Qt Widgets in QML. Without signals on the properties, bindings won't work. Also without a default children property, the hierarchy doesn't build up naturally (or at all, the plugin of just qmlRegisterTypes might only work for single widget scenes). Neither the property set nor the property implementation is geared towards animation in widgets, so I doubt you'd get good results from trying to animate it using QML animations (worth a test though). All are fixable, but would require significant work on the widget set. All these issues are also reaching beyond features that are provided by .ui files, so go past the issue of porting from Qt 4. I thought I had an ancient example which exposed QWidget in 4.6, but I can't find it. For the reasons described, it wasn't very useful anyway. The key point is that you can have any tree of QObjects described in QML, and it would be trivial to create a wrapper that places the root item as the central widget in a QMainWindow, as opposed to the current wrapper which places the root item into a QQuickItem scene. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
Thanks for the update. I just want to say 'hear hear' (or at least Looks good to me, but someone else must approve) ;) I do think that it would be a *very good idea* to have a QtWidget maintainer. Not because Girish isn't a good approver (since he obviously is) - but in order to ensure that people sees QtWidgets as alive. One of the reasons people consider Qt Widgets as dead (and can argue that they are) - is the lack of a maintainer(!) - and it would be far easier to spread the word about QtWidgets if we had a such. But of course the Widgets are still alive - and Stephen Kelly is also helping improving the Item Views in Qt Widgets - and afaik there has been some nice fixes. To brag a bit I have (with his help) improved QHeaderView so that TableViews can handle many data and unlike Qt4 do moveSection, swapSection(s), hideSection and trunc of model reasonable fast. (Hopefully without any regressions:) ) However - the above is actually not just to brag. It is to give an example of something that has been improved. We need to show and know(!) about QtWidgets progress. It is easy to state: Qt is alive - but someone could ask ... why?. (And the reason 'it wasn't killed is not enough ...). So if people knows about big (or many) improvements to QtWidgets - it could be a good place and time to speak up. So here is a good chance for people to give credit to themselves (or others) Btw. Is somebody looking into the regressions in QGraphicsView? On Tue, Jun 26, 2012 at 12:56 PM, Harri Porten por...@froglogic.com wrote: Here are my notes from the QWidgets session on June 22th, 2012, 11:30 o'clock: http://qt-project.org/groups/qt-contributors-summit-2012/wiki/QtWidgets General === - Great interest in QtWidgets - Code base actively ported to Qt 5, far from dead. - Present company considering maintainership Candidates for new widgets == - Breadcrumb navigation - Progress spinner - Make use of KDE Frameworks 5 + Clear button in QLineEdit + URL button, etc. - Check out widget galleries from other toolkits - Be aware of platform-specific IP protection Help with migration from Qt 3/4 to 5 - Desktop QML components (using QStyle) - Wrap QWidgets in QML container element - Educate developers about UI/backend separation - Converter of .ui files to QML? Open Issues === - Regressions in QGraphicsView - Fixes needed for Mac OS X Lion - Investigate Windows 8 Metro - Get message out about QWidgets being alive ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
On 27/06/2012 12:55, ext Thorbjørn Martsum wrote: Btw. Is somebody looking into the regressions in QGraphicsView? Nope, QGV is currently lacking a maintainer. Anyone with qualifications and feeling the urge? :) -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
Hi! On Wed, 27 Jun 2012, Thorbjørn Martsum wrote: I do think that it would be a very good idea to have a QtWidget maintainer. Not because Girish isn't a good approver (since he obviously is) - but in order to ensure that people sees QtWidgets as alive. One of the reasons people consider Qt Widgets as dead (and can argue that they are) - is the lack of a maintainer(!) - and it would be far easier to spread the word about QtWidgets if we had a such. Yes. And to be realistic: a single maintainer won't be enough. It's a lot of different fields that might need to be distributed on several shoulders. So even if some individual or company steps up one has to be fair and rather help than demanding too much. But of course the Widgets are still alive - and Stephen Kelly is also helping improving the Item Views in Qt Widgets - and afaik there has been some nice fixes. To brag a bit I have (with his help) improved QHeaderView so that TableViews can handle many data and unlike Qt4 do moveSection, swapSection(s), hideSection and trunc of model reasonable fast. (Hopefully without any regressions:) ) Nice to hear. However - the above is actually not just to brag. It is to give an example of something that has been improved. We need to show and know(!) about QtWidgets progress. It is easy to state: Qt is alive - but someone could ask ... why?. (And the reason 'it wasn't killed is not enough ...). So if people knows about big (or many) improvements to QtWidgets - it could be a good place and time to speak up. Right. That was the main message we wanted to bring across. To state that a positive feedback loop rather than a negative self-fulfilling prophecy is needed and doable. So here is a good chance for people to give credit to themselves (or others) Btw. Is somebody looking into the regressions in QGraphicsView? As Marius already hinted at: it's needed. But given the complexity no easy job. A full-time job maybe. Harri.___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from the QWidget session
Hm... What about adding new (maybe rather simple) widgets? QtCreator has QtColorButton class, QtFontButton, lineedit for editing shortcuts (i have my own modified copy). Browser example has ModelMenu and ModelToolBar classes (rather useful in some cases). Recently, I implemented Windows menu (popup menu with list of top-level windows and actions to minimize/maximize/change current window). I can add these classes to QtWidgets, if needed. IMHO, it's nice to have color button in Designer, for example. Ivan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
