[Development] QColor and HSL's hue
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
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
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?
> -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++]
> -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)
> -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
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
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
> -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
> -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)
> -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)
> -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)
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)
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)
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
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
-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
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
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
-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
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
-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
-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
-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
-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
-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
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
-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