PDA

View Full Version : QSkinWindows Classes



kernel_panic
28th September 2007, 17:01
Hello again!
Heres an new Version of my Classes. Please close the other thread. He went too big.
New:
-> For Both Linux + Windows
-> ARGB under Windows / not under Linux
-> Buttons can glow under Mouse

marcel
29th September 2007, 11:47
Next time put some screenshots in the post :).
We already know what the code can do(at least me), now just want to see how it looks.

kernel_panic
29th September 2007, 17:44
Screenshot:

kernel_panic
3rd October 2007, 12:12
Now the classes are available at qt-apps.org
Please take a look, because they now have an option which makes widgets look like
Vista Aero Widgets.
http://qt-apps.org/content/show.php?content=67309

wysota
3rd October 2007, 13:17
I hate to be a spoil-sport, but I have some comments on your work. Don't you think you are entering the competence of a window manager? 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. Using your approach one breaks one of the fundamental features of Qt - platform integration. Qt apps are meant to blend into the operating system and look exactly the same as "native" applications. If one changes the theme in the window manager (be it Aero, Aqua or KDE), Qt applications will adjust. This is not the case with your approach (although of course you've done a great job in doing what you did, it looks neat), so the use of your component is really limited. Especially on X11 platforms and when KDE4 enters the scene, your solution will become obsolete on this platform. 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.) instead of hiding those details from him. I admit your solution is pretty, but I'm not sure if it is a step in the right direction.

kernel_panic
3rd October 2007, 16:16
it's not mentured to be used for big apps...
it's something what you can use for small tools, which shouldn't look like normal apps...
i understand what you mean, but sometimes it's nice to have another decoration than the normal apps, or?
For an IDE or an EMail CLient or an internet browser i would never use this classe, because it doesn't fit, but for eg a pdf printer (windows), or chat program it's not bad, or?

wysota
3rd October 2007, 16:41
The point is that it is the end-user who should decide how the application looks like and not the programmer. 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.

I mean that the idea itself is ok, it's just that I think you are doing it on a wrong level. If you implemented it as a window manager decorator or even a QStyle subclass (with some style hacking of course) it would be a general use approach.

kernel_panic
3rd October 2007, 18:32
hm, ok...
but for style hacking i have to hook the window manager and than it isn't multiplatform anymore....

wysota
3rd October 2007, 18:39
No no... by the style I mean QStyle and hacking involves things like setting proper pixel metrics and stuff. But really, I have nothing against your approach - I just think its usefulness might be very limited. And of course slower than drawing directly on a widget (actually to the backstore).

kernel_panic
3rd October 2007, 19:25
how can i do this?
show me code and i will try!

wysota
3rd October 2007, 19:49
I don't have a ready solution for everything.

marcel
3rd October 2007, 20:14
Well, it can be done, but styling the title bar and window frame has nothing to do with QStyle, at least not on Win and Mac.

You can do it relatively easy on Windows, there are lots of resources on codeproject and codeguru, but I have no idea on how can you do it on Mac. There has to be something on developer.apple.com.

My opinion is that you can get away with making it look good on Win and Linux, but there's another story on Mac. I can't imagine a window like that looking good on that platform. They even have a GUI design guidelines document(it's freely available) on how to make your application integrate with the desktop and the other applications look and feel.

kernel_panic
4th October 2007, 07:19
Ok now!
It works and that is all that it should do. and it works on window / linux, all that i wantet. Maybe the way how it does the skinning isn't perfect, but it works.
If someone has an code example or can me say how to make it better, ill test it. But pls, don't grumble without having a better solution!

Carpe Diem! Markus

wysota
4th October 2007, 22:00
Oh come on! A brainstorm often helps you know. No need to take it personal. If I had a solution ready, I'd just post it instead of pointing out possible weaknesses in yours. And believe me, you wouldn't have to test it just the same as you don't have to agree with me or even read my posts. You can even ignore me completely, this forum's software offers that possibility.

magland
5th October 2007, 01:40
Well regardless of whose grumbling and whose taking it personally, I think the software is very nice, and I hope the direction of this thread stays on the positive track it deserves.

Personally, I intend to use these classes to conveniently make some cool-looking utilities at my workplace -- where few users have interest (or ability) to customize their desktop, and for my kids -- who are too young to realize anything except WOW COOL LOOKING WINDOW!

kernel_panic
5th October 2007, 07:41
Hey! I'm glad you are interrested in this. i would be glader if you could help me developing something in the way you described, but everything i saw on codeproject and codeguru was deleting the titlebar and setting a label instead. the borders are the same.
The only thing that could be interresting is that there is shown how to add a shadow. this coukd be interresting. maybe the classes are 0.6 in the next days:).

