Menus looks really bad.
You’ve got younger eyes 
Menus are over highlightened with default theme. It’s something like +50 on red green and blue. I guess half will look as good. Unfortunately, IIRC you can’t change that with the ControlLook so it looks bad.
Thanks! thats appears to be an old version or maybe you forgot to restart tracker after set the controlllok .
This is how looks with the lastest changes, scrollbars, rounded buttons, sliders, menu backgrounds:
IMHO, looks better with light colors.
15 Likes
Much better. Even nice! Great job.
3 Likes
Need to see to update the recipe to latest changes then
Very nice indeed… Looking forward to test it out! Great job!
#joinTheRevOSlution
Very nice *insert amazed anime face here*!
Time for nitpicking.
For the inactive windows, just like the active tab has a distinct colour from the rest of the system, an inactive tab might have a slightly different colour (a lighter one perhaps), it would also help to increase the contrast for the tab buttons (close, zoom). Or you can just change the tab buttons’ colour, it’s your call.
I think because system elements do not have enough contrast IMHO. See MediaPlayer buttons, or any other button. On the third photo, Defaults and Revert both look like active (or inactive) at first look (at least to my eye), the only difference looks like the font colour. For the light mode it looks amazing, on the dark one, needs a bit more tweak.
Hi, I really like this dark theme though I have yet to try it myself. Mostly because I lost track of where I’d seen it. So I’m posting to make others aware as well, and hopefully we could consider having a dark theme in Haiku…
2 Likes
Both themes are pretty good, but they’ve repeatedly caused my nightly installations to fail booting completely after the boot screen. Perhaps it would be better if they’re shipped with the system as optional themes, since they would be compiled and tested along with the nightlies and TCs?
It would be better to fix whatever is causing this, we provide binary compatibility for decorators. If they for some reason return bad data or crash the app_server It should simply restart but without the decorator next time.
Problem is not the software itself but nightlies code is evolving. Nahuel really does what he can, even providing binaries when possible. To keep your software working on nightlies, you need to build it against this new code but packages in Haikuports are build against beta x code until new beta y is almost arrived.
Add to that the bug selecting default decorator back when your language is not English…
One thing that could be done is to have separate repos for nightlies and stable but I guess it would be hell to maintain and Haikuports don’t have manpower for that.
Another would be to add some code that will check if the add-on has been built against the same api that the one used by the system and, if not, ignore the add-on leaving a message in syslog. People would then know why it had no effect or why they don’t see in the list. Probably too much work for the purpose and Haiku don’t have manpower either.
1 Like
Interesting. I though the reason the decorator is crashing app_server is because there isn’t binary compatibility across versions…
This is incorrect, we provide binary compatibility exactly to avoid this.
Here is an example of a recent decorator api change i have done: https://git.haiku-os.org/haiku/commit/?id=409d65c0d64212efc6882e81140647201c03c59d
The api did change, but the ABI did not, the old decorator will simply fall back to in-tree code if it does not provide those functions.
Compiling a new version may fail I think, but old versions will still work.
And it works indeed most of time but, apparently doesn’t in that case.
https://git.haiku-os.org/haiku/commit/?id=773d5303d13d7d763ab82b35a23499c951e54737
Sometimes we find a thing that we can’t fix. Or we just forget to maintain the ABI and change things that shouldn’t be changed.
I don’t think the answer is “put everything in Haiku source repository”. I don’t think the answer is “pretend the problem doesn’t exist after several people complain about it”.
It’s rather “let’s try to see how we can make such breakage not happen again, because currently, they do”.
4 Likes
I didn’t know about that change, thanks for the correction. This makes me wonder why app_server would launch with an incompatible addon though, do we not have something to avoid this?
I don’t think themes have been in focus before, so probably very little real world testing. Now that we are starting to see themes it starting to expose bugs in that area. Just report bugs as you find them, don’t worry too much if it is a duplicate. A bug reported twice is much better than a bug not reported at all.
12 Likes
What do you suggest? We can detect if the add-on fails to load (missing symbols or the like), but if it crashes, it’s more complicated.
Is there a bugreport with a debugger report to investigate? Maybe that would help fixing things?
I would suggest working to make app_server crashes less fatal, e.g by connecting to a new instance, perhaps we can somehow detect if a decorator was at fault and avoid loading it next time?