Quote Originally Posted by bantri View Post
That´s exactly what a powerful gui lib is supposed to do... to give the option of doing styling in everything, including the application frame...
I don't agree. You are looking from a point of view where the window manager is strictly part of the OS kernel (namely Windows) where the decoration can be considered part of the application itself because there is no real separation between the window manager and the application and it's hard to consider the decorations stylable (contrary to what Aqua or X11 window managers offer). If I'm the user, I want the application to look like I want it, not like the programmer wanted it. I want to have total control over my desktop. I don't really see the point of emulating real window manager decorations with pseudo-decorations like WinAMP or XMMS do. Imagine having a nice looking customized OSX system with a single application that looks like WindowsXP. Sorry, I don't buy that...

I´ve got a different point of view about this:

IMHO True cross-platform means more the having the same client area behavior, it means having the same *application frame* behavior,
Sorry, I don't agree. I've seen applications on Linux looking exactly like MS Windows app (it was Rational Rose, I think) and it just didn't fit into the overall look&feel. Furthermore if I'm used to some behaviour and I have never seen/used/liked some other behaviour and suddenly some application enforces that other behaviour, it will feel odd. That's why we have classes like QDialogButtonBox - to provide a platform dependent look and feel in a platform independent application. So it's exactly the opposite of what you say - a platform independent app is not even that the client area looks the same on all platforms, it's that the application looks (and feels) like other ("native") applications on the same platform.

Nope... Qt apps will just *submit* to the new theme because there is NO provided option for styling the application frame. If there were options to do this styling then the application itself could switch the style the same easy way that it switches the style for widgets inside the client area.
I think that is the whole point of window system theming... So that applications that don't know a thing about theming adjust to the theme. That's a problem with some old Win32 applications - controls are drawn using custom routines that look like the standard Win32 controls, but they also look like that on newer systems like XP or Vista. This is because of what you seek - the toolkit had total control over the application look. That is exactly the same problem with Qt Windows style. Fortunately XP and Vista styles are drawn using native routines. This causes some problems (like the red pushbutton syndrome), but lets the application adjust to the rest of the system.

This talk is highly offtopic, because I have nothing against skinning applications (I don't agree with such approach but I think it is nice to have such an option), but it seizes to be an advantage when you try to skin an application to look like it has the default decorations with one exceptions (for example semi-transparent client area). That's because the user expects the app to look and behave like other apps but it's not the case because the decorations are fake.

What surprises me is that this idea emerged from a single user trying to compensate this deficiency in a very complex lib that deals with styles and not emerged from the lib developers themselves.
If you look closely at the structure of the toolkit, you'll notice that the developers have simply different goals than you.

well... i think that having the ability to design and use a different skin to change the look of an application is exactly what prevents it from getting obsolete, so it can adapt to whatever new layout appears. NOT having the option of skinning is the "obsolete" case IMO.
It shouldn't adapt in such a way that you have to change the application code. And that is exactly what happens here. Imagine that in the next release of your wonderful system the creators add a "make some magic" button to the system decorations. In that case you have to emulate the button by reimplementing the skin or the whole skin system (depending on how the skin system was implemented in the first place).

LOL I think he is actually "forcing" the Qt programmers to step back, by proving a pretty shameful situation, by showing that IT´S POSSIBLE to DO this feature,
Sure it is possible. It's also possible to implement all windows and widgets in OpenGL to provide additional speedup, but then there is a problem that applications won't behave properly on systems that either don't support OpenGL at all or only support it in software. That's why wms like compiz/kwin4 emerged - to do it on the proper level, without bothering the application developer - let the user decide what he wants.

I agree that kernel_panic made a wonderful job and I agree that maybe it'd be nice to have a functionality to influence the system decorations a bit more than we can do it now in Qt, but I'm suggesting to implement it in such a way that it doesn't break the things it breaks now. I won't give an ultimate solution here - I know nothing about Vista programming, for instance, so I can't generate code that would work there. That's a job for someone else, I don't have a feeling that I need to do everything myself. I'm simply pointing out weaknesses in this exact approach.