I think my classes are an easy way of skinning apps and tools and it doesn't matter in the first way how they do it. it just works. but i think it would be interresting to do some window manager hacking. preferential on windows.like stylexp ore window blinds does it.
But i don't know how to do this...

But which developer needs something like this just for adding some custom look to a widget?

elcuco
5th October 2007, 11:42
do you mind me asking for a small feature request? It seems some people would like to disable the skined windows. How about having a checkbox which disables your skins and uses the natural window decorations?

(easier said then done, I know)

marcel
5th October 2007, 11:59
Yes, and I would like to buy the whole package.

kernel_panic
5th October 2007, 12:27
Buy??? What do you want to buy?

And the disabling is no problem!
Will add this.
For all:
The SkinConfig wihich is included in the project should be added as a dialog of the app, if the user should change things on the skin.
i will add the disable feature.

marcel
5th October 2007, 12:33
Yes. I was joking.

kernel_panic
5th October 2007, 13:00
Haha!:rolleyes:
more feature requests?

krawek
5th October 2007, 16:16
Haha!:rolleyes:
more feature requests?
what about use QPixmapCache to speedup the painting?
http://doc.trolltech.com/qq/qq12-qpixmapcache.html

marcel
5th October 2007, 17:21
Qt doesn't paint the skins, there were used platform dependent solutions.

kernel_panic
5th October 2007, 17:36
hm the problem is, the only thing i could cache is the the size of the pixmaps, but not more...

bantri
7th October 2007, 05:41
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
7th October 2007, 10:58
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
7th October 2007, 11:45
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
7th October 2007, 14:00
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
7th October 2007, 14:45
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
7th October 2007, 18:08
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
7th October 2007, 19:36
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;)

marcel
7th October 2007, 19:38
No problem, then he/she sublcasses his/her 3rd party mainwindow from qskinmainwindow.

3rd party usually means a library, so the sources shouldn't be modified, even if available.

wysota
7th October 2007, 20:54
How about making your widget a direct QObject subclass and implementing everything in event filters? This would reduce the need of having to subclass your widgets. Of course it might mean other problems instead...

And yes, by 3rd party I mean "no way to modify source code". Above mentioned approach would (or at least could) solve the problem.

BTW. I still think you do it in the wrong layer, nothing changed in that regard ;)

kernel_panic
7th October 2007, 21:24
hm... with qobject is a good idea, but how should i do this? give me some hints!
maybe we could dicuss this in a chat if you have msn, pls add me
markus.kuenkler@gmx.de
how do you think should i do it in another layer?

djurodrljaca
7th October 2007, 22:17
You could look in the QT4 sources... it is GPL. :cool:

wysota
7th October 2007, 22:20
hm... with qobject is a good idea, but how should i do this? give me some hints!
Install an event filter on the widget you want to "monitor" so that all its events will go through your monitor. Then you can intercept paint events, mouse events, resize events or any other events you want and handle them there. Just look out not to fall into an infinite loop with the paint event.


maybe we could dicuss this in a chat if you have msn, pls add me
Sorry, no MS c**p here :)


how do you think should i do it in another layer?
Some platform dependent code would be needed and you'd have to redesign everything so I guess this won't happen for your current project.

