From the OG post
So far your suggested changes have been quite constructive in their aproach imo, also assimilating feedback. I don’t think everything will be added obviously, for example adding more options for stuff is something Haiku generally views very unfavorably. Configuring margins is not something a User should need to do. So if slightly bigger margins are part of this controllook they should probably just be that. The option then would be from choosing the controllool (though I would not call it tidy then, it doesn’t really describe it accurately in my mind)
The existing flatcontrollook is a major downgrade in visual clarity imo. So I don’t quite understand the pushback for a potential theme… the solution to not use it, like one can for the flat one seems simple to me.
To explain the thing with the settings a bit more, Haiku has it’s own philosophy called the Haiku way, and that obviously depends a bit on which dev you ask, but to me it seems a big part of this is staying out of the way, and not ask users questions unless you absolutely need to. Keyboard layout is something we have to ask for example, locale is something we can configure.
But options to control rendering details are really frowned upon… Those seem less usefull, and with the option to switch out the entire controllool we have a kind of middle ground where you can still do some of these things, but don’t have to make every haiku user have to think about this.
The mental load goes from
have default theme
→ like it ; keep it
→ don’t like it ; look for options
to
have default theme
→ like it ; contemplate wether margins need to be configured
… especially if we take rounded corners seriously
There are two aspects to that:
- People can explain why they don’t like it
- As a developer, what is nice about Haiku is that I know exactly what the window will look like for all users. I know there will be a large window border and an easy to grab resize knob, and so on. If theming becomes popular, these features that are now taken for granted, may not be anymore. The result in other OS is each app re-inventing its own window management and controls. The lack of uniformity resulting from that is not great.
So, yes, theming is fine, but it should either be careful to preserve all the features (they may be exposed in different ways), or otherwise, this will always remain something that is “at the edge” of Haiku, something that you can do, but that is not really supported.
Yes, I agree. That is also what I ment with some of these ideas making sense, and some maybe not so much. I think the responses here so far have been great, explaing why something works the way it does, instead of only saying that it is the way it is.
Thanks! I have enjoyed the collaboration here.
Some pushback is good, and constructive questions drive me to keep iterating and finding solutions.
I like the margins and borders here, but finding the right pixel thickness would help. I find the double border in the default mode slightly confusing.
I think it’s helpful to separate the theme from the overall user experience.
For example, HaikuDepot’s redesign dives deeper into the user experience, improving readability and interactions. The current version has noticeable inconsistencies with the rest of Haiku.
Options and user choice are something Haiku already supports in spirit. For instance, the Deskbar can already be moved and resized, and icons in this bar can be placed freely. The only thing I’m proposing is adding the ability to detach it, which could benefit certain workflows.
I agree, only ask questions to the user when it is fully necessary.
For Tracker, the options are:
- Padding options in list view
- Icon size options for list view
- Scrollbar visibility toggle
And yes, while disabled scrollbars provide some spatial feedback, they are also non-functional controls, which can be misleading, and it is for me. The current version forces that decision on me, no choice.
The intent would be to separate theme from features. Has this message done that or what would be the best way to do it?
I hear you, and I agree. OS features should be fully supported. I’m not interested in pushing a theme that breaks things or creates fragmentation. If that’s the case, then it’s probably not worth continuing.
That said, I do still see room for improvement in areas like HaikuDepot, even without significant UI changes. Some elements are straining or inconsistent, and I suspect I’m not the only one who feels that way overall
How things are supposed to look is always contemporary and therefore follows trends, that’s not a bad thing per se. Having rounded borders for the Deskbar and even some spacing from the corner might look nice, but it destroys its usability (as in Fitt’s law).
Personally, I wouldn’t be opposed to have options for scroll bars that hide when they aren’t needed, or general padding sizes. But those would always need to be system wide and not just affect Tracker.
One could also have a ControlLook implementation that has options for this. BTW, I guess the main reason for the visible but disabled scroll bars is to have the resize corner stand out less.
Totally! I don’t think trends are just bad, but in this case, it’s hardly even a trend.
Just look at this bold, trendy kid called Windows XP with its rounded top bars and gradients. Th design elements here have been around for decades, drawing inspiration from NeXT, BeOS, and macOS Jaguar and Lion
That sounds awesome!!
For the deskbar we should probably do the KDE floating panel thing where you can still click as if there wasn’t any floating.
IMO that’s just horrible design, same with the invisible but clickable window borders.
I agree with the window borders.
EDIT: Meant to be a reply to the previous post
What I ment was that if you change the rendering, say to have bigger margins, then your controllook could do that potentially. But it should not be a tracker setting, if it is now every visual style has to support this which makes no sense. I’d prefer if in your case your controllook would simply give the info on what size is apropriate, some support for this exists already.
Something like scrollbar visibility is not something we want as an option I think, and even then if we wanted it it would require a lot of code reworking because now you have to resize the view live based on the mouse cursor state for this, or alternatively always render an empty area.
We have disabled controls in other places, if that rendering is confusing perhaps it needs to be adjusted.
HaikuDepot redesign is a seperate point indeed. It does have some problems that should be adressed (so far many suggestions have looked like app stores, which i heavily dislike… your suggestion on the other hand goes in the right direction but is missing some important things, so may require more iterations)
I’d argue that disabled controls are often confusing. I’ve seen this firsthand over the years in games and when tracking click rates and usage rates. People tend to try interacting with them anyway, and are unsure why they don’t function.
If the rework is extensive, it’s difficult to weigh the effort against the actual benefits.
I’d be very-very happy to see a rounded corners toggle/option system-wide. It makes systems more enjoyable to use for me. MacOS Jaguar had only top-rounded corners, just like Windows XP in 2001-2002, and it made MacOS Panther’s four rounded corners in 2003 such a welcome addition. It’s still a thing today.
That’s good to hear! Let’s talk about HaikuDepot and figure out what needs adjusting. I’ll stick to the default UI there so we can stay focused on the core issues.
Edit: MacOS Panther was released in 2003, not 2023
That part is easy in the sense of “just” enabeling a controllook that renders like this. my prototype works like that, but is unfinished.
Ooooh, I want to test it! Is there anything technical preventing it from being packaged into Haiku?
It’s unfinished, before it makes sense to package it would need more work. I had a lot more stuff planned for it but did not develop it further in 2023
You can clone it from the review https://review.haiku-os.org/c/haiku/+/6211
then go into the directory, build it with jam and put the resulting binary into ~/config/non-packaged/control_look/
It’s also missing implementations for most things, instead using HaikuControlLook. For a comprehensive implementation I’d want to implement the things myself anyhow.
Edit: I might use some stuff from your suggestions to continue developing it, or we can work together on it, though I am obviously biased aswell and do want some stuff differently, like aqua like scrollbars
I would use this as my “default”
It’s a modernized traditional look. You would instantly recognize The BeOS tradition, but the feel is modern. I think it’s great.
I’m digging the modern flair of your UI mock-ups. Seems worthy to dabble with for consideration targeting R2 if the ship has already sailed for R1 when it comes to modernizing the UI a teensy bit.