Pulkomandy, I just have to disagree there. On the Haiku tracker, bug reports get attended to immediately. Enhancement requests, not so much.
I submitted this enhancement request: https://dev.haiku-os.org/ticket/12623 It does not require any new code, just a label change. Two minutes’ work, tops. Humdinger and Waddlesplash agreed that it looked like a good idea. But ten months later, it has not been assigned to anyone, it has not been done, it has not even been denied. It just sits there, lost among thousands of more pressing matters.
I understand that there are priorities. Really, I do. But filing an enhancement request is not a magic bullet to getting things we want in Haiku. Things get lost there too. Can you see why we might just as well daydream on the forum?
My concern is not that much making things solved faster. Opening tickets won’t help a lot for that. It is more a problem of tracking what is done, and what is yet to do. With a single ticket for each request, we can follow the changes and then close the ticket.
In a forum post like this, on the other hand, we accumulate a lot of requests and then it is difficult to follow which are obsolete, and which still stand. Don’t hesitate to nudge the devs a little for your favorite tickets on the forums or IRC, however. The ticket base is so large that tickets can get lost there, unfortunately.
Is there some lists or tags for tickets like “under way”, “in work”, “done”. Is there tickets sorted by categories in some way? How I can find some ticked, for example “mouse tickets”, “interface tickets” or something else.
And after all, were I can find some “how to” for how to write ticket, bug report, and for ever you need from us, you Haiku developers.
I would like that we had some tweaked alternative standard Haiku GUI theme with rounded on corners buttons and other GUI elements rounded in that manner. Maybe roundness of corners even can have alterable settings in preferences? That be cool thing.
Don’t you think it would be better for the crew to concentrate on slightly more important matters like getting R1 out of the door, rather than waste time on superficial nonsense of this nature?
Alternatively, learn how to do it yourself, and do it.
Actually, I do not agree with you. Your think small. I think, is better have interesting OS, which attracts more people to the project, and actually developing will go faster in this way, but if you decide to cut features attractive to users you get opposite effect.
Yes, I can learn do it my self, you can say this to every one, by the way. But maybe that every one have some more interesting things to do?
I just give idea, maybe some one can and want do this? why not do then?
Now, why we won’t do it. There are multiple things at play, here are some.
“Sane defaults, not maximum configurability”. This has two goals. First, making the OS simple, so that there are not too much options everywhere. Look at KDE control panels to see what I mean. And second, making the OS uniform, so that it is easily recognizable when you see it.
Rounded buttons look ugly and 2000ish. It was good in early Mac OS X and Windows XP time, but now the trend is back to flat squared things. I find that the UI of Haiku makes a good balance: very slightly rounded buttons (just 1 pixel at the corners), subtle gradients (not flat design and not ugly glowing things), etc. It is agood balance between the two extremes other OSes seem to be oscillating (10 years of flat look, then 10 years of gradients everywhere).
It makes a mess of testing. Anyone writing an app must already check that it works fine at various font sizes and color sets. Now they would also need to check it looks fine with both round and squared buttons. It quickly becomes a mess to check all cases for any slightly complex application. This is why we don’t want to officially support several different looks.
What we can do, however, is provide support for installing extra looks from 3rd parties. This way, users and developers have some freedom to experiment outside of the “Haiku Way” and try their own things. If it is a great success and we find out 90% of users are doing it, we will probably make it the default.
I thought that decorators can change look of controls too. That’s sounds good 'cause lot of «we need customization» voices can be satisfied with «use decorators».
Do you know why BeOS authors thought that borders need decoration and other controls not?
You did not read my message completely
First, BeOS had decorators only as an hidden feature (or “easter egg”). By default it wasn’t even possible to change the color of the window border. And their implementation was completely different, there was no decorator class at all, it was all hardcoded in app_server.
As I said, what you need to change is not the decorator, but the “control look”. It is not more difficult or anything, just a different place.
And finally, changing the control look is a lot more work because apps can do their own custom widgets and drawing (and any advanced app does that a lot). If you mix standard controls and custom ones, how do you make sure they blend together well? It is a very hard task, as you notice when launching some old app which expects the BeOS look on Haiku, for example.
On the other hand, decorators control the window border, on which the app has no control. So, it is much more easy to replace without as much problems. This is why this was added to Haiku already: because someone had written the decorators and they worked fine.
Yes. At the moment it isn’t extracted as an add-on, so the simplest way would be to recompile the whole libbe with your changes. Later we can extract it to an add-on (there are a few missing bits to make this happen in the code).
ControlLook is basically a consolidation of all the drawing code from each of the pieces of the interface kit (BButton, BSlider, BMenuField, etc.) in one place, nothing more, nothing less. If we seriously want to implement theming, we need to build an API from ControlLook with reasonable methods like DrawButtion(), DrawSlider(), DrawMenuField(), etc. Once that is done the result should be moved into BDecorator in app server so that decorators can alter not just the look of the window border and tab but also each of the interface kit controls as well.
What I’d like to see as a proof of concept is the BeDecorator extended to use the pre-control look drawing code that has been remove from the tree (but still exists in the repository somewhere). This would allow you to switch between the current theme and a theme reminiscent of BeOS R5. While this wouldn’t be particularly useful except to BeOS luddites, once all that above work is done it will be much easier for us to transition to the new style whatever and whenever that may be.
Theoretically the MacDecorator and WinDecorator could be extended to make Haiku look like classic MacOS or Windows 98. But for this to happen you’d have to write all the drawing code for each of the controls, so, I doubt anyone would want to do that work, and I don’t expect or even desire for that to happen. Long term it would be better if we nix those decorators and focus on the BeDecorator, HaikuDecorator (derived from current ControlLook) and future decorators. Maybe we could throw a Dan0/Zeta Decorator into the mix just for fun.
These ideas are all Glass Elevator of course, not something that we need to or even want to focus on in the pre-R1 timeframe.
There really are more important issues right now. Having said that, being able to personalize one’s desktop within reasonable limits is always desirable. But we don’t want the situation on your average Linux desktop, with hundreds of settings scattered all over the menu system.
No. R1 is not “today’s OS”. If we tried to do that, in 2020 we would have an OS ready for 2017. In 2023 we will have an OS ready for 2020. And so on. And we will never release anything.
This is why R1 is very clearly defined as “compatible with BeOS R5”. We have already left way too much “just one more thing” slip in. This has to stop.
