regolith-linux
Usability: lack of highlight on active window leads to cursor getting lost.
Is your feature request related to a problem? Please describe. On a setup with multiple 4K monitors, the combination of unclutter behavior with lack of highlighting on the currently active window means the mouse cursor can easily get lost and become extremely difficult to find, breaking my concentration.
This is a major usability issue. I've seen a couple of other minor ones, but this is the one that blocks me from switching to Regolith from stock i3.
Describe the solution you'd like Under stock i3 the frame of the active window lights up, constraining where I need to look for the cursor enough that I am not jarred out of my flow state by the lesser effort required to look for it. I want this feature back in Regolith,
Describe alternatives you've considered An acceptable alternative would be a way to make the cursor pointer larger so it's more visible in text windows. That and the ability to easily turn off unclutter,
The focused window is highlighted through native i3 functionality, it's just very subtle with the default theme (a small, 1 pixel border, in a light, grey'ish white). You can either set the Xresources definition i3-wm.window.border.size to a different pixel width (e.g. 2) or switch to a different "Look" if you think it's not noticeable enough.
You can also turn off unclutter by setting the Xresources value of i3-wm.program.unclutter to an empty string ("").
@moritzheiber I submit that "very subtle" is in this context a mistake. If you want to onboard users of stock i3 effectively, the default look ought to be one that does not diminish important visual cues to the point of making them hard to even notice. It;s not good enough to say "switch to a different look"; if the default look is you-fail-ergonomics-forever, your trial user is just going to back off in a hurry, as I almost did.
Recommendation: thicken the border to 3 pixels by default, and (this is more important!) use the same medium blue color that stock i3 uses to light up the header bar of the window with focus. The effect you want is for the user to recognize that color and instantly know what's going on,
I would actually prefer to keep the unclutter behavior but (a) get my easily visible window highlight back, and (b) something like quadruple the size of my cursor pointer so that it's as visible as it used to be at 1280x1024. Can you recommend any way to do that?
Hi Eric :smile: , here's how you'd set the window border pixel width to 3 pixels:
~$ echo "i3-wm.window.border.size: 3" >> ~/.config/regolith/Xresources
~$ regolith-look refresh
Adjusting the cursor size is a bit more involved. Both Xresources and GNOME have to be updated. For X, this will do it:
~$ echo "Xcursor.size: 96" >> ~/.config/regolith/Xresources
~$ regolith-look refresh
For GNOME, in the control panel, under Universal Access there is a Cursor Size option in which the size can be selected.
Regarding the default look and regular i3 users, I see how Regolith's default UI could be confusing for those more familiar w/ the stock i3 look. While the default look isn't intended to help existing i3 users in migrating, I really like the idea of having a look specific to this purpose.
Thanks for your feedback and sharing your perspective as to how we can improve Regolith, much appreciated!
As for the "discover mouse pointer" feature, there is something along those lines in macOS. GNOME has implemented its own take on it called "locate pointer". Unfortunately, it doesn't appear as though gnome-flashback (which Regolith is using in the background) has support for it.
It's nice to know that in theory I could fix part of what was bugging me, but...
...for starters, your recommended ritual failed. I found the GNOME accessibility panel, clicked on the mouse cursor size item, and got a popup giving me a choice of five cursor sizes. So far so good - but there was no way to tell that popup "I'm done, you can hand control back to the Accessibility panel now." Because it was stuck in a modal dialogue, the Accessibility panel was also wedged - couldn't be gracefully exited, couldn't be minimized. I had to use killall from a shell window to get rid of it and of course the cursor change didn't take.
Do you actually try these recipes before you give them to people? Because near as I can tell this one could never have worked.
This isn't the first time Regolith has slapped me with a stuck configurator window. One of the other five usability issues I have queued up is from the last time it happened. From my notes: "The display configurator is unkillable. There's no confirm/exit option, and the window-kill keystroke it gives under Help did not. I had to reboot to get rid of it."
There's some general problem here with how GNOME configuration windows work under Regolith. Don't tell me Super-Q is the answer, because there's an ambiguity between "close" and "abort" in that; some applications react to having a dialogue killed by retaining whatever state it set up, while others discard the state. If you don't know which behavior you're going to get, Super-Q is an excessively blunt instrument. And in the Accessibility case I didn't see the cursor change when I selected a different size, pointing strongly towards "abort".
If there was some interface cue that should have told me how to get confirm-and-exit in this situation, it was so subtle that I missed it. So let's talk about subtlety...
When you say "it's just very subtle", as you did about the native i3 active window highlight, that's a misspelling of "we fail at UX design". Heed the words of Jef Raskin writing about humane interfaces and feel some shame that a crusty Unix old fart from the days of ASR-33 Teletypes has to remind you of them: UI elements need to be obvious and habituating. "Subtle" is bad - it means you're increasing the cognitive load on the user, not decreasing it.
I've already described three ways that the Regolith UX fails the Raskin test. I think the intention behind Regolith is really cool, and I think it can be done right, which is why I've already shipped you a documentation MR and am pursuing these UX screwups. But I hit those and three other usability issues in my first two hours. That's not a good execution record.
One major way your execution can get better is if you suppress the urge you're probably having right now to say "But you should have known X" for some value of X. Wrong answer. Another necessary trait of good UI design is that it's discoverable. Most of your potential users will have far less tolerance than I do for discovery costs; they won't survive as many "hello, wall" moments as me before they run away.
Another major way it can get better is if you lose the Unix-culture mentality that lots of configurability excuses choosing your defaults badly. People from other programming cultures laugh at us when we do things like telling me you can (sort of) fix things with a five-part ritual including four shell commands. And they're right to laugh.
Choose better defaults. Not "subtle" ones. It doesn't do any good to say "Oh, you can try an alternate look" if your defaults are such an ergonomic fail that I suspect all the alternates are likely to be equivalent failures with superficially different paint jobs.
You guys are trying to do a thing that I think is brave and worthy, pushing i3 towards a better UX. Please take these criticisms not as hostility but as tough love for the concept. I think you can do better than I've seen so far - there's plenty of science to tell you how if you choose to pay attention to it. I hope you will want to.
I agree with your points about UX. And yes, gnome-settings is not the perfect integration with a tiling wm such as i3, however it is pretty good at what it does. An initial motivation of mine for producing Regolith was to lower barriers for people that may not have the time or skills to setup their own systems, but want something other than what typically is shipped as default desktops for users. It's my belief these default UIs are designed primarily for ease of use for those coming from Windows computers, or at least sticking very closely to the WIMP metaphor. I believe there are many users out there that are poorly served by these lowest-common-denominator interfaces.
The reality is that the UI issues you mention are simply rooted in an integration we provide from an upstream project, gnome-flashback. Regolith as a project lives off of the spare time by a handful of people. Most of that time is spent in helping people with issues, and fixing bugs in the modest places where we choose to focus our development energy, such as the shell scripts that populate the bar. Forking gnome-settings to provide a better UI experience would be an improvement (others have noted the issue you have w/ the mouse cursor selection flow) but simply not within the current human/time budget of the project. That said,with Wayland on the horizon we'll need some new front-end for settings and perhaps we'll find or produce something which has the right mix of affordances and capabilities for configuration. We'll see!
Eric, as someone already using i3 and looking at Regolith, may I ask; what is it about Regolith you find interesting? I'm assuming you've already got an i3 based setup, and would expect you like it. What does Regolith offer you? As I mentioned Regolith is really designed for those that are coming from a traditional desktop environment, so I'm curious as to your perspective here. And, thanks for the feedback :smile:
Let me take your last question first. I use stock i3 and like it, but I find its choices are a bit too eccentric and austere at times. What I hope for from Regolith is a set of tweaks and customizations written by people who have paid very careful attention to ergonomics and know how to improve UX (e.g .lower the friction cost of using i3). I believed from what I read in your documentation that you were attempting something like this.
Along those lines, by the way, you might want to take a look at Lunaria: https://github.com/dfoxfranke/lunaria It was designed by a friend of mine dissatisfied with the ergonomics of the standard ANSI terminal-color values; he made the Eclipse variant for me. I think integrating it into the Regolith metapackage would improve the UX. I can certainly vouch for it making stock i3 more pleasant to use.
I get it about the integration problem. OK, if you can't fix that seam at least you can document it better. Maybe the Regolith docs need a new section on awkward spots and traps? You could use it, for example, recommend increasing the cursor size and telling people how to do a conform-and-exit on that piece of the configurator.
As for that new front end, let me suggest that in the spit of suckless-tools you should try to write something like an equivalent of sys/ for GNOME/Wayland configuration - bunch of magic devices on a FUSE filesysatem that can be queried or poked to changed settings. Document that interface and let the front-ending begin. (You could maybe talk me into working on that.)
And please fix the active-window highlight to be more obvious by default. That is still an ergonomic crash landing.
Absolutely agreed regarding documentation. What we have is suitable for technical users that have already had some experience w/ i3 and or other desktop Linux components. One thing I have a hard time with is structuring the documentation such that it scales well to varies categories of user. Too many technical details may scare away the less confident, where as too much preamble and explanation bores others. Also, can be difficult to succulent describe how various things are put together, yet I do not like the idea of avoiding the topic of how a given thing works.
Regarding a filesystem interface to settings, yes that's a great idea. I spent some time trying to represent the desktop notification subsystem as a FUSE filesystem in Vala but was unable to get the event loops in FUSE and GLib to play nicely. I am guessing (but am not sure) that gnome-settings-daemon and gnome-control-center are similar to this but the IPC is dconf/gsettings rather than a direct filesystem interface. Ideally the backend would be component/plugin based so that it may scale to whatever system it's running on (xorg/wayland). I also think it's worth a look at seeing how gnome-settings-daemon runs on Wayland. I don't know anything about gnome-shell so am unsure if there are any components there of sufficient generalness to be of use. There are some fundamental differences in what compositors in Wayland "own" vs what window managers in Xorg own, or at least this is the conclusion I came to from reviewing the Sway compositor's configuration format. In any case, if you're interested in contributing we'd love the help!
Lastly, regarding the usability changes, I'll add that to the project for 2.0. There are a few other tweaks I'd like to make as well, for example for multi monitor setups, the workspace indicator does not display the selected workspace on a non-selected monitor.