QSkinWindows Classes

[marcel]

Yes. I was joking.

[kernel_panic]

Haha!
more feature requests?

[krawek]

Haha!
more feature requests?

what about use QPixmapCache to speedup the painting?
http://doc.trolltech.com/qq/qq12-qpixmapcache.html

[marcel]

Qt doesn't paint the skins, there were used platform dependent solutions.

[kernel_panic]

hm the problem is, the only thing i could cache is the the size of the pixmaps, but not more...

[bantri]

Interesting subject

>Don't you think you are entering the competence of a window manager?

Exactly... But i see by another point of view...

He´s entering at this specific "lack" of competence of the gui lib, and supplying ways to do better finishing in the application itself, rather than making nice finishing on the client area only.

>From what I understand you get rid of standard window decorations by creating >frameless windows and draw the "skin" yourself, correct? That's exactly what a window >manager is supposed to do.

Don´t think so... 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... and it doesn´t, in short words: Qt does not have factory included facilities to do styling on the application frame and titlebar, it only does styling inside the client area. Which i consider not enough, maybe the Qt developers should watch this lib and incorporate it to give the programmer the option to decide whether the top level frames will be customized or system dependent. This seems a very interesting option to me.

>Using your approach one breaks one of the fundamental features of Qt - platform >integration.

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, so as an *option* if i can chose having exactly the same style for top-level frames across OS´s, that would be very interesting, like showing windows with "pixel by pixel equal" applications. (and that includes the app frame, i know some other libs that do it... IF the developing users choose to...)

>If one changes the theme in the window manager (be it Aero, Aqua or KDE), Qt >applications will adjust.

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

>so the use of your component is really limited.
exactly the opposite IMO... this lib compensates the "limitation" of Qt not being able to do styling in the application frame, having the default system style is just the developer option not to use this lib.

>Especially on X11 platforms and when KDE4 enters the scene, your solution will become >obsolete on this platform.

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.

>In my opinion you are doing a step back here - you are "forcing" the programmer to >think about low-level things (like borders, decorations, skins, window geometry etc.)

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, so i think that there´s some revision to be done on the lib to incorporate this facility and "then" the Qt USERS don´t have to think about magical ways of styling the app frame and having to do some valuable research achieve this like he did.

>I admit your solution is pretty, but I'm not sure if it is a step in the right direction.

As i see is a matter of choice... I think that if a lib that has included facilities for styling, styling the client area only is not enough, but even in this case i could choose NOT to use styles.
In the case of the application frame there is NO option of styling, so in this case is not a matter of choosing using styles or not, unless you USE the skin lib you will have NO top-level application style at all...

Nice work Kernel !

Keep up the good work!

best regards

bantri

[wysota]

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.

[kernel_panic]

The user CAN decide wether he wants to have skins or not... This was the aim of the lib from the beginning. you have a config file, in which all options can be changed and you have a config tool (i will build it into the Windows in the next time) with which you can do it easily.

An other feature is that the developer doesn't have to write big code for skinning his app. He just has to sublcass the window from one of the skinwindows of the class and skinning is done. All the rest is done by the config file.

Did you ever compile the lib and looked how it works?

>Looking at the screenshot you provided I see you actually try to mimic the look of real
>Windows decorations. The type of application doesn't really matter here.

This isn't the aim.... I just extracted the pixmaps for this skin from a theme file of windows... because im not good at designing. It only shall view that the lib works and how it works.

He can although decide which skin he wants to use. and he can easily make skins of his own.
This lib is just a helper until trolltech adds such a feature in the lib.

And how you said: its not a must have, but its a nice to have. And which user is interrested wether the application is managed from the window manager or mangages by herself, if you don't see any difference?

[wysota]

The user CAN decide wether he wants to have skins or not... This was the aim of the lib from the beginning. you have a config file, in which all options can be changed and you have a config tool (i will build it into the Windows in the next time) with which you can do it easily.

Correct me if I'm wrong but then the application developer has to take care of adjusting geometries, etc. As you are drawing the skin in the client area (you are, right? Or am I missing something?) if you discard the skin, you either have empty margins around your window or you have to adjust the client rect to remove that margin. And of course each application developer has to have his own infrastructure for storing/restoring/adjusting that. Furthermore you enforce wrapping the "base" window into your own QWidget subclass, right? This is also prone to problems - things like windowTitle, windowIcon and some additional QMainWindow features will stop working. You should think about intercepting events associated with these features and forwarding/reimplementing them in your subclass.

An other feature is that the developer doesn't have to write big code for skinning his app. He just has to sublcass the window from one of the skinwindows of the class and skinning is done. All the rest is done by the config file.

Yes, this is nice. It's something a bit similar to Qt StyleSheets. You could even use the same syntax for your configuration infrastructure.

Did you ever compile the lib and looked how it works?

Because of disk problems I lost all my Windows development data including the compiler and Qt installation, etc. so I can't do that until I reinstall everything. But I had a look at the source code and I've seen screenshots.

This isn't the aim.... I just extracted the pixmaps for this skin from a theme file of windows...

Yes, I understand that. The point is that by doing that you suggest its meant to do just that (for instance by extending Qt-Aero cooperation with "glassy" area).

This lib is just a helper until trolltech adds such a feature in the lib.

You mean skinning system decorations? I don't think they will. But if you mean an ability to influence the non-client rect to create glass effects, I think it's just a matter of time (just take a look at Mac only features implemented in recent Qt releases) and as a temporary solution your idea is cool.

And which user is interrested wether the application is managed from the window manager or mangages by herself, if you don't see any difference?

This user who customizes his/her system look&feel. I know it is still a minority of users when we talk about Windows systems (at least ones used mainly for gaming or office uses), but that's also because systems prior to Windows XP were simply not themable. If you take a look at what KDE offers, you'll think different.

BTW BasysKom created a system for skinning applications by generating a QStyle subclass based on a set of pixmaps and rules provided by the application developer. Just another approach to skinning applications (without interfering the WM though).

[kernel_panic]

No he doesn't have to take care. I compensite this problem of geometries. He only has to subclass. And the problem with windows users which theme their desktop is fixed with 0.5.5.
You can now fully disable the skins, even skinwindow lib is compiled into the app. I added a property in the config file.
WindowTitle wotks either, i didn't add the icon feature and the problem with mainWindow features can be fixed easily by setting for central widget of QSkinMainWindow the programmers mainwindow(will fix this, the classes aren't version 1.0 of course there are some bugs).

Why do you need windows development data? it works on linux, either (and there it was developed).

I don't think, a Qt Stylesheet like config would be good, because i only save the skin path, wether blur or not, style on/off, Window Background Color, Title Color and Title font. It's easier and faster with QSettings.

Can't find the engine of BasysKom, this could be interresting.

[wysota]

WindowTitle wotks either, i didn't add the icon feature and the problem with mainWindow features can be fixed easily by setting for central widget of QSkinMainWindow the programmers mainwindow(will fix this, the classes aren't version 1.0 of course there are some bugs).

What if someone has his/her own (or better yet 3rd party) QMainWindow subclass?

I don't think, a Qt Stylesheet like config would be good, because i only save the skin path, wether blur or not, style on/off, Window Background Color, Title Color and Title font. It's easier and faster with QSettings.

Oh... I though you meant that the skin itself is configurable through the engine.

Can't find the engine of BasysKom, this could be interresting.

I can't find it on their webpage currently. But you can ask Axel, he was one of the developers creating that application.

[kernel_panic]

No problem, then he/she sublcasses his/her 3rd party mainwindow from qskinmainwindow.
i'd like to have a engine for my skinclass, but for this i need halp, if you want, you could help me with this