kernel_panic
7th October 2007, 22:34
hey thats no problem! show me code man!

what instant messaging system are you using instead?

wysota
7th October 2007, 23:16
what instant messaging system are you using instead?

Skype, Jabber or QtCentre private messaging system ;)

kernel_panic
8th October 2007, 07:22
ok, i will get a jabber id. i will let you know if i have an accaount.

bantri
8th October 2007, 22:28
>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.

Well i guess then you´re out of luck in this matter then...

As a curiosity i´ve calculated the area in a maximized app my screen, i use 1152x864 pixels=995328 pixels) and the titlebar uses 1152x20=23040 pixels which represents 2.31% of the total area in a maximized application.

it means that for the other 97.69%, if i wish to make a total carnival using styles, i can... and those styles will change only if i choose to do so...

perhaps you can ask Qt guys to remove all the styling option so you can get a 100% of compatibility with the operating system... i´m just pledging about styling the remaining 2.31% because i think it´s interesting to have the ability to match those with the styles i choose for the rest of application...

>Imagine having a nice looking customized OSX system with a single application that looks like WindowsXP.

Mimicking any OS appearance is not my objective, i just think that it would be nice and better looking, and more important than this: to be COHERENT -> to make the style of the frame similar/equal/compatible to the style inside the frame.

Somehow it seems to me that it looks more professional and well finished, if i have the 3 buttons (close, maximize, minimize) to look and use the same style of the rest of the application.

In the case of the wooden style for example, everything is changed in style but then, the surrounding frame, title and buttons have the same "cheesy" appearance... it doesn´t look like a complete job of making some application... it looks like two different styles for one application...

As i see, there should be an option where the gui asks just for an empty rectangle in the desktop area, and does all the finishing, (frame, titlebar and control buttons included) i know that windows have this resource, but don´t know about other OS´s and this is one of the reasons it would be useful to have this styling option.

Since windows 2000 there are resources for dealing transparency, layering, frameless windows but it seems that Qt forgot to use those finishing capabilities to make a 100% stylable gui, it´s easy to transfer the responsibility for skinning to the OS but somehow i think that adding fantastic resources for doing things inside the client area and not having the small remaining work of adding a mere top level widget to do an obvious resizing frame, with some title and buttons seems incomplete to me.

But Hey...

They made a gazillion lines of source code to do everything you can imagine for graphical objects, complex styles, vector drawing, affinne transforms, a form designer to compose the layout and styles and stuff but when it comes to the top level frame...

ooops...

That´s the responsibility of the OS, the gazillion lines of source code are not able to do a lousy resizable frame, a title with a background gradient and a bunch of buttons...

Is it so difficult to acomplish this task that it should be done by some user?

Wouldn´t be better to do a standard top level widget inside the lib to deal with this case?

Wouldn´t be better to also in the form designer to change the style of the application frame along with the contents, so they would match?

I´m just thinking bigger here, i think that it would be very attention catching to make some apps using a gui with some nice drop shadows, custom buttons, transparency, even when running OS´s like 2000, and not having to count on some "special patch" (at least there is a patch, and it´s great) to make it work a 100%.

In the mean time OS manufacturers get all the credit to make better looking interfaces (and the money too maybe?)

i can be wrong... but then... how about doing some voting for any gui users and ask them:

Would you like to have the same styling control in the application frame (in forms designer) so you can make it similar to the style used for the client area?

and let´s see the results...

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

Then again, why should they include the styling facility at all?
You should ask Qt guys to remove it...
Remember... I´m just pledging about the remaining 2.31% area.
The solution in this case is not only the application frame.
Using styling has "nothing" to do with native look and feel...
It´s about being original and dedicating some work for crafting different layouts.
For doing the default OS components,
i think that there are some other libs that that don´t do any styling at all...
They just do calls directly to the operating system, and they´re even faster...
Doing "standard gray buttons" is much faster and much easier than spending time changing the border, the font, the shadow, the antialiasing, the roundness, the icons, the background...

