Moderator
|
While working on the Extended HIG for tabs proposal I noticed usage of both control and widget terms exchangeably in the HIG documents. Would it make sense to pick only one? For example, compare Tab Control and Message Widget in the KDE HIG.
IMHO widget is traditionally a bit wider term, not reduced to controlling something. If it helps, it's user-visible in specialized apps (like Kexi app builder's Form Designer or Qt Designer) that expose the concept to user. If course 99% of the apps do not need to expose any such term to the user at all, no matter if control or widget is used. Also, from my experience, Free Software often use widget, closed one not so often. |
Registered Member
|
I can explain this
We discussed widgets vs. controls when we started the HIG reboot. The reason why we chose "controls" was that we thought "widgets" might remind developers (which are the main target of the HIG, not end users!) of QWidgets and therefore might make them think that the HIG only applies to the QWidgets world. We thought that "controls" would encompass both QWidgets and QML controls. The fact that the message widget is called widget is because it's kalled KMessageWidget in the code (and we were not aware of a QtQuick equivalent with a different name). If "Widget" has crept into other HIGs as well, then thatw as by accident. The goal is to always use "control" to be implementation-neutral. If you convince us that "widget" does not make developers think "QWidgets", then we'll happily revise that decision |
Moderator
|
Well,
The story behind Control in Qt Quick is quite simple if I remember correctly from the Qt Contributors summit: to avoid references to Qt Widgets indeed. Semantics of both terms were secondary at that time. I understand the target of HIG is toolkit independent, it shall be useful even if some brave hacker decides to use HTML5 as the building block. Now, if technically-oriented reader studies the HIGs, controls suggest the Qt Quick GUI elements. Since the HIG is a book in form, perhaps "GUI element" term would fit? PS: Even after a Qt Quick port of Kexi materializes (for tablets), I am convinced to use widget term in user-visible strings. By the way the "GUI element" is the general term but rarely used *in messages* because it's hell long. I am also doing translation of the app to Polish and a word based on "widget" was accepted as the generic term (a single noun was needed for important reasons, including using short identifiers). |
Registered Member
|
Yeah, we made the decision to go with "control" before QQuickControls was born. I agree that now we're inadvertently biased towards the latter
About end-user-facing text: To be honest, we haven't thought about that yet, as applications talking to the user about widgets is a special case. We're completely open to suggestions in that regard. |
Registered Member
|
I'm fine with both terms. If we switch to 'widget' it would be a lot of effort to replace all 'controls'.
|
Registered users: bancha, Bing [Bot], Evergrowing, Google [Bot], lockheed, mesutakcan