[Development] QColor and HSL's hue

[Curtis Mitch]

Is there any technical reason (besides compatibility) why QColor::hslHueF() 
can't return a value between 0 and 1?

I see that other projects do this:

https://developer.mozilla.org/en/docs/Web/CSS/color_value#hsl()
https://github.com/bgrins/TinyColor/issues/12

If the colour being represented by QColour is black, QColor::hslHueF() will 
return -1:

http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/painting/qcolor.cpp#n1787

This makes it difficult to construct colours from the HSL getters of QColor 
(when making a HSL-based colour picker, for example); how would I work around 
the case of a negative hue?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties

[Curtis Mitch]

Thanks guys.

Is this worth mentioning in the documentation?


From: Development 
<development-bounces+mitch.curtis=theqtcompany@qt-project.org> on behalf of 
Giuseppe D'Angelo <giuseppe.dang...@kdab.com>
Sent: Monday, 7 March 2016 21:19
To: development@qt-project.org
Subject: Re: [Development] Usage of Q_OBJECT macro in QObject subclasses that 
don't use signals, slots, or properties

Il 07/03/2016 20:55, Curtis Mitch ha scritto:
> Why is this the case? What strange behaviour could result from not doing so?

qobject_cast breaks; the meta object system reports and uses the wrong
class name (so things like "inherits", "className" etc. don't work);
tr() uses the wrong context; and so on.

qobject_cast breakage may be serious enough to justify an automatic -1
to all public QObjects-without-Q_OBJECT classes.

Cheers,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
KDAB - The Qt Experts

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties

[Curtis Mitch]

Recently I noticed this sentence in QObject's documentation [1]:

We strongly recommend the use of this macro in all subclasses of QObject 
regardless of whether or not they actually use signals, slots and properties, 
since failure to do so may lead certain functions to exhibit strange behavior.

Why is this the case? What strange behaviour could result from not doing so?

[1] http://doc.qt.io/qt-5/qobject.html#Q_OBJECT
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] How can Qt 5.6.0 MinGW pass in CI with QTBUG-49971 open?

[Curtis Mitch]

> -Original Message-
> From: Development [mailto:development-
> bounces+mitch.curtis=theqtcompany@qt-project.org] On Behalf Of Thiago
> Macieira
> Sent: Thursday, 3 March 2016 9:07 AM
> To: development@qt-project.org
> Subject: Re: [Development] How can Qt 5.6.0 MinGW pass in CI with QTBUG-
> 49971 open?
> 
> On quinta-feira, 3 de março de 2016 08:56:35 PST Roland Winklmeier wrote:
> > So how is it possible that this error does not show up in CI? I did
> > download the Qt MinGW 4.9 version, so CI should fail to build.
> 
> -Wundef is not enabled by either -Wall or -Wextra. It's entirely correct C
> source to #if on undefined tokens: they become zeroes.
> 
> -Werror is never enabled to end-users either, so QTBUG-49971 is not a real
> FTBFS.

Ferocious Triceratops Baring Fearsome Strength? Phew. I thought we'd gotten rid 
of all of those!

> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++]

[Curtis Mitch]

> -Original Message-
> From: Development [mailto:development-
> bounces+mitch.curtis=theqtcompany@qt-project.org] On Behalf Of Jedrzej
> Nowacki
> Sent: Friday, 26 February 2016 9:44 AM
> To: development@qt-project.org
> Cc: Thiago Macieira ; Milian Wolff
> 
> Subject: Re: [Development] templated QObjects [was: Re: We are planning to
> upgrade qdoc to use clang for parsing C++]
> 
> On Thursday 25 of February 2016 19:22:55 Milian Wolff wrote:
> > On Donnerstag, 25. Februar 2016 09:02:11 CET Thiago Macieira wrote:
> > > On quinta-feira, 25 de fevereiro de 2016 17:33:52 PST Cristian Adam
> wrote:
> > > > This might be a burden for some of the Qt developers (Windows ones).
> > > >
> > > > But all the Qt users get a modern / flexible moc, see this thread:
> > > > https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked
> > > > /d09c9
> > > > 0e
> > >
> > > I don't think we need a more flexible moc. What do we want to do
> > > that we can't do with the current one?
> > >
> > > Don't say "template QObjects". That has other reasons for being a
> > > bad idea, currently.
> >
> > Can you explain what those reasons are? I'd really love to write a
> > generic QAbstractTableModel implementation that operates using
> > concepts. Currently that would require type erasure and thus another
> > set of virtual function calls...
> >
> > I.e. in many projects I end up writing the same boiler plate code to
> > display a QVector in a view. As far as I can see most of
> > that could be abstracted away easily, leaving only slim concepts to the
> struct:
> >
> > struct MyRowType {
> > QString foo;
> > int bar;
> > QVariant data(int column, int role) const {
> > if (!role == Qt::DisplayRole) return {}
> > switch (column) {
> >   case 1: return foo;
> >   case 2: return bar;
> > }
> > return {};
> > }
> > };
> >
> > this could easily be extended to other methods, such as setData,
> > headerData, etc. pp. In the end, one would only need to implement a
> > trivial minimal API at the place where the data is actually stored.
> > And no, I do _not_ consider the current QAIM interface trivial to
> implement, not even for "simple"
> > lists!
> >
> > If we'd have templates QObjects, the above could easily be written. I
> > bet there are other valid use-cases.
> >
> > Cheers
> 
> Hi,
> 
>  When first time I heard about templated QObject, QAIM was my first
> thought :-) The thought evolved over last months and now I think that QAIM
> should not be QObject at all, it is just an unnecessary cost.