I guess i just got used to use winamp (the skins just look soo cute :)) to more than just playing music, but to see that the developers took some time to make it original and now i´m raising the same concept for a gui, whatever it is, and as i am a bit lazy i´m just wan´t to easily compose some styles and let the lib do the rest. That would be very confortable...

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

exactly... when you see nice styled buttons and frames inside the client area they´re real, but when you see nice buttons and frames on the application frame, they´re fake.

Which means that all the purpose for making the client layout easy in the forms designer turns into a hard work when trying to do the same in the application frame.

Faking and having hard work for making the application buttons to have the same style as the inner client windows is the only way to do it, because there is no implemented facility for this in Qt.

I guess then, that, making gui with Qt is easy "as long" as you don´t wan´t to style the application frame...
after all this is the supposed responsibility of the OS.

For those who want the easy way then sticking with the "two" different layout look and feel is the way... i´ll stick with qskinwidget, because at least those 200 lines of code compensate what the gazillion lines of code don´t do...

-To allow styling of the application frame.

>If you look closely at the structure of the toolkit, you'll notice that the developers have simply different goals than you.

probably that´s the case...

i think about some simple goals:

To make the best style looking application as possible with the least work as possible.

Best looking to me does include the application frame to have the same appearance of it´s contents.

Which means that if a make a smooth antialiased wooden button/border on the client area, the application buttons would be smooth antialiased wooden buttons/borders too, and they would be this way in different OS´s...

Those buttons don´t have to be the same as the operating system(i´m not considering OS mimicking), they have to be the same as the client area.

After all what´s the point in doing styling if, at the end, the frame that surrounds your application will be different from it´s contents.

What´s the point in styling the client area easily if, when it comes to make a similar top-level frame you have to accept that it will look different, and there will be no facility to manage it in some easy way?

It seems to me like some pretty incomplete job to make some imense gui that gives you everything to program easy and nice layouts but can´t control it´s "own" application frame, creating some fantastic effects inside the client area but presenting itself with a mediocre frame around the application.

It´s like presenting the Monalisa without the detailed golden frame and shadows around...
It just seems incomplete...
Can you picture it?
http://www.eecs.tufts.edu/~mchow/excollege/s2006/examples/monalisa.jpg

This is a dubious case...
who owns the responsibility for the transition frame beetween the app and the OS desktop?

I think it´s the gui responsibility to do that. (as an extra and a very nice option).

I´m just thinking versatile here, it is obvious that a gui that allows control in this area will have one more aspect to be popular than guis that don´t. And my point of view as a programmer is that if there is some way to just make an application to stand out above others in this aspect it would be an attention catcher, showing skinned windows like vista without having vista is an attention catcher, even if it does mimic vista because it opens a range of new possibilites, which don´t necessarily include mimicking.

wysota
9th October 2007, 00:42
Well i guess then you´re out of luck in this matter then...
I don't feel that way. I think currently I do have total control over the desktop.


As a curiosity i´ve calculated the area in a maximized app my screen, i use 1152x864 pixels=995328 pixels) and the titlebar uses 1152x20=23040 pixels which represents 2.31% of the total area in a maximized application.

it means that for the other 97.69%, if i wish to make a total carnival using styles, i can... and those styles will change only if i choose to do so...
I'm afraid I don't understand what you mean. If you want to have total control (as the application developer) over 100% of the screen, just enter full screen mode.


perhaps you can ask Qt guys to remove all the styling option so you can get a 100% of compatibility with the operating system...
Could you explain? You can always remove the decorations by passing an appropriate hint to QWidget.


Mimicking any OS appearance is not my objective, i just think that it would be nice and better looking, and more important than this: to be COHERENT -> to make the style of the frame similar/equal/compatible to the style inside the frame.
I tend to do it the other way - to make the interior compatible with the exterior, but I guess it's just a matter of choice. If I wanted to get rid of system decorations, I'd use a frameless window or enter full screen mode.


