Re: [Development] Proposal to deprecate the amazing QApplication::globalStrut
> On 5 Dec 2019, at 20:05, André Pönitz wrote: > > On Thu, Dec 05, 2019 at 06:12:53PM +0100, Giuseppe D'Angelo via Development > wrote: >> Il 04/12/19 12:56, Volker Hilsheimer ha scritto: >>> IIRC, then I added that in the early Qt 2 days, anticipating that with >>> Qt/Embedded we might see our widgets landing on touch screens “any moment >>> now”. The idea was to have a global setting that ensured that widgets and >>> other interactables (such as menu items, list items, checkbox markers etc) >>> are >>> at least x,y pixels large. >>> >>> Well, the world has moved on, and the value has never been consistely used >>> in >>> styles or widgets anyway. >> >> Ignoring for a moment the rest of the discussion: does such a value _make >> sense_ >> in the first place? >> >> Qt-provided styles always tried to follow the OS native style, even in the >> sizing of the controls. Arbitrarily resizing controls has always been >> possible, >> but generally doing that either violates the guidelines of the native style >> (e.g. making a push button 100px high) or breaks the widget altogether >> (making a >> push button 5px high). >> >> In this light, what's the idea of a global minimum size useful for? A native >> style should rightfully completely ignore it. A non-native style could have >> it a >> as a tunable parameter, but then, actually, it could have _any_ amount of >> tunable parameters (e.g. have a minimum size for buttons, a minimum size for >> labels, etc.). >> >> Does anyone have more insights? > > I have no insight, but I can imagine scenarios where e.g. visually impaired > would like to increase minimum size of UI elements also for desktop > applications > wihout necessarily applying some global scaling to all elements. > Not matching native style is certainly a minor issue in this context. > > That's pure speculation though, and at least in the Qt Creator context > I am not aware that such a request has ever been made, and I doubt that > the current two(!) uses of QApplication::globalStrut() would be sufficient > to meet such need accidentaly. > > Andre’ The raison d’être for globalStrut was Qt/Embedded on Sharp Zaurus (it was added for Qt 2.2), and IIRC Matthias wanted to make it easy to “port” Qt *(and KDE) UIs to such Qt/Embedded devices. We only had widgets, and we had the style API from Qt 2 (which was completely different); there was no need for animations, touch was with stylus or fingernail, accessibility was barely a thing even on Windows. With the benefit of hindsight, the globalStrut design was already then dubious; instead of requiring every QWidget::sizeHint implementation to respect the globalStrut, the layout engine might have been the right place for this. When we introduced the “new” Qt 3 QStyle API, things became worse; sub controls would need to respect the globalStrut as well for “interactable elements” like a spinbox’s up/down button. But the reason why we moved to Qt 3’s QStyle API again was Windows XP and macOS introducing completely new requirements for styling, and in those pixmap-based styles, a globalStrut makes no sense (as Giuseppe points out). Today, we have QtQuick for designing touch-friendly UIs. And if you build a widget-based UI for a touch screen, then you probably want a dedicated style for that as well (you at least don’t care about native styles; I suppose you can just reimplement QFusionStyle and return expanded metrics). If you build for desktop, your users will want native look’n’feel, and they'll use that environment’s accessibility feature if they need magnification. I would imagine that the last thing users with need for assistive technologies need is every application introducing a different way to become useable for them. Volker PS: The discussion on how QStyle could become more property-driven/declarative perhaps belongs into a different email thread. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal to deprecate the amazing QApplication::globalStrut
On Thu, Dec 05, 2019 at 06:12:53PM +0100, Giuseppe D'Angelo via Development wrote: > Il 04/12/19 12:56, Volker Hilsheimer ha scritto: > > IIRC, then I added that in the early Qt 2 days, anticipating that with > > Qt/Embedded we might see our widgets landing on touch screens “any moment > > now”. The idea was to have a global setting that ensured that widgets and > > other interactables (such as menu items, list items, checkbox markers etc) > > are > > at least x,y pixels large. > > > > Well, the world has moved on, and the value has never been consistely used > > in > > styles or widgets anyway. > > Ignoring for a moment the rest of the discussion: does such a value _make > sense_ > in the first place? > > Qt-provided styles always tried to follow the OS native style, even in the > sizing of the controls. Arbitrarily resizing controls has always been > possible, > but generally doing that either violates the guidelines of the native style > (e.g. making a push button 100px high) or breaks the widget altogether > (making a > push button 5px high). > > In this light, what's the idea of a global minimum size useful for? A native > style should rightfully completely ignore it. A non-native style could have > it a > as a tunable parameter, but then, actually, it could have _any_ amount of > tunable parameters (e.g. have a minimum size for buttons, a minimum size for > labels, etc.). > > Does anyone have more insights? I have no insight, but I can imagine scenarios where e.g. visually impaired would like to increase minimum size of UI elements also for desktop applications wihout necessarily applying some global scaling to all elements. Not matching native style is certainly a minor issue in this context. That's pure speculation though, and at least in the Qt Creator context I am not aware that such a request has ever been made, and I doubt that the current two(!) uses of QApplication::globalStrut() would be sufficient to meet such need accidentaly. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal to deprecate the amazing QApplication::globalStrut
Il 05/12/19 19:10, Uwe Rathmann ha scritto: You could argue that a good style API allows to increase all sizes by overloading the virtual methods, but this is very tedious and I doubt, that you can do everything this way. Not necessarily; a style could have on itself the "equivalent" of globalStrut. However QStyle doesn't seem to have the equivalent of sizeHint / minimumSizeHint, so widgets cannot delegate that calculation to the style (which may take into account its own globalStrut), and instead widgets have use globalStrut themselves... And of course you won't be able to handle 3rd party widgets that QStyle does not know of. F.e for Qwt widgets only globalStrut is effective. So, what you're implying is: lacking a better QStyle replacement, and I strongly doubt we'll get one in Qt 6, 1) we need globalStrut, 2) we should fix all Qt's own widgets to honour it? My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal to deprecate the amazing QApplication::globalStrut
On 12/5/19 6:12 PM, Giuseppe D'Angelo via Development wrote:
In this light, what's the idea of a global minimum size useful for?
It is/was useful for widget applications running on devices with touch
screens, where the default metrics from the styles are too small.
You could argue that a good style API allows to increase all sizes by
overloading the virtual methods, but this is very tedious and I doubt,
that you can do everything this way.
And of course you won't be able to handle 3rd party widgets that QStyle
does not know of. F.e for Qwt widgets only globalStrut is effective.
Proper sizeHint implementations have to look like this:
QSize QwtWheel::sizeHint() const
{
const QSize hint = ...;
return hint.expandedTo( QApplication::globalStrut() );
}
Uwe
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal to deprecate the amazing QApplication::globalStrut
Hi Shawn, FWIW I did try to make that point during the session, since you weren’t there to do it yourself, that you would like to have something like a table of QVariants instead of only colors (to include things like icons and border line widths and radii), and also that the ColorRole enum should be extensible or replaced with something that is extensible (such as a string). When looking at the current implementation you have a combination of attributes coming from the widgets ( colors, fonts, ... ) and from QStyle ( metrics like QStyle::PixelMetric, ... ). Then you have some code that is located inside of the style, that is responsible for layouting and rendering the subcontrols from these attributes. Whether these attributes are stored in a table as QVariant or somehow else is a detail of the implementation - the issue I'm interested in is a system that allows me to extend/replace the number of attributes and the layout/rendering code in a more flexible way. Another aspect I'm missing is how to define transitions between states in an easier way. So I would like to have a system that allows me to set state depending attributes and some definitions for the state transitions ( f.e QEasingCurve::Type + duration ), so that the style can manage the transitions automatically by interpolating between the attributes. a) The system I have implemented in QSkinny splits the layout/rendering code into different classes. Those are called skinlets - what might translate to controlDelegate in the usual Qt terminology. f.e the following code registers/replaces a skinlet for a custom control: skin.declareSkinlet< MyControl, MyControlSkinlet >(); Then you can add whatever attributes are used by MyControlSkinlet and you are done. Such a system allows to replace/expand/remove the number of controls being supported by a style in a much easier way than with the monolithic approach you have in QStyle. b) Then I indeed have a table of attributes with colors/metrics/flags + attributes for the transitions. The basic idea behind separating the attributes from the delegates is that setting attribute values is something a GUI designer can do while creating scene graph nodes ( this is what the skinlets do ) is definitely a job for an experienced developer. I was thinking it would be a good start to add a high-numeric-value QPalette::ColorRole::UserRole and then you could extend that with your own enum for use in your own widgets and styles. Please allow me to add fonts here as well. All projects I have been part of in the last decade had a concept of using font roles. You have a preference dialog where the user can assign specific fonts to given roles, like f.e Title/Body/... So I would also raise the question if the inheritance model that is used for fonts in widgets and QC2 still matches the reality of the applications. But what to do instead then? More work is being done already at this time to get QPalette working better in Qt Quick, but maybe we should replace it with something else entirely? With Qt6 we will see fundamental changes in the scene graph and below and a new QML version. So the controls are actually the only layer of the Qt/Quick stack, that is not under heavy reconstruction. The question is how much changes you are willing to do. IMHO it would be time to move on with the controls too - but can this be done without major API changes ? So in the logic of being sensitive with breaking APIs this can only be done as Quick Controls 3. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal to deprecate the amazing QApplication::globalStrut
Il 04/12/19 12:56, Volker Hilsheimer ha scritto: IIRC, then I added that in the early Qt 2 days, anticipating that with Qt/Embedded we might see our widgets landing on touch screens “any moment now”. The idea was to have a global setting that ensured that widgets and other interactables (such as menu items, list items, checkbox markers etc) are at least x,y pixels large. Well, the world has moved on, and the value has never been consistely used in styles or widgets anyway. Ignoring for a moment the rest of the discussion: does such a value _make sense_ in the first place? Qt-provided styles always tried to follow the OS native style, even in the sizing of the controls. Arbitrarily resizing controls has always been possible, but generally doing that either violates the guidelines of the native style (e.g. making a push button 100px high) or breaks the widget altogether (making a push button 5px high). In this light, what's the idea of a global minimum size useful for? A native style should rightfully completely ignore it. A non-native style could have it a as a tunable parameter, but then, actually, it could have _any_ amount of tunable parameters (e.g. have a minimum size for buttons, a minimum size for labels, etc.). Does anyone have more insights? Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal to deprecate the amazing QApplication::globalStrut
Hi, Am 05.12.19 um 14:25 schrieb Shawn Rutledge: So I’m tempted to think that we could try to extend QPalette to store other data types in addition to colors, but it doesn’t look possible to maintain existing API or implementation enough to be worthwhile; and it would tend to become too much of a “kitchen sink” to keep calling it QPalette. In KDE we have this class KColorScheme [1] which provides semantic color roles, like "positive" (usually green, used for success), "neutral" (gray or orange), and "negative" (usually red, used for failure), among other things, as well as "color sets" (e.g. Window, Button, ToolTip, Selection). This way we can have a different link color for Selection, so that blue hyperlinks turn white when ontop of a blue list selection. We use this class extensively throughout our applications but since it requires reading KDE configuration files to get the colors, as Qt doesn't have them, it pull in a lot of dependencies. If we had QPalette extended to support semantic colors and color sets, we could have them configured by our Platform Theme plug-in and as a result drastically reduce our dependency chain. I don't know how common this concept is on other platforms, though. See also our discussion on KDE's Qt 6 workboard: [2]. Cheers Kai Uwe [1] https://api.kde.org/frameworks/kconfigwidgets/html/classKColorScheme.html [2] https://phabricator.kde.org/T11587 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal to deprecate the amazing QApplication::globalStrut
> On 5 Dec 2019, at 09:14, Uwe Rathmann wrote: > > Unfortunately the session about styles at the QtCS ( > https://wiki.qt.io/Qt_Contributors_Summit_2019_Program#Future_of_QStyle_for_widgets_and_controls > ) had been moved to a time slot where I had already left. > > One thing I had planned to mention is that I consider the whole styling > concept you have in Qt today as a thing of the past for embedded UIs. > All user interfaces I have worked on in the recent years consist to > 30-50% of custom controls - and the requirement of being able to style > them is beyond the concept of QStyle and friends. > > F.e think about QPalette - what is even used for QC2. This might have > been good enough for desktop applications and its limited set of > widgets, but not for the variety of fancy controls you find on embedded UIs. > > But the problem of how to make 3rd party controls "stylable" goes back > to the very beginning of QStyle - I never had a solution for my Qwt widgets. FWIW I did try to make that point during the session, since you weren’t there to do it yourself, that you would like to have something like a table of QVariants instead of only colors (to include things like icons and border line widths and radii), and also that the ColorRole enum should be extensible or replaced with something that is extensible (such as a string). I was thinking it would be a good start to add a high-numeric-value QPalette::ColorRole::UserRole and then you could extend that with your own enum for use in your own widgets and styles. Just as we provide Qt::UserRole for extending Qt::ItemDataRole. But alas enums cannot be inherited, so functions like QPalette::color(QPalette::ColorGroup, QPalette::ColorRole) cannot take enums that users have provided along with their custom widgets. That’s why QAIM::data() takes an int role instead of Qt::ItemDataRole, and also why enums don’t make actually make good keys. So I’m tempted to think that we could try to extend QPalette to store other data types in addition to colors, but it doesn’t look possible to maintain existing API or implementation enough to be worthwhile; and it would tend to become too much of a “kitchen sink” to keep calling it QPalette. But what to do instead then? More work is being done already at this time to get QPalette working better in Qt Quick, but maybe we should replace it with something else entirely? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal to deprecate the amazing QApplication::globalStrut
On 12/4/19 4:07 PM, Volker Hilsheimer wrote: That’s cool! Sadly, many of our widgets (for instance, none of the item views), and none of our quick controls respect the globalStrut property. QApplication is about widgets, while Qt/Quick is usually QGuiApplication and should be no argument here. Adjusting the itemViews to respect the globalStrut should be no big deal - IIRC I did this once by overloading QItemDelegate::sizeHint. Application UIs are anyway designed for touch if they are for devices; trying to make desktop UI concepts and widget sets work for touch UIs is fortunately a thing of the past. I agree, that not many projects will start on embedded devices with Qt/Widgets nowadays - the only motivation I can imagine might be avoiding QML. But there is a lot of legacy code and migrating it to a more recent version of Qt is not the past. F.e our previous generation of terminals is done by tweaking the windows style and is also using globalStrut. Without it things would be harder - probably not possible without patching the implementation of the windows style. So, even if it were done more thoroughly, I think a toolkit-specific “strut configuration” is no longer a sensible approach. Unfortunately the session about styles at the QtCS ( https://wiki.qt.io/Qt_Contributors_Summit_2019_Program#Future_of_QStyle_for_widgets_and_controls ) had been moved to a time slot where I had already left. One thing I had planned to mention is that I consider the whole styling concept you have in Qt today as a thing of the past for embedded UIs. All user interfaces I have worked on in the recent years consist to 30-50% of custom controls - and the requirement of being able to style them is beyond the concept of QStyle and friends. F.e think about QPalette - what is even used for QC2. This might have been good enough for desktop applications and its limited set of widgets, but not for the variety of fancy controls you find on embedded UIs. But the problem of how to make 3rd party controls "stylable" goes back to the very beginning of QStyle - I never had a solution for my Qwt widgets. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal to deprecate the amazing QApplication::globalStrut
> On 4 Dec 2019, at 13:15, Christoph Feck wrote: > > On 12/04/19 12:56, Volker Hilsheimer wrote: >> Hi, >> >> QApplication::globalStrut is a property that has outlived its purpose. >> >> IIRC, then I added that in the early Qt 2 days, anticipating that with >> Qt/Embedded we might see our widgets landing on touch screens “any moment >> now”. The idea was to have a global setting that ensured that widgets and >> other interactables (such as menu items, list items, checkbox markers etc) >> are at least x,y pixels large. >> >> Well, the world has moved on, and the value has never been consistely used >> in styles or widgets anyway. > > I am not in the position to object code changes, but the Skulpture widget > style fully respects the globalStrut for all widgets since many years. > > https://kdepepo.wordpress.com/2009/03/12/global-strut-feature/ Hi Christoph, That’s cool! Sadly, many of our widgets (for instance, none of the item views), and none of our quick controls respect the globalStrut property. So if we want to make this a thing, then it requires a fairly significant effort across our widgets (not to speak of testing the outcome). It will probably still be possible to implement a style that expands all things to a configurable size; you don’t need QApplication::globalStrut for that. Application UIs are anyway designed for touch if they are for devices; trying to make desktop UI concepts and widget sets work for touch UIs is fortunately a thing of the past. To support people with neeed for visiual or motoric support features, device platforms have accessibility solutions as well. So, even if it were done more thoroughly, I think a toolkit-specific “strut configuration” is no longer a sensible approach. Cheers, Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal to deprecate the amazing QApplication::globalStrut
On 12/04/19 12:56, Volker Hilsheimer wrote: Hi, QApplication::globalStrut is a property that has outlived its purpose. IIRC, then I added that in the early Qt 2 days, anticipating that with Qt/Embedded we might see our widgets landing on touch screens “any moment now”. The idea was to have a global setting that ensured that widgets and other interactables (such as menu items, list items, checkbox markers etc) are at least x,y pixels large. Well, the world has moved on, and the value has never been consistely used in styles or widgets anyway. I am not in the position to object code changes, but the Skulpture widget style fully respects the globalStrut for all widgets since many years. https://kdepepo.wordpress.com/2009/03/12/global-strut-feature/ ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