What about using C++ models in QML? QAbstractItemModel has to be a QObject for 
that reason alone. Often you also want to control the contents of the model by 
some UI-driven property in QML (e.g. a filter for a list of contacts based on a 
text input field).

>  The main problems of templated QObject are captured more or less in this
> thread: http://lists.qt-project.org/pipermail/development/2013-
> March/010288.html
> 
>  Personally I still think it would be a fancy feature, a bit dangerous to
> implement maybe even dangerous to use, but really cool :-D
> 
> Cheers,
>  Jędrek
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Scalable UIs in QtQuick (take 2)

[Curtis Mitch]

> -Original Message-
> From: Development [mailto:development-
> bounces+mitch.curtis=theqtcompany@qt-project.org] On Behalf Of Nikita
> Krupenko
> Sent: Thursday, 18 February 2016 12:36 PM
> To: development@qt-project.org
> Subject: Re: [Development] Scalable UIs in QtQuick (take 2)
> 
> 2016-02-18 12:50 GMT+02:00 Hausmann Simon
> :
> > (1) In order to make it really easy to scale "logical" pixels without
> having to introduce your own context property or factor in a .qml file
> that you multiply everywhere, we could turn the regular "pixels" in
> QtQuick into truly logical pixels that scale with an application wide (or
> window wide) factor. So Image { width: 100 ... } will scale automatically
> from 100 logical pixels to maybe 200 physical pixels on a x2 display. This
> assumes the availability of API to change this mapping.
> >
> > (2) In the events where you still _want_ to use physical pixels, you
> could use "px" units.
> >
> > So at first nothing would change for app developers at all because we
> > map logical pixels to physical pixels. But if you'd like to, you could
> opt into changing this mapping and having a relatively easy fallback to
> physical pixels using for example the "px" unit. We might as well offer
> the other physical units anyway, that probably causes little to no harm.
> 
> Isn't (1) already done with Qt::AA_EnableHighDpiScaling?
> [snip]

This was exactly my thought. I wonder if this functionality is still needed now 
that we have the high DPI support.

___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] some questions about QtGamePad

[Curtis Mitch]

I have no comments on this subject whatsoever, but I'd like to take the 
opportunity to make an example of how not to communicate to other people:

> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On Behalf Of
> Matthew Woehlke

> terrible idea

> terrible design
 
> How do you even handle hats???

> That's... stupid
 
> If you supported arbitrary axes, *you'd have these already*.

> That's just... inconsiderate.

As is usually the case with people who behave like this, you sound like you 
have some really great points, but they're lost behind a lot of what seems 
like... outrage? People will be much more likely to take what you have to say 
into consideration and engage in discussion with you in the future if you tone 
it down and treat them like you'd like to be treated. That is, don't talk to 
people like they're idiots.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] API review and API quality

[Curtis Mitch]

I don't really understand the question you're asking. :D

> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On Behalf Of
> Andreas Hartmetz
> Sent: Monday, 18 January 2016 3:49 PM
> To: qt-dev 
> Subject: [Development] API review and API quality
> 
[snip]
> Nowadays, API not contributed by TQtC is not-really-reviewed on Gerrit.

Can you share an example of this?

> Everything I have written about API applies to documentation as well. It
> seems like whatever the implementor writes is accepted and that is that.
> AFAIU that was not exactly how it used to be done at Trolltech when it was
> still called Trolltech?

Here as well? 

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Aliasing with QSGRectangleNode

[Curtis Mitch]

> -Original Message-
> From: Gunnar Sletta [mailto:gun...@sletta.org]
> Sent: Wednesday, 16 December 2015 9:05 AM
> To: Curtis Mitch <mitch.cur...@theqtcompany.com>
> Cc: development@qt-project.org
> Subject: Re: [Development] Aliasing with QSGRectangleNode
> 
> It is curious that the aliasing in the 1x image is not reproducible with
> the Rectangle {} element and only for some of the elements.. Some subtlety
> with the private api. One difference might be that you are giving your
> rectangle nodes an explicit x/y while the Rectangle element uses a
> transform node. It would require a bit of digging..

Thanks! That fixed it. :)

For those interested, I changed it to the following:

QPointF pos = QPointF(boundingRect().width() / 2 - circleRadius, 
boundingRect().height() / 2 - circleRadius);
pos = moveBy(pos, 360 / circles * i, boundingRect().height() / 2 - 
circleRadius);
rectNode->setRect(QRectF(QPointF(0, 0), QSizeF(circleRadius * 2, 
circleRadius * 2)));
rectNode->setColor(i % 2 == 0 ? QColor("#353637") : 
QColor("transparent"));
rectNode->setPenColor(QColor("#353637"));
rectNode->setPenWidth(i % 2 == 0 ? 0 : 1);
rectNode->update();

QMatrix4x4 matrix = transformNode->matrix();
matrix.translate(pos.x(), pos.y(), 0);
transformNode->setMatrix(matrix);

> The segmentation you see in the 2x and 6x images is a different problem.
> That comes from the fact that the rectangle node doesn't know its render
> size, so when the thing gets scaled up by 2x or 6x it doesn't know to take
> that scale factor into account. This is another place that needs to look
> up QQuickWindow::effectiveDevicePixelRatio() and apply that to the
> segmentation factor.
> 
> cheers,
> Gunnar
> 
> > On 15 Dec 2015, at 17:03, Curtis Mitch <mitch.cur...@theqtcompany.com>
> wrote:
> >
> >
> > Hi.
> >
> > I'm implementing a busy indicator for the new controls using
> QSGRectangleNode. Even after calling rectNode->setAntialiasing(true), I'm
> noticing some strange aliasing going on. Take a look at the various
> attached screenshots to see what I'm talking about (the 2x/6x variants are
> with QT_SCALE_FACTOR set). For filled "rectangles", there seems to be a
> lack of antialiasing on the outer left side, and for unfilled rectangles
> with borders, it's missing on the left inner side.
> >
> > The attached zip file contains a simplified example to try out.
> >
> > Anyone know why this is happening?
> >
> > Cheers. 2x.png>___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] RFD: plugins vs QStringLiterals

