There are a few things that are in tree (Mac and Win decorators for example) that doesn’t have any less problems than the Flat decorator. If no developer maintains them, they just keep being broken.
I strongly disagree with this. It seems like lets make an OS for developers, and lets limit things for the benefit of those developers.
I want the freedom to customize some parts. I think this can be done without causing problems for developers, so I don’t even think it is a good argument.
3 Likes
What? why?
I don’t see any point in having to develop on github, let’s lock ourselves in more for no reason…
I know, but I did not get it to work : /
That’s kinda the reason I want to make my own controllook : ), I can go a bit further in the direction of aqua, I think HaikuDecorator is fine as a default.
1 Like
Every option added is twice the smmount of unique setups to test, in my changed to the scrollbars I already never tested the other option, as It never occured to me.
To make a broader point: the exposed, and proposed settings are specific to a certain controllook and should never have been exposed there. The default controllook should hsve exactly 0 options, if you want something else you can pick a different one.
So do you already test with all fonts and sizes as well? It seems like we should not allow any options as we can’t test everything anyway?
1 Like
There is a big difference between adding options for pointless cosmetic changes and something that makes the UI actually useable on bigger monitors. I don’t test with all sizes, but I do with some.
It is not pointless. It’s your opinion that it is, and you are using an argument that can only be applied in a selected manner to avoid any good discussion about it.
Yes, this would be a good way of doing this. Then we probably can end these arguments as well.
The option is pointless, there is no good reason why we should add an option for this, either we add it by default or leave it out.
I don’t apreciate the accusation, surely we can have a normal discussion? what gives?
It was not meant as any accusation.
I was just saying that we do not and cannot test all options already. but somehow that is used as a valid argument for this case?
PulkoMandy brought it up,
and I would say it is more we should not add options we know nobody will test with.
The bigget argument to me is that the rendering change is way too insignificant to warrant an option. If we make an option for this why not make an option for any other possible rendering change?
An unofficial applet for this seems fine, but again I would say that HaikuDecorator itself should have no options at all.
This I agree with.
As long as it is possible to use different themes we don’t have to argue if round buttons look good or bad or other visual aspects.
4 Likes
Yes, when I design an UI I have to test it at several font sizes (at least 10, 12, 18 and probably I should do also 24pt now there are high DPI displays).
That’s what I mean: that’s already 4 options. If I have to check rounded vs square buttons additionally, that’s 8 options if I want to test all cases. And this becomes exponentially more complex everytime we add an option (in theory, as I said, some options are more likely to have an impact than others, or sometimes they are uncorrelated, for example dark vs light mode can be tested independently and not in all font sizes).
1 Like
Coloring hurts.
3 Likes
That’s just my color settings *shrug*
1 Like
Well, it’s not my kind either but at least it certainly makes spots to improve obvious.
1 Like
Yay round corners! 
5 Likes
Window round corners may need implementing app_server semi-transparent window support.
i think that, Haiku gui api should allow for overide of native window themes, on per application basis, and be contained specifically to that particular application, it’s windows and children
it’s a win win