... and to the proper recipient again...
Anfang der weitergeleiteten E‑Mail:
> Von: Till Oliver Knoll <till.oliver.kn...@gmail.com>
> Datum: 19. April 2012 10:44:51 MESZ
> An: Nikos Chantziaras <rea...@gmail.com>
> Betreff: Re: [Interest] Contributor agreement rundown
>
>
>
> Am 18.04.2012 um 22:02 schrieb Nikos Chantziaras <rea...@gmail.com>:
>
>> Qt already detects the environment, but it's all kept private. What I
>> had in mind is exposing this to the user through QSysInfo when he needs
>> to provide different behavior for Gnome, KDE, Xfce, and others.
>
> Can you give a practical use case where one wants to implement different
> behaviour depending on the desktop?
>
> I'm just asking, because my gutt feeling tells me that this should be kept
> and handled internally.
>
> For example: platform icons (for standard actions such as Open, Save, Close,
> Print...). Qt already has a mechanism (was it QIconFactory?) to create/get
> appropriate icons.
>
> Example: order of OK, Cancel etc buttons in dialogs. There exists a Qt layout
> container which takes care of that.
>
> Example: Standard button texts "Cancel" vs "Abort" and the like. I think
> there are button "roles" which already take care of that.
>
> So what beyond these points do you have in mind? And even if there were such
> scenarios: wouldn't it be better to "solve this within Qt" (in the manner as
> the techniques above) instead of burdening that task upon the actual
> application?
>
> Or do you want to, say, implement a "Show in File Explorer" functionality and
> "when I run under KDE, show my file in Foo File Explorer, but when under
> Gnome, show them in Bar File Explorer"?
>
> (But then again, wouldn't it make more sense to add such a "Show in File
> Manager" functionality to QDesktopService instead?)
>
>
> So what's the concrete use-case you have in mind?
>
>> QSysInfo currently provides the windowsVersion() and macVersion()
>> routines,
>
> To find out *at runtime* which OS version your application is running can be
> very useful in dynamically determining what platform-specific functionality
> is available, together with "resolving the necessary framework linking at
> runtime as well".
>
> That is especially easy on OS X which supports "weak linking" (meaning: your
> application won't complain at dynamic link time if it doesn't find a
> functionality present only on 10.7 Lion and upwards, but it currently runs on
> 10.6.8 Snow Leopard). That works because in Objective-C you rather send
> "messages" to objects, rather than trying to resolve method addresses at
> runtime: in case it doesn't understand a message it throws an exception
> "message not understood" which you can actually catch at runtime, so your
> application doesn't die (I believe).
>
> Or you can test at runtime whether a given object understands that "message"
> (and if not, don't send it).
>
> Or if you know in advance that a given object doesn't understand a given
> message, because you know that functionality is only available since a given
> release... that's where knowing on which OS release your code is running
> becomes very useful.
>
>
> In a C++ method call you would get an "unresolved address" or whatever system
> exception and your application is terminated by the OS. In such a case you
> would have to dynamically load the libraries and resolve the symbol adresses
> at runtime - just like Qt does that with the OpenGL library.
>
>> and I wanted to extend it with desktopEnvironment() and a new
>> enum DesktopEnvironment { Gnome, KDE, Xfce, /* ... */ }. A
>> DesktopEnvironmentVersion enum might also make sense.
>
> It wouldn't probably harm to have it. I'm just saying that most use-cases
> should probably be used "within Qt itself" to properly handle the "look and
> feel" on a given desktop manager. And as mentioned above, there is already
> lots of support already (also for the standard file dialogs etc.).
>
> Cheers, Oliver
>
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