[Curtis Mitch]

> -Original Message-
> From: Development [mailto:development-boun...@qt-project.org] On Behalf Of
> Thiago Macieira
> Sent: Thursday, 5 November 2015 5:45 PM
> To: development@qt-project.org
> Subject: [Development] RFD: plugins vs QStringLiterals
> 
[snip]
> 
> 1) Declare it SEP and only apply workarounds for the places where
> QStringLiteral is used in our plugins, suggesting that people do the same
> in their plugins.

SEP?

> Problems: libraries loaded by plugins, fragile.
> 
> 2) Deep-copy the QStringLiterals
>  a) with atom/quark
>  b) without
> 
> Problem: performance impact, complexity of the atom/quark solution.
> 
> 3) Never unload any plugins, possibly also compiling our own libraries and
> plugins with -z nodelete. Solves most of the problems, including the C++
> vtable case.
> 
> Problems: doesn't catch bypassing of QLibrary (dlopen/LoadLibrary calls),
> prevents upgrading of plugins without restarting the host application.
> 
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [ANNOUNCE] DaD's House! (Beta)

[Curtis Mitch]

> -Original Message-
> From: Konstantin Podsvirov [mailto:konstan...@podsvirov.pro]
> Sent: Thursday, 10 September 2015 4:13 PM
> To: Curtis Mitch <mitch.cur...@theqtcompany.com>; development@qt-
> project.org; CMake Developers <cmake-develop...@cmake.org>
> Subject: Re: [Development] [ANNOUNCE] DaD's House! (Beta)
> 
> 10.09.2015, 16:41, "Curtis Mitch" <mitch.cur...@theqtcompany.com>:
> >> From: Konstantin Podsvirov [mailto:konstan...@podsvirov.pro]
> >>
> >> By clicking on the link, you will be able to get the installer is the
> >> same as the QtSDK and a few clicks to get the binaries, libraries and
> >> linking headers of any of the participating modules.
> >
> > But what am I even clicking the link for? What service does this thing
> provide?
> 
> For example, You want to create a very large and useful application which
> uses a lot of dependencies.
> And you want to deploy it on the Windows.
> 
> You go to the site:
> 
> http://dad.podsvirov.pro
> 
> Download appropriate to your development environment setup.
> 
> Quickly and easily install any required dependent modules and receives a
> development environment, local deployment and testing.
> 
> When you're finished designing, you can create compatible with this
> environment the installer to install your application on other machines.
> 
> Main technologies:
> * Development languages: C, C++ (Qt, Qml, Quick) and other
> * Project management: CMake, but can use other
> * Creating installer based QtIFW (CMake allows you to automate the process
> of creating an installer).
> 
> I answered Your question?

Yes, thank you. :) Hopefully that description saves others the trouble as well.

> Regards,
> Konstantin Podsvirov
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [ANNOUNCE] DaD's House! (Beta)

[Curtis Mitch]

> -Original Message-
> From: Konstantin Podsvirov [mailto:konstan...@podsvirov.pro]
> Sent: Thursday, 10 September 2015 3:18 PM
> To: Curtis Mitch <mitch.cur...@theqtcompany.com>; development@qt-
> project.org
> Subject: Re: [Development] [ANNOUNCE] DaD's House! (Beta)
> 
> 10.09.2015, 16:06, "Curtis Mitch" <mitch.cur...@theqtcompany.com>:
> > What is it, really?
> >
> > Personally I read the email and had no idea, and it didn't make me want
> to follow the link to find out.
> >
> 
> By clicking on the link, you will be able to get the installer is the same
> as the QtSDK and a few clicks to get the binaries, libraries linking and
> headers of any of the participating modules.

But what am I even clicking the link for? What service does this thing provide?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] [ANNOUNCE] DaD's House! (Beta)

[Curtis Mitch]

What is it, really?

Personally I read the email and had no idea, and it didn't make me want to 
follow the link to find out.

> -Original Message-
> From: development-bounces+mitch.curtis=theqtcompany@qt-project.org
> [mailto:development-bounces+mitch.curtis=theqtcompany@qt-project.org]
> On Behalf Of Konstantin Podsvirov
> Sent: Thursday, 10 September 2015 3:02 PM
> To: CMake Developers ; development@qt-
> project.org
> Subject: Re: [Development] [ANNOUNCE] DaD's House! (Beta)
> 
> The first 100 views!
> The interest is there (though not great), but where are the questions and
> suggestions?
> 
> 09.09.2015, 21:12, "Konstantin Podsvirov" :
> > Hi, Dear Developers!
> >
> > Want to advertise a development environment that I am developing.
> > The emergence of this environment would be impossible without two
> fundamental technologies incorporated in it.
> >
> > Firstly is CMake, which you can use to build very much!
> > Secondly - this is a new set of tools for creating cross-platform
> installers for desktop QtIFW.
> >
> > Not without my contribution to their ligament - CPack IFW generator.
> >
> > I am developing this project for about one year and I want to share my
> results, and in return get valuable feedback from users.
> >
> > I started with Windows, which sometimes are lacking in a good open
> solutions. But the technology can be extended to other desktops.
> >
> > Project status I appreciate Betta, but quite stable and very functional.
> >
> > Official website of the project:
> >
> > http://dad.podsvirov.pro
> >
> > If the project is gaining popularity, then I'll accept links to new
> mirrors for removing the load from my server.
> >
> > rsync//download.podsvirov.pro
> >
> > Main module - main :-)
> >
> > I write it in a list for developers that would first obtain a qualified
> appraisal.
> >
> > Looking forward to your answers, questions and suggestions.
> >
> > Happy programming!
> >
> > --
> > Regards,
> > Konstantin Podsvirov
> 
> Regards,
> Konstantin Podsvirov
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Quick Controls Dialogs -- enabled state of the standard buttons (API choices)

