![]() I might opt later for doing this, but currently its not needed, as my forms mostly consist of line edits, a few combo boxes and a yet to be implemented richttext/html editor.īut then there is also another important question: when should I extract the value of a control to actually set it as a value in the corresponding standard C++ like data wrapping class? Should I update a dir name with each keystroke made in the line edit? And should I also then update any occurrence of this name? I opted for the focus lost of a control, in order to save an edited value. I'm lucky to know that I only will need mostly QLineEdits, but this makes it really difficult to write generic code that deals with those classes, except one would write specializations for each type. There is no common interface, or even a class for it. There is no interface which allows to simply query for the (current) value of a QWidget control, each class has a specific method, most classes are derived from QWidget them selves. What I'd like to show with this table is, that there is no simple interface, if one wants to transfer values out of a control in a form like class. The interface which Qt provides for extracting the actual value of an actual control such as QLineEdit, QTextArea, QComboBox etc is a little mess. I prefer to build those forms in the RAD Editor of QtCreator, but you also can simply stick to gether the needed layouts and controls in any QWidget derived class to get a form like window to display and edit things. My application will feature many forms where data is exposed to the user, so changes can be made. In my Introduction into Qt series I already wrote a good basic overview on QWidgets, so I don't want to repeat to much of this here, and more forward to focus on actually using QWidgets to build forms. I am much more productive in QWidgets, and as I do have a need to use this program at some day, I opt for the more mature technology, which also has great tooling support in the QtCreator: QWidgets. ![]() Writing a Qt wrapper around my Qt-free backend, to expose it to a QtQuick UI will bring me just more work, but no benefits compared to QWidgets. There is no such thing in QML as generic concepts, everything that needs to be exposed to QtQuick needs to go through Qt land first, meaning I have to expose it either as its own QObject derived type or implement a model for it. One goal of this project is to explore the possibilities of creating generic code for use in Qt, such as the generic context menu class. Also I do favor C++ over Javascript, and I'm not sure what the benefit is of adding another layer of JS Logic into my code. I do have quite a bit of experience in QWidgets, I couldn't write similar code for QtQuick. QtQuick is since Qt5.5 offering most controls which QWidgets has, yet the tooling for QWidgets is in the Creator much nicer, and makes me more productive, then when getting frustrated with the QtQuick editor.Īs this is going to be a complex application, I don't want to add a nother layer of complexity, aka QML/Javascript and its Qt driven engine. ![]() Currently my code is based on Qt 5.3, a TreeView Element in QtQuick is now only added in Qt 5.5. I plan to implement a smaller, not to complex application later this year actually in QWidgets AND QtQuick, as a basis to compare and see where things are heading UI wise in Qt. Why I opt for QWidgets instead of QtQuickįirst, this post is not about comparing both UI implementations. And wouldn't it fit so well in this series? Some of the feedback on last weeks part about context menus and widgets was that using QtQuick for UI would be now much more feasible. So, the main focus of this post is the form like panel/widget classes that allow editing of different elements in the tree. The last post was about writing a generic class for context menus. ![]() The sixt part of my series about writing applications in C++ using Qt and boost is about my thoughts on widgets and how to interact with data from them. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |