Thank you Andre, for putting that much more tactfully. My frustration is not 
due to anyone on this list, but a more general frustration with modern UIs that 
lack intuitiveness. It seems that it's assumed tht people will click around and 
explore the UI, however I claim this is a product of bad design to start with. 
I spent a lot of time in the 90s and 2000s studying UIs. And in fact I give *a 
ton* of credit to Qt made making great UIs easily. There was once a process 
that I used to to go through of UI normalization, which is derived from 
database normalization (3NF and the like). There were a few common rules that 
when applied would result in a very clear, intuitive UI. I constantly have to 
explain these to people graduating with degrees in design. Too concerned with 
colors, padding and fonts, the usability is overlooked. 6 steps to so something 
that could happen in 2, and without cluttering the UI.

Anyway, to bring it back to the matter at hand, yes, you are again correct. My 
conclusion of "buttons" is too specific to engage in a cooperative dialog. I'm 
open to a variety of UI solutions.
I see it in my mind as:
Build & Run      [+] [^] | // (+ = Add Kit, ^ =import icon)
- Platform1              |
--Build                  |
--Run                    |
Build & Run              | 
[+ Kit]  [Import]        | // or move to bottom of Build & Run area, below 
platform list.
- Platform1              |
--Build                  |
--Run                    |

I remain open to alternatives. Like, we could see what other platforms or 
builds are available, and offer them with an "activate" button.

So while fiddling around some more, it seems this last option is already the 
case (See attached) There are grayed out options, and when I click on them they 
get a red exclamation. Neat. Id on't know why this didn't work to begin with? 
But it does now. 

One suggestion is when I click on the Platform, it selects the build child 
item. It might be useful to display the context menu since I effectively can't 
do anything with the platform item. But if I right click on the platform, I can 
disable it (or copy steps). It's be a good way to clue the user into the 
availability of a context menu.

> Sent: Thursday, December 01, 2016 at 4:07 PM
> From: "André Pönitz" <>
> To: "Jason H" <>
> Cc: "Andre Poenitz" <>, qt-creator 
> <>
> Subject: Re: [Qt-creator] Lost in 4.2
> On Thu, Dec 01, 2016 at 05:33:08PM +0100, Jason H wrote:
> > > Sent: Thursday, December 01, 2016 at 5:02 PM
> > > From: "Andre Poenitz" <>
> > > To: "Mike Jackson" <>, "Jason H" <>
> > > Cc: qt-creator <>
> > > Subject: Re: [Qt-creator] Lost in 4.2
> > >
> > > 
> > > Mike Jackson <>
> > > > <rant>
> > >  >  Rule 1: "new" way of doing user interfaces dictates that in no way
> > >  > should the UI widgets indicate that they can be clicked, moved or
> > >  > interacted with. It is entirely up to the user to simply click all over
> > >  > the interface until some hidden menu shows up or something happens.
> > > 
> > > This is an old-fashioned, standard context menu on items in a tree view,
> > > a concept that is in use in dozens of places all over of Qt Creator since 
> > > the beginning.
> > > 
> > > The fact that it *also* reacts to single clicks is a convenience shortcut
> > > for people who are capable of reading documentation or possible
> > > asking politely on the mailing list. Also rather old-school skills.
> > 
> > 
> > It looks nested, but not a tree to me. 
> It is a QTreeView. There's a delegate to make the first level of items a
> bit larger and bold. The view is also forced to be always expanded, and
> the expand/collapse markers are suppressed (since they wouldn't serve
> much of a purpose since it's not collapsable...)
> The core of this terrible modernization is
>     void SelectorDelegate::paint(QPainter *painter,
>         const QStyleOptionViewItem &option, const QModelIndex &index) const
>     {
>         auto model = static_cast<const ProjectsModel *>(index.model());
>         QStyleOptionViewItem opt = option;
>         if (TreeItem *item = model->itemForIndex(index)) {
>             switch (item->level()) {
>             case 2: {
>                 QColor col = creatorTheme()->color(Theme::TextColorNormal);
>                 opt.palette.setColor(QPalette::Text, col);
>                 opt.font.setBold(true);
>                 opt.font.setPointSizeF(opt.font.pointSizeF() * 1.2);
>                 break;
>                 }
>             }
>         }
>         QStyledItemDelegate::paint(painter, opt, index);
>     }
> All these *gosh* deviations from a stock QTreeView instance are direct
> responses to explicit requests that were made by users of the features
> during the four(!) months this has been publically accessible to anyone
> who has a strong opinion on how the next release of a piece of software
> should look like.
> The change went in intentionally in the very early days of the 4.2 
> development branch since it is known and understood that certain 
> people are bound to express strong opinions on any kind of UI change,
> warranted or not, etc, etc, to give everybody remotely interested
> the opportunity to comment early, ideally before UI string freeze
> which typically marks the end of UI changes for a release.
> > There needs to be buttons.
> Let me try to translate this into something that I would consider
> a socially acceptable phrasing of exactly the same idea:
>    "Hey guys, I really tried, but had a hard time to find out how to get
>     a kit active for my project. Can't you add a button or two to make
>     the functionality from the context menu more directly accessible?"
> My role then would be to respond with something like
>    "Well, it would make it look more cluttered, but sure, there's
>     still some room at the bottom, should we put it there?"
> This follows a traditional pattern of human communication, even if it
> looks a bit convoluted, if not nonsensical. It leaves you enough room to
> not spell out what you really mean between your lines, and it leaves me
> enough room to not spell out things I really mean between my lines and
> gives both of us an opportunity to actually solve a problem without
> getting overly agitated or upset.
> >I vehemently oppose degradation of usability because it isn't "modern".
> You bark at a change that effectively removes several hundred lines
> of custom code implementing a machinery of two (three, actually)
> handcrafted tab bars that were specifically designed to look different
> and modern at the time and was unique not only within Creator, but also
> not present in any other application I am aware of, and that replaces
> aforementioned with a stock 90's treeview with two dozen lines of
> customization on top (also available at the time).
> Looks like mankind truly entered the post-factual age.
> Andre'
Qt-creator mailing list

Reply via email to