[Curtis Mitch]

From: Vladimir Moolle [mailto:vmoo...@ics.com]
Sent: Wednesday, 26 August 2015 12:01 AM
To: Rutledge Shawn shawn.rutle...@theqtcompany.com
Cc: Filippo Cucchetto filippocucche...@gmail.com; Curtis Mitch 
mitch.cur...@theqtcompany.com; development@qt-project.org
Subject: Re: [Development] Qt Quick Controls Dialogs -- enabled state of the 
standard buttons (API choices)

Hi, thank you all for the comments and suggestions you’ve left.  They’ve helped 
us come to a consensus as to what is desired for the future API.  We’d like to 
make the following proposal for the new version of Dialog.

1 .  Upon collective agreement, the main use case becomes something like:

Dialog {
ButtonBox { // probably, no need to prepend the name with Dialog,
// provided ButtonBox ends up in Dialogs module
// (and not in Controls nor Layouts modules)
Button {
ButtonBox.standardButton: StandardButton.Ok
}
Button {
ButtonBox.standardButton: StandardButton.Cancel
  enabled: some binding expression
}
}


This adds the desired ability to govern buttons’ enabled state with bindings, 
and also to apply styles, etc. (all without the clutter of “button delegates” 
as proposed in #6 of the last week’s e-mail, and with no proxy objects or 
button getters).

2 .  One nice feature of above API could be possibility to use completely 
custom items for buttons, as long as they specify a standard role via the 
attached property (and have a clicked signal):

Dialog {
ButtonBox {
MyCustomButton {
// has a clicked() signal (otherwise a warning is emitted by 
ButtonBox)
ButtonBox.standardButton: StandardButton.Cancel
}
}

3 . Moreover, it could be possible to allow the user to add buttons lacking any 
standard behavior to the ButtonBox:

Dialog {
ButtonBox {
Button {
// would require adding StandardButton.Other to the StandardButton 
flags
//   (so that buttons could be differentiated from other children 
of ButtonBox)
ButtonBox.standardButton: StandardButton.Other // Default value for 
this property
onClicked: custom handler
   }
}

4 . Given the above, parenting (and laying out manually) arbitrary other items 
becomes simple, too:

Dialog {
ButtonBox {
MyCustomBackground {
// lacks ButtonBox.standardButton property, and is not laid out by 
ButtonBox
anchors.fill: parent
}
Button {
ButtonBox.standardButton: StandardButton.Ok
   }
}

5 . It may be beneficial to deprecate the current standardButtons-based API in 
favour of the new one (in Controls 3?), and opt for manual (rather than 
automatic, with a possibility to discard) ButtonBox insertion into the dialogs 
-- this comes at a cost of a couple extra braces, but makes code intent more 
explicit, and allows for trivial parenting to the ButtonBox (when it is 
necessary, as in #4 above).

Additionally, another, simplified item could be added, leveraging the new API 
to implement the old one and ease porting the existing code.

Best regards, Vladimir

What is the benefit of adding ButtonBox over just adding a Dialog.buttonRole 
attached property?

It’s also a bit scary that there are now three ways to add buttons to a dialog:


-standardButtons

-Declaring them as children (manual layout)

-Declaring them as children of a ButtonBox (automatic layout)

By the way, I’m not saying that the attached property approach is any better in 
this regard (you can replace the last bullet point with it and it still 
applies), I just think it’s growing quite complex.

Can’t we just deprecate standardButtons and tell users that ButtonBox or 
Dialog.buttonRole is the new way of declaring standard buttons?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt Quick Controls Dialogs -- enabled state of the standard buttons (API choices)

[Curtis Mitch]

From: development-bounces+mitch.curtis=theqtcompany@qt-project.org 
development-bounces+mitch.curtis=theqtcompany@qt-project.org on behalf of 
Vladimir Moolle vmoo...@ics.com
Sent: Saturday, 22 August 2015 01:22
To: development@qt-project.org
Subject: [Development] Qt Quick Controls Dialogs -- enabled state of the 
standard buttons (API choices)

[snip]

6. Finally, Dialog could accept (optional) delegates for the buttons created, 
allowing for arbitrary customizations, i.e.:
Dialog {
...
StandardButtonDelegate {   //name arguably could be better
role: StandardButton.Apply // could be roles here even
StandardButton {   // a Button, but with default bindings for 
text, etc.
enabled: some binding expression
}
}
StandardButtonDelegate {   //name arguably could be better
role: StandardButton.Apply // could be roles here even
Rectangle {// a very custom button
   ...
signal clicked // or a warning emitted by Dialog if absent
enabled: some binding expression
}
}
}

[snip]

At this stage, wouldn't it just be easier to declare regular buttons as 
children of the dialog and then introduce some Dialog.buttonRole attached 
property? For example:

Dialog {
Button {
Dialog.buttonRole: StandardButton.Ok
}
Button {
Dialog.buttonRole: StandardButton.Cancel
}
}

The dialog can still take care of the layouting of the buttons, and the text 
would even be set for you (unless you want to set your own). We could document 
this as overriding the standardButtons property if both are specified for 
whatever reason.

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 4.8: disabling the CI and closing for anything except security fixes

[Curtis Mitch]

From: development-bounces+mitch.curtis=theqtcompany@qt-project.org 
development-bounces+mitch.curtis=theqtcompany@qt-project.org on behalf of 
Thiago Macieira thiago.macie...@intel.com
Sent: Friday, 14 August 2015 22:19
To: development@qt-project.org
Subject: Re: [Development] Qt 4.8: disabling the CI and closing for anything
except security fixes

On Friday 14 August 2015 09:41:16 Lisandro Damián Nicanor Pérez Meyer wrote:
 On Thursday 13 August 2015 17:40:24 Thiago Macieira wrote:
  I recently tried to fix a very simple bug in Qt 4.8 but I can't get the
  change to integrate because the CI seems to have fallen into disrepair.
 
  Instead of using valuable QA time in fixing the CI for 4.8, I'd like to
  propose instead that we simply disable the CI for that version and close
  Qt
  4.8 for any submission except security fixes. Gerrit would be configured
  for pure merging instead of staging, but that would only be enabled to
  Gerrit admins and they'd only do it after confirmation from the security
  team (security@qt- project.org).
 
  Any objections?

 FWIW I think this is they way to go.

Seeing that we have support across the board, I'll ask the Gerrit admins to do
the change.

I'll also drop my fix because it's not a security fix.

We can also close all Qt 4.x bug reports that do not apply to Qt 5 and aren't
security issues.

[snip]

I created a filter for those bugs:

https://bugreports.qt.io/issues/?filter=16968

I'll try to do a bulk close of those bugs and reference this thread.

(Sorry about the formatting, on Windows...)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QNoDebug - available but undocumented

[Curtis Mitch]

 -Original Message-
 From: development-bounces+mitch.curtis=theqtcompany@qt-project.org
 [mailto:development-bounces+mitch.curtis=theqtcompany.com@qt-
 project.org] On Behalf Of Tomasz Siekierda
 Sent: Friday, 31 July 2015 10:43 AM
 To: Smith Martin martin.sm...@theqtcompany.com
 Cc: development@qt-project.org
 Subject: Re: [Development] QNoDebug - available but undocumented
 
 On 31 July 2015 at 10:26, Smith Martin martin.sm...@theqtcompany.com
 wrote:
  qdebug.cpp should contain a comment like this:
 
  /*!
\class QNoDebug
\internal
  */
 
 Well, it does not contain this comment.
 
 Olivier Goffart:
  It's a fake class that replaces QDebug when QT_NO_DEBUG_OUTPUT is
 defined.
  That way the code compiles but is optimized away.
 
 Thanks for the explanation. I've asked because I've been surprised to
 see it being used in some project like this:
 
 #ifdef DEBUG_FETCHER
 #define fetcherDebug qDebug()
 #else
 #define fetcherDebug NoDebug()
 #endif
 
 as a temporary solution to enable debug output of a new feature.

What's the benefit of this over QLoggingCategory?

 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtQuick TestCase with other top windows

[Curtis Mitch]

From: development-bounces+mitch.curtis=theqtcompany@qt-project.org 
[mailto:development-bounces+mitch.curtis=theqtcompany@qt-project.org] On 
Behalf Of Filippo Cucchetto
Sent: Wednesday, 29 July 2015 9:53 PM
To: development@qt-project.org
Subject: [Development] QtQuick TestCase with other top windows

Hi everyone this is my first post on the mailing list so please bear with me.
Currently i'm trying to create some tests for the qtquick menuba.
For achieving this i need to create an ApplicationWindow and sending events to 
it.
Currently the TestCase qml component sends all the events to the Test window.
This obviously doesn't fit my use case.
I investigated a little how to fix that:

1) Add a battery of overloads for the mouseClick and keyPress functions that 
take
a QWindow* parameter.
Pros: the current tests are not effected by the change and it's a more general 
approach (useful in some particular cases like mine).
Cons: a new set of functions. In particular from the qml side we will have the 
pairs [keyPress, keyPressInWindow], [mouseClick, mouseClickInWindow] etc.

2) Make the TestCase send the events to the window where a particular item 
belongs.
However this works with the functions that take a QQuickItem as a parameter 
(like mouseClick(item, x, y, ...) but not for keyPress(...) since it doesn't
have a QQuickItem argument. The idea is to forward the key events to the 
currently active window (so the one that has the keyboard focus).
Pros: no API bloat
Cons: i implemented it and a lot of test cases broke. Basically most of them 
rely to the current TestCase behaviour to send
 events to the testcase window. This change broke some test where  we have 
popups, like in the ComboBox tests.
3) Make a standalone C++ app for making such tests without touching the 
TestCase code.
Pros: Current tests are not effected.
Cons: Some code duplication. Furthermore, currently, most of classes inside the 
QtQuickControls plugin aren't exported so even if my app is linked to it i 
cannot use them.
To be honest, i basically tried all the previous 3 options and if i'm the one 
to choose i would go with the option (1)
since i don't want to break everyone's  code.


--
Filippo Cucchetto

I’m probably missing something, but what’s wrong with extending the existing 
tst_menubar?

http://code.qt.io/cgit/qt/qtquickcontrols.git/tree/tests/auto/menubar/tst_menubar.cpp

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtQuick TestCase with other top windows

[Curtis Mitch]

I thought that you were writing tests within Qt?

From: Filippo Cucchetto [mailto:filippocucche...@gmail.com]
Sent: Thursday, 30 July 2015 8:41 AM
To: Curtis Mitch mitch.cur...@theqtcompany.com
Cc: development@qt-project.org
Subject: Re: [Development] QtQuick TestCase with other top windows

I wrote that and i basically broke the one definition rule of C++ since in the 
.prohttp://code.qt.io/cgit/qt/qtquickcontrols.git/tree/tests/auto/menubar/menubar.pro
 file
i added the plugin cpp files. This results in one definition of QQuickMenuBar
inside the plugin and one inside the test.
I think that this could be solved if we export those classes from the plugin and
the test links to it (see the point (3) of my previous email).




2015-07-30 8:09 GMT+02:00 Curtis Mitch 
mitch.cur...@theqtcompany.commailto:mitch.cur...@theqtcompany.com:
From: 
development-bounces+mitch.curtis=theqtcompany@qt-project.orgmailto:theqtcompany@qt-project.org
 
[mailto:development-bounces+mitch.curtismailto:development-bounces%2Bmitch.curtis=theqtcompany@qt-project.orgmailto:theqtcompany@qt-project.org]
 On Behalf Of Filippo Cucchetto
Sent: Wednesday, 29 July 2015 9:53 PM
To: development@qt-project.orgmailto:development@qt-project.org
Subject: [Development] QtQuick TestCase with other top windows

Hi everyone this is my first post on the mailing list so please bear with me.
Currently i'm trying to create some tests for the qtquick menuba.
For achieving this i need to create an ApplicationWindow and sending events to 
it.
Currently the TestCase qml component sends all the events to the Test window.
This obviously doesn't fit my use case.
I investigated a little how to fix that:

1) Add a battery of overloads for the mouseClick and keyPress functions that 
take
a QWindow* parameter.
Pros: the current tests are not effected by the change and it's a more general 
approach (useful in some particular cases like mine).
Cons: a new set of functions. In particular from the qml side we will have the 
pairs [keyPress, keyPressInWindow], [mouseClick, mouseClickInWindow] etc.

