Thanks. I did manage to track down a copy but this one is higher resolution.
Keep up the work on the control look and decorator I think they are a good option to have for Haiku. I will be out of town for a bit but when I get back I can see if I can help on the decorator crash. Good idea to test with the BeDecorator, if that is crashing something is definitely going on 
The decorator is working again!
Good to hear that you got it to work again. I messed with ControlLook slightly but I did not touch decorators or app server.
Im working in an old mockup that “integrate” the menu to the decorator. At the moment im here:
But, one problem persist: Exist any way to know in the controlLook who is the active window?
It’s probably easier to make the controllook change the appearence of menus, they can be in a lot of places, they just usually are at the top of the window.
You should be able to call view->Window()->IsActive() from the control look to determine whether or not the window is the currently active window (i.e. the one with a yellow tab.)
We need compositing in app_server to display drop shadows around windows. Window drop shadows could be implemented using software 3D acceleration without needing 3D accelerated video drivers. This would be an important step once we do have them.
However like so many things somebody has to do that work and it’s a major change to app_server drawing which makes it a daunting task.
This should be the new default decorator, for sure.
I am planning to propose we bundle this with Haiku, but that we give the user the option to choose which one they want to use.
it can be good if have the 2 classics, but is good to have a new one too, more fresh. Haiku need it a lot.
Yes, that was what I was thinking as well.
I was even thinking if someone could make a BeOS-style theme we could include that too.
it is already one there, but the control look disappear for me, i am using the Be decorator.
But no control look in game with it.
I don’t understand why everyone says that. It seems possible to draw shadows without compositing? What would be the problem there?
Sure it creates some more redrawing (you need to redraw the windows that are under the shadow, and then add the shadow over that), but it could work.
The real problem is that shadows look ugly and disturbing to me 
. I usually work with a lot of overlapping window and they would just get in the way, obscuring things that I want to keep visible. And they do not bring a lot of value. The main arguments seem to be “it looks nice” (this is subjective) and “it makes the active window easier to see” (we already have a solution for that, making the window border highlighted).
The difference to me seems that for drawing the window is considered to be obscured but for pointer events it is not obscured, I don’t know if we have something like that yet but we would probably need that for rounded window borders too, which is clearly the next step after shadows.
I don’t see a technical reason why this wouldn’t work without compositing apart from such an api maybe not existing yet? I haven’t checked anyhow.
I was always hoping that Haiku could get window compositing working for my HiQDock to have a true transparent background 
But that’s still Qt based, right?
Yes - the Qt APIs to set window to transparent would have to be hooked to native if/when Haiku native APIs supported window transparency.
Old school design and philosophy is what I love on Haiku, and why I really want it to be a solid alternative to Windows, MacOS, GNOME, KDE, etc…
I really don’t need shadows, I don’t want it and I don’t want Haiku to lose it’s attractivity because of modern things…
Any update on this beautiful flat and dark decorator ?
Unfortunately as of hrev55399, the Flat decorator is broken again:
The Flat ControlLook meanwhile doesn’t cause the system to die, but it doesn’t seem to actually be applied anymore even when selected:
