GNOME Human Interface Guidelines Being Updated For GTK4, Other Modern Features

[remenic]

Strictly speaking: there is no rationale in dragging a button - because buttons are not able to be dragged; or how many buttons, switches or flips have you dragged in your kitchen so far?

It is natural to drag sliders (some Hi-Fi have them or audio mixers), turn knobs - or even drag and detach tabs, if you think of them as "pages" in a book with a tab attached on the page's edge.

Please explain to me the expected behaviour of these elements in the headerbar when draging:
- a text-field: does it select text or drag the window?
- a slider: does it change the value? drag the window? only then hitting the "knob" or only when hitting the "bar" or only when hitting above/below the bar and the knob?
- a tab: does it detach? move the window?

In short: overloading elements with special, not intuitive and "unrealistic" behaviour only works because the effect is so unnatural it does not conflict with naturally expected behaviour.
But then again, what will be gained by adding unnatural behaviour to elements that otherwise mimic real-life everyday elements?

I think the comparison to a button stuck to a wall is a bad one. The window that the button is attached to is free-moving. So moving the button would move the window, but there are cases where it would not, like scrollable area's. Because of those difference, if you would try to always mimic real life, it would just be confusing because we aren't interacting with real life object. It's all simulated, and thus can (and does) behave different depending on the context.

But I think GNOME's solution to buttons is pretty good, but there are limitations like those that you mention. Dragging a slider would probably not move the window. Same for editable textfield maybe. So I guess a headerbar filled with tabs, sliders and text fields would make for a nearly unmovable window. I'd like to see a real-life example of that though. I don't think anyone has been crazy enough to do that.

[skeevy420]

What exactly do you expect to happen when dragging a button?

Nothing. You don't move objects with buttons. When you do you rip them off your clothing or electronics devices because buttons are static and perform a fixed function in a fixed place. There is nothing Human about dragging buttons.

If moving the window is not the answer, then what is the rationale behind that?

Performing the fixed function it is supposed to do like "Close" or "Menu" or "Search". Are you for real with that question?

Do you push the power button of your oven to move it across the kitchen? Do you pull it back with the bake button? Exactly. Humans don't use buttons to move things.

The window is glued to the desktop? Or is it just too heavy and only the title bar has the power to move it?

The Human way of moving things is to grab it by the handle. Another word for handle is bar. The title bar moves thing. That's Human logic at work. Now you might be wanting to counter that with Header Bars and Title Bars are both Bars. That's correct. On KDE only the actual title part of the bar moves stuff. The title bar has no other function that to show a name and act as a grab bar. The buttons only perform button actions. The ONLY time the buttons will move a window is if the Meta/Win key is held down which enables using the left clicker to move a window anywhere you grab it.

Or maybe it magically unlocks the window from its current position but touching it.

You said butt touching.

Humans also like toilet humor.

[jacob]

Libadwaita is a great example of upstream collaboration. The transformation from traditional desktop widgets to a hybrid desktop/mobile environment is a huge task. Congratulations to all involved.

Huge task and hugely counterproductive. I really don't understand why people believe that crippling the desktop and reducing it to a mobile environment was ever a good idea.

[reba]

Because of those difference, if you would try to always mimic real life, it would just be confusing because we aren't interacting with real life object. It's all simulated, and thus can (and does) behave different depending on the context.

True, what is displayed on the screen is not physically real - but the elements represent real-life things:


Checkbox
Classical pushbutton with indicator-light.


Radio-Button
AM/FM-select buttons on radios. That's actually where the name comes from. Allows you to select exactly one of the provided frequency ranges.

^ Here "LW" is pressed and thus selected. AUS=off, KW=Kurzwelle/short wave, MW=Mittelwelle/medium wave, LW=Langwelle/long wave


Combo-Box
Select exactly one of the provided options, e.g. number locks. It's a combination after all...


Button
You all know these...



Tab
Pages with tabs on it, like the name says.


Scroll-Bar
Well, this was something I has to think about for longer, but then:

And only after I found about a papyrus scroll it dawned to me: it's a scroll bar after all, isn't it?


