[Development] Qt Platform Extras
Jake Thomas Petroules
jake.petroules at petroules.com
Fri Mar 1 08:27:38 CET 2013
Why are we discussing adding conversion operators from/to native objects in QtCore/QtGui? The methods that did so were removed in Qt 5 in order to increase modularity, why would we go the opposite direction again?
Petroules Corporation (www.petroules.com)
Email: jake.petroules at petroules.com
Telephone: +1 (970) 587-3821
On Mar 1, 2013, at 2:21 AM, Sorvig Morten <Morten.Sorvig at digia.com> wrote:
> On Mar 1, 2013, at 12:28 AM, Thiago Macieira <thiago.macieira at intel.com> wrote:
>> On quinta-feira, 28 de fevereiro de 2013 21.32.26, Sorvig Morten wrote:
>>> On Feb 28, 2013, at 4:50 PM, Thiago Macieira <thiago.macieira at intel.com>
>>>> On quinta-feira, 28 de fevereiro de 2013 14.42.53, Tor Arne Vestbø wrote:
>>>>> I'm probably missing something obvious here, but why are these not with
>>>>> the class that they convert from?
>>>>> - conversion operator (or toFoo function if expensive)
>>>>> - constructor (explicit if expensive)
>>>> Because we cannot assure that the library that contains the class in
>>>> question is actually linking to the necessary libraries.
>>>> This is the case on Mac OS X. QtGui does not link to ApplicationServices,
>>>> so it does not have access to CGRect.
>>> Well, we can make QtGui link to ApplicationServices if needed - It already
>>> links to CoreFoundation. Why would it be a problem in practice?
>> Because we can't do the same for other architectures and windowing systems.
> Which ones?
> It seems reasonable to divide the platform set in two then:
> 1) The platform can guarantee the presence of certain libraries at runtime. QtCore and QtGui can contain conversion functions to native types.
> 2) It's uncertain what libraries you'll find. No conversion functions.
> In other words, optimize for the capabilities of each platform instead of using the lowest common denominator.
> Development mailing list
> Development at qt-project.org
More information about the Development