Page 2 of 3 FirstFirst 123 LastLast
Results 21 to 40 of 46

Thread: QSkinWindows Classes

  1. #21
    Join Date
    Jan 2007
    Posts
    177
    Thanks
    8
    Thanked 10 Times in 9 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: QSkinWindows Classes

    Haha!
    more feature requests?

  2. #22
    Join Date
    Jan 2006
    Posts
    24
    Thanks
    2
    Thanked 2 Times in 2 Posts
    Qt products
    Qt3 Qt4
    Platforms
    Unix/X11

    Default Re: QSkinWindows Classes

    Quote Originally Posted by kernel_panic View Post
    Haha!
    more feature requests?
    what about use QPixmapCache to speedup the painting?
    http://doc.trolltech.com/qq/qq12-qpixmapcache.html

  3. #23
    Join Date
    Feb 2006
    Location
    Romania
    Posts
    2,744
    Thanks
    8
    Thanked 541 Times in 521 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: QSkinWindows Classes

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

  4. #24
    Join Date
    Jan 2007
    Posts
    177
    Thanks
    8
    Thanked 10 Times in 9 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: QSkinWindows Classes

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

  5. #25
    Join Date
    Sep 2007
    Location
    Brazil
    Posts
    6
    Thanked 1 Time in 1 Post
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: QSkinWindows Classes

    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

  6. The following user says thank you to bantri for this useful post:

    kernel_panic (7th October 2007)

  7. #26
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: QSkinWindows Classes

    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.

  8. #27
    Join Date
    Jan 2007
    Posts
    177
    Thanks
    8
    Thanked 10 Times in 9 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: QSkinWindows Classes

    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?

  9. #28
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: QSkinWindows Classes

    Quote Originally Posted by kernel_panic View Post
    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).

  10. #29
    Join Date
    Jan 2007
    Posts
    177
    Thanks
    8
    Thanked 10 Times in 9 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: QSkinWindows Classes

    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.

  11. #30
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: QSkinWindows Classes

    Quote Originally Posted by kernel_panic View Post
    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.

  12. #31
    Join Date
    Jan 2007
    Posts
    177
    Thanks
    8
    Thanked 10 Times in 9 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: QSkinWindows Classes

    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

  13. #32
    Join Date
    Feb 2006
    Location
    Romania
    Posts
    2,744
    Thanks
    8
    Thanked 541 Times in 521 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: QSkinWindows Classes

    Quote Originally Posted by kernel_panic View Post
    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.

  14. #33
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: QSkinWindows Classes

    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

  15. #34
    Join Date
    Jan 2007
    Posts
    177
    Thanks
    8
    Thanked 10 Times in 9 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: QSkinWindows Classes

    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?

  16. #35
    Join Date
    Jul 2007
    Location
    Slovenia
    Posts
    14
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: QSkinWindows Classes

    You could look in the QT4 sources... it is GPL.

  17. #36
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: QSkinWindows Classes

    Quote Originally Posted by kernel_panic View Post
    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.

  18. #37
    Join Date
    Jan 2007
    Posts
    177
    Thanks
    8
    Thanked 10 Times in 9 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: QSkinWindows Classes

    hey thats no problem! show me code man!

    what instant messaging system are you using instead?

  19. #38
    Join Date
    Jan 2006
    Location
    Warsaw, Poland
    Posts
    33,359
    Thanks
    3
    Thanked 5,015 Times in 4,792 Posts
    Qt products
    Qt3 Qt4 Qt5 Qt/Embedded
    Platforms
    Unix/X11 Windows Android Maemo/MeeGo
    Wiki edits
    10

    Default Re: QSkinWindows Classes

    Quote Originally Posted by kernel_panic View Post
    what instant messaging system are you using instead?
    Skype, Jabber or QtCentre private messaging system

  20. #39
    Join Date
    Jan 2007
    Posts
    177
    Thanks
    8
    Thanked 10 Times in 9 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows

    Default Re: QSkinWindows Classes

    ok, i will get a jabber id. i will let you know if i have an accaount.

  21. #40
    Join Date
    Sep 2007
    Location
    Brazil
    Posts
    6
    Thanked 1 Time in 1 Post
    Qt products
    Qt4
    Platforms
    Windows

    Default Re: QSkinWindows Classes

    >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/exc...s/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.

Similar Threads

  1. QtTest: Unittesting in several classes
    By Jojo in forum Qt Programming
    Replies: 2
    Last Post: 25th August 2009, 13:38
  2. Design classes in OOP?
    By vql in forum General Programming
    Replies: 5
    Last Post: 25th October 2007, 15:18
  3. Qcj Data classes initial release
    By croftj in forum Qt-based Software
    Replies: 0
    Last Post: 1st May 2007, 03:51
  4. Adding nonQt classes to QtApplication
    By codebehind in forum Newbie
    Replies: 11
    Last Post: 23rd April 2007, 22:08
  5. How to search a string in xml file with Qt Dom classes
    By doganay44 in forum Qt Programming
    Replies: 2
    Last Post: 5th October 2006, 21:16

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.