Flat Decorator and ControlLook

Love the new FlatLook, looks very slick. Would absolutely adore a completely flat version of the decor (without any gradients whatsoever), other than that, no real complaints! :+1:

Build for it is not enabled for 32-bit Haiku at haikuports, build it locally and installed, looks great!
Not sure if this was before also, but I see a black outline on the yellow tab? Thanks for this, should’ve installed it sooner :slight_smile:

flatstyle

Enabled the recipe so it builds for x86_gcc2 also, should be available once buildbot is finished :slight_smile:

Menus looks really bad.

You’ve got younger eyes :slight_smile:

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 :slight_smile:.

This is how looks with the lastest changes, scrollbars, rounded buttons, sliders, menu backgrounds:

flat5 flat4 flat3 flat2 flat1

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 :slight_smile:

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