2) Make the TestCase send the events to the window where a particular item 
belongs.
However this works with the functions that take a QQuickItem as a parameter 
(like mouseClick(item, x, y, ...) but not for keyPress(...) since it doesn't
have a QQuickItem argument. The idea is to forward the key events to the 
currently active window (so the one that has the keyboard focus).
Pros: no API bloat
Cons: i implemented it and a lot of test cases broke. Basically most of them 
rely to the current TestCase behaviour to send
 events to the testcase window. This change broke some test where  we have 
popups, like in the ComboBox tests.
3) Make a standalone C++ app for making such tests without touching the 
TestCase code.
Pros: Current tests are not effected.
Cons: Some code duplication. Furthermore, currently, most of classes inside the 
QtQuickControls plugin aren't exported so even if my app is linked to it i 
cannot use them.
To be honest, i basically tried all the previous 3 options and if i'm the one 
to choose i would go with the option (1)
since i don't want to break everyone's  code.


--
Filippo Cucchetto

I’m probably missing something, but what’s wrong with extending the existing 
tst_menubar?

http://code.qt.io/cgit/qt/qtquickcontrols.git/tree/tests/auto/menubar/tst_menubar.cpp




--
Filippo Cucchetto
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Q_DECLARE_TYPEINFO compile time checks

