Re: [Development] C++20 goodies (was: Using '#pragma once' instead of include guards?)
Nice. I'm a bit surprised file_name() returns a char* rather than a std::filesystem::path, but it'll do. It's also nice to see source_location has a function_name() that can finally unify the disparate ways of getting that information. The advantages are for instance that file_name() does even work on tiny bare metal targets without heap. It can be processed in constexpr at compile-time. const char* gives the user a lot of freedom to decide what to pay for. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qbs development
> Just for the sake of clarity, who *is* the Maintainer of QBS ? > Our wiki's [[Maintainers]] page only mentions Christian Kandeler as > maintainer of Qt Creator's integration with it. I gather Ivan is a/the > principal developer of QBS in practice. Is Ossi co-Maintainer, or are > you really talking about his Approver rights (which, IIUC, suffice to > make a +2 significant) ? > > Before we resort to [0] QUIP 2's "extreme circumstances" provisions, > please let's do what we can to work our way through the steps that come > before that - for which we first need to settle the question of who *is* > The Maintainer (or who are The Maintainers, if more than one) of QBS. > > [0] http://quips-qt-io.herokuapp.com/quip-0002.html Christian Kandeler is the only maintainer. Ivan Komissarov is the most active developer in that repository and has approver rights as well. We are talking here about the situation that the maintainer has given a +2 while a person unrelated to that particular repository has stopped the patch with a -2. On the other hand, that person has neither shown any intention to implement that feature nor has the person contributed to the codebase during the last couple of years. The question is whether this is an abuse of approver rights. This is a relevant question for the Qt project. Any person with approver rights has the ability to cause a production stop. Ivan is asking for help in this particular case and I am seconding his request. Richard Weickelt ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Releasing] [Interest] download.qt.io is down
Hi, > We are > also checking alternative options like using another service provider or our > own machine room in the same capacity where CI and related development > systems are running. ... or like setting up a load balancer that distributes download requests to the mirrors? That would be beneficial for everyone and lower the utilization of download.qt.io. Richard ___ 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
> Right. That will become an issue in 4 months when GCC 11 ships with its > internal > header-dependency refactorings, breaking all sorts of Qt code, and > that will then > bubble down to various distro downstreams during this year and next. Then > again, > distro packagers can hopefully handle that. Using the Qt packages or > installer for 5.15 may > give you a broken Qt somewhat sooner. Intriguing. Could you elaborate? Thanks. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Building additional components with Conan for Qt 6
Hello Ilkka, thanks for the heads up. I have some further questions: 1. Will Conan be used to manage dependencies of Qt as well? 2. How will the recipes be managed and where on code.qt.io can I find them? 3. Is TQtC going to host a Conan repository for binary packages as well? 4. What is the Qt Company's position regarding conan-center? Thanks BR Richard Weickelt ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] How to perform unattended installations of Qt? (Was: Changes to Qt offering)
> Still waiting for instructions on how to do an unattended installation of a > binary Qt. While you are waiting, have you seen those pages? - https://www.qt.io/blog/qt-online-installer-4.0-pre-alpha-released - https://wiki.qt.io/Online_Installer_4.x Bonus: - https://pastebin.com/jUN51zci Maybe you wanna give it a try and let us know how well it works? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Windows 7 support will be dropped in Qt 6
> Oddly enough, continued support for the Free Software ecosystem around > Qt is one of the things most of us who work here care about deeply, so I have no doubts that Qt engineers do. I can see this in in every code reciew and I appreciate it very much! > Our management, in any case, knows full well that the Free Software side > of the Qt ecosystem is vital to the continued viability of this company > and any business model it can realistically hope to make a living off. I doubt it. The recent decisions made by your management point into a different direction. Public communication by your top level management says something else or would you call this post https://www.qt.io/blog/qt-and-open-source "communication"? I doubt that your top level management has a sustainable strategy to nurture and expand the OS community. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] GitHub Pull requests
> AppVeyor supports Linux, but they support Dot Net on Linux, which isn't > interesting. Travis does not support Windows (or didn't, last I checked). > That means I need both to have the two to support three OSes. Travis supports Windows. The machines are not fast, but it is usually enough. > > GitHub Actions didn't exist until last November. But it doesn't help > right now because their Windows support does not come with Qt > pre-installed, like AppVeyor's does. Building Qt, even if just a minimal > QtCore and QtTest, just to unit-test TinyCBOR, is out of the question. > Did you also read the part where I already spend half my yearly > allocation of TinyCBOR just to maintain the .travis.yml file? Note how > that's using apt-get to install Stephan Binner's builds of Qt for Ubuntu > on Linux and Homebrew on Mac. Imagine having to *build* Qt, on Windows. FWIW: We use Travis to build and test Qbs on all 3 major platforms and the maintenance does not require much effort. https://code.qt.io/cgit/qbs/qbs.git/tree/.travis.yml However, important features like sharing artifacts between stages are still missing and reinstalling all dependencies every time is not always 100% reliable. Although Travis is less popular these days, their UI is still the tidiest I have seen and their open source offering (5 parallel executors) is still very generous. AppVeyor recently started advertising that VM images can be customized. I have not tried it. > That's why I asked last month (and still have no official reply) on how > the Qt Company suggests we use Qt in public CIs, if the binary build is > locked to Qt Accounts. Do you seriously expect to get a reply? Are you a paying customer? Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] GitHub Pull requests
>> In an ideal world... >> >> - Alice opens a pull request on GitHub. >> - A bot sees the PR and opens a corresponding request on Gerrit. >> - Bob comments on the Gerrit request. >> - A bot sees Bob's comment and replicates it to the GitHub PR. >> - Alice replies (on GitHub) to Bob's comment. >> - A bot sees Alice's comment and replicates it to Gerrit. >> >> ...and so on. > > Then Bob asks Alice to make a change in commit, and she has to make > push -f in her branch. After that, review comments on GitHub are smashed, > while remain perfectly readable in Gerrit, and Bob can see difference > between patch versions while Alice cannot. There is a github plugin for Gerrit that promises some form of integration: https://gerrit.googlesource.com/plugins/github/ It seems to be enabled on gerrithub: http://gerrithub.io/ "GitHub pull requests Keep in touch with external users synchronizing pull requests with reviews." "Pull requests with Gerrit Fetch your GitHub pull requests and upload them in Gerrit for review. Enable a single point of validation of the Code Review workflow and keep your external contributors up-to-date on GitHub." I haven't tried it though. Does it work? Maybe there is a project on https://review.gerrithub.io/ where you can see github PR syncing in action. Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
Tino, Volker, > In a CI/CD pipeline that depends on 3rd party packages like Qt, it’s a good > idea to manage your own artefact/package repo, so that you have control over > the versions you are building and testing against - or at the very least to > become independent of 3rd party infrastructure that you have no control over, > but might block your build or deployment. How about the Qt company providing Qt as a Conan package on bintray.com? Conan is currently the most versatile packager solution and is much better suited for CD than vcpkg, choco and what not. This shouldn't be even a full-time job and would create a *lot of value* for the open source community and might help to expand your user base without adding costs for maintaining infrastructure and download bandwidth. Every open source user is a good for the Qt eco system and ensures that Qt stays relevant. You could also contribute to https://github.com/bincrafters/conan-qt and ensure that it is properly working and pre-built binary packages are available. It would be in the best interest of the Qt project and thus also of the Qt company. Best regards Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Changes to Qt offering
>> 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? I wonder if selling per-developer licenses is still a sustainable business model at all. We are living in times where big players are pressing their frameworks into the market, being backed up by more developers than the Qt company will ever have. It's hard to compete and make money. Maybe the Qt company should close the doors and be turned into a foundation running the infrastructure behind qt-project.org and coordinate further development. For the benefit of Qt and in order to prevent forks. Just kidding. > 1. Work on making Qt more relevant. For me this means bringing QML to the web. > Obviously tQtC will have to determine those priorities. > 2. Don’t scare people off before they even start. Much lower initial pricing, > no historical licensing, more distant ramps for price increases. > 3. Focus on getting people/companies to make multi person-year investments in > Qt-based projects — it is only these projects that can stomach high license > fees. 4. A more attractive overall end-to-end development package. After downloading the Qt SDK and QtCreator there is still a lot of work to do until you have an application that you can deploy with confidence. I am not talking about writing the actual code. Especially automating the build/test/deployment part of multi-platform project eats up a lot of resources, is full of pitfalls and this can be real bummer if you're just a small company or the Qt application is not your core product. Did I already mention that a Qbs-alike language would have been a great use-case for pipeline infrastructure? Even big companies are burning lots of manpower in that task and still often don't get it right. If paying a predictive and non-hurting amount of money would allow me to focus on my actual product, I might most likely do it. Felgo has entered that direction only last year, but I don't know how their solution sells though. Maybe it's too late for Qt to invest in that area. 5. Make contributions more attractive and rewarding and allow contributors to actually get something out of it. - Getting a +2 on a S,M,L,XL sized patch gives credits. - Fixing an issue that was confirmed to be an issue gives credits. - Answering a question in the Qt forum gives credits. - Credits can be used for upgrading Qt online services described in 4. - Credits can be put on issues. - Credits can be converted into money. - Customers buying a license would get access to business support, but also get some credits automatically. - Everybody could buy credits - The exchange rate of credits/money depends on supply and demand In addition, there would be a public, but very visible reputation system which only accounts for contributions (in any form in the Qt project). ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt Marketplace
> - Product repo contains a Conan recipe. Conan takes care of > getting/building the dependencies. That sounds interesting. Will the QtCompany use Conan as _the_ package manager for the market place and Qt6? Is there more information available? Thanks Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt Contributor Summit 2019 sessions
> I'm wondering if anyone is interested in my experiences with using the > Qt/Quick technology in a non standard way. I was specifically thinking of > the QSkinny theming system and the implications of doing scene graph node > composition ? What is the latter? I'm not sure if that is what You have in mind, but I think that QML's language features: - declarative by default, imperative only when needed - uses a simple and widely used language (JS) for imperative tasks - component-oriented - property bindings - dynamic evaluation in flexible contexts make it a very good foundation for DSLs for automation tasks as well as description of systems. Qbs is an excellent example how such a QML-ish DSL could look like (although it's not based upon QML/QtQuick at all) and what it gains: - easy to read/understand code - easy to re-use components - simple core DSL/concept, but high flexibility Some example applications (I won't rant on other build automation tools and their DSLs here): 1. CI systems Almost all follow a purely declarative approach with YAML and score very poorly in above 3 categories. Jenkins declarative pipelines are another poor example (not to mention that the documentation is a maze): No inheritance, no property bindings, hard to remember... 2. Package managers Conan abuses Python as a DSL. Poor semantic error messages, high languange overhead and has to fall back to imperative programming even for the simplest things. 3. Configuration automation Ansible uses YAML as the core language and little bit of Python when dynamic behavior is needed. The languages don't play well together, although I wouldn't say that the overall result is very poor. But QML would score much better IMO. 4. Test automation This is how a Qbs-inspired, QML-based and scalable test automation DSL could look like: https://qst.readthedocs.io/en/latest/usage.html To use QML as a DSL, I think it would be necessary to expose more internal APIs of the QML core. APIs and hooks would be needed to traverse the component tree and evaluate components or parts of components on demand and modify contexts as needed. Refer to https://bugreports.qt.io/browse/QTBUG-69075 for instance. On the other hand, C++ would probably be a poor choice to implement the applications (DSL back-ends) I have in mind and this suggestion comes 10 years too late. Languages like Go and Rust are are popular for a reason. I can't blame the Qt company for not doing this, but I think that an easy-to-use CI service for Qt applications with a Qbs-alike QML-ish DSL could have given QML as well as Qbs much more traction. Oh well... Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Where to find development snapshots of Qt
> You can download snapshot via online installer. At the moment we don't publish > separate src packages to download.qt.io Thanks, but I can't see any Qt snapshots in the online installer. Some of the "preview" packages there are even outdated. This is what I see: https://pasteboard.co/Iz16Exp.png ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Where to find development snapshots of Qt
> I guess that building Qbs in Coin is the only way to build against unreleased > Qt versions. How much effort would that be to set up and to maintain for an external contributor? Any experiences? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Where to find development snapshots of Qt
Hello, I would like to build and test Qbs against development snapshots of Qt in order to prevent disasters like https://bugreports.qt.io/browse/QBS-1492 from happening again. Are there any snapshots of the Qt SDK available in some form? Something like the 7z packages used by the installer tool would be perfect. I checked download.qt.io and it looks like snapshots have been published at some point in the past, but it is hard to see through there. QtCreator publishes daily builds. I found https://wiki.qt.io/How_to_get_snapshot_via_online_installer but does that apply to commercial customers only? Thanks Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Using windeployqt from a cross-compiled Qt
Hello, I've been trying to use windeployqt from a cross-compiled (mingw-w64 on Linux) Qt. I must be the only person on the planet doing this because there is a bug in windeployqt preventing it. The PE functionality is guarded by Q_OS_WIN. https://code.qt.io/cgit/qt/qttools.git/tree/src/shared/winutils/utils.cpp#n971 I guess that Q_OS_WIN is a host-dependent define and of course it is not there when compiling host tools on Linux. Does Qt provide any target-specific define that could be used instead? I've filed https://bugreports.qt.io/browse/QTBUG-77823 in any case. Thanks ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Assistant WebKit/WebEngine support
> Qt used to make a point on having superior documentation to most other > frameworks, and it was (and still is) one of the reasons for its success. > Whatever we can do to help make the documentation better is something I > think we should do. Is it well known, how many QtCreator users are even using the integrated help functionality? How many Qt users are using QtAssistant and how many prefer the online documentation? I stopped using the integrated help and QtAssisant at some point and now I am exclusively using the online documentation in my regular browser. I can't give an exact reason, but I can see a correlation of multiple things: 1) Fast internet access became available everywhere I worked and there was no noticable delay anymore in page loading. 2) I am reading so much in the browser anyway that I feel more comfortable also reading the Qt docs in it. 3) I am using my browser anyway while working with Qt because I often search in the mailing list, forum, other docs, etc. 4) Using a regular search engine leads to good-enough search results and is very fast 5) There was the point where Qt's online docs started to look better. Cripser fonts, more whitespace, better code highlighting. I guess no matter how hard you try and how much effort you put into it, I'll probably never use QtCreator's integrated help again. I'd rather appreciate QtCreator to be slim and fast, both when using and building it. I think the time, energy should rather be spend in improving the documentation as a whole. I'd like to see more video tutorials about QtCreator best practices, for instance. And yes, I (and a lot of users) would appreciate if qdoc would output exactly the same nice html design as doc.qt.io. The current output is so ugly (Doxygen is even worse) that I even prefer to write API documentation directly in rST/Sphinx. Best regards Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Configure command lines of official Qt releases
>> Thanks, Ivan. While this is true for other libs like xcb, Qt does not ship >> icu. It uses either the one provided by the system or a thin replacement >> resulting in a reduced localization feature set according to >> https://wiki.qt.io/Qt_5_ICU#Design_Principles > > Linux binaries are shipped with ICU. It's not possible to use system version, > because > ICU doesn't provide stable ABI. Good point. Indeed, libQtCore.so links to libicui18n.so.56 => /opt/Qt/5.12.3/gcc_64/lib/./libicui18n.so.56 (0x7f457026f000) libicuuc.so.56 => /opt/Qt/5.12.3/gcc_64/lib/./libicuuc.so.56 (0x7f456feb7000) libicudata.so.56 => /opt/Qt/5.12.3/gcc_64/lib/./libicudata.so.56 (0x7f456e4d4000) Now I can see how "-R ." makes sense. By "Qt does not sip icu" I meant that the Qt source package does not ship icu, but would use whatever it finds on the build host. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Configure command lines of official Qt releases
On 05.06.2019 21:28, Иван Комиссаров wrote: > AFAIK -R . is used to load that icu libraries I told you about in Gerrit. > > Otherwise it will try to load the system ones instead of the shipped ones > with Qt. Thanks, Ivan. While this is true for other libs like xcb, Qt does not ship icu. It uses either the one provided by the system or a thin replacement resulting in a reduced localization feature set according to https://wiki.qt.io/Qt_5_ICU#Design_Principles I am a bit confused by "-R .". after reading the documentation: -R Add an explicit runtime library path to the Qt libraries. I thought that "." is always implicitly the first path where the run-time linker looks for (other)libraries. So I don't understand why it is set explicitly. Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Configure command lines of official Qt releases
> Excellent yes. That was a recent addition to the installer framework, > very useful for exactly that purpose. Thanks for _all_ replies! Actually, the configure command line in the COIN logs differs from https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config?h=v5.12.3-packaging so I rather used the ones from the COIN logs. Could somebody explain why the Linux release explicitly specifies "-R ." as configure option? I have never seen that being used before. Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Configure command lines of official Qt releases
> I think this was asked on the interest list back in January [1]. I did search on the Qt mailing lists, but even when I type exactly the subject of the thread you referred to, google doesn't find it. I would expect "Official builds configuration options site:lists.qt-project.org" to bring this post up: https://lists.qt-project.org/pipermail/interest/2019-January/032221.html but it seems like google hasn't even indexed it. > The answer is here: > > https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config Great. Thanks. Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Configure command lines of official Qt releases
Hi, where can I find the configure command lines that have been used for Qt binary releases provided at https://download.qt.io/official_releases/qt/ ? Is there also more information available about the environment they have been built on? I am particularly interested in the Linux release. Thanks ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
> - People nowadays will just use the flatpak / appimage / snap / whatever I can see how that works for single-binary GUI applications. Do you know any example for a complex Qt-based multi-binary (preferably command line usage) application that does that well? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Gerrit is back
> There are more tweaks that would be nice to apply to the UI to make it > better. Does the new version make this any easier? What's your advice for > people who'd like to contribute UI tweaks? What's the best way to > proceed? (in the sense of empowering potential contributors instead of > asking you to do all the changes) This is a very very positive way of saying that the new UI is: - less structured - less intuitive The update contains indeed nice new features, but as an occasional contributor I feel less productive because I need to learn where to click every other day. The old gerrit was certainly ugly, but it felt much more tidy. I would be very happy if someone with UI experience could clean up the stylesheet. :) Thanks Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt XML and Qt Xml Patterns
> This was a case where I thought it is obvious already. The definition of > "Done" (given by Thiago earlier in this thread) has not applied for a > long time anymore. There hasn't been maintainer for a long time. I > understand this leave use cases in the dust but this can only by averted > if somebody steps up to actively main this module. There is no point > claiming support otherwise. > Nothing has been decided at this stage but unless a new maintainer can be > found, it might even slip into Removed state in Qt 6. > Please consider this mail as an official announcement of Qt Xml Patterns > deprecation. It's good that Bernhard has received an official statement. In general, I think the Qt Company could make a little more effort to communicate such decisions, educate its user community, and attract new potential maintainers. Actually, communication should start before a problem results in a decision. Isn't that an important aspect of community building? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A deployment tool for Linux
On 10.04.2019 23:21, Marco Bubke wrote: > Sounds you want flatpak. ;-) All those run-time extracted application container formats might be nice solutions for GUI applications which is apparently the main target of Qt. But my observation is that they perform rather poorly when being used for command line applications or a combination of both. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A deployment tool for Linux
> You may need to do custom steps on artifacts produced by windeployqt before > packing them, so it's better to have separate tools for "bundling" and > creation > of actual packages. Well, that's easily solved. The "tool" doesn't need to do everything on a single invocation which leaves enough room for custom steps. However, I do see the point of using different tools for that purpose. Yet it would be convenient and time-saving to have everything under the same roof within a common framework and good reference documentation :) ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Gitlab at qt.io
> Since its company-internal, the answer likely doesn't matter to you. But it > doesn't have CI. If a repository is worth having CI for, it should go to > Gerrit. > Thanks for replying anyway. Interesting. I was looking for a (semi-)open and maintainable CI solution that I could propose for Qbs. Not using gerrit is not an option. But the Qt Company seems to lack of an easy-to-use CI solution for this kind of project and the current amount of contributors. Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A deployment tool for Linux
>> I, as a person, think that a "deployment tool for Linux" is >> something that spits out packages in half a dozen "native" >> distribution package formats. > > Nope, that tool is called "package maintainer" :) Blessed be those who have a "package maintainer". I don'ẗ think it's that easy. If I would want to bring my software product into the official distribution repositories, maybe and of course every open source project should aim for it. But that's quite some effort and sometimes even impossible. I would be interested to know how easy it is to release a Qt-based application with a bleeding edge Qt version (or with a patched one) to the official Debian repositories. And if I had a proprietary product and want to make updating as convenient as possible for my customers? Nothing stops me from publishing a self-containing .deb, .rpm, .whatever on my website. If there was a one stop shop tool that produces a collection like this with very little effort: https://speedcrunch.org/download.html I would be sold. Maybe even in combination with setting up my own package repos. But with very little manpower that can be cumbersome. >> Collecting "resources that the application uses (like [...] >> graphics, [...]" *and dependencies* would be a (important) >> step, but not all that it takes. > > By this logic windeployqt should produce .msi packages Wouldn't be the worst feature though, would it. That doesn't make Andre's comment less valid. Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Gitlab at qt.io
Hi, I would like to know more about https://git.qt.io - What's the purpose and the future plan? - Is it available to registered users at qt.io ? I couldn't log in. - Is it connected to gerrit or can it be connected? - Does it offer gitlab CI? Thanks Best regards Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake Workshop Summary
> But do note that our parallelism isn't that bad right now. There's a long > critical path before parallel things can currently be built, but once QtQml > is > built, the number of jobs that can be launched in parallel is very big. What > doesn't need that build isn't very large. Could you elaborate a bit on that? Are you saying that the number of modules depending on QtQml is "very big" and hence it is on a critical path or is this module different from other critical modules like QtNetwork or QtCore? ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Build system for Qt 6
On 18.12.2018 21:20, Thiago Macieira wrote: > On Tuesday, 18 December 2018 11:44:38 PST Denis Shienkov wrote: >> If Qt maintainers says that they will not remove the QtCreator && QBS >> integration in future (I'm about QBS project manager plugin), then I >> will not worry (don't care) about CMake. I will use QBS in any case. > > So long as someone is maintaining the plugin, it should be no problem. > > Who's the maintainer now? And who's going to be the maintainer in two years? Now: The same people who have been maintaining Qbs during the last years. Future: Unclear. Jochen was so kind and made a vague declaration of intent here https://lists.qt-project.org/pipermail/qbs/2018-October/002270.html At least for keeping Qbs integration in QtCreator at the current level. Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Build system for Qt 6
> On Sunday, 16 December 2018 20:12:47 PST Richard Weickelt wrote: >> ... and if you cross-compile, you definetly don't want to your build system >> to stick its nose into your system librararies on any platform. > > No, you really DO. The issue is what "system" is: it's the sysroot for your > target platform, not the host system where you're building from. Yes, I implied host. I don't want any build system to crawl my host sysroot unless being explicitly told to do so. Thanks for clarifying. [...] > And that's why I don't cross-compile. The Intel world is a shiny place to live ;-) ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Build system for Qt 6
> Here in Fedora, we actually *want* CMake to find system libraries. The > situation on Windows is of course different, and third-party packages for > GNU/Linux may or may not want to use the system libraries, but our > distribution packages definitely want to use them. ... and if you cross-compile, you definetly don't want to your build system to stick its nose into your system librararies on any platform. Therefore I see build automation and packaging as orthogonal processes. IMO it lowers the usage complexity and leaves more room for flexibility when being kept separate. The package system would be responsible to resolve dependencies and could produce files that the build automation system would consume. I kind of like the idea behind Conan which does only package management, dependency resolution and provides simple-enough generators for all kinds of build automation system. The discussion about build systems reminds me a bit of a religious war. I made my peace with CMake and use it only when being paid for. It allows me to use the browser more often and to find obscure stuff on the internet. It's an expensive tool. After work I want to get my stuff done with low investment, hence I often use Qbs ;-) Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Who is in charge of qt-project.org?
Tuukka, On 02.11.2018 13:44, Tuukka Turunen wrote: > > Exactly. We are very pleased if there are people who start to contribute > to Qbs. So far it has been very little by others than employees of The Qt > Company. Here are some possible reasons: - the Qbs core code base is complex - the code contains very little documentation - the codebase evolved fast - technical decisions and planning happened behind closed doors - most users were comfortable with the development speed and TQtC employees fixing bugs and helping on the mailing list. I'd say that TQtC employees have done an excellent (technical) development job, really. But that alone has not lead to a healthy community of contributors. This is not to blame TQtC, it's my personal view from outside. I haven't contributed anything to Qbs, but I have been following the development with high interest and I am happily using it. > We will continue maintaining Qbs so that it stays supported until end of > 2019 and also release a new version in April 2019 as promised. Most > likely Qbs remains usable a long time after support ends - even without > anyone from the community working on it. > > This is a good opportunity for those interested in further developing Qbs > to step up and start taking it forward. We can help with the reviews and > provide the infrastructure. We can help even with new releases, if there > is enough interest to develop it further. Could you please post that on the Qbs mailing list, maybe even in the blog? I believe that this is the right communication style to go forward and it is very important that TQtC communicates proactively and clearly what it can help with. I don't expect You to coddle the community, but please keep in mind that there is very little community feeling until now. We are starting almost at 0 now. > I do not think anyone questions the technical merits of Qbs over qmake or > CMake. Qbs is better than these in many ways. For that reason we have > kept on investing into it. But we also need to be realistic and think > about what paying customers prefer. While we have some customers using > Qbs, the use of CMake is much, much bigger. Both by the number of > customers using it and by the size of the customers' usage. > > We probably should have opened the dialogue about the future of Qbs > during the process of thinking about the options. This would have been > good and fair towards the community. Absolutely, yes! That's too late now. But it's not too late to keep Qbs alive. For example, you could start by revising your blog post and giving it a more inviting character. Next step could be maybe a meeting with community members where we would clarify how the commitment of the TQtC looks like. I am sure that there are many open questions. Thank You Richard ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Who is in charge of qt-project.org?
> It seems to differ quite a bit in scale. That blog post has 7 comments. > Compare it to nearly 150 on "Deprecation of Qbs" in 3 days and countless > emails here on the mailing list. I seem to wonder if the whole issue > could be avoided if it was approached a bit more diplomatically from the > Qt Company's side. After all there is a point of you advertising the Qbs > as the future before. The Qt Project has large community and maybe if you > tried to hand it over to someone else in it things would not accrue > nearly as much controversy. For example publically looking for a new > maintainer with the goal to have it purely community driven in a year > (and announce it as such). Rather than dropping the bomb-like title such > as "Deprecation of Qbs". > > > > It is a differnet situation to deprecating of an old technology (like Qt > Quick Controls 1), isn't it? You are not doing it with Qbs on technical > grounds but rather on business grounds so giving it the same treatment > is just wrong in my opinion. Since your plan is to invest in it for a > year anyway it would be better to spend that time (and money) on actively > working to hand it over to someone. There have been people (and > companies) in this very mailing list (and Qbs one) that said they would > take it over. Announcing it to the world and waiting for the community to > magically appear and contribute did not work during Qbs' life under the > Qt Company (although after you invested in the docs its usage started to > spike this year) so please do not make the same mistake again and give it > a chance for real this time by _actively_ trying to hand it to someone > else. Thanks, Michael. This eMail contains pretty much what I have been thinking during the last days as well. Well written. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build system for Qt 6
On 30.10.2018 18:14, NIkolai Marchenko wrote: > For anyone interested in QBS survival, let's fill the sheet with QBS > ecosystem. > Maybe if we show TQtC that people are actually using it they will reconsider. > > Post your projects (and ones you know of) here: > > https://docs.google.com/spreadsheets/d/1CwXx2F1zuATYY3GGOTkFgDB9jwMPghf6az_RVOnskfk/edit#gid=0 FWIW: Typing "filetype:qbs site:github.com" in google gives me 622 results. Narrowing the search down by "Project filetype:qbs site:github.com" gives me 271 results. I don't know how to filter out duplicates nor forks of Qbs and QtCreator. I also don't know enough about search engines to see whether the user base of Qbs is growing or declining. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build system for Qt 6
> Can you name any project of moderate complexity using it? https://github.com/bjorn/tiled ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build system for Qt 6
> Qbs is something that has been developed almost exclusively by The Qt > Company. As such, TQtC had to also look at it from a business perspective > and how it fits into the larger picture of making Qt successful. To make > a long story short, while Qbs is pretty cool and interesting technology, > it doesn’t really help us expand the Qt ecosystem and usage. Qbs has made the development of multi-platform applications with multiple libraries a breeze for me. Even projects that contain firmware for different target architectures in addition to a Qt application are no problem at all with Qbs. Thanks to Qbs, I can focus on code and not on the build system. I achieve more in less time. I always thought that Qbs was a great example for using QML. > To make Qbs really successful would require a rather large effort and > investment in promoting it towards the larger C++ ecosystem as a new > build tool. At the same time it has to be an open source product to stand > any chance in the market. Together this makes it challenging for TQtC to > see how to recover that investment. Thus this investment would be at the > expense of other things we’d like to do, like improving our IDE, working > on rearchitecting and cleaning up our core frameworks for Qt 6 or the > design tooling we are currently investing into. The Qt Company believes > that those other investments are more important for the future of Qt than > our choice of build tool. It seems that Qbs never got much traction within the Qt Company either. Outside the regular blog posts, I don't see any attempt to promote Qbs anywhere. Correct me if I'm wrong. I may have noticed that Jake Petroules did his best to get the word out, but I guess that was his private mission rather than his official role in the Qt Company. What I can't complain about is the unprecedented dedication and professionalism of Christian, Jörg and Jake on this project. Also all support questions were answered in lightning speed. > As such, we were left with the question on whether we need Qbs as the > build system for Qt 6 or whether cmake (as the other alternative) would > be up to the task. > [..] > Given that we are confident we can build Qt 6 with cmake, I believe that > it makes most sense to follow down that route. In case you’re interested, > you can have a look at the cmake prototype code for qtbase on Gerrit in > the wip/cmake branch. Please also let us know if you’re interested in > helping with the effort of porting Qt’s build system over to cmake. > > We have been developing Qbs over the last years, and as such are > committed to it for some more time. We are planning on another feature > release in the first quarter of next year and will support it in Qt > Creator for at least another year. Qbs is open source and if someone > wants to take over and develop it further let us know as well. I’d also > like to use this place to thank Christian and Jörg for all their great > work on Qbs (and of course also anybody else who contributed to it). How can we leverage from the next half year to smoothly turn Qbs into a community-owned OS project? Does anybody know a positive role-model for this? I don't want to miss out on the productivity gains I've made with Qbs, but on the other hand I have very little free time. However, I would voluntarily contribute to the documentation of Qbs. Richard ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 6 buildsystem support requirements
>> How much custom c++ code does it contains for just qt? > > which build system which supports automatic calling of moc doesn't have > specific code for qt ? Qbs :-) At least no C++ code. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTBUG-43096 - QML instantiation performance decadence
> There are JavaScript interpreters for microcontrollers (see Duktape and > Jerryscript). But those are designed to run on tens of *kilobytes* of RAM. > You > can't compare them to Qt, as they have special limitations to run that way. > For example, neither implementation supports "eval". I wonder if those tiny devices with tens or even hundreds of kilobytes RAM running Jerryscript would be already sufficient for a "QML light". I am not talking about QML GUIs, but rather simple sensor/actor applications consisting of few state machines and using one of the 1001 available communication stacks. MCU vendors usually offer and praise their own C SDKs, but my experience so far is that it can take a very long time to achieve even simple applications and one has to write either a lot of boilerplate code or use fragile and obscure tools. QML has some powerful features that feel like a quantum leap when compared to C: - property bindings - easy component composition - signals, signal handlers - ... If we had nice QML modules like Qt Bluetooth and Qt Sensors available for tiny devices, I believe that application development would become very simple and convenient. I am making a few assumptions here: - the whole application structure would be static, no dynamic loading of components - bindings are resolved at build-time. - the application would be compiled to bytecode on the host before being flashed onto the target - the back-end of those modules would most likely not be Qt - it would be possible to deduce, which features the QML application actually uses so that unused functionality can be dropped at build-time. I would be interested in other opinions. Maybe I am on a completely wrong track here. Richard ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