As i see, there should be an option where the gui asks just for an empty rectangle in the desktop area, and does all the finishing, (frame, titlebar and control buttons included) i know that windows have this resource, but don´t know about other OS´s and this is one of the reasons it would be useful to have this styling option.
Well... please look into QWidget API then. It is all there and it is currently what kernel_panic's solution does.


Since windows 2000 there are resources for dealing transparency, layering, frameless windows but it seems that Qt forgot to use those finishing capabilities to make a 100% stylable gui, it´s easy to transfer the responsibility for skinning to the OS but somehow i think that adding fantastic resources for doing things inside the client area and not having the small remaining work of adding a mere top level widget to do an obvious resizing frame, with some title and buttons seems incomplete to me.

From what you say it seems that you should take a closer look at Qt capabilities. Of course it's not all there, but then Qt is not meant for that and never was. It's not an ultimate solution to everything. It's nice that something works on Windows 2000 or Windows Vista, but what happens if someone starts the application on a system that doesn't support all these gizmos? Your beautiful glassy/transparent/whatever style would look broken. Qt provides window and widget transparency on systems that do support it in a fail-safe way. For more complicated things, you need to do some system dependent work (like enabling ARGB windows on X11) and when you do, additional capabilities are there (in Qt) for you to make use of.


They made a gazillion lines of source code to do everything you can imagine for graphical objects, complex styles, vector drawing, affinne transforms, a form designer to compose the layout and styles and stuff but when it comes to the top level frame...
Well... Currently there are almost 9000 threads on this forum and one of them concerns customizing drawing system decorations and remaining threads concern things like layouts, graphical objects, complex styles, vector drawing, transformations and form designing. With all do respect, these features are something that all developers use to implement their applications and only a few applications need styling system decorations. That's where those "gazillions" of code lines come from.


That´s the responsibility of the OS, the gazillion lines of source code are not able to do a lousy resizable frame, a title with a background gradient and a bunch of buttons...
Yep... and it can't bake cookies. Darn... I'd like a cookie baking API so much... It'd be best if it was hardware-accelerated too!


Is it so difficult to acomplish this task that it should be done by some user?
I'm glad that Trolltech focuses on bringing a multimedia framework to Qt and on bringing Qt to new platforms (like WindowsCE, Windows Mobile, etc.) instead of dealing with deep window manager (!!! not platform!) dependent code for hacking system decorations. But hell... that's my opinion and you don't have to agree.

Here you go: http://www.trolltech.com/developer/task-tracker
You can report your suggestion there. Maybe the Trolls will share your point of view and write another gazillion lines of code to do what you ask.


Wouldn´t be better to also in the form designer to change the style of the application frame along with the contents, so they would match?
What if I start your application on a system that has the title bar below the client area with close button in the top left corner of the window and maximize and minimize buttons on the right edge of the window? I don't think your forced decoration will fit my system. Sorry, I simply don't agree with your point of view and based on what the Trolls do, I doubt they will as well.


I´m just thinking bigger here, i think that it would be very attention catching to make some apps using a gui with some nice drop shadows, custom buttons, transparency, even when running OS´s like 2000, and not having to count on some "special patch" (at least there is a patch, and it´s great) to make it work a 100%.
Great, but this is not something that should be implemented on the application level. Please, stop thinking "Windows" when you mean "Operating System".


i can be wrong... but then... how about doing some voting for any gui users and ask them:
Please start a new thread with a poll for that. We've trashed this thread enough.


Then again, why should they include the styling facility at all?
To make your app look good on different platforms through a use of platform independent API. Kiosk platforms and other single application platforms included. These don't contain system decorations at all.


Remember... I´m just pledging about the remaining 2.31% area.
QWidget::showFullScreen()