[Curtis Mitch]

 -Original Message-
 From: m...@kdab.com [mailto:m...@kdab.com] On Behalf Of Marc Mutz
 Sent: Monday, 27 July 2015 3:29 PM
 To: Curtis Mitch mitch.cur...@theqtcompany.com
 Cc: development@qt-project.org
 Subject: Re: Q_DECLARE_TYPEINFO compile time checks
 
 On Monday 27 July 2015 14:02:59 Curtis Mitch wrote:
  You mentioned that you have some kind of enforcement of the
  Q_DECLARE_TYPEINFO stuff - can you please share this so that others
 can
  run it on their modules?
 
 It currently conflicts with Thiago's changes to add Q_RELOCATABLE_TYPE.
 I'll
 upstream parts of it that can be upstreamed once his stuff has merged,
 but the
 basic trick is:
 
 - add isSpecialized = false to the primary QTypeInfo template
   ( = Q_IS_ENUM when Q_RELOCATABLE_TYPE lands)
 - add isSpecialized = true to all specialisations
 - static_assert that QTypeInfoT::isSpecialized in various places:
   * inside QVector::append
   * QList::node_construct
   * Q_DECLARE_METATPYE
   * whereever else it makes sense (I have the above three)
 
 That doesn't catch all cases, of course, and it will not compile as long
 as
 QtCore hasn't been fully fixed (which requires Q_RELOCATABLE_TYPE), but
 we
 don't have a central macro that declares a type as a value type, so the
 three
 places above are the best I have come up with so far.
 
 I'll upstream the addition of isSpecialized once Thiago's stuff is in.
 We
 should probably also change the Q_DECLARE_SHARED to be
 Q_DECLARE_VALUE_TYPE
 and _WITH_SWAP(). Then we have a central macro to put these checks,
 maybe just
 for headerscheck.
 
 Thanks,
 Marc
 
 --
 Marc Mutz marc.m...@kdab.com | Senior Software Engineer
 KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
 Tel: +49-30-521325470
 KDAB - The Qt Experts

Hmmm, I don't think that helps with 
https://codereview.qt-project.org/#/c/122268/, for example.

Oh well.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Tool to record GIFs

[Curtis Mitch]

Hi.

I recently pushed a patch [1] that adds a GIF recorder tool (it's a manual 
test) to qt-labs/qtquickcontrols2.

The tool provides a convenient way to record a GIF as you interact with a Qt 
application. It can also record the events that occurred during the recording 
and output them as calls to QTest functions (currently only mouse events), 
which can then be reused to reproduce the events later. This is mostly useful 
for cases where you have an existing GIF that shows interaction with some UI, 
and the appearance/styling of the UI  is altered at some point and you don't 
want to have to waste time trying to recreate the events yourself through 
interaction with the application.

You can see an example of its usage here:

