Re: [Development] Commercial-only 6.2 LTS phase starts: Closing the 6.2 branch(es) on 20th April
On Tue, 20 Sept 2022 at 01:34, Konstantin Ritt wrote: > Hi Tuuka, > > By that link I didn't mean QTBUG-102962 exactly, but 23 matching bugs for > a single component (which is not even one of the top-wanted components). > On vanilla 6.2.4, QCamera simply doesn't work on many Android devices. All > these issues were resolved for 6.2.5. Coincident? > > > We are no holding back on bug fixes, though. > > so the fix is in Qt 6.3.1 > Technically you aren't. But in fact you are! > That is what I called "please stick to unstable, semi-functional versions > of Qt, test them and report bugs". > 6.3 brought a bunch of new bugs and regressions, and some of them still > aren't fixed. As for example, look at -- > https://bugreports.qt.io/browse/QTBUG-98964?jql=text%20~%20%22Binding%20on%20contentItem%20is%20not%20deferred%20as%20requested%20by%20the%20DeferredPropertyNames%20class%20info%20because%20one%20or%20more%20of%20its%20sub-objects%20contain%20an%20id%22 > -- (and not only at QTBUG-98964). > Fixed in 6.3.0? Sure it is. But it is still reproducible in dev... > Maybe it is not really important? Well, I personally can live with it. > Until I get a hang/crash report in release due to this issue... > > And that's just a single example of many. > Okay, perhaps I should stick back to 6.2.4, keep my eye on commits > picked-up to mysterious 6.2.5 and apply them manually. Thanks, > cherry-picking monkey is a job I was dreaming of! > > When I chose Qt for developing my apps, it was "Code less, create more[, > deploy everywhere]". > I was ok with building Qt from sources when you started selling binaries > to your commercial folks. Waste of an hour of my machine power per several > months was not a big price for stability update. > But we definitely didn't choose to be your free testing crowd! > > > Regards, > Unhappy monkey > As much as I dislike The Qt Company unfriendly behaviour toward LGPL users and the fact that IMHO The Qt Company seems to be taking decisions that should be taken by the Qt Project, I have to say that Qt did not have any form of LTS before Qt 5.6 and I do not remember seeing any complaints about it during Qt 4 or early Qt 5 era. The biggest issue was The Qt Company dropping open source support for Qt 5.15 while Qt 6 was far from ready. There was no LTS during Qt 4, but Qt 4 did get support for at least a couple of Qt 5 releases. Thankfully KDE saved the day by having kde/5.15 branch IMHO the fact that Qt .1 or .2 releases are seemingly never usable for some users because of new bugs and regressions is a symptom of quality issues that should not be solved by an LTS. My 2 cts Benjamin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Licensing of qtbase
On Wed, 13 Jul 2022 at 13:05, Florian Bruhin wrote: > > https://www.qt.io/product/features?hsLang=en#js-6-3 lets you see the > individual components of Qt and what license they are available as. > > That's some high level of FUD and BS. If I select LGPLv3, all Qt tools are greyed out (moc, qmake, Qt Creator, etc.). Sure these tools are themselves not licensed under LGPLv3, but nothing prevents them from being used for LGPLv3 projects. Ang given the text at the top of the page: > Please select a [...] license model, [...] programming language to see, > what items are available for that selection. > it will clearly make some people think that one cannot use these tools with LGPLv3 projects. Especially because when selecting a language it will filter based on which languages can be used with a tool, not which languages a tool is developed with. Anyway, I think the easiest way to get info about Qt license is https://doc.qt.io/qt-6/licensing.html for general information and https://doc.qt.io/qt-6/qtmodules.html#gpl-licensed-addons for checking modules that are not available under LGPLv3. BR Benjamin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QWebEnginePage and Qt 6: protected virtual functions and signals
On Thu, 27 May 2021 at 14:52, Allan Sandfeld Jensen wrote: > > Most of the changes to signal form are not that simple, and requires a lot > more work. Not even sure we will manage to deal with the mess that is > acceptNavigationRequest before feature freeze. It's easy, if you force users to use direct signal/slot connections and the handling to be done in the slot. I thought that was the case for some existing signals. Do you intend to support async handling for the new signals ? Note that I am not saying the new extendable classes should not be added. IMHO they should even be added to the old virtual protected functions. If these classes allow async handling (like QWebEngineCertificateError already does), it will be easy for users to add the signals if they need to. Anyway, my point is that signals are not equivalent to virtual protected functions. There is a semantic difference and an architectural difference. Just because you can turn virtual protected functions into signals does not mean you should. To me it is even worse than breaking ABI or source compatibility. You are breaking the architecture of user software. If the event looks like an internal behavior it should be a virtual protected function. If the event looks like something you want to tell the world about it, it should be a signal. Nice examples of that are all the QWidgets where "internal events" are implemented using QEvent and protected virtual functions, while "external events" are using signals. Back to QWebEnginePage. IMHO handling of SSL errors or navigation requests looks a lot like internal events you want to implement using virtual protected functions. For handling requests to open a new window, this can be discussed as a page might not be best placed to know how to open a new window/tab. Yet I still have an issue with using signals which are a many-to-many event system to dispatch requests that must be handled only once. Also the virtual protected functions can decide to handle the request themselves, or fallback to their parent implementation. That's something hardly doable with signals. Hence why replacing one by the other can break users software architecture. Random thoughts: Could this willingness to replace virtual protected functions by signals be linked to QML? In QML we do not have virtual protected functions and can only use signals... Regards Benjamin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QWebEnginePage and Qt 6: protected virtual functions and signals
On Thu, 27 May 2021 at 14:17, Allan Sandfeld Jensen wrote: > On Donnerstag, 27. Mai 2021 13:55:01 CEST Benjamin TERRIER wrote: > > On Thu, 27 May 2021 at 11:25, Allan Sandfeld Jensen > > > > But then in my code, each time I see a CrazySSLPage I am never sure that > it > > will ignore SSL errors. Maybe someone called QObject::disconnect() on it. > > > > CrazySSLPage page; > > page.disconnect(); // It's just a QWebEnginePage now > > If you call disconnect on a QWebEnginePage (or most advanced Qt classes) > you > have bigger problems than that, we rely on that for internal stuff too. As > a > C++ toolkit we can not protect users from doing bad things, it is always > in > their power. > Then maybe a warning should be added to: https://doc.qt.io/qt-5/qobject.html#disconnect-2 But it does not change my point about signal vs protected functions. Let's say I have a QWebEnginePage subclass that only allows some SSL errors by checking asynchronously a blocked list (using the defer() function of the QWebEngineCertificateError) External code can connect to the signal and ignore/block the error before the async check has completed, breaking the behavior of the subclass. IMHO using signals to implement the class behavior breaks encapsulation. The behavior that was protected and defined in the class, is now defined outside of the class and is publicly available to be overridden. Signals are not a replacement for virtual protected functions. I have a strong feeling that moving signals, without having the ability to block signals by implementing protected functions, will lead to brittle code for Qt users. The worse part, is that right now it is possible in user code to implement a SignalWebEnginePage, that will expose its protected functions as signals. After moving to signals, it won't be possible to not expose them. With this change, as-is, Qt users are losing features, for some convenience that they could implement themselves with a few lines of code. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QWebEnginePage and Qt 6: protected virtual functions and signals
On Thu, 27 May 2021 at 11:25, Allan Sandfeld Jensen
wrote:
>
> I am not sure I see a significant difference. They are both compile-time.
> A
> "user" of your widget could also derive it and override the virtual
> function
> just as well as they could override your the signals?
>
>
>
No, they are not both compile-time.
With virtual functions, only subclasses that are defined at compile-time
are allowed to override.
Also, it is possible to prevent overriding using the final keyword.
With signals, the behavior can be changed at any time, including run-time,
by any part of the code.
Let's say I want a page that always ignores SSL errors.
I could do:
class CrazySSLPage final : public QWebEnginePage {
protected:
bool certificateError(const QWebEngineCertificateError &) { return
true; }
};
Then in my code, each time I see a CrazySSLPage I am sure that it will
ignore SSL errors.
With signals I could have to do:
class CrazySSLPage final : public QWebEnginePage {
public:
CrazySSLPage() {
connect(this, &QWebEnginePage::certificateErrorOccured,
[this](const QWebEngineCertificateError &error) {
error.ignoreCertificateError(); });
}
};
But then in my code, each time I see a CrazySSLPage I am never sure that it
will ignore SSL errors. Maybe someone called QObject::disconnect() on it.
CrazySSLPage page;
page.disconnect(); // It's just a QWebEnginePage now
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] QWebEnginePage and Qt 6: protected virtual functions and signals
Hi, I just saw this ticket: https://bugreports.qt.io/browse/QTBUG-74587 and this related gerrit change: https://codereview.qt-project.org/c/qt/qtwebengine/+/346723 I am not sure what to think about it. Sure it is nice to be able to customize a QWebEnginePage without deriving from it, but turning all protected functions to signal seems a bit overkill and I would think it is exposing too much. And it is replacing compile-time behavior with run-time behavior. In particular, I like the ability to have my own class "MyWebEnginePage" with customized behavior. With protected functions, I can be sure that an instance of MyWebEnginePage will behave as expected, as defined at compile-time in the overridden functions. With the new API, it will always be possible to connect/disconnect signals at run-time, meaning that I have no guarantee on the behavior of a MyWebEnginePage. I'd like to suggest that we keep the old API (protected functions) and only emit a signal if its associated function has not handled the event/request. This way, users are still able to create their own MyWebEnginePage with guarantees that it will behave as defined in the class functions. Cheers, Benjamin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Renamed: Running a service for Qt community
On Fri, 21 May 2021 at 14:32, Joerg Bornemann wrote: > On 5/21/21 12:41 PM, Benjamin TERRIER wrote: > > > And now: > > - all new modules and supported platforms are Commercial/GPLv3 only. > > Which is very different from commercial-only. > Please don't cut half of what I said to make me say something I did not say. You said that during Trolltech times that Qt Windows was commercial only and the open source part was under GPL (not LGPL). I said, without being truncated: > And now: > - all new modules and supported platforms are Commercial/GPLv3 only. > - Qt 5.15.3+ is commercial only So we have some parts that are commercial only, and some parts that are open sourced only under GPL (not LGPL). Given that this no LGPL policy is applied to all new modules (except Qt 3D which was made by KDAB) and all new platforms, and that all LTS are commercial only, the part of Qt that is commercial-only or GPL-only is only going to grow. Meaning that Qt as a whole in the future might look a lot more like the Qt from Trolltech than the Qt from Nokia. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Renamed: Running a service for Qt community
On Thu, 20 May 2021 at 17:18, Jason H wrote: > > Anyway, these issues aren't insurmountable, apparently they can be changed > with the stroke of a pen. (Where is Qt's Open Governance? - still think I > misunderstood what that was about) Since TQC alone can decide that the Qt Project won't release Qt 5.15.3+ without consulting the mailing list and going through the lazy consensus decision process, I think it's safe to say that Open Governance is dead. > **What would the next milestone be? Not Qt6. It's just a version. I'd like > to see Qt take on the web, the pieces are there, with WebAssembly and > QHttpServer. The web meanwhile has gotten more Qt-like with webpack and > other compilation-step tools. I think this would really embiggen the Qt > community, but the release practices would have to be brought inline with > like, say Node's: > https://nodesource.com/blog/understanding-how-node-js-release-lines-work/ > which means no commercial-only LTS releases, or releasing an incomplete > major version. > QHttpServer and WebAssembly are GPLv3 only (like all new modules and platform support). So they will only get traction from commercial users or GPLv3 projects. TQC is cutting itself from all LGPL users who will simply use one of the many other http servers available under a more permissive license, or even just drop Qt and switch to standard web techs which are more mature that Qt WASM. On Fri, 21 May 2021 at 10:18, Joerg Bornemann wrote: > > 1. In the glorious days of Trolltech and Qt 3.3.3, the Windows port, for > example, of Qt was commercial-only. The open-source part of the dual > license was GPL. Contributions from outside the company were nearby > non-existent. > And now: - all new modules and supported platforms are Commercial/GPLv3 only. - Qt 5.15.3+ is commercial only It looks a lot like "the glorious days of Trolltech and Qt 3.3.3" Can we conclude that contributions from outside the company are going to be nearly non-existent? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6 repo
On Thu, 14 Jan 2021 at 08:21, Nibedit Dey wrote:
> Thank you everyone for the suggestions.
> I posted in the development group as there was less participation on the
> topic in the interest group.
> Below are my suggestions:
>
>- Create a clean qt6 supermodule for better maintainability. It's
>still not too late.
>- If the qt5 supermodule is renamed, then it will still have many qt5
>branches. This may create confusion while looking for specific branches.
>- The use of a script is a good idea, but it needs to be mentioned in
>the README document. Else new Qt developer or contributors may face
>difficulties while building from source.
>
>
Actually, I agree with Thiago and think that scripts to handle the branches
is a bad idea and that the current perl script should be gone.
All is required for new Qt developers is:
1. A good branch naming scheme (this we have)
2. Rely on standard git submodule mechanisms
3. A clear documentation of the branch naming scheme and branching
conventions
Adding a script only adds a black box and makes things confused. What is
the script doing? Is it doing special stuff ? Can I use a git submodule
command or will it break the magic the script did and I will have to
rebuild everything?
If the goal is to ease the entry of new developers, the use of industry
standard tools is to be favored against the use of helper scripts.
Also I can see the point of renaming the 'qt5' repo to 'qt' since it
contains Qt 6 and Qt 5, but I cannot see the point of splitting the repo in
2 ('qt5' and 'qt6').
My 2 cents
Benjamin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January
On Tue, 5 Jan 2021 at 16:55, Volker Hilsheimer wrote: > > Apart from that: is Qt 5.15.2 really so broken that people can’t use it > without getting more patches? > A quick search in Jira gives already 11 "P1: Critical" bugs with Fix Version 5.15.3. With 5 issues about crashes, 1 memory leak and 1 issue about spaces not always being rendered on macOs. I think that just the last one would qualify as "so broken that people can't use it". Well, at least for macOs users who need to display texts. Benjamin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January
Le lun. 4 janv. 2021 à 15:57, Tuukka Turunen a écrit : > > > Hi Roland, > > > > Just so that there is no misunderstanding Qt 5.15.2 release stays > available for all users, it is just the upcoming LTS phase patch releases > that will be commercial only. In essence for the open-source users Qt 5.15 > is similar to Qt 5.13 and Qt 5.14 (non-LTS releases). > It's not the same because when 5.13 and 5.14 support was dropped, 5.14 and 5.15 were released. Now even if 6.0 is officially released, a lot of modules are not yet released and won't be available before 6.1 or 6.2 is released. A lot of open source users are blocked, having no patch releases for 5.15 and no way to use Qt 6 yet. > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January
Le lun. 4 janv. 2021 à 16:06, Calogero Mauceri a écrit : > As far as I understand the next LTS release will be Qt 6.2. > If 5.15 will not receive any more patches open source users are left > without LTS till 6.2 is released. Am I correct? > > From now on, will LTS releases be available only for commercial users? > Yes. LTS is a commercial only thing now. So Qt 6.2 will be LTS only for commercial users. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January
On Mon, 4 Jan 2021 at 14:14, Oswald Buddenhagen wrote: > On Mon, Jan 04, 2021 at 10:55:03AM +, Tuukka Turunen wrote: > >With Qt 6.0.0 released and the first patch release (Qt 6.0.1) coming > >soon, it is time to enter the commercial-only LTS phase for Qt 5.15 > >LTS. > > > that's some brilliant timing, given that no actual qt 6 release even > exists yet. (yeah, 6.0 is a joke given that you intend to break binary > compat in 6.1 - that's the wisdom of linking r&d's bonus payments to > release dates even for major versions). > > Yes, it would have made sense that the Qt Company waits for all modules to be available in Qt 6 before dropping the 5.15 open support... Also some patches have already been merged between the 5.15.2 and today. I am thinking about this one in particular: https://bugreports.qt.io/browse/QTBUG-88688 which is a regression from 5.15.1. I find it kind of weird to release 5.15.2 let some patches in and then lock the branches in the middle of the 5.15.3 development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Making Binary Incompatible Changes after Qt 6.0
On Wed, 9 Dec 2020 at 10:17, Alexander Nassian < nass...@bitshift-dynamics.com> wrote: > 4) Don‘t release a major version that lacks half of the modules of the > prev version in a hurry for no reason. > Especially just after deciding to remove the concept of LTS for open source users, effectively creating a 1 year gap between 2 equivalent releases of Qt (5.15.2 -> 6.2.0). Back to the topic, wouldn't it be acceptable to break BC before 6.2 release? I mean Qt 6 isn't really complete until 6.2, so if a break is required it kind of makes sense to make it happen before everyone has made the switch from Qt 5 to Qt 6. My 2 cents Benjamin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Making Binary Incompatible Changes after Qt 6.0
On Tue, 8 Dec 2020 at 17:44, Volker Hilsheimer wrote: > > > > On 8 Dec 2020, at 16:28, Thiago Macieira > wrote: > > > > On Tuesday, 8 December 2020 01:55:12 PST Giuseppe D'Angelo via > Development > > wrote: > >> Raising the bar: apart from some cases of API problems in 6.0, would it > >> be feasible to do a BC break after every LTS? We might find more > >> annoyances we want to fix. > > > > So long LTSs don't happen more often than every 4 years. > > Hm, every third release is an LTS: 5.9, 5.12, 5.15, perhaps 6.2. > > So, that’s every 1.5 years if we stick to the current release cadence. > > As a Qt developer I find this very tempting. But it also means that the > whole world has to rebuild all the Qt things every 18 months, which is > perhaps not great from an eco-system perspective. > > > > Aren't LTS a commercial only thing now? So doing a BC after an LTS isn't much different than doing it after any other version for distro maintainers and the open source world in general. Benjamin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Status of QWebEngine
On Mon, 21 Sep 2020 at 14:10, Allan Sandfeld Jensen wrote: > > Use the SHA1s in dependencies.yaml > > That's not very practical to do by hand, but it worked. Thanks ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Status of QWebEngine
Hi, I am trying to contribute to the dev branch of qtwebengine, but I cannot get it to compile with Qt 5.15.1 or with Qt 6 preview. With Qt 5.15 the compiler complains that `QWebEngineCertificateError` does not have a default constructor (required because of `Q_DECLARE_METATYPE(QWebEngineCertificateError)`). And with Qt 6 the compiler complains that QStringList is being declared with `using` in qtcontainerfw.h: using QStringList = QList; and as a class in pref_service_adapter.h: QT_FORWARD_DECLARE_CLASS(QStringList) So which version of Qt should I be using to build qtwebengine dev? Thanks Benjamin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Fri, 28 Feb 2020 at 10:35, Edward Welbourne wrote: > > > Indeed; most of the case for "emit" can be answered by a sensible naming > convention. > One case where it does not work is in connections. emit somethingWasDone() and emitSomethingWasDone() look similar. But the emit in connect(obj, &MyClass::emitSomethingWasDone, ...) looks a bit superfluous to me. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On Fri, 21 Feb 2020 at 09:24, Kai Köhne wrote: > Hi, > > Another alternative is to actually use C++ attributes for this: > > [[qt::emit]] somethingChanged(); > > C++ attributes are required since C++11, and since C++17 the compiler is > also required to just ignore one's it doesn't know [1]. Because it is part > of the core language, It is also something every C++ IDE and tool does > accept (and could even check for) ... > I would like the idea of using attributes for this. However, compilers are allowed to warn for unknown attributes, which is useful to detect typos. This means that we would get a warning for each usage of [[qt::emit]]. So unless there is a way to disable unknown attribute warnings for a specific set of custom attributes this will be a pain. My 2 cents Benjamin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
On Wed, 29 Jan 2020 at 17:02, Volker Hilsheimer wrote: > > On 29 Jan 2020, at 15:20, Benjamin TERRIER wrote: > > On Wed, 29 Jan 2020 at 14:10, Cristián Maureira-Fredes < > cristian.maureira-fre...@qt.io> wrote: > >> > >> but for Windows/macOS this might have three solutions (maybe more): > >> - Using package managers that provide Qt, > >> - Download and compile Qt by themselves, > >> - Create an account and use the installer. > > > > > > How is any of these a solution to the fact that your a putting a barrier > for new users? > > These are just 3 bad solutions to a problem that did not exist yesterday > and that we have to deal with > > because you removed the 2 main points of entry for new Qt users: the > offline installer and > > the non-privacy-violating online installer. > > Hm, if the problem didn’t exist, then why did the solutions exist? Package > managers on Windows and macOS provide Qt in the past, after all, and > > $ sudo apt-get install -y qtcreator > PS C:\Users\vohi> choco install qtcreator > $ brew install qt-creator > > give me a Qt development environment on Linux, Windows, and macOS. > That's a case of "I do it THIS way, why is anyone caring about THAT way?". Well guess what, not everybody wants to use the Qt/QtCreator version that comes from their package manager or wants to build Qt/Qt Creator on their machine, especially given Qt compile time. Also this type of arguments is meaningless. If the installers have no value why does TQtC is making them a commercial only feature? Why have we had them for years? Why are people, on this mailing list, discussing which toolchains should be covered by the installers? The answer is simple. These installers are used by a lot of people and they bring value. And everyone knows that, otherwise TQtC would not make them commercial only and the open source users would not be complaining. > You obviously don’t trust that TQtC will treat the data the > online-installer either demands or requires with the appropriate > confidence. So, shouldn't you build Qt from sources? Your IP address is > PII, after all. Why did you trust that The Qt Company didn’t collect > personal data from you previously - just because you didn’t have to enter > your email address? > > That's not the issue. Do not make me say what I have not said. I have a Qt Account, I have used it on Jira and Gerrit. It is not a matter of whether I trust the Qt Company with my email or not. I have no issue of making an account for pushing commits and creating Jira issues. Because it is a fair requirement. In the same way I accept to share my IP address with websites I visit. Because it is a fair requirement. However, I do not see why I should provide my email to download binaries of an open source project and I think this is abusive. Also it is not a matter of thinking that TQtC was not collecting data from me. They surely have some data on me and can surely associate some of the downloads I made with my email address through my IP address. But they surely cannot associate ALL downloads I made with me and I do not see why they should be able to do so. And even if I was OK with the Qt account thing *for me*, I know that other people do not agree and will try to find a way to make their own installers. This will arm the community and how people see Qt. And I cannot be OK with this. BR, Benjamin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
On Wed, 29 Jan 2020 at 14:10, Cristián Maureira-Fredes < cristian.maureira-fre...@qt.io> wrote: > > but for Windows/macOS this might have three solutions (maybe more): > - Using package managers that provide Qt, > - Download and compile Qt by themselves, > - Create an account and use the installer. > > How is any of these a solution to the fact that your a putting a barrier for new users? These are just 3 bad solutions to a problem that did not exist yesterday and that we have to deal with because you removed the 2 main points of entry for new Qt users: the offline installer and the non-privacy-violating online installer. > Good thing that you replied in any case, > because I really think we should separate the different use cases: > > - For people already using Qt, with Qt accounts, > that's not a problem. > This, and a lot of what TQC employees are saying on these changes, does sound like the famous sentence from Don Mattrick about the Xbox One: "We have a product for people who aren't able to get some form of connectivity; it's called Xbox 360." Back to the topic, I have a Qt account, I do NOT want to use it to install Qt. I am pretty sure we will have community provided offline, and even maybe online, installers soon enough. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
On Tue, 28 Jan 2020 at 17:37, Volker Hilsheimer wrote: > > > The Qt Company is a public company; we are not yet profitable, but things > are getting there. Given how significant the Qt Company contribution to Qt > is, making it a sustainable business should be in the interest of anyone > that wants to see Qt continue to be a successful and evolving technology. > > Making backporting of fixes to old branches a commercial-only service is > an attempt to encourage more companies that are basing their business on > Qt-based software to contribute with funding. Ideally without antagonizing > the community, but that’s obviously a difficult balance to strike. > > Would making Qt cheaper make it more likely that the Qt Company becomes a > sustainable business? Would giving a few licenses out for free to > contributors help with that? I doubt it would make much of a difference. > > Should we turn the Qt Company into a business for which Qt becomes a > secondary priority, and where we develop Qt only as a means to an end > (which would be the kitware business model)? I really don’t think that > would serve Qt very well. > > Maybe you all have great ideas that we missed though. What kind of change > do you think would give companies a really good reason to buy a license, > without at the same time hurting the community? > >From my experience and what I glimpsed from online communities: - Offer a paid support service without having to buy a commercial license - Remove the prohibitive cost of moving from open source to commercial. - To my best knowledge the Qt Company is asking a retroactive fee for all the time the open source version was used. - Change your pricing. Offer small subset of features at lower price. Each time I was in a company using Qt and we asked ourselves if we want to move from open source to commercial it was because of a single feature was missing. Each time we compared the cost of buying Qt licenses (not even talking about the retroactive fees) vs using something else, we used something else. Typical example: a project need to draw charts. Can we use Qt Charts ? No because it is GPL only. Do we buy a Qt license or use Qwt ? We use Qwt. I understand that the price of Qt licenses, if expensive, is matching what the full Qt commercial offering is providing. But my experience is that people are interested in a single feature and the expense cannot be justified for a single feature. I am not sure that taking from the community features like the offline installers, which are just nice to have, but does not justify buying Qt will bring you more costumers. Even worse, you risk that the community will roll out their own offline installers and in the end the community will be unhappy of TQC and TQC will have 0 new costumers coming for the offline installers. - - - Bring stability. Stop changing your offerings and policies. - You has a Qt for mobile app offer and removed it some months. You know have a Qt for startups offer, how many people won't buy it because they think it will go the same way. You offered LTS, and 3 LTS later it's gone for open source users. You are making people worried for the future of Qt and more and more I see people looking for alternatives for this reason. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
Le mar. 28 janv. 2020 à 03:22, Thiago Macieira a écrit : > On segunda-feira, 27 de janeiro de 2020 14:47:46 PST NIkolai Marchenko > wrote: > > Assuming we have a VM that is restricted to connecting to the internet, > we > > previously could dump the installer there and install Qt. > > Now, we need to have an intermediary PC with the same OS to first install > > the binaries via online installer and then copy those binary files to > that > > first VM. > > > > This is an extraneous and completely artificial step for absolutely no > > reason other than TQtC paywalling them, which is ridiculous. > > Previously, you anonymously downloaded the offline installer from another > machine, then copied it over to the VM, and installed there. > > Now you're going to download the offline installer from another machine > after > typing your password, then copy over to the VM and install there. > > What's the hurdle? > You might have missed the info because it is in the blog post, but not in Lars email: There will be no more open source offline installer. For binaries, open source users will only have access to the online installer that will require a Qt Account. > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
On Mon, 27 Jan 2020 at 23:23, Ville Voutilainen wrote: > > Correct. Necessary for specific purpose seems to be what article 5 > requires, and then you get explicit consent for that > specific purpose, and GDPR's articles 5 and 6 are covered (of course > the rest of article 5's requirements need to be covered). > You're not necessarily going to like that specific purpose (or the > outcome of all this, including the consent query), > but GDPR requirements don't seem too difficult to fulfil, and there's > nothing particular in the new offering that would > instantly and obviously go even close to violating GDPR, based on my > layman reading of it. I don't think GDPR > will change the course of the offering, so if you want to change that > course, I think you need a different avenue > of argumentation. > Well it depends on how you interpret the GDPR, a strict interpretation is that since The Qt Company does not technically needs email addresses to distribute binary packages, requiring users' email addresses does violates the GDPR. A loose interpretation is that The Qt Company does require the email addresses for its business model and it is enough to be GDPR compliant. I guess we will not know which is the correct one until there is a trial with a ruling of the CJEU. Until then I do not see the GDPR changi any company business model and offering. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
On Mon, 27 Jan 2020 at 23:29, Ville Voutilainen wrote: > On Tue, 28 Jan 2020 at 00:17, Cristián Maureira-Fredes > wrote: > > > > Hello David, > > > > On 1/27/20 11:00 PM, David Edmundson wrote: > > >> All security fixes are made available to everyone, for all Qt > versions that > > >> they affect, provided it's still a supported Qt version (or it was > easy to > > >> make the fix). > > >> > > > If we could have that explicitly in writing from TQC, that would mean > a lot. > > > > The blog post states: > > > > "We are changing our process in R&D to push all bug fixes to the main > > development branch first, and then backport selected bug fixes back into > > stable release branches. This process ensures that the latest version of > > Qt will always contain all bug fixes. This process change was discussed > > during the last Qt Contributor Summit – we communicate the exact process > > details when Qt 5.15 will be released. Otherwise, development processes > > and the governance model will not change." > > > > This means that you still have access to all the fixes for 5.15 > > that happen after 5.15.2-3, since they will be on the dev branch. > > The dev branch bug fixes don't necessarily apply cleanly to 5.15. > > > > I can easily envision a situation that affects only Qt5.15, but not > > > Qt6.0 at which point it's not covered by what has been suggested > > > officially so far as there would be nothing to cherry-pick. > > > > > > David > > > > If there is a bug on 5.15 and not on 6.0, > > a fix will be pushed to the dev branch, then cherry pick to the > > commercial LTS version, but the patch will still be there, so you > > can just added to your local Qt version. > > And this sort of fixes might also not apply cleanly, or even exist at > all, if 6 doesn't have the bug. > 6 is dev, dev is 6, dev is not some perpetual 5.x+6.x upstream master > branch. > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development The wiki states that "5.15 is 'dev' in the Qt 5 series", so my understanding is that all fixes, even those for the commercial LTS will need to go through the public 5.15 branch. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
On Mon, 27 Jan 2020 at 22:56, Ville Voutilainen wrote: > On Mon, 27 Jan 2020 at 23:43, Benjamin TERRIER > wrote: > > >> I know, but since there's no free right to download binaries, GDPR > >> doesn't prevent getting explicit consent before allowing > >> a download. Would you like me to give people more ideas? :) > > GDPR states that data collection shall be "limited to what is necessary". > > Requiring explicit consent for the user to provide data is not enough to > be GDPR compliant. > > The required data has to be "necessary". > > That is one of six lawful bases for processing data. There are five > others. GDPR doesn't require all six > to apply, it requires at least one. > I believe you are talking about article 6, I am talking about article 5 which does not have this "at least one" clause. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
On Mon, 27 Jan 2020 at 22:35, Ville Voutilainen wrote: > On Mon, 27 Jan 2020 at 23:12, André Somers wrote: > > > > > > On 27/01/2020 22:07, Ville Voutilainen wrote: > > > On Mon, 27 Jan 2020 at 21:56, Dmitriy Purgin > wrote: > > >> By the way, gathering emails by requiring an account to download the > software without any technical reason might be indeed an example of a GDPR > violation. > > > I am not a lawyer, but I am unaware of any free software license that > > > gives you a right to download binaries at the terms > > > of your own choosing. Source downloads are a different matter. > > > > GDPR has nothing to do with software licenses. > > I know, but since there's no free right to download binaries, GDPR > doesn't prevent getting explicit consent before allowing > a download. Would you like me to give people more ideas? :) > GDPR states that data collection shall be "limited to what is necessary". Requiring explicit consent for the user to provide data is not enough to be GDPR compliant. The required data has to be "necessary". ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
I've had a Qt account for years, it doesn't change that I do not want to use it to download a Qt version. It is obvious that that in the world that we live today having an account > for a service is not a blocker for people in general. > Qt users are not "people in general", they are software developers and they understand that this is an artificial barrier. I hope all software developers understand that they should not need an authenticated access to download public tars of an open source project. we believe that we provide value to our users through the installer and the > Qt Marketplace to justify the Qt Account. > Do all Qt users have value in the Qt Marketplace? For open source user, I am pretty sure the answer is no. For commercial/company users, I doubt all developers need access to the marketplace. What does the installer brings now that was not their in 2015 ? Nothing. So it was a bad idea in 2015, and still is a bad idea. On a more general note. It seems you are trying to make money by taking feature from the open source versions (like the offline installer). What you take really hurts the usage of open source users and hurts the Qt community. But at the same time I am not sure these small features will justify buying a license that cost several thousand dollars per seat. Especially when company that want to move from open source to commercial have to pay a prohibitive retroactive license fee. It is cheaper and faster to make your own offline installer. Le lun. 27 janv. 2020 à 17:25, Tuukka Turunen a écrit : > > Hi, > > Well, quite many things have changed since 2015. One important item is > that almost one million users have already voluntarily created (and > verified) themselves a Qt account. > > See the FAQ (linked from the blog post): > > “Q: Will requiring the Qt Account drive away all Qt users? > A: We have had the Qt Account as an option for over 4 years, and during > that time there has been already nearly a million people who have > registered and verified their Qt Account. It is obvious that that in the > world that we live today having an account for a service is not a blocker > for people in general. Everyone has the option of building Qt from sources > if they do not like the installer, but we believe that we provide value to > our users through the installer and the Qt Marketplace to justify the Qt > Account.“ > > Yours, > > Tuukka > > -- > *Lähettäjä:* Development käyttäjän > Benjamin TERRIER puolesta > *Lähetetty:* maanantaina, tammikuuta 27, 2020 6:03 ip. > *Vastaanottaja:* Qt development mailing list > *Aihe:* Re: [Development] Changes to Qt offering > > Quoting The Qt Company itslef: > > Thanks for your feedback to the new online installer asking for a Qt >> Account signup. We have evaluated the feedback received via the blog, >> various discussion forums, irc and other channels. Based on all these >> comments and discussions with our partners we realize that this was not our >> finest moment. >> Preventing the growth and usage of Qt in the open source community is not >> what we want to happen. We did already see a nice jump in the number of Qt >> Accounts, >> but it was never our intention to make our valued community and >> contributors upset with us or stop using and contributing to Qt. >> *We clearly ill-calculated how asking for a Qt Account with the online >> installer would make our users feel*. A mistake. Sincere apologies. >> > [...] >> *We do hope that this eases your concerns, and that we can continue with >> your trust*. >> >> >> >> https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer >> > > So apparently the trust of the QT community os nt a concern anymore... > > Le lun. 27 janv. 2020 à 15:42, NIkolai Marchenko > a écrit : > >> I am afraid I do not have other words for this model than : absolutely >> disgusting and a complete dick move. Especially login requirement for >> binaries. >> I don't even understand how distros are now supposed to keep qt code safe >> since constantly pushing qt version up is recipe for problems and there >> will be no critical bugfixes to branches that distros were stabilized at. >> >> >> On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll wrote: >> >>> Hi all, >>> >>> The Qt Company has done some adjustments to the Qt will be offered in >>> the future. Please check out >>> https://www.qt.io/blog/qt-offering-changes-2020 . >>> >>> The change consists of three parts. >>> >>> One is a change in policy regarding the LTS releases, where the LTS part >>&g
Re: [Development] Changes to Qt offering
My understanding of the agreement between The Qt Company and the KDE Free Qt Foundation is that if the Qt Company releases a commercial Qt version without releasing the corresponding open-source version within 12 months, the ownership of Qt will be transferred to the KDE Free Qt Foundation under a BSD license. (section 3.(ii)). I am pretty sure a source only release would be enough. So I bet that the LTS branches will be public, but we will not have a binary release through the installer. Le lun. 27 janv. 2020 à 17:17, Bogdan Vatra via Development < development@qt-project.org> a écrit : > Hi Lars, > > În ziua de luni, 27 ianuarie 2020, la 16:34:44 EET, Lars Knoll a scris: > > Hi all, > [...] > > > > One is a change in policy regarding the LTS releases, where the LTS part > of > > a release is in the future going to be restricted to commercial > customers. > > All bug fixes will (as agreed on the Qt Contributor Summit) go into dev > > first. > > I was at the Qt Contributor Summit, and I can swear that I not heard > anything about LTS being restricted to commercial customers... > > Just to be crystal clear, will you close also the branches? > What will happen if I want to fix something in one of these LTS branches? > > > Backporting bug fixes is something that the Qt Company will take > > care of for these LTS branches. We’ve seen over the past that LTS support > > is something mainly required by large companies, and should hopefully > help > > us get some more commercial support for developing Qt further. > > I bet you the following scenario will happen soon: > - someone will fork Qt LTS (most probably immediately after you closed > these > branches, if not even sooner) > - the community will continue to support that fork as it's open, with > improvements, bug fixes, security patches, etc. > - you'll not get these patches as they are not contributed via your > gerrit... > > > > None of these changes should affect how Qt is being developed. There > won’t > > be any changes to Open Governance or the open development model. > > If the qt5 branches will NOT be closed, then yes, you are right, if they > will > be closed then, I'm afraid, your statement can't stand... > > Cheers, > BogDan. > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
Quoting The Qt Company itslef: Thanks for your feedback to the new online installer asking for a Qt > Account signup. We have evaluated the feedback received via the blog, > various discussion forums, irc and other channels. Based on all these > comments and discussions with our partners we realize that this was not our > finest moment. > Preventing the growth and usage of Qt in the open source community is not > what we want to happen. We did already see a nice jump in the number of Qt > Accounts, > but it was never our intention to make our valued community and > contributors upset with us or stop using and contributing to Qt. > *We clearly ill-calculated how asking for a Qt Account with the online > installer would make our users feel*. A mistake. Sincere apologies. > [...] > *We do hope that this eases your concerns, and that we can continue with > your trust*. > > > > https://www.qt.io/blog/2015/05/06/changing-qt-account-to-be-optional-in-the-online-installer > So apparently the trust of the QT community os nt a concern anymore... Le lun. 27 janv. 2020 à 15:42, NIkolai Marchenko a écrit : > I am afraid I do not have other words for this model than : absolutely > disgusting and a complete dick move. Especially login requirement for > binaries. > I don't even understand how distros are now supposed to keep qt code safe > since constantly pushing qt version up is recipe for problems and there > will be no critical bugfixes to branches that distros were stabilized at. > > > On Mon, Jan 27, 2020 at 5:35 PM Lars Knoll wrote: > >> Hi all, >> >> The Qt Company has done some adjustments to the Qt will be offered in the >> future. Please check out https://www.qt.io/blog/qt-offering-changes-2020 >> . >> >> The change consists of three parts. >> >> One is a change in policy regarding the LTS releases, where the LTS part >> of a release is in the future going to be restricted to commercial >> customers. All bug fixes will (as agreed on the Qt Contributor Summit) go >> into dev first. Backporting bug fixes is something that the Qt Company will >> take care of for these LTS branches. We’ve seen over the past that LTS >> support is something mainly required by large companies, and should >> hopefully help us get some more commercial support for developing Qt >> further. >> >> The second change is that a Qt Account will be in the future required for >> binary packages. Source code will continue to be available as currently. >> This will simplify distribution and integration with the Marketplace. In >> addition, we want open source users to contribute to Qt or the Qt >> ecosystem. Doing so is only possible with a valid Qt Account (Jira, code >> review and the forums all require a Qt Account). >> >> The third change is that The Qt Company will in the future also offer a >> lower priced product for small businesses. That small business product is >> btw not limited to mobile like the one Digia had some years ago, but covers >> all of Qt for Device Creation. >> >> None of these changes should affect how Qt is being developed. There >> won’t be any changes to Open Governance or the open development model. >> >> Best regards, >> Lars >> >> ___ >> Development mailing list >> Development@qt-project.org >> https://lists.qt-project.org/listinfo/development >> > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Interest] XCB clipboard freeze
Le mar. 5 nov. 2019 à 17:39, Thiago Macieira a écrit : > > Probably *because* events would be processed during the wait. We all know > nested event loops are bad design. In this case, this stems from another > bad > API design: the clipboard handled synchronously, when it clearly isn't. > > Note: I don't know the QClipboard API. This could be just the backend, in > which case my explanation is wrong and the QXcbClipboard should be > refactored > to operate reactively. As Linux kernel core developer Alan Cox said, > "threads > are for people who can't program a state machine". > > I worked a little bit on QXcbClipboard and I was able to make it work asynchronously. This solves my issue of freezing. However, since the QClipboard API is synchronous there is no place and time to make the asynchronous work when the user is requesting content. So my solution is to fetch the clipboard content asynchronously when Qt receives clipboard events from X11. The drawback is that whenever a user copy something to the clipboard, the Qt application will automatically fetch this something and therefore consume memory to store the content. This might be a negligible issue when copy/pasting short texts, but this will certainly be an issue if when someone copies a 100MB image, all the Qt applications allocate 100MB. I guess unless we change QClipboard API to make it async (like in GTK) I do not see how to solve this issue. BR Benjamin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Google Summer of Code
2018-02-13 17:22 GMT+01:00 Thiago Macieira : > > On terça-feira, 13 de fevereiro de 2018 04:13:20 PST Frederik Gladhorn wrote: > > Hi all, > > > > The Qt Project has been accepted as mentor organization for GSoC. Yay! > > https://summerofcode.withgoogle.com/organizations/5388456415461376/ > > That reads "The Qt Company", not "The Qt Project". > > > We now should collect ideas for projects that students could work on, we > > started here: > > https://wiki.qt.io/Google_Summer_of_Code/2018/Project_Ideas > > Would've been nice to be told we were applying, so we could contribute to the > ideas list. > That's because according to the Qt Project governance model, if the mailing list has never been informed that the Qt Project was applying, then the Qt project was not applying. So it looks to me that the Qt Company applied for the Qt Project. Or am I missing something? Anyway that's a great idea, and I like the idea of an IncludeOS port of Qt. Is there some decisions already made about the licensing of the contributions? Like, are contributions going to be released under GPL/LGPL/Commercial license like most of Qt, or are they going to be GPL/Commercial only? Regards, Benjamin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [FYI] the new way to retarget gerrit changes
2018-01-10 11:23 GMT+01:00 Oswald Buddenhagen : > On Wed, Jan 10, 2018 at 10:37:25AM +0100, Benjamin TERRIER wrote: > >What happens if the change already exists in the target branch? > > > the system would tell you to contact an admin if you tried nonetheless. > > >[3]https://codereview.qt-project.org/#/c/214657/ > > > it's gone. Thanks! I tried the bot command, it worked like a charm. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [FYI] the new way to retarget gerrit changes
2018-01-09 19:09 GMT+01:00 Oswald Buddenhagen : > On Tue, Jan 09, 2018 at 04:42:51PM +0100, Robert Löhning wrote: > > Will changes keep their approvals or will those be lost so that > > approvers have to give them again on the new branch? > > > this implementation calls the same underlying script as i do manually, > so nothing changes. Hi, What happens if the change already exists in the target branch? As a real example I have https://codereview.qt-project.org/#/c/197888/ that should be retargeted to the dev branch. However, as I am quite new to gerrit I have made the mistake to push to dev thinking it would retarget, but effectively creating a new change: https://codereview.qt-project.org/#/c/214657/ Regards, Benjamin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How is Quick Controls 2 deployment meant to be ?
2017-07-08 21:16 GMT+02:00 Massimo Callegari via Development : > > > The fact that something is a 'text' file does not make it different, > > permissions make a difference. > > True, but this discussion moved specifically to Linux, while what I mentioned > in the first place was Windows, which is sadly still the most used platform > in the world. The same applies to Windows (since Vista I think). Standard users do not have write access in system critical folders including "Program Files" and Admins will only have access after a UAC prompt. That's why some software install themselves in user's AppData when the user does not have admin rights. Benjamin Terrier ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal for Qt 5.10 platforms and configurations changes
2017-04-28 14:23 GMT+02:00 Thiago Macieira : > On Friday, 28 April 2017 03:56:22 -03 Jani Heikkinen wrote: >> Yes, MSVC 2017 is already supported in Qt 5.9 and we are trying to get >> pre-built binaries available before final release; let's see if we can >> make it happen > > I remember a discussion about whether we needed MSVC 2017 binaries in the > first > place, since they're binary compatible with MSVC 2015 and we don't have > "win32-msvc2015" anymore, which concluded we did. I don't remember the reason. > > Does anyone? I recall this (it's from you): > We can't drop it from the CI. I don't think we can drop it from the build > packages either, since usually you compile with the oldest you plan to use. So > if you're correct and VS2017 is binary-compatible, then we are already > providing the packages for VS2017. http://lists.qt-project.org/pipermail/development/2017-February/028768.html BR, Benjamin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] SIGFPE in QQuickMenu and QBasicDrag
Hi, I've started to work on a patch to fix QTBUG-45045 (https://bugreports.qt.io/browse/QTBUG-45045). The main issue is that the cursor position is compared to "int(qInf())" to check its validity. However casting infinity to int is undefined behavior and in some cases can trigger a SIGFPE and crash the process. For most users this generally does not happen because floating points exceptions are masked by default for x86 and x86_64 cpus. To fix this, the naive solution would be to replace "int(qInf())" by "std::numeric_limits::min()" as these two expressions evaluate to the same value (when SIGFPE is not triggered), but this does not solves the underlying issue. It seems the issue comes from the fact that "QPointF QGuiApplicationPrivate::lastCursorPosition" is initialized to "QPointF(qInf(), qInf())", so when "QCursor::pos()" is called and there is no screen and no cursor position was ever recorder, the value "QPointF(qInf(), qInf()).toPoint()" is returned. And because of the way "QPointF::toPoint()" is implemented, this is the same as "QPoint(qRound(qInf()), qRound(qInf()))" and "QPoint(int(qInf()), int(qInf()))". So in a way it makes sense to check against "int(qInf())" later in the code, except it is still undefined behavior. IMHO a solution could be to change "QPointF::toPoint()" so that for each coordinate -infinity is casted to std::numeric_limits::min() and +infinity is casted to std::numeric_limits::max(). What do you think about this? BR Benjamin Terrier ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] invokeMethod() with function pointers
Hi, I'd like to get this in before 5.9 FF. The current state is: - It works for member functions, function pointers and functors - It soft breaks existing code that were passing null literals. - The new functions do not accepts any arguments, users have to use lambda - The new functions do accept an optional return argument in the form "ReturnType *" (without using Q_ARG), the type is checked during compilation for function pointers (member or not) using QtPrivate::FunctionPointer. I am not sure for functors though as QtPrivate::FunctionPointer does not work in this case, but QFunctorSlotObject ensure that the actual return type of the functor can be assigned to a ReturnType. What must be done: - Add documentation - Complete auto tests - Optionally, remove the "ReturnType *" argument and for users to use lambda with capture. This remove the need to check for return in case of queued connection, but add the responsibility for the user to ensure the lifespace of variable captured by reference to sill be valid when the lambda is executed. - Optionally, move the function pointer/lambda to the last argument position. This can make nicer code when using lambda, at the cost of having to provide more overloads instead of using optional arguments. I would appreciate if any of you could check the gerrit change ( https://codereview.qt-project.org/#/c/182339/) and provide feedbacks, especially if there is anything that would require a major change of the current state. Also, I'd like to get more opinions about the 2 optional changes. Thanks. Regards, Benjamin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] invokeMethod() with function pointers
2017-01-20 3:01 GMT+01:00 Thiago Macieira : > Because it's a template, so the template when Func = char* matches better than > the overload with const char*. I assume that using nullptr without casting > also breaks, correct? Correct. > From what you explained, this will not affect the case when the pointer is a > const char *, so neither > > const char *func = "deleteLater"; > QMetaObject::invokeMethod(&obj, func); > > nor > > const char *func = nullptr; > QMetaObject::invokeMethod(&obj, func); > > will stop compiling. So if you add an overload taking a non-const char* (and > its unit test), we also catch the even more dubious code: > > char func[] = "deleteLater"; > QMetaObject::invokeMethod(&obj, func); > > The only case that would break would be for a constant null pointer literal, > which in my opinion is acceptable, since it should never happen in real code. As an alternative to adding "char *" overload, it seems that replacing "std::is_same" by "std::is_same" in the "QtPrivate::QEnableIf" part of the template solves the issue for char * and const char *. Also I have checked QTimer and QTimer::singleShot(0, &obj, (char *)0); doesn't compile because the "wrong" overload is chosen. Removing the const in the std::is_same should also fix this. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] invokeMethod() with function pointers
Hi, I've got an issue. Adding template static typename QtPrivate::QEnableIf::IsPointerToMemberFunction && QtPrivate::FunctionPointer::ArgumentCount == -1 && !std::is_same::value, bool>::Type invokeMethod(QObject *object, Func function) to QMetaObject breaks existing code and the auto tests in particular. In tst_qmetaobject.cpp there is this test: QVERIFY(!QMetaObject::invokeMethod(&obj, 0)); because the new overload of invokeMethod() gets called this lead to compilation error instead of just returning false at run-time. To solve the issue one must add an explicit cast like so: QVERIFY(!QMetaObject::invokeMethod(&obj, (const char*)0)); Note that casting to "char *" does not solve the issue. Is this "source break" acceptable (it might be looking at "Source break policy for function overloads" discussion and quip 6) and the autotests should be fixed? Or should another solution be found (Thiago proposed to use a different name in QTBUG-37253)? Thanks Regards, Benjamin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] invokeMethod() with function pointers
2017-01-16 10:34 GMT+01:00 Olivier Goffart : > On Samstag, 14. Januar 2017 17:28:01 CET Benjamin TERRIER wrote: > > Hi everyone, > > > > I'm trying to contribute by making QMetaObject::invokeMethod() take > function > > pointers instead of function names. > > > > I've come up with something that works by looking at the code of > > QMetaObject::invokeMethod, QObject::connect and QMetaObject::activate. > > Thanks for your contribution. > > What's the use case for this function? For direct call you better of > calling > the function directly, and the equivalent of QueuedConnection can be > achieved > with QTimer::singleShot. > Nevertheless, i guess it's worth adding for the sake of consistency. > Talking for me here, I use QMetaObject::invokeMethod() to call slots of QObject accross threads. I could make use of the new form to call any function (not only slots) and to have some checks during compilation. The QTimer solution could work, but you cannot add parameters without using std::bind. However, I don't really like QGenericArgument which forces to use Q_ARG. > This > was just a workaround back in the Qt 4 days, around the lack of template > member function and variadic template. Since we know the arguments of the > slot > at compile time, it would be much nicer to pass the arguments directly. > Agreed. I've got something working with variadic templates, I'll update the change later. But for consistency, it should stay in QMetaObject, I'd say. We might need > to > move a few more things to qobjectdefs_impl.h to make it happen. Can this be done in the same commit? Or do I need to make 2 changes? Benjamin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] invokeMethod() with function pointers
2017-01-14 18:42 GMT+01:00 Thiago Macieira : > > No one can see it while it's a draft. You have to publish the change. > > Ok, it's done. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] invokeMethod() with function pointers
Hi everyone, I'm trying to contribute by making QMetaObject::invokeMethod() take function pointers instead of function names. I've come up with something that works by looking at the code of QMetaObject::invokeMethod, QObject::connect and QMetaObject::activate. However it does not check for parameters and it is implemented as a function of QObject (because I needed QSlotObjects classes which are not available in qobjectdef.h). It can handle QObject member functions and functors in which case "this" is used to select the event loop (like connect() functions). I've uploaded my change as a draft on gerrit: https://codereview.qt-project.org/#/c/182339/ Here is the link to the relevant bug report: https://bugreports.qt.io/browse/QTBUG-37253 I welcome any comment and feedback. BR, Benjamin Terrier ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] A new approach for Qt main()
2016-12-12 10:56 GMT+01:00 Mark De Wit : > I have an application based on qt-solutions qtwinmigrate sample. > > Because we're integrating Qt into an existing MFC application, we're not even > running QApplication exec. The application uses MFC's entry point for > startup and drives the Qt event loop manually as part of the MFC event loop. > > Mark I also did something like that on Linux with a software written with another graphical framework. We made it work by calling QApplication::processEvents() in the other framework event loop. Benjamin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.8.0 Beta packages available for testing
2016-10-25 16:53 GMT+02:00 Thiago Macieira : > > Em terça-feira, 25 de outubro de 2016, às 16:42:43 PDT, Benjamin TERRIER > escreveu: > > I just found a bug in 5.8 which make "impossible" to build Qt with MSVC on > > French systems: > > > > https://bugreports.qt.io/browse/QTBUG-56731 > > > > There is a workaround though: fix qconfig.pri after running configure. > > > > On a side note this bug might cause side effects on English systems as > > QT_CL_MAJOR_VERSION and QT_CL_PATCH_VERSION may not be properly set. > > > > Best regards, > > Should be fixed by https://codereview.qt-project.org/172928, which landed in > 5.6 as 6851cf52afe188e94344ce22074af97e054f5896 but hasn't made its way to 5.8 > yet. This patch fixes tools\configure\environment.cpp However in 5.8 the fixed line does not exist anymore in this file, but the same regexp appeared in configure.pri (which is a new file compared to 5.6). So the same fix should be applied to configure.pri, but at 2 places (see bug report). I guess it is because of the new configure system. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.8.0 Beta packages available for testing
Hi, I just found a bug in 5.8 which make "impossible" to build Qt with MSVC on French systems: https://bugreports.qt.io/browse/QTBUG-56731 There is a workaround though: fix qconfig.pri after running configure. On a side note this bug might cause side effects on English systems as QT_CL_MAJOR_VERSION and QT_CL_PATCH_VERSION may not be properly set. Best regards, Benjamin Terrier 2016-10-24 15:09 GMT+02:00 Jani Heikkinen : > Hi all, > > We have finally (almost) full set of Qt 5.8.0 beta installers for testing > > > > windows: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/627/ > > mac: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/521/ > > linux: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/553/ > > src: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/latest_src/ > (submodules are just copied so mirroring is still ongoing) > > > > Packages are RTA tested & seems to be pretty much OK so please test the > packages and make sure all blockers are visible in blocker list ( > https://bugreports.qt.io/issues/?filter=17924 ) > <https://bugreports.qt.io/issues/?filter=17924>. All known blockers > should be fixed in these packages so these will be released as Qt 5.8.0 > beta if no new blockers found during testing. > > > > Packages are based on https://codereview.qt-project.org/#/c/174531/ > > > > br, > > Jani > > ___ > 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] QUuid documentation
Le 10 sept. 2016 12:18 AM, "Edward Welbourne" a écrit : > > Benjamin Terrier: > >> However, my knowledge is that whatever the method one use to generate > >> your UUID, one can never guarantee its uniqueness. Meaning that the > >> Qt documentation is falsely guarantying unique UUID and therefore > >> should be changed. > >> > >> If anyone can confirm, I'll create a bug report. > > Thiago Macieira > > Right, it's not guaranteed. It's just that the chance of collision is > > virtually zero. > > ... and for sufficiently small values of "virtually zero", that's as > close a guarantee as you'll get to anything, because no matter how well > you think you can guarantee things, cosmic rays still sporadically flip > bits in your memory. > > I read a most illuminating paper a few years back that looked at the > reliability of tests of prime-ness for large numbers. There's a widely > used approach that's cheap and theoretically not guaranteed but easy to > apply to enough test-cases to reduce the likelihood of error to > ignorably low. This was compared to the best known "provably correct" > algorithm for determining primeness - which is significantly more > computationally expensive. Due to the (ridiculously rare) flipping of > bits by cosmic rays hitting the processor and memory, the latter was in > fact *less* reliable than the former, because the former ran faster so > incurred a smaller chance of errors due to stray rays. > > I don't think we should worry about documenting how not-quite-perfect > our guarantee of UID uniqueness is in a case where - realistically - > the difference from perfection is ignorable. > > Eddy. > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development I agree with both of you. Still I'd like the documentation to be changed, mainly for 2 reasons. 1. For the sake of correctness. The sentence "the UUID will be of cryptographic quality, which will make the UUID unique" is false on a logical/mathematical/algorithmical point of view. And here the documentation is about what the code does, what the implemented algorithm provides, and it does not provide a 100% guaranteed unique UUID. Starting to justify that the UUID should be documented as guaranteed unique in this part of the documentation is out of scope because you make assumptions on where and how the code will be executed. It would be way better to tell that cryptographic quality UUID are as unique as any UUID can be and that in most use cases its uniqueness can be safely implied (because hardware is less reliable, etc.). 2. For the sake of educating people When reading "the UUID will be of cryptographic quality, which will make the UUID unique", people who do not have advance knowledge on UUID and such could come to think that there is a way to guarantee UUID uniqueness. And I'm pretty sure you could end up with quotes of Qt documentation to back up the claim that "UUID can be unique if the RNG is of cryptographic quality". BR, Benjamin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QUuid documentation
Hi, As of Qt 5.7, QUuid::createUuid() documentation is: > On any platform other than Windows, this function returns a new UUID with > variant QUuid::DCE and version QUuid::Random. If the /dev/urandom device > exists, then the numbers used to construct the UUID will be of cryptographic > quality, which will make the UUID unique. Otherwise, the numbers of the UUID > will be obtained from the local pseudo-random number generator (qrand(), > which is seeded by qsrand()) which is usually not of cryptograhic quality, > which means that the UUID can't be guaranteed to be unique. > > On a Windows platform, a GUID is generated, which almost certainly will be > unique, on this or any other system, networked or not. So according to this there are 3 kinds of UUID: - Generated by /dev/urandom - Generated by qrand() - Generated on Windows OS The documentation states explicitly that the first type is unique and that the 2 last types are not unique. However, my knowledge is that whatever the method one use to generate your UUID, one can never guarantee its uniqueness. Meaning that the Qt documentation is falsely guarantying unique UUID and therefore should be changed. If anyone can confirm, I'll create a bug report. BR, Benjamin Terrier ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QImage::transformed returns shallow copy for QTransform::TxNone matrix type.
2016-07-11 21:21 GMT+02:00 Sune Vuorela : > On 2016-07-11, Allan Sandfeld Jensen wrote: >> On Monday 11 July 2016, Benjamin TERRIER wrote: >>> QImage::detach() is not public API. >>> However QPixmap::detach() is, so why QImage::detach() couldn't be made >>> public too? >>> >> It probably should be. It is a lot more sensible to use than copy(rect()). > > https://codereview.qt-project.org/#/c/164886/ > > /Sune > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Just something worth stating here, from Mark Mutz on the codereview: "QImage::detach() doesn't (if the QImage was constructed from the mutable-uchar* ctor)." So it's seem that all detach() functions which are internal will not detach when using external data which is the case discussed here in the first place. However detach() member functions which are part of the public API (e.g QPixmap::detach()) will always detach. The consequence is that for Tomasz Olszak's use case calling QImage::detach() is a bad idea because (1) it is not public API and (2) it will NOT detach. So the only solution seems to call the non const version of bits() as suggested earlier. BR, Benjamin Terrier ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QImage::transformed returns shallow copy for QTransform::TxNone matrix type.
2016-07-11 16:03 GMT+02:00 Paul Olav Tvete : > On mandag 11. juli 2016 12.54.58 CEST Simon Hausmann wrote: >> Instead of using copy(), why not call the non-const bits() function (and >> don't use the returned value). That will detach [...] > > Instead of using bits(), why not call detach() directly? ;) > > - Paul > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Hi, QImage::detach() is not public API. However QPixmap::detach() is, so why QImage::detach() couldn't be made public too? BR, Benjamin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of Standard Library containers in Qt source code
2016-07-02 16:30 GMT+02:00 Stephen Kelly : > Benjamin TERRIER wrote: > >> But how come a raw loop can be excluding? It should be understandable by >> any C++ developer and, I would dare to say, by any C-style programming >> language developer. > > I don't think anyone can understand or reason about raw-loop-heavy code (see > PS below). I use 'excluded' to refer to people who are not willing to do so. > They exclude themselves from working on Qt code because they can not reason > about it. > > In the same sense, Thiago is 'excluded' from reading and understanding code > which uses 'container.empty()' or which doesn't use raw-loops, because he > would choose to not work on such code. > > There is a divide. The 'exclusion' is self-decided. > > Does that make sense? If you have a better phrase than 'self-exclusion' for > that then it could be useful to share it. Ok for me if you meant it this way. > Someone unwilling to attempt to reason about the code in that function is > 'excluded' from fixing something in it or extending whatever features it > has. I'd boldly reply to that that if one is unwilling to reason about a piece of code, one should not be fixing it. But I'd also agree that the code should be as readable as possible to get a many developers to contribute. Back to Qt current situation I think that the lack of comments in some parts is a bigger throwback than the code style. And back to the actual topic of Qt/STL containers, I am for option 3 if the project can afford the extra development and maintenance otherwise I'd go with option 4. Br, Benjamin Terrier ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use of Standard Library containers in Qt source code
> However, everyone else is excluded by it. When my colleagues find long > functions, lots of nested if()s and for()s, ++foo somewhere in while loops, > they find it much harder to reason about the code. Now I do too. > > So, by sticking to lots of raw loops, you're actually actively excluding > other parts of the C++ community from participating. I don't have numbers to > qualify it, but there seems to me to be a much larger community following > modern C++ practices than following Qt practices on questions like this. You can't say that using raw loops (vs stl algorithms) is "actively excluding" any C++ developer. I would agree to say that simplifying code by using STL makes the code more readable for developers used to the STL. And that raw loops and nested controls can be less readable. But how come a raw loop can be excluding? It should be understandable by any C++ developer and, I would dare to say, by any C-style programming language developer. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Scope of source code license files
Le 14 juin 2016 13:22, "Sze Howe Koh" a écrit : > > On 7 May 2016 at 12:20, Joseph Crowell wrote: > > > > On 4/05/2016 7:39 PM, Lars Knoll wrote: > >> > >> On 02/05/16 14:37, "Development on behalf of Sze Howe Koh" wrote: > >> > >> > >> > >>> Hello, > >>> > >>> The LICENSE.GPLvX and LICENSE.LGPLvX files from > >>> http://code.qt.io/cgit/qt/qtbase.git/tree/ (and submodules) start with > >>> "The Qt Toolkit is Copyright (C) 2015...", but then they go on to say > >>> "You may use, distribute and copy the Qt GUI Toolkit under the terms > >>> of..." > >>> > >>> Is this correct? What about non-GUI parts of the toolkit? > >> > >> The GUI in here is just a historical thing. It applies to Qt. > > > > > > Wording should probably should be changed then as times have changed and Qt is certainly no longer just a GUI toolkit. > > Here's the first batch, targeting the "5.6" branch. If this is OK, > I'll submit similar patches for the other repos too: > > https://codereview.qt-project.org/#/c/162394/ > > Some more questions: > > 1) What about http://code.qt.io/cgit/qt/qtbase.git/tree/LGPL_EXCEPTION.txt > ? It's currently presented as additional permissions on top of LGPL > v2.1. I presume LGPL v3.0 should be included too? I'd like to get an answer to this question. If the exception doesn't apply to LGPLv3 then people might not be able to make proprietary applications with Qt. Because without it, the LGPLv3 only give exception for inline functions of less than 10 lines, meaning that developers would have to check every Qt header for every release to ensure there are no 11+ line long inline functions. Also without the exception, I see no points in using LGPL as I guess there should be at least one inline/template function breaking the 10 line limit. > 2) https://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ > says that "Qt 5.7 will not be available under LGPLv2.1 anymore" -- > Does that mean LICENSE.LGPLv21 should be removed from the 5.7 branch > onwards? > I'm wondering if having these license files still in there doesn't automatically make Qt 5.7 available under LGPLv2.1? Maybe Dr Till Jaeger has an answer. > > >> Cheers, > >> Lars > > > Regards, > Sze-Howe > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development BR Benjamin Terrier ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal to change connectSlotsByName behavior
2015-12-04 10:30 GMT+01:00 Marc Mutz : > This is precisely the reason why connectSlotsByName is a bad idea in the first > place; changing the name of a widget breaks connections (at runtime, not at > compile time as with QObject::connect()). > > Just don't use it. Then we can let the function r.i.p. come Qt 6... :) As many seems to think connectSlotsByName should not be used, maybe it should be, as André Somers said, deprecated. However it is used by the designer plugin within Qt Creator as it uses the fact that uic will generate a call to connectsSlotByName to automatically generates slots when the user clicks on "Go to slots.." in the context menu. This means that every widget class that has a ui file will call connectSlotsByName. There is still an open bug report asking to make the call optional (https://bugreports.qt.io/browse/QTBUG-27866) BR, Benjamin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Proposal to change connectSlotsByName behavior
Hi everyone, This message follows an exchange I've had with Thiago on a bug report: https://bugreports.qt.io/browse/QTBUG-49749 In the current state, QMetaObject::connectSlotsByName() tries to find, for each slot named "on__" in a given object, a child object named " and connect the signal to the slot. Moreover the documentation says that the search is recursive so any descendant QObject is looked up (not only direct children). My issue here is that the search is done by instantiation order (depth-first search) which means that if 2 (or more) children have the same name one has to know which one is instantiated first to know which one will be connected. And of course imposing on the developer to use unique names throughout a QObject hierarchy is not feasible in particular if he/she is using a third-party library and might not know the object names used internally. This can lead to various hazardous situation, for instance, in a perfectly working software, one can break the behavior of the main window by simply adding a widget in a grand-grand-child widget. Or worse if the UI is made using Qt Designer, the behavior of the application can be changed by simply reordering the widgets in the layout as it will also change their creation order. An application could even break at runtime if a user enables a plugin or set an HMI element visible. In my opinion it also breaks encapsulation as the naming in a widget can alter the signal/slot connections in another widget. My proposal is to change the behavior of connectSlotsByName to do a breadth-first search. In this case, if a direct child is a match it will be used for the connection regardless of possible matches deeper in the hierarchy. Doing so would solve the situations stated above and restore encapsulation. It seems that Thiago's opinion is that it can not be changed as this behavior has been here since Qt 4 and it might break existing applications. On my side I think it's at least a buggy and error prone behavior or even a flawed design and that it must be changed as soon as possible. About the risk of breaking existing applications, I think making the change is less risky for Qt users as in the current state every Qt software can break with any change to an object name or instantiation order. Also as Qt Designer does push the users to use the connectSlotsByName mechanism, it is even possible to generate an example of this "unwanted" behavior without writing a single line of code (see attached zip in the bug report). Regards, Benjamin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Contribution: Windows Stock Icons
Hi, For the first point I think it is a good idea. However the second point seems to be already taken care of. As far as i know, the current API for obtaining such icons is QStyle::standardIcon(), looking at its implementation in QCommonStyle, it calls QPlatformTheme::standardPixmap() for multiple hardcoded sizes (16x16 and 32x32 at this moment). So the returned QIcon already provides various resolutions. It might be improved by calling QPlatformTheme::standardPixmap() for sizes matching SHGSI_LARGEICON, SHGSI_SMALLICON, SHGSI_SHELLICONSIZE. Regards, Benjamin 2015-11-14 14:03 GMT+01:00 Frank Richter : > Hello everybody, > I made some (non-trivial) changes to the Windows stock icon implementation. > The goals were > 1. Use public/"modern" APIs as much as possible to obtain the icons. > 2. Make the various different resolutions stock icons are provided in > available to Qt. > > For the first goal I changed to code to use SHGetStockIconInfo as much as > possible and shell item icons for some other icons; hardcoded resource IDs > and the legacy IDI_ icons are only used as a last resort. (It's worth > mentioning that the IDI_ icons will only return "Windows 7" style icons; for > the new Windows 8 icons you need to use SHGetStockIconInfo. > > For the second goal I added an icon engine that looks at some raw icon > resource data to load all available sizes. To expose all those sizes I added > a platform theme method to return an icon engine for a stock icon. > > Of course I'd very much like to see this make it; however, I think that > before starting to submit individual patches for review maybe a bit of > "approach review" might be a good idea. > * Are these changes desireable? > * What do you think of returning icon engines from the platform theme? > * And what about the more bare-metal icon loading? > > For the time being I uploaded the changes (in order of evolving > implementation) to github: > https://github.com/res2k/qtbase/commits/dev > > Looking forward to your feedback, > - Frank > > > ___ > 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
