Re: Feedback wanted: Improvements to current Qt Widget/style mechanism
On Tuesday 06 April 2010, Caio Marcelo de Oliveira Filho wrote: what i didn't see was anything about animaton / state transition requirements and what isn't in scope (e.g. feed starving children, improve Qt's model/view painting with delegates). Regarding animation/states: it seems like it's something to be implemented by specific styles and/or widgets. The idea here is to provide a Styling mechanism that is flexible enough to support whatever look and feel designers want. That includes animations, but no dedicated infrastructure was thought for that. the style shouldn't be more targeted about provide the right graphical elements? state tracking seems more a job for the populator if i understood correctly the first descryption of it? Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Feedback wanted: Improvements to current Qt Widget/style mechanism
On Wed, Apr 7, 2010 at 7:18 AM, Caio Marcelo de Oliveira Filho caio.olive...@openbossa.org wrote: Marco Martin notm...@gmail.com writes: Hello Marco, on one hand, i feel in order to succeed the normal qwidgets need to use this (so until qt5 their api would be a mis of model and view related stuff), but this brings to the question: what about subclasses of qwidgets that subclassed it for functionality? (i.e. kpushbutton) The current KPushButton would not be affected as there will not be a break in Qt's binary compatibility. See below if you were talking about migrating the current KPushButton to the new approach. a) Style::populate(Widget, Model = 0) method Style classes provide a populate method that is called by styleable widgets upon their construction. The arguments are the widget itself, it will be the parent of the primitives created by the style, and the optional model (backend) used by this widget. uh, so would be the primitive qobjects? Yes, they have to be at least QObjects because we want to make use of properties and notify signals in those models. Note that this is the point of view of the Style, for the Style class, its really not important the exact type here, only that it is a QObject. The fact that it has a more specific type may or may not be important, if you are populating your widget with a QML component, it isn't, you simply will load the Button.qml with a property 'model' available and put the model there. However, if you're building a C++-based style, you can either use just the QObject interface, or (in the case of our populator system) cast the correct type of the Model that you expect from that widget type. who would decide what the binding is? The Style. That has to do with look and feel, only the Style knows which primitives should react to changes in the widget/model. And also which primitives should affect the model and widget (the MouseArea for instance). It's a sane approach, however, my concern is how it goes together everything it exists right now: as i said many qwidget are subclassed for a mix of look and functionality requirements, so while wouldn't be possible to change kpushbutton and the likes to the new system overnight, even if it wouldn't be necessary to do big binary incompatible changes. i don't have clear answers, but it should be done in the way it would provide the smootherst transition path compared to what we have now Our proposal suggests that widgets are implemented in a way that the logic parts are separated. This logic parts of widgets can be reused internally by existing Qt4 QWidgets -- some of those parts even can be extracted from the Qt4 QWidgets themselves. Those parts, if made public, could be used internally by KWidgets as well. Imagine a QButtonModel, that could be extended with more functionality (let's say, KAuth integration) and a KButtonModel could be created. This KButtonModel could be used as implementation detail of both KPushButton and Plasma::PushButton. We understand that this by itself already is a good thing for KDE, that uses the entire KPushButton to get the behaviour for Plasma::PushButton. Even better, if a new environment appear (let's say, Qt make a new canvas or this new Style approach in a future version of Qt), will be easy to just reuse the logic in KButtonModel. For the Style part, we are not so sure if today's QWidget can benefit from that, but we are trying to propose something that minimize (and in some cases even reduce to zero) the need of redoing it all over again for the next Canvas. The graph scene assumption that is in the Style proposal probably will be still appliable in the next Canvas, so even if the basic types change, the core of a Style (and of the widgets visual parts) can still be easily portable. Hope that it clarified a little bit the issue. Glad to hear that is exactly the idea i had back in January...I think I talked about it to Marius, Artur and Gabriel. Dude seriously I need to come to Recife! Cheers, -- Caio Marcelo de Oliveira Filho OpenBossa - INdT ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Feedback wanted: Improvements to current Qt Widget/style mechanism
Hello! We had some talks about this during Tokamak3 (in Switzerland) and we collected the feedback, thought about some solutions and came up with this proposal. It's also important to say that we want to do everything related to this subject as open as possible and that's why we're including you since the beginning of the discussions :) So please, give us some feedback and help us improve the state of the art of Qt's widgets/styles. Hi, We are writing to get some feedback from you in the context of a proposal to improve current widget/style mechanism of Qt. We would like to ask you to read this and provide feedback, in particular by answering the last three questions. Keep in mind that all of this is work in progress, and even though we wrote some experimental code, there's nothing written in stone. == Reason == Developers that want to customize the UI and/or behavior of existing Qt widgets (QWidgets or QGraphicsWidgets) are not able to do that with QStyle, or don't want to, either because it uses an outdated procedural painting approach or because it is not flexible enough. As a result, many people writing rich UIs are writing their own widgets instead of using those available in Qt. However this process is time-consuming and leads to the creation of code that is duplicated and prone to bugs. The Qt Components project was born to provide a better solution for those willing to customize the look and feel of C++ widgets as well as to provide an easier way for Qt Quick developers to handle the boilerplate code of their UI. == Proposed solution == Our proposed solution has the two following parts: -- Models -- The first is a set of UI-independent models (back-ends) that will hold the boilerplate logic currently found inside the technology-specific widgets (QPushButton, QSlider, etc) What we want to solve here is the separation between what is: - look and feel: How does this button respond to a hover event? What is the click area of it? Is this slider shown as a bar or a twisting knob? - state and logic: The mouse went out and in the mouse area, is that a click? This button is inside a mutual exclusivity group, which button should I uncheck when this one is checked? The benefit is that Qt Quick designers can use this button backend to handle the developer-oriented logic and focus on what matters, UI. Also, if we have widgets implemented as QWidgets for instance, it becomes easy to implement their QGraphicsWidget or QDeclarativeItem counterparts, without duplicating the code. -- Style -- The second is a new styling mechanism that is flexible enough for rich UI applications to use and that fits the existing technologies as well as the upcoming ones. The main reason for creating a new style system in Qt is to use a primitive-graph approach over the existing procedural painting. That means the style will be responsible for hooking a group of primitives (image, text, rectangle) in the about-to-be-styled widget, rather than actually painting parts of it. That way we have more flexibility over how to style the widget, and it becomes easier for the canvas to automatically cache painted primitives. We came up with an architecture that uses the following concepts, that are somehow independent and that we would like to hear feedback about. a) Style::populate(Widget, Model = 0) method Style classes provide a populate method that is called by styleable widgets upon their construction. The arguments are the widget itself, it will be the parent of the primitives created by the style, and the optional model (backend) used by this widget. Example: When populating a Button the style creates two background primitives (one for pressed, one for released) and one text primitive for the button label. That probably looks fine, but raises a question, what would happen when the button label changes? How would the primitive be updated? The same holds for a button press, how would the background primitive know about that? We do not intend to create an updatePrimitives method or something that would require the widget state information to flow through the style. Neither we wanted the Button to assume/expect anything about the primitives it has. To keep that decoupled, we would rather use the data binding concept from Qt Quick. That means when the style populates the button for the first time it would create a binding between the label property exported by the button and the text property of the text primitive. For the background, it would bind the pressed property from the button model to the visible property of the pressed background primitive. Once again, the idea is to use a more designer-friendly concept and reduce the style API to a
Re: Feedback wanted: Improvements to current Qt Widget/style mechanism
On April 6, 2010, Artur Souza (MoRpHeUz) wrote: We came up with an architecture that uses the following concepts, that are somehow independent and that we would like to hear feedback about. each sound more or less plausible, but what are the functional requirements for this system? reading the various proposed methods and reverse engineering them, it seems that list is something like: * decouple logic from presentation * scoping, so the logic and/or presentation associated with a widget can be changed on the fly in an app depending on the scope (case given in your email was main UI versus a config dialog) * designer friendly * ability to do CSS styling for QtWebkit (hooray for *proper* native widgets in QtWebkit!) what i didn't see was anything about animaton / state transition requirements and what isn't in scope (e.g. feed starving children, improve Qt's model/view painting with delegates). if you can provide some more insights into the above, then i can probably provide something closer to useful input in return :) -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Feedback wanted: Improvements to current Qt Widget/style mechanism
On Tuesday 06 April 2010, Artur Souza (MoRpHeUz) wrote: Hello! We had some talks about this during Tokamak3 (in Switzerland) and we collected the feedback, thought about some solutions and came up with this proposal. It's also important to say that we want to do everything related to this subject as open as possible and that's why we're including you since the beginning of the discussions :) So please, give us some feedback and help us improve the state of the art of Qt's widgets/styles. Hi, We are writing to get some feedback from you in the context of a proposal to improve current widget/style mechanism of Qt. We would like to ask you to read this and provide feedback, in particular by answering the last three questions. Keep in mind that all of this is work in progress, and even though we wrote some experimental code, there's nothing written in stone. == Reason == Developers that want to customize the UI and/or behavior of existing Qt widgets (QWidgets or QGraphicsWidgets) are not able to do that with QStyle, or don't want to, either because it uses an outdated procedural painting approach or because it is not flexible enough. As a result, many people writing rich UIs are writing their own widgets instead of using those available in Qt. However this process is time-consuming and leads to the creation of code that is duplicated and prone to bugs. this actually happens for two reasons: to change the look is one, but i have more often seen it done purely to enhance functinality, so what would have needed to be changed is the model side. any solution should allow both use cases. so, to do a simple example let's say that the default pushbutton model doesn't allow to have a menu on press (i know it will, just an example) so, in order to have a pushbutton with menu i have to: a) subclass the pushbutton model, to add the menu manipulation into it b) subclass the visualization to let's say add an arrow that indicates it expands. The Qt Components project was born to provide a better solution for those willing to customize the look and feel of C++ widgets as well as to provide an easier way for Qt Quick developers to handle the boilerplate code of their UI. == Proposed solution == Our proposed solution has the two following parts: -- Models -- The first is a set of UI-independent models (back-ends) that will hold the boilerplate logic currently found inside the technology-specific widgets (QPushButton, QSlider, etc) What we want to solve here is the separation between what is: - look and feel: How does this button respond to a hover event? What is the click area of it? Is this slider shown as a bar or a twisting knob? - state and logic: The mouse went out and in the mouse area, is that a click? This button is inside a mutual exclusivity group, which button should I uncheck when this one is checked? The benefit is that Qt Quick designers can use this button backend to handle the developer-oriented logic and focus on what matters, UI. Also, if we have widgets implemented as QWidgets for instance, it becomes easy to implement their QGraphicsWidget or QDeclarativeItem counterparts, without duplicating the code. on one hand, i feel in order to succeed the normal qwidgets need to use this (so until qt5 their api would be a mis of model and view related stuff), but this brings to the question: what about subclasses of qwidgets that subclassed it for functionality? (i.e. kpushbutton) -- Style -- The second is a new styling mechanism that is flexible enough for rich UI applications to use and that fits the existing technologies as well as the upcoming ones. The main reason for creating a new style system in Qt is to use a primitive-graph approach over the existing procedural painting. That means the style will be responsible for hooking a group of primitives (image, text, rectangle) in the about-to-be-styled widget, rather than actually painting parts of it. That way we have more flexibility over how to style the widget, and it becomes easier for the canvas to automatically cache painted primitives. yeah, this is a good thing We came up with an architecture that uses the following concepts, that are somehow independent and that we would like to hear feedback about. a) Style::populate(Widget, Model = 0) method Style classes provide a populate method that is called by styleable widgets upon their construction. The arguments are the widget itself, it will be the parent of the primitives created by the style, and the optional model (backend) used by this widget. uh, so would be the primitive qobjects? Example: When populating a Button the style creates two background
Re: Feedback wanted: Improvements to current Qt Widget/style mechanism
Hello Aaron, each sound more or less plausible, but what are the functional requirements for this system? If we had to say _one_ problem that we want to solve, in a very informal way, that would be: Avoid the need of every new Qt-based framework/library in town to reimplement a widget and style infrastructure In particular every new project on top of QGraphicsView had to deal with that, we at INdT had a couple of those projects internally, and publicly we have libdui, UI Extensions for Mobile (aka Orbit) and the Plasma widget set. Even with QML at hand, we understand there's a demand for avoid doing stuff again and again. For example, reimplementing the logic of a scrollbar in QML is clearly possible, but in practice, you don't want to deal with that when developing applications. We think that providing the right set of tools, much of this rework and implementations of basic widget infrastructure could be avoided. In this context, some points we think are important in order to reach this goal: 1) Decoupling logic from presentation. Marius presented the core of this idea Bossa Conference this year (slides: http://www.slideshare.net/mariusbu/the-future-of-qt-widgets). With this model idea for example, it would be possible to have a class with all the information needed to make a pushbutton, that KDE would extend it and could share between Plasma::PushButton and KPushButton for instance. This would avoid having a KPushButton inside a Plasma::PushButton just to use it's logic and change the view of the widget. 2) Allow the subgraph approach instead of procedural painting As said in the email, existing QStyle does not fit for that job. 3) More extensible style system A Style system that enables us to take care of WebKit requirements is a big win, making the life easier for QtWebKit simply use the platform style and fallback to a FullCSSStyle if necessary (if the page CSS demands that). A Style system that enables using QML to describe the interface of our widgets (and even use this style in a C++ program). And that enable QML to use QDeclarativeItems that are styled in C++, what people call using native/platform style in QML. This relates to our core problem. QStyle wasn't enough for requirements of Orbit and libdui, and they had to build their own style systems. what i didn't see was anything about animaton / state transition requirements and what isn't in scope (e.g. feed starving children, improve Qt's model/view painting with delegates). Regarding animation/states: it seems like it's something to be implemented by specific styles and/or widgets. The idea here is to provide a Styling mechanism that is flexible enough to support whatever look and feel designers want. That includes animations, but no dedicated infrastructure was thought for that. Cheers, Artur, Caio and Eduardo -- Caio Marcelo de Oliveira Filho OpenBossa - INdT ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