Progress-Bar
While it looks strange at first it makes sense: you fill it up to the desired level and then you know it is how much you wanted it (usually 100% of something).
And the progress bar is filling, isn't it?


Any element I was missing?

[remenic]

Performing the fixed function it is supposed to do like "Close" or "Menu" or "Search". Are you for real with that question?

Do you push the power button of your oven to move it across the kitchen? Do you pull it back with the bake button? Exactly. Humans don't use buttons to move things.

I was talking purely about the act of performing a drag action on any button. It does nothing, except in some cases draw the button as pressed, but while you're performing the drag action, nothing happens. Except when you release it inside the button's space, but I wasn't talking about that.

I was talking about what people might expect to happen when you do that. If you try to apply real-life physics to UIs, then perhaps dragging the button should move the window. The analogy I'm seeing in my head, is the window is like a piece of paper where the application draws itself on. Heck, just imagine it being 2121 and the window is now like a tablet capable of somehow projecting a physical button, just so we would have something more physical to compare to. Unless that awesome tablet is either freaking heavy or tapered to the desk it's lying on, trying to move the button will move the tablet it's connected to somehow. Don't ask me details on how this works yet, I won't even be around that long to know how it works, so please just use your imagination.

But normal people (I'm not really one of them) don't even drag buttons, do they? Even if GNOME lets you drag a window by button in the headerbar, most people probably won't know unless they discovered it by accident.

Please do take this reply with a grain of salt though, I'm not trying to have a serious debate about this. Just sharing my perspective.

[skeevy420]

reba
Toggle switch
(picture of light switch)

Hamburger Menu
(picture of a junk drawer)

Popup Notification
(picture of a traffic ticket on windshield)

remenic
KDE does the same thing, the action of the button when you start and stop a drag inside the button. If you start the drag in the button and end outside it does nothing at all; neither drags nor does the button function. If you start in one button and end in another it also does nothing. That's where they're different and, IMHO, KDE does it better because, accessibility wise, if you have an issue where your hand twitches you might not want accidental click movement to move things around if you're trying to click close. Your hand twitches, moving it to close was hard enough, and now your hand twitches the window somewhere else? That sucks.

For another real world analog -- I wouldn't pick my bass guitars up by the the tuning pegs, tone knobs, volume knobs, or strings. All of those do a form of input but none are adequate for the input action of picking up and moving it around without risking damage or tuning issues.

You just don't pick up a stringed instrument by the E String in the same vein that close shouldn't be used for drag-and-drop window movement -- playing with fire should not be the encouraged norm.

[Jaxad0127]

KDE allows dragging from open space and non-interactable elements (like text labels and images). This makes sense. If an element is interactable, you expect clicking on it to try to interact with it, not what is underneath it.

[cynical]

No. Not really. "Open" ones running Linux distros simply don't exist in the wild. The last one I saw was a (now ancient) Thinkpad X61 tablet back in 2007 (Gnome 3's absured GPU requirements can't even support this machine now anyway).

That’s absurd. I have an HP Spectre 2-in-1 and Gnome works great on it in tablet mode.

[cynical]

Except that I have to waste my time to think on what not to click.

Aren’t you guys always complaining about how much “wasted space” the padding is? Now you are complaining you don’t know where to click? Lol. You clearly don’t use Gnome.

I don’t sit there in agony trying not to click on controls because there is plenty of empty space to use.

[cynical]

Huge task and hugely counterproductive. I really don't understand why people believe that crippling the desktop and reducing it to a mobile environment was ever a good idea.

Well what’s actually happening is they are making their desktop equally useful in a mobile environment with a touchscreen, which is more and more common. I love that I can turn my laptop into a tablet and Gnome actually gives me a usable UI along with a software keyboard. It’s awesome.

One time I had a bug that killed my trackpad and all I had to do was tap my way to the settings, then tap twice to disable and re-enable it. That is a very useful feature and would be a pain with UI elements that weren’t designed for use by a touchscreen. And If I want to use the tablet mode on my 2-in-1, things just work as I expect. If you don’t use those features then it will be a waste for you but it is useful to some of us.

I only wish I could get a quality phone that runs the same software with good battery life but it will be a while…