[Interest] Fwd: Contributor agreement rundown

[Till Oliver Knoll]

... and to the proper recipient again...


Anfang der weitergeleiteten E‑Mail:

> Von: Till Oliver Knoll <till.oliver.knoll at gmail.com>
> Datum: 19. April 2012 10:44:51 MESZ
> An: Nikos Chantziaras <realnc at gmail.com>
> Betreff: Re: [Interest] Contributor agreement rundown
> 
> 
> 
> Am 18.04.2012 um 22:02 schrieb Nikos Chantziaras <realnc at 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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20120419/07079fc5/attachment.html>