On 11 September 2013 01:07, Laszlo Papp wrote:
> On Tue, Sep 10, 2013 at 4:46 PM, Thiago Macieira
> wrote:
>>
>> On terça-feira, 10 de setembro de 2013 22:31:53, Sze Howe Koh wrote:
>> > On 10 September 2013 14:27, Knoll Lars wrote:
>> > > Ok, let's use QtWin for the namespace. For the module it
On Tue, Sep 10, 2013 at 4:46 PM, Thiago Macieira
wrote:
> On terça-feira, 10 de setembro de 2013 22:31:53, Sze Howe Koh wrote:
> > On 10 September 2013 14:27, Knoll Lars wrote:
> > > Ok, let's use QtWin for the namespace. For the module itself it makes
> IMO
> > > to keep the 'Extras' in the name
On terça-feira, 10 de setembro de 2013 22:31:53, Sze Howe Koh wrote:
> On 10 September 2013 14:27, Knoll Lars wrote:
> > Ok, let's use QtWin for the namespace. For the module itself it makes IMO
> > to keep the 'Extras' in the name.
> >
> > Cheers,
> > Lars
>
> QtWin or QWin?
QtWin, it's a name
On 10 September 2013 14:27, Knoll Lars wrote:
> Ok, let's use QtWin for the namespace. For the module itself it makes IMO
> to keep the 'Extras' in the name.
>
> Cheers,
> Lars
QtWin or QWin?
Comparison with other namespaces: http://qt-project.org/wiki/Qt_5_Structure
Earlier discussion on this
Ok, let's use QtWin for the namespace. For the module itself it makes IMO
to keep the 'Extras' in the name.
Cheers,
Lars
On 06.09.13 15:52, "Sorvig Morten" wrote:
>I agree, QtWin::foo looks much better. We can rename the QtMacExtras
>namespace as well.
>
>What about the module name itself? Woul
I agree, QtWin::foo looks much better. We can rename the QtMacExtras namespace
as well.
What about the module name itself? Would we still say "import QtWinExtras" and
"#include "?
Morten
On Sep 6, 2013, at 11:49 AM, Nurmi J-P wrote:
> I also very much like the idea of sticking the conversion
I also very much like the idea of sticking the conversion functions right into
the respective classes in QtCore and QtGui.
At least QtWinExtras still has lots of helper methods that do not fall into
this category, though. All that Windows specific window blurring, peeking,
colorization etc. stu
Yes yes a thousand times yes!
On 9/3/13 14:41 , Sorvig Morten wrote:
> I think the advantages of having these functions available in QtCore/Gui
> outweighs the risk of customers accidentally using platform-dependent code.
> Maintenance will be easier since there is less code duplication.
>
> Mor
I think the advantages of having these functions available in QtCore/Gui
outweighs the risk of customers accidentally using platform-dependent code.
Maintenance will be easier since there is less code duplication.
Morten
On Sep 2, 2013, at 11:38 PM, Joseph Crowell wrote:
> Most of the functio
Most of the functionality was already in Qt 4 and was moved out for Qt 5
because of maintenance issues and different code for different platforms
exposed to the customer.
On 02/09/2013 10:35 PM, Sorvig Morten wrote:
> I agree the "Extra" looks superfluous. In fact I'd like to go a bit further
>
I agree the "Extra" looks superfluous. In fact I'd like to go a bit further and
suggest we don't have platform extras at all and instead integrate the
functionality into Qt:
- Conversion functions for types in QtCore to QtCore
- Conversion functions for types in QtGui to QtGui
- Widgets to QtWid
+1 from me for doing it everywhere, including in the library names.
--
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com
On Aug 30, 2013, at 9:17 AM, Nurmi J-P wrote:
> Hi all,
>
> While we still have a chance to tweak things
Hi all,
While we still have a chance to tweak things before releasing 5.2, I'd like to
re-open the discussion about platform extras naming.
Short version:
Could we rename the QtMacExtras & QtWinExtras namespaces to just QtMac & QtWin?
(QtX11Extras namespace doesn't exist, at least yet)
Long v
On 3/4/13 13:16 , Samuel Rødal wrote:
> On 03/04/2013 01:08 PM, Sorvig Morten wrote:
>>
>> On Mar 4, 2013, at 8:13 AM, Samuel Rødal
>> wrote:
>>>
>>> What about things such as offscreen platform plugins used for
>>> testing? Or what about a theoretical platform plugin that would
>>> stream renderi
On 03/04/2013 01:08 PM, Sorvig Morten wrote:
>
> On Mar 4, 2013, at 8:13 AM, Samuel Rødal wrote:
>>
>> What about things such as offscreen platform plugins used for testing?
>> Or what about a theoretical platform plugin that would stream rendering
>> commands to somewhere else? Imagine running wa
On Mar 4, 2013, at 8:13 AM, Samuel Rødal wrote:
>
> What about things such as offscreen platform plugins used for testing?
> Or what about a theoretical platform plugin that would stream rendering
> commands to somewhere else? Imagine running wayland clients on Mac or
> Windows for instance,
On 03/01/2013 11:22 AM, Friedemann Kleint wrote:
> Hi,
>
> >I suppose it would not be a detriment. Where do you draw the line?
> Which platforms, what functions and types? Here are some candidate types
> for constructors and conversion operators...
>
> The thing to keep in mind is basically that
Hi,
>I suppose it would not be a detriment. Where do you draw the line?
Which platforms, what functions and types? Here are some candidate types
for constructors and conversion operators...
The thing to keep in mind is basically that the decision to remove the
pixmap conversion functions was
On Mar 1, 2013, at 10:37 AM, Jake Thomas Petroules
wrote:
> I suppose it would not be a detriment. Where do you draw the line? Which
> platforms, what functions and types?
I would leave that decision to the platform maintainers. An initial minimal set
would be good though, for example OS X/
I suppose it would not be a detriment. Where do you draw the line? Which
platforms, what functions and types?
Here are some candidate types for constructors and conversion operators on
their corresponding Qt types, which I can think of off the top of my head:
Windows:
POINT
RECT
HICON
HBITMAP
On Mar 1, 2013, at 8:27 AM, Jake Thomas Petroules
wrote:
> 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?
The argument fo
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?
Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@pe
On Mar 1, 2013, at 12:28 AM, Thiago Macieira 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
>>
>> wrote:
>>> On quinta-feira, 28 de fevereiro de 2013 14.42.53, Tor Arne Vestbø wrote:
I'm probably missing som
On quinta-feira, 28 de fevereiro de 2013 21.32.26, Sorvig Morten wrote:
> On Feb 28, 2013, at 4:50 PM, Thiago Macieira
>
> wrote:
> > 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 cla
On Feb 28, 2013, at 4:50 PM, Thiago Macieira
wrote:
> 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 exp
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 cann
On Thu, Feb 28, 2013 at 2:08 PM, Knoll Lars wrote:
> Actually, I would like Qt Addons to live in a namespace, esp. for new
> ones. The namespace name ought the be the same as the module's name. This
> is really there to avoid name clashes with other parts of Qt. With a
> namespace, you have all t
Actually, I would like Qt Addons to live in a namespace, esp. for new
ones. The namespace name ought the be the same as the module's name. This
is really there to avoid name clashes with other parts of Qt. With a
namespace, you have all the freedom you want on how to name methods
inside. developers
On 2/25/13 17:12 , Joerg Bornemann wrote:
> On 25/02/2013 16:27, Jake Thomas Petroules wrote:
>
>> I'd prefer Qt namespace with no platform indicators, i.e.:
>>
>> Qt::toHICON
>> Qt::toHBITMAP
>> Qt::toCGImageRef
>> Qt::toNSString
I'm probably missing something obvious here, but why are these not
Hi Sascha,
My point is that we cannot know whether we'll have to encode the platform in a
function name again in the future, in which case we'll have functions with and
without the platform in their name. Your point is that this won't ever happen.
We can just avoid this risk of an inconsistent f
On Monday, February 25, 2013 05:50:06 PM Joerg Bornemann wrote:
> On 25/02/2013 17:25, Sascha Cunz wrote:
> > Why would a function that is "potentially useful on more than one
> > platform" go to platform extras?
>
> Because it's working on native types (more than just one) and encoding
> all type
On 25/02/2013 17:25, Sascha Cunz wrote:
> Why would a function that is "potentially useful on more than one platform" go
> to platform extras?
Because it's working on native types (more than just one) and encoding
all type names into the function name would be strange. The same
function name co
On Monday, February 25, 2013 05:12:48 PM Joerg Bornemann wrote:
> On 25/02/2013 16:27, Jake Thomas Petroules wrote:
> > I'd prefer Qt namespace with no platform indicators, i.e.:
> >
> > Qt::toHICON
> > Qt::toHBITMAP
> > Qt::toCGImageRef
> > Qt::toNSString
> >
> > It's obvious to which platform e
Why is that...?
Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petrou...@petroules.com
Telephone: +1 (970) 587-3821
On Feb 25, 2013, at 11:12 AM, Joerg Bornemann wrote:
> On 25/02/2013 16:27, Jake Thomas Petroules wrote:
>
>> I'd prefer Qt namespace with no platform indic
On 25/02/2013 16:27, Jake Thomas Petroules wrote:
> I'd prefer Qt namespace with no platform indicators, i.e.:
>
> Qt::toHICON
> Qt::toHBITMAP
> Qt::toCGImageRef
> Qt::toNSString
>
> It's obvious to which platform each function belongs; there's no need to
> qualify it beyond necessary. If WinRT i
I'd prefer Qt namespace with no platform indicators, i.e.:
Qt::toHICON
Qt::toHBITMAP
Qt::toCGImageRef
Qt::toNSString
It's obvious to which platform each function belongs; there's no need to
qualify it beyond necessary. If WinRT introduces an NSString class and OS X
adds HBITMAPs only then shoul
On 25/02/2013 09:35, Sorvig Morten wrote:
> - Stand-alone function namespace:
> * Qt::toPlatformType (“Qt::toWindowsHBITMAP”. “Qt::toMacCGImageRef”)
> -OR-
> * QPlatform::toType(“QWindows::toHBITMAP”, "QMac::toCGImageRef")
I vote for the latter naming scheme. We shoul
unces+jerome.pasion=digia@qt-project.org
[development-bounces+jerome.pasion=digia@qt-project.org] på vegne av
Sorvig Morten [morten.sor...@digia.com]
Sendt: 25. februar 2013 09:35
To: development@qt-project.org
Emne: [Development] Qt Platform Extras
Hi,
Getting ready for the 5.1 feature free
Hi,
Getting ready for the 5.1 feature freeze, I think we should take some time
unifying the structure and API of the platform extras modules.
There has already been some private discussion on this topic, and this is an
attempt at reaching a final consensus. I think it's important that these
mo
39 matches
Mail list logo
