Xfce 4.16pre1 Released As The First Step Towards This Next Desktop Update

[Vistaus]

The GTK scrollbar stays hidden until movement is performed via keyboard or mouse, then it becomes visible with a fade-in animation, while floating on the content behind it, and stays very thin to save horizontal space. When it's thin, it's perfectly serviceable as an indicator of where you are e.g. in a document, and it's not distracting. Then, if you move the pointer close to it, it expands over a quasi opaque background to be both clearly visible and easy to grab. The content, which by the way is what really matters, never has to sacrifice horizontal (or vertical) space.

My eyes have trouble seeing those scrollbars and grabbing them after they appear doesn't always work for me either. So yeah, for me they *are* a nuisance.

[chocolate]

Let me explain it in simpler terms:

If YOU want something to change, that YOU will have to do it.

Don't rely on others. Don't rely on me. Don't rely on anyone.

It's your choice.

Uhm, excuse me? I'm already OK with the direction the free desktops are taking. Was my post not clear or did you miss my point? What I meant is: I find it appalling how some people can devote so much time to spreading FUD in forums that developers probably don't even frequent at all, hence my invite (directed at those people) to reach out to developers if they are really passionate about their own workflow.
Cheers.

[chocolate]

My eyes have trouble seeing those scrollbars and grabbing them after they appear doesn't always work for me either. So yeah, for me they *are* a nuisance.

Then this is what we should be talking about, and in your shoes I would reach out to my DE's developers and kindly suggest an advanced accessibility feature to make floating scrollbars thicker.

Potential improvements based on the current state of things, not FUD based on hearsay from years ago. Someone should watch and learn.

[skeevy420]

Headerbars in GTK let you do just that. Try to open GNOME Text Editor/gedit and find out for yourself. The title of the document is displayed at the center of the headerbar, and if it's a saved file, its path is shown in a smaller font beneath the title. Besides, the whole headerbar is draggable, you just have to be familiar with the paradigm. The "handle" area is in fact larger and easier to click when moving the pointer vertically. If you don't want that, the headerbar is not mandatory... the app can still make use of a simple titlebar that is going to be more or less thin depending on the theme.
Inadvertent clicking? I don't know, clicking is not the same as grabbing, and I find that the slightest movement after clicking a headerbar widget either nullifies the grab altogether or translates to a successful grab; it never clicks unless the pointer stays still.

I've never found headerbars difficult to figure out and operate. Some of the sub-functions I didn't know because I didn't know what the picture stood for, but basic usage...moving, minimize, maximize, close...I could always figure out. I assume everyone outside of the noobiest of computer noobs is the same -- basic usage, sure; the pictograms, maybe.

Nothing fundamentally wrong with it, I think it could be retained on a desktop. But you imply that such an approach can be structured, while another would not. Apps can have a useless menubar just as well as they can have a well-structured headerbar and additional bars underneath. Or do you think GNOME Builder, for example, is failing in this regard? If you are passionate about Xfce, the matter is whether Xfce developers will make sapient use of headerbars and the rest of the toolkit, not necessarily whether the technology itself is flawed.

I've always thought that was the fundamental problem of GNOME forcing everything to adopt the hamburger style and depreciating the menubar style. It also brings up another issue of making users have to learn pictograms...essentially having to learn another language to run the programs and desktop environment. In that regard, I think that makes the menubar style simpler and easier for anyone to pickup and use.

The GTK hamburger menu does indeed save vertical space, and it doesn't care if you negate this in caps lock. Its popup also does not expand into multiple columns, it stays in one column and shifts from a level to another using animations.

11px of text is less vertical space than a 20px icon. However, 8 characters of 11px text is more horizontal space than a 20px sq. icon. With horizontal widescreens, it's more moot since there is more horizontal space available to accommodate a menubar. With 4:3 and vertical oriented widescreens, the hamburger style starts to make more sense since horizontal text space that a menubar needs is more of a premium.

The hamburger saves horizontal space while sacrificing vertical space. That's actually my biggest issue with CSD since I use a horizontal oriented widescreen for my desktop.

The GTK scrollbar stays hidden until movement is performed via keyboard or mouse, then it becomes visible with a fade-in animation, while floating on the content behind it, and stays very thin to save horizontal space. When it's thin, it's perfectly serviceable as an indicator of where you are e.g. in a document, and it's not distracting. Then, if you move the pointer close to it, it expands over a quasi opaque background to be both clearly visible and easy to grab. The content, which by the way is what really matters, never has to sacrifice horizontal (or vertical) space.

For me, that's related to the lack of information being presented that topolinik was talking about on the last page. When the scrollbar isn't present it doesn't give off the impression that the content is supposed to be scrolled or moved around. When it's present and the bar isn't there or it's greyed out it's clear and obious that that's all the content there and when the bar is there and/or it isn't greyed out it's clear and obvious that there is more content (and which way we need to scroll or move to get to it in the case of multiple bars). I also find "fade-in fade-out dynamic controls" to be annoying in general.

And to think that this stuff is free to install and try...

Which is why we've all given everything a spin and have our own opinions on it all.

[Sin2x]

Sin2x Why not just leave now? Do you really think any project wants users who take random fights against “gnomification” or come up with bogus claims about consistency? CSD is a major benefit to XFCE and losing a vocal minority is not a big deal.

Are you an Xfce developer?

[Sin2x]

Sin2x No

It was a rhethorical question. I know that you are not a developer of Xfce or any other software for that matter. Therefore you have no right to claim what is a big deal for the Xfce and what is not.

As for my aesthetical preferences - Xfce serves them well as of now, so there is no need to switch. Time will tell if that remains so, just don't presume that public opinion doesn't influence what is going to happen in that time.

[JackLilhammers]

Obviously CSD and Headerbar Designs are the future and there’s no turning back. Consistency comes from accepting this.

I think someone said at Microsoft thought the same thing when they introduced the Metro UI.
Guess they turned back after all. Well, after Windows 8 and a truckload of negative feedback.

Btw I don't really care about CSDs, because to the user are mostly an implementation detail, OTOH headerbars can be useful if used carefully, like MacOs and Windows do.

PS: Consistency comes from accepting this. This sentence makes no sense. At all.

[tildearrow]

Wow, darn it, 144Hz effectively turned the thread into a flamewar again....

2 pages of noise and counting .-.

[itoffshore]

I hope dual monitor features get some love:

• ability to pin an app to a specific screen
• ability to NOT mirror screens

at the moment using ARANDR scripts bound to keys in XFCE