For now just bookmarking here: http://semantic-ui.com has a rich and convenient vocabulary of UI elements. There are obviously other reasonable assorted lists published online. Feel free to share. Most of them are more high-level than what we have in Qt Widgets or Qt Quick Controls.

I am just hoping that someone would think about adaptation one or more UI elements from there. The fact that they come from the web world is secondary I think, actually web developers had to start from near-zero level (<form> controls are ridiculously simplistic) have opportunity to take a step back. And they did so. Implementation is horrible if you look closely compared to what Qt/KDE accepts but the non-implementation factors are worth a notice maybe.

Please let me to even note just one small example, context-pointing type of label:



It's rarely adopted in KDE apps or desktop apps in general. But yeah, I am using it in Kexi already. it kills so many annoying small message boxes that blink on your screen.

I am not pushing to extend our HIGs to ridiculously detailed. It may be that we could have a "candidates" to the HIG and let application developers to ask here, adopt concepts, experiment. Once element is popular among apps in our community, it can evolve into an official one. Just a though.

And hey, this gives opportunity to employ powers of design in our community!

PS: There are also catalogs such as http://quickui.org/catalog that are not just references of controls but often discusses key attributes in terms of UX. For example: Popup.

PS2: Qt Quick adds some support for Andoid style of controls these months so if a Qt app uses Qt Quick it automatically can have access to the extended set. Example is Action Bar. Maybe Qt Widgets apps for non-mobile use cases could benefit from at least some of the control types? Implementation (Qt Quick Controls vs Qt Widget) is largely separate but hopefully some HIG pages can be shared regardless of the target (mobile or desktop devices).

We're certainly open to new interaction patterns in addition to what QWidgets (+KWidgets) and QtQuickComponents/PlasmaComponents offer as today.

The HIG is supposed to be more of a description of what's already there (if what's there is good) than of what we imagine things to be (with some exceptions), though.
Therefore I'd think it makes sense that - similar to what you suggest - we explore new interaction patterns while designing and implementing new user interfaces or redesign existing ones). Then if we see that those work well both from a usability and from a technical perspective, we can write HIGs to push them as a standard.

I would second the idea of adopting this for our HIG. In general we should move towards more "on spot" information.

But yeah, I am using it in Kexi already.

If you have something that will be useful in more than one app, propose it for KWidgetAddons

david_edmundson wrote:If you have something that will be useful in more than one app, propose it for KWidgetAddons

Sure, on my TODO list. For now I have a bit specialized extension of KMessageWidget



IIRC some of my improvements went to KMessageWidget (kdelibs4) long ago but not the 'callout' feature. I must admit it's hard to program and use it because of specifics of how Qt Widgets work; apps use layouts, callouts sometimes like to be like popups. There are challenges when apps get resized.

But overall I like the final effect, apps feel nicer when they don't shot modal dialogs too often.

Actually, for the specific situation shown in your example, a callout with controls in it is not the right control.
RKward handles this situation better:

As whether the file exists can be detected before the form is submitted, a checkbox makes more sense than asking a question (how would the user's answer to the question be visualized in the form before it's submitted?).

colomar wrote:Actually, for the specific situation shown in your example, a callout with controls in it is not the right control.
RKward handles this situation better:

As whether the file exists can be detected before the form is submitted, a checkbox makes more sense than asking a question (how would the user's answer to the question be visualized in the form before it's submitted?).

Thanks but it looks suspicious to me. I see a number of GUI bloopers there; moreover the dialog looks really complicated and IMHO deserves turning it into an assistant. If you want to propose the alternative confirmation approach, let's have separate thread...

jstaniek wrote:Thanks but it looks suspicious to me. I see a number of GUI bloopers there; moreover the dialog looks really complicated and IMHO deserves turning it into an assistant. If you want to propose the alternative confirmation approach, let's have separate thread...

The dialog overall is... well... not exactly well designed, to say the least. I should have added that as a disclaimer
It was just the first example that came to my mind for the confirmation, which is one thing I think it does right.

About the extended messagewidget in general: Yes, it could be used in other places, though we have to be very careful with the guidelines for it. The general HIG for the messagewidget states "Do not add additional controls to the message panel". The reason for that is that a messagewidget is something that users may see, but not necessarily have to see or interact with. It should be used to display additional information, not for making choices.