https://codereview.qt-project.org/#/c/122111/6/tests/manual/gifs/tst_gifs.cpp

I'm interested to know if anyone else would get a use out of this. Other Qt 
modules could benefit from it. Currently the GifRecorder class assumes a 
QQuickView, but it should be quite trivial to have a WidgetGifRecorder and a 
QuickGifRecorder.

Cheers.

[1] https://codereview.qt-project.org/#/c/122111/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Curtis Mitch]

 -Original Message-
 From: development-bounces+mitch.curtis=theqtcompany@qt-project.org
 [mailto:development-bounces+mitch.curtis=theqtcompany.com@qt-
 project.org] On Behalf Of Marc Mutz
 Sent: Friday, 10 July 2015 11:04 AM
 To: development@qt-project.org
 Subject: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO
 
 Hi,
 
 I'll never manage to eradicate inefficient QLists if people continue to
 add
 new ones :) So here are some things I'd like _everyone_ to watch out for
 in
 reviews and mercilessly -1:
 
 - using QList
 - not using Q_DECLARE_TYPEINFO
 
 Let me qualify that a bit: QListC is a _very_ bad idea for virtually
 any C,
 because the minutest of mistakes (and the default behaviour _is_ a
 mistake)
 can render it utterly and unacceptably inefficient. I won't give you the
 whole
 story (google QList harmful for that), but never, ever use QListC
 *unless*:
 
 - sizeof(C) == sizeof(void*) (*both* on 64 and 32-bit platforms!) _and_
 C has
   been declared Q_MOVABLE_TYPE or Q_PRIMITIVE_TYPE
 -or-
 - the use is unescapable, because other parts of Qt use it (e.g.
 QVariant,
   QModelIndex).
 
 The latter doesn't mean that you should _always_ use QList for QVariant
 or
 QModelIndex. If all you're doing is local to your class, then by all
 means use
 a QVector.
 
 QVector is the correct default container. If you actually need list
 behaviour
 (ie. linked lists), use QLinkedList instead. It tends to be _faster_
 than
 QList.
 
 In private implementation, also consider using std::vectorC, esp. if
 you
 never copy it and C is (explictly or implicitly) move-enabled. It
 typically
 produces up to 1KiB less executable code than QVector. *Per
 instantiation*.
 
 If in *any* kind of doubt whether QList is acceptable, or any of your
 container choices, feel free to add me as a reviewer.
 
 And please, whenever you add a new type (not just class, *any* type,
 incl.
 enums, but excluding QFlags (which are automatically primitive)),
 strongly
 consider Q_DECLARE_METATYPE with the appropriate flag (yes, even

I'm guessing that you meant to write Q_DECLARE_TYPEINFO here?

For those (like me) wondering why Marc is advocating the use of this macro, 
it's briefly explained in the documentation [1]:

You can use this macro to specify information about a custom type Type. With 
accurate type information, Qt's generic containers can choose appropriate 
storage methods and algorithms.

Flags can be one of the following:

Q_PRIMITIVE_TYPE specifies that Type is a POD (plain old data) type with no 
constructor or destructor, or else a type where every bit pattern is a valid 
object and memcpy() creates a valid independent copy of the object.
Q_MOVABLE_TYPE specifies that Type has a constructor and/or a destructor but 
can be moved in memory using memcpy().
Q_COMPLEX_TYPE (the default) specifies that Type has constructors and/or a 
destructor and that it may not be moved in memory.

[1] http://doc.qt.io/qt-5/qtglobal.html#Q_DECLARE_TYPEINFO

 Q_COMPLEX_TYPE). About the only time this can be considered optional is
 for
 polymorphic classes. It should become second nature to
 Q_DECLARE_TYPEINFO.
 
 It should be considered a _must_ to Q_DECLARE_TYPEINFO any type that is
 put
 into a QVector, QList or QVariant. In fact, my local copy enforces this
 at
 compile-time. I hope to push this work at some point, but of course,
 that
 means that each and every occurrence in Qt itself first needs to be
 fixed, and
 even then, we can only enable it as an opt-in to not break user code
 (even if
 it deserves to be broken).
 
 Thanks,
 Marc
 
 --
 Marc Mutz marc.m...@kdab.com | Senior Software Engineer
 KDAB (Deutschland) GmbH  Co.KG, a KDAB Group Company
 Tel: +49-30-521325470
 KDAB - The Qt Experts
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Curtis Mitch]

 -Original Message-
 From: development-bounces+mitch.curtis=theqtcompany@qt-project.org
 [mailto:development-bounces+mitch.curtis=theqtcompany.com@qt-
 project.org] On Behalf Of Giuseppe D'Angelo
 Sent: Friday, 10 July 2015 12:05 PM
 To: Smith Martin; development@qt-project.org
 Subject: Re: [Development] HEADS UP: Don't use QList, use
 Q_DECLARE_TYPEINFO
 
[snip]
 
 (*) not movable, or bigger than a void*. And user-defined types are not
 movable by default (they're complex). And if we forget
 Q_DECLARE_TYPEINFO on public types, we can't add it back because it's
 binary incompatible.

How is it binary incompatible?

 Cheers,
 --
 Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
 KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
 KDAB - The Qt Experts

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

[Curtis Mitch]

 -Original Message-
 From: giuseppe.dang...@kdab.com [mailto:giuseppe.dang...@kdab.com]
 Sent: Friday, 10 July 2015 12:22 PM
 To: Curtis Mitch; Smith Martin; development@qt-project.org
 Subject: Re: [Development] HEADS UP: Don't use QList, use
 Q_DECLARE_TYPEINFO
 
 Il 10/07/2015 12:12, Curtis Mitch ha scritto:
  How is it binary incompatible?
 
 Because the code produced by QListC (which is inlined) is incompatible
 if C becomes a good type (from a bad one) or viceversa.
 
 The code for a bad C involves allocating every C object on the heap,
 putting the pointer in the backing array, and dereferencing that pointer
 to get the C back; the code for a good C involves putting and
 retrieving C straight into/from the backing array.
 
 What happens if you have a library which creates a QListC assuming C
 to be bad, and then passes that QListC to your app, which assumes C
 to be good? This is what happens if you add a typeinfo after you
 forgot.
 
 Cheers,
 --
 Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer
 KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
 KDAB - The Qt Experts

Ah, I see. Thank you.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] date/time adjust for (auto) testing