I guess then, that, making gui with Qt is easy "as long" as you don´t wan´t to style the application frame...
after all this is the supposed responsibility of the OS.
No, not the OS... Window manager - these are completely different entities. You're thinking "Windows" again. And even Windows toolkits don't provide API for styling system decorations. You have to dive into bare WinAPI to do that.


i think about some simple goals:

To make the best style looking application as possible with the least work as possible.

Best looking to me does include the application frame to have the same appearance of it´s contents.

From what you say I think that for you the look of the application comes first - apps should look nice, regardless of the fact that they don't do anything. I like the object oriented environment with high level frameworks like Interview, Arthur, Scribe or Graphics View. And I like it that I can ask some person who is more graphics capable than I am to use stylesheets to style the application for me without having to write a single line of code. Seems that we have different goals and there is no way we'll agree here.


What´s the point in styling the client area easily if, when it comes to make a similar top-level frame you have to accept that it will look different, and there will be no facility to manage it in some easy way?
Who said you have to accept it? Get rid of it if you don't want it! Draw your own frame, your own buttons and everything else you want. You can even use setMask() to neutralize a portion of the decoration if you wish. It's all there for you and you can use it. Of course if you want to disable the window manager for your application, you'll have to handle all events yourself, But seems that's an obvious price to pay.


who owns the responsibility for the transition frame beetween the app and the OS desktop?
The Window Manager.


I´m just thinking versatile here, it is obvious that a gui that allows control in this area will have one more aspect to be popular than guis that don´t. And my point of view as a programmer is that if there is some way to just make an application to stand out above others in this aspect it would be an attention catcher, showing skinned windows like vista without having vista is an attention catcher, even if it does mimic vista because it opens a range of new possibilites, which don´t necessarily include mimicking.

So why don't you sit down, implement it and start selling it to the vast area of developers just waiting to customize their system decorations? Just do it properly. Kernel_panic's solution looks nice in some cases but is a terrible hack. It's very simple but already contains many constraints. And you can't customize system decorations with it. You bypass the window manager and do everything it does yourself. Which immediately means you're losing all advanced capabilities of the window manager, be it kwin or Aqua. And behind the scenes it also means your application seizes to be portable. If you accept those restrictions, you are very welcome to use the solution. If your clients start complaining they can't do this or that (for instance stick the application window on top of other windows, move the window to another desktop or another screen), maybe you'll start seeing it my way.

kernel_panic
10th October 2007, 22:25
on qt-apps.org is the new version available!
it is now just one qobject.
to implement styles link the library, include the qskinobject header and
call were you want to init the skins:


QSkinObject * object = new QSkinObject(this);

Thanks to wysota for the great tip with the object!

maktub
10th January 2008, 10:27
hi kernel_panic

I've been trying out your QSkinObject. Looks great, but I have two problems with loading a QMainWindow in your test program.
- Where the window title should be, I see a rectangle over it.
- If I try to add a MenuBar it sets itself on top of the titlebar and the buttons

I've added a screenshot of the windows.
http://members.home.nl/s.groosman/QSkinWindows.png

could you give some advise?

kernel_panic
10th March 2008, 09:23
yes....
for the mainwindow use sth like that:


MyMainWindow w;
QMainWindow w1;
QSkinObject *o = new QSkinObject(&w1);
o->startSkinning();
w1.setCentralWidget(&w);
w1.show();

and the other one can be fixed with the newer lib

jpn
11th March 2008, 11:47
Be careful!


{
MyMainWindow w;
QMainWindow w1;
...
w1.setCentralWidget(&w); // w1 becomes w's parent
w1.show();
} // (*)


(*) First "w1" goes out of scope and deletes its children, including "w". Then "w", which was already deleted by its parent ("w1"), goes out of scope => crash!

JaRo999
20th April 2010, 13:35
Hi.

Have anyone .svg file for Vista Aero Widgets?
I'm using qskinobject 0.8 from http://qt-apps.org/content/show.php/QSkinObject?content=67309 and there are only blue.svg and template.svg files in source files.