[Curtis Mitch]

 -Original Message-
 From: development-bounces+mitch.curtis=theqtcompany@qt-project.org
 [mailto:development-bounces+mitch.curtis=theqtcompany@qt-project.org]
 On Behalf Of André Somers
 Sent: Wednesday, 3 June 2015 8:39 AM
 To: development@qt-project.org
 Subject: [Development] date/time adjust for (auto) testing
 
 Hi,
 
 We have applications that use the current date and time at places spread
 around the code. For normal operations, that works very nicely. However,
 we find that for (auto) testing, it would be very convenient if we could
 trick the application into believing it is some other date/time, so that
 we can test if certain behaviours work the way we would like to
 automatically. Currently, these tests take a lot of time because we
 actually need to manually adjust the system date and time, do some
 stuff, then adjust again, etc.
 
 It would be really confortable if there was some control to set a
 date/time offset (so the time keeps running) or a fixed date/time to be
 returned from currentDate(), currentTime() or currentDateTime()
 respectively. I guess access to such a thing does not belong in the main
 Qt classes, but is really a testing tool, so perhaps it could find
 refuge in QtTest somewhere. Would a contribution adding such a thing
 stand any chance of being accepted, or would this be considered out of
 scope or even unwanted?
 
 An alternative might be to hook the windows kernel API, but that may be
 much tricker to get right and may have unforseen consequences for the
 code injected by Squish doing the actual testing.
 
 André
 
 --
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

Sounds like a great thing to have if you can get it working. The QDateTime 
tests themselves would benefit from this quite a lot.

Perhaps you've already seen, but it looks like Thiago attempted something 
similar with a8c74ddcf78604c9038ba2a2bea81e445e4b3c58:

http://code.qt.io/cgit/qt/qtbase.git/tree/tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp#n2988


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A better headersclean test

[Curtis Mitch]

 -Original Message-
 From: development-bounces+mitch.curtis=theqtcompany@qt-project.org
 [mailto:development-bounces+mitch.curtis=theqtcompany@qt-project.org]
 On Behalf Of Thiago Macieira
 Sent: Tuesday, 6 January 2015 4:53 PM
 To: development@qt-project.org
 Subject: Re: [Development] A better headersclean test
 
 On Tuesday 06 January 2015 10:14:35 Curtis Mitch wrote:
   For development I usually do debug builds, so it would be nice to
 avoid
   the extra build time (and extra nagging during the build) most of
 the
   time, and just let CI enforce it, as long as that is reliable.
  +1
 
 So I guess both of you are ok with having the option to opt-out with the
 default being to compile headers.

Yeah, that's fine.

 --
 Thiago Macieira - thiago.macieira (AT) intel.com
   Software Architect - Intel Open Source Technology Center
 
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] A better headersclean test

[Curtis Mitch]

 For development I usually do debug builds, so it would be nice to avoid the 
 extra build time (and extra nagging during the build) most of the time, and 
 just let CI enforce it, as long as that is reliable.

+1
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] changing Q_GADGET

[Curtis Mitch]

 -Original Message-
 From: development-bounces+mitch.curtis=theqtcompany@qt-project.org
 [mailto:development-bounces+mitch.curtis=theqtcompany@qt-project.org]
 On Behalf Of Simon Hausmann
 Sent: Friday, 28 November 2014 12:20 PM
 To: development@qt-project.org
 Subject: [Development] changing Q_GADGET
 
 Hi,
 
 Monsieur Goffart did awesome work in the dev branch on allowing
 structures with
 Q_GADGET to have properties and invokable methods. This brings the macro
 to a
 much wider audience and I'd like to use this opportunity to propose a
 slight
 change to it that may be controversial:
 
 The macros Q_OBJECT and Q_GADGET both - towards the end of their
 definition -
 change the member access permission level to private. It's always been
 that
 way.
 
 I'd like to propose changing Q_GADGET to not change the access
 permission
 level, so that you can write
 
 struct MyStructure
 {
 Q_PROPERTY(int x MEMBER x)
 Q_GADGET
 
 int x;
 }
 
 
 I feel that Q_GADGET has its primary use with structures and the default
 access level for those is public. I find it awkward that you currently
 have to
 write:
 
 structure MyStructure
 {
 Q_PROPERTY(int x MEMBER X)
 Q_GADGET
 public:
 int x;
 }
 
 
 The proposed change would have two effects:
 
 1) It makes any existing code that _relies_ on Q_GADGET turning to
 private
 suddenly expose members in structures.
 
 2) On paper it breaks binary compatibility with MSVC, in the unlikely
 event
 that somebody
 a) produces a DLL and cares about binary compatibility
 b) exposes bare structures
 c) relies on Q_GADGET turning access permission levels to private
 
 
 I feel that the effects are negligible compared to the benefit of a
 better API.
 
 What do you think?
 
 
 Simon
 ___
 Development mailing list
 Development@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/development

This sounds quite reasonable to me. I wasn't even aware of this behaviour, and 
would be quite worried if people were using these macros as access modifiers. 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development