Re: [Development] Playground Request: ClapInterface

[Jean-Michaël Celerier]

As someone involved in the audio ecosystem, the Clap plug-in API is quickly
becoming an industry standard,
is now supported by multiple digital audio workstation software (Reaper,
Bitwig, qtractor) and a recurrent topic in audio conferences and circles.
It has its own wikipedia page:
https://en.wikipedia.org/wiki/CLever_Audio_Plug-in

- 12 pages of products using CLAP on KVR:
https://www.kvraudio.com/plugins/the-newest-plugins/clap-plugins
- https://github.com/free-audio/clap
- https://u-he.com/community/clap/
- https://lwn.net/Articles/893048/
-
https://www.sweetwater.com/insync/clap-the-new-clever-audio-plug-in-format/
- https://www.martinic.com/en/blog/clap-audio-plugin-format
- https://bedroomproducersblog.com/2022/08/29/clap-plugin-format/


Never heard of the other one.

On Mon, Mar 18, 2024 at 12:11 PM Volker Hilsheimer via Development <
development@qt-project.org> wrote:

> > On 18 Mar 2024, at 12:27, Dennis Oberst via Development <
> development@qt-project.org> wrote:
> >
> > Hello all,
> >
> > I'd like to request a new playground repository to continue the
> development of the "Clap Interface," a client-side library that uses QtGrpc
> to provide integration with the CLAP audio plugin standard, ultimately
> allowing to build audio plugins with Qt user interfaces.
> >
> > Description: Qt interface for the CLAP audio-plugin standard
> > Project name: qtclapinterface
> >
> > The Clap Interface emerged from the research concluded in my thesis,
> which you can find and read here. As its counterpart, there is the
> 'clap-rci' library, which provides the server-side integration. I won't go
> into too much detail, but it works through headless audio processing and
> remote GUIs to achieve integration with Qt. You can find it here.
> >
> > Given the time constraint of 6 months for writing 2 libraries and a
> thesis, they have some rough edges. Nevertheless, they proved my point: Qt
> integration with audio plugins is possible! I'm currently in the process of
> rewriting those libraries in my free time, but I would still like to have
> this version openly available.
> >
> > Suggestions/Opinions/Ideas, I take them all.
> >
> > best,
> >
> > Dennis
>
> Hey Dennis,
>
> Nice, seems like a cool use case of gRPC for building out-of-process
> plugins!
>
> My knee-jerk reaction is that it might be a good idea to spell this out as
> QCleverAudioInterface, because
>
> https://github.com/LAION-AI/CLAP
>
> which, while also “something audio”, is completely not related, so perhaps
> better to be verbose.
>
> And I’m not entirely sure that “Interface” is the right word... since it
> seems to be more an integration or bridge, perhaps?
>
> Volker
>
> --
> 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] Should QObject::event() be protected or public?

[Jean-Michaël Celerier]

There's nothing more frustrating that instantiating a C++ type on the stack
like

 MyType foo;

and having to call a function with:

 static_cast(foo).someVirtualMethod();

because "The base class is the interface" and all the
overriding methods are marked private.
This is just adding bureaucracy for absolutely no good reason and doesn't
help *anyone*.

On Fri, Mar 15, 2024 at 1:32 PM Christian Kandeler via Development <
development@qt-project.org> wrote:

> On 3/15/24 18:09, Marc Mutz via Development wrote:
> > I like simple rules. "Overrides should have the same access level as the
> > initial virtual function." is a simple rule.
>
> But it makes no sense in general. The base class is the interface, and
> overrides should have the least possible visibility for their purpose.
>
>
> Christian
>
> --
> 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] Using '#pragma once' instead of include guards?

[Jean-Michaël Celerier]

>The only way you’d have a strong case with this is if it has some other
significant benefit, like compilation speedup.

The main benefit to me is that it entirely removes possibilities for
conflict due to headers having the same name. At least Qt takes great care
of avoiding this but still, notice that e.g. the authors of Qt3D's
Qt3DCore::QTransform had to be careful to not just do #ifndef QTRANSFORM_H

Now what happens when someone develops a different library but with a
header guard similar to Qt's?

If I grep into the various cloned projects on my hard drive, for instance I
see

#ifndef QRENDERER_H
#ifndef QGLRENDERER_H
#ifndef QSEARCHFIELD_H
#ifndef QLOG_H
#ifndef QJACK_H
#ifndef QENC_H
#ifndef QRANGESLIDER_H
#ifndef QDOUBLERANGESLIDER_H

etc... is the Qt project 100% confident that it will *never ever* use these
names? With pragma once this is a 100% non-problem.


On Thu, Oct 13, 2022 at 9:10 AM David Skoland via Development <
development@qt-project.org> wrote:

> Hi,
>
> Using #pragma once does make assumptions about filesystems and compilers,
> which in turn makes assumptions about how Qt is installed and included
> (and we’ve seen a handful of…. creative examples of both).
>
> This results in risk to developers who *use* Qt (many), which must be
> weighed against convenience for developers who *develop* Qt (few). It
> seems like a hard sell. The only way you’d have a strong case with this is
> if it has some other significant benefit, like compilation speedup.
>
> Cheers,
> David Skoland
>
> On 12 Oct 2022, at 13:25, Hasselmann Mathias 
> wrote:
>
> Sounds like an excellent plan.
>
> Ciao
> Mathias
>
> Am 12.10.2022 um 12:35 schrieb Volker Hilsheimer via Development:
>
> On 11 Oct 2022, at 22:11, Thiago Macieira 
> wrote:
>
> On Tuesday, 11 October 2022 12:25:13 PDT Kyle Edwards via Development
> wrote:
>
> Speaking as co-maintainer of CMake, we have effectively required #pragma
> once to build CMake itself since August 2017, we officially codified
> this as policy in September 2020, and we will soon be writing a
> clang-tidy plugin to enforce this in our CI. We have not received any
> complaints about it. Just my $0.02.
>
> Thanks for the information. This confirms what we already knew that all
> systems
> and compilers where Qt would be compiled do support it.
>
> However, neither Qt Creator nor CMake are libraries. They are not
> comparable.
>
>
> Thanks all for sharing your insights and digging up the previous
> discussions as well.
>
> The summary of all this then seems to be:
>
> - ok to use '#pragma once’ in headers that are not designed to be included
> by Qt users, i.e. in tools, applications, examples and demos, tests
> - for everything else, in particular for public and, for consistency’s
> sake - private headers in Qt, we continue to use conventional include guards
>
> Rationale: #pragma once is not well enough defined and not part of the
> standard, and we cannot make any assumptions about how Qt is installed,
> used as part of a larger SDK etc. So best to stay conservative.
>
> If that’s not entirely off, then I’d like to put this into
> https://wiki.qt.io/Coding_Conventions [1], preempting perhaps a new
> thread on this topic in a few years.
>
> Volker
>
> [1]: And since that page seems rather outdated - e.g. we do use
> dynamic_cast in Qt today, and the suggestion to normalize signals and slots
> should rather suggest to make connections via PMF syntax - perhaps it’s
> time to move this to a QUIP where we can discuss and review such changes in
> gerrit. I won’t have time to do that for a while (perhaps ditto for
> https://wiki.qt.io/Qt_Coding_Style), but perhaps someone else wants to
> give this a shot.
>
> ___
> 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
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Updating x86 SIMD support in Qt

[Jean-Michaël Celerier]

Re. wasm, as far as I know it's 32-bit (not x86 at all) but with a
compatibility layer provided by emscripten
which allows sse & avx intrinsincs to be translated to either equivalent
vector instructions in the wasm bytecode,
or shims which do it manually.

Cheers,

------
Jean-Michaël Celerier
*cto* ossia.io | *consulting inquiries* celtera.dev | *personal*
jcelerier.name
t: +336 81 31 53 08


On Wed, Jan 19, 2022 at 4:30 PM Thiago Macieira 
wrote:

> On Tuesday, 18 January 2022 20:56:10 PST Lorn Potter wrote:
> > wasm is a special case, as we turn it off by default, regardless of
> > detection. We cannot allow detection by default (specified by some
> > configure argument which is currently -sse2) because browsers do not
> > support it by default, and there is no way to just not use it once it is
> > compiled in.
>
> Hello Lorn
>
> Please explain. What architecture is WASM producing binaries for? Is it
> 32-bit
> i386? Or is it 64-bit x86-64? Because the latter requires SSE2 to do
> floating
> point.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel DPG Cloud Engineering
>
>
>
> ___
> 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] QThread::create mandatory in Qt 6?

[Jean-Michaël Celerier]

(It also has the very nice feature of using lld on windows, which links
mch faster than bfd / gold, which
could be useful for reducing CI times)
<http://www.jcelerier.name>


On Fri, Nov 20, 2020 at 9:27 PM Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:

> > The big problem I see on Windows is unfortunately not the C++ standard
> library, but the C standard library. MinGW defaults to crtdll, the one
> from
> MSVC 6, which is not C99-compliant (MSVC 6 is from 1998 after all). A
> better
> alternative exists in the form of the Universal CRT, but that only comes
> by
> default with Windows 10, so we'd need to drop support for 8.1 -- have we
> done
> that? -- and recompile GCC and/or LLVM so they ask the linker to link to
> ucrt.
>
> https://github.com/mstorsjo/llvm-mingw can be made to target ucrt; it
> even has
> releases: https://github.com/mstorsjo/llvm-mingw/releases/tag/20201020
>
> As a data point, I've been using this toolchain for my own stuff for a
> couple years now
> and it works really well, though I only exercise
> qtbase/qtdeclarative/couple of smaller libs.
>
> All the best,
> Jean-Michaël
>
>
> On Fri, Nov 20, 2020 at 5:09 PM Thiago Macieira 
> wrote:
>
>> On Friday, 20 November 2020 00:09:46 PST Oliver Wolff wrote:
>> > The question is not about having one more supported Windows
>> > configuration. We do not have the resources to add more and more
>> > configurations to support, so it's more a "replace mingw for Windows
>> > with something else" situation. As there seems to be a need for an open
>> > alternative, it looks like we cannot/should not go the clang-cl way, but
>> > clang-mingw if we replace mingw with a clang toolchain.
>>
>> That is not an option. We must have one MinGW configuration.
>>
>> We can choose which compiler and which version thereof, especially if the
>> official MinGW comes with an old GCC. If we think Clang + libcompiler-rt
>> +
>> libc++ is a better solution for Windows, then we should explore it and
>> even
>> make it the default. But unless we do it RIGHT NOW, we will need an
>> overlap
>> period with a libstdc++ MinGW, due to ABI break.
>>
>> The big problem I see on Windows is unfortunately not the C++ standard
>> library, but the C standard library. MinGW defaults to crtdll, the one
>> from
>> MSVC 6, which is not C99-compliant (MSVC 6 is from 1998 after all). A
>> better
>> alternative exists in the form of the Universal CRT, but that only comes
>> by
>> default with Windows 10, so we'd need to drop support for 8.1 -- have we
>> done
>> that? -- and recompile GCC and/or LLVM so they ask the linker to link to
>> ucrt.
>>
>> --
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>   Software Architect - Intel DPG Cloud Engineering
>>
>>
>>
>> ___
>> 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] QThread::create mandatory in Qt 6?

[Jean-Michaël Celerier]

> The big problem I see on Windows is unfortunately not the C++ standard
library, but the C standard library. MinGW defaults to crtdll, the one from
MSVC 6, which is not C99-compliant (MSVC 6 is from 1998 after all). A
better
alternative exists in the form of the Universal CRT, but that only comes by
default with Windows 10, so we'd need to drop support for 8.1 -- have we
done
that? -- and recompile GCC and/or LLVM so they ask the linker to link to
ucrt.

https://github.com/mstorsjo/llvm-mingw can be made to target ucrt; it even
has
releases: https://github.com/mstorsjo/llvm-mingw/releases/tag/20201020

As a data point, I've been using this toolchain for my own stuff for a
couple years now
and it works really well, though I only exercise
qtbase/qtdeclarative/couple of smaller libs.

All the best,
Jean-Michaël


On Fri, Nov 20, 2020 at 5:09 PM Thiago Macieira 
wrote:

> On Friday, 20 November 2020 00:09:46 PST Oliver Wolff wrote:
> > The question is not about having one more supported Windows
> > configuration. We do not have the resources to add more and more
> > configurations to support, so it's more a "replace mingw for Windows
> > with something else" situation. As there seems to be a need for an open
> > alternative, it looks like we cannot/should not go the clang-cl way, but
> > clang-mingw if we replace mingw with a clang toolchain.
>
> That is not an option. We must have one MinGW configuration.
>
> We can choose which compiler and which version thereof, especially if the
> official MinGW comes with an old GCC. If we think Clang + libcompiler-rt +
> libc++ is a better solution for Windows, then we should explore it and
> even
> make it the default. But unless we do it RIGHT NOW, we will need an
> overlap
> period with a libstdc++ MinGW, due to ABI break.
>
> The big problem I see on Windows is unfortunately not the C++ standard
> library, but the C standard library. MinGW defaults to crtdll, the one
> from
> MSVC 6, which is not C99-compliant (MSVC 6 is from 1998 after all). A
> better
> alternative exists in the form of the Universal CRT, but that only comes
> by
> default with Windows 10, so we'd need to drop support for 8.1 -- have we
> done
> that? -- and recompile GCC and/or LLVM so they ask the linker to link to
> ucrt.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel DPG Cloud Engineering
>
>
>
> ___
> 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] QProperty and library coding guide

[Jean-Michaël Celerier]

> We are not casting these structs to or from anything though, do we?

...

>const auto *thisPtr = reinterpret_cast(reinterpret_cast(this) -
propertyMemberOffset);

sounds pretty much like the structs are indeed being casted to / from
anything <_<


On Fri, Jul 17, 2020 at 2:13 PM Ulf Hermann  wrote:

> >> The struct has no data itself, so ideally would be of size zero.
> >
> > I'm missing some piece of the puzzle: if you take action->text, and text
> > is a zero-size struct, how does the operator() applied to it figure out
> > which action needs to read the text property from? E.g. like so:
> >
> >> QAction *action = ~~~;
> >> auto prop = action->text;
>
> This already gives you the string. You cannot retrieve the property
> itself. You can alternatively do action->text() or action->text.value().
> They all do the same thing.
>
> The member to access in the private object is hardcoded in the generated
> implementation of value(). The public object to pick the private object
> from is retrieved by offset from the address of the property. moc
> generates code like this:
>
> qreal QQmlComponent::_qt_property_api_progress::value() const
> {
>  const size_t propertyMemberOffset =
> reinterpret_cast(&(static_cast *>(nullptr)->progress));
>  const auto *thisPtr = reinterpret_cast *>(reinterpret_cast(this) - propertyMemberOffset);
>  return thisPtr->QQmlComponent::d_func()->progress.value();
> }
>
> I see where you're coming from. If the address doesn't exist, this
> shouldn't be possible. However, no_unique_address does not mean that the
> object has no address. It just means that it can share the same address
> with other objects.
>
> best,
> Ulf
> ___
> 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] QProperty and library coding guide

[Jean-Michaël Celerier]

It does work "in practice", but from the answer I got on SO, it's still
technically UB.
If anyone wants to add another, more positive answer sourced from the
standard though it'd be very welcome :)

https://stackoverflow.com/questions/57823192/does-casting-an-empty-base-class-optimized-object-to-another-type-break-strict-a/57823574

All the best,
Jean-Michaël

On Fri, Jul 17, 2020 at 9:26 AM Lars Knoll  wrote:

>
>
> > On 16 Jul 2020, at 23:35, Thiago Macieira 
> wrote:
> >
> > On Thursday, 16 July 2020 13:16:41 PDT Giuseppe D'Angelo via
> Development
> > wrote:
> >> Il 16/07/20 12:43, Volker Hilsheimer ha scritto:
> >>> For pre-C++20 (where it’s possible to have zero-size structs), and for
> >>> compilers that don’t respect the [[no_unqiue_address]] attribute, all
> >>> these struct-instances are put into a union. In that case, a class
> using
> >>> QProperty will be larger (by the same amount no matter the number of
> >>> properties) than the same class in Qt 5. With C+++ 20 and compilers
> that
> >>> do respect [[no_unique_address]], the size and layout of these classes
> >>> will be the same.
> >> I'm not fully understanding this last part -- does changing compiler
> >> break ABI, because the implementation of properties change (from an
> >> union to [[no_unique_address]] members)?
> >
> > Yes.
> >
> > Already sent a -2 to the commit that added this support, because it
> can't
> > work. The commit will need to be reverted.
>
> Yes, it can and it does work. And it’s what we should be doing on
> compilers that support [[no_unique_address]].
>
> It does mean that a pure C++17 and a C++20 build aren’t binary compatible,
> but I think we should pay that price.
>
> If I remember correctly, the only compiler that doesn’t yet support it is
> MSVC. BC mainly matters on desktop Linux and those all support the feature,
> so we can enable it from the get go.
>
> Cheers,
> Lars
> >
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> >  Software Architect - Intel System Software Products
> >
> >
> >
> > ___
> > 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] Switch the main "Qt Build System"

[Jean-Michaël Celerier]

Opening the root qt5/CMakeLists.txt has worked fine for me to work on e.g.
qt3d through QtCreator - did not really notice any performance penalty from
opening the whole project (except the initial "configure" step).

Kind regards,
Jean-Michaël



On Tue, Jun 9, 2020 at 10:05 AM Andy Nichols  wrote:

> Hi Alexandru,
>
> I think Brett touches on the biggest blocker for me and that is actually
> related to Qt Creators ability to open and use modules built using cmake.
> I am actually really impressed with state of the CMake support for build Qt
> as it is right now, and wish I could more actively use it, but
> unfortunately my current workflow involves using Qt Creator to develop Qt,
> and I have to work on modules that are not just QtBase.  Despite adding my
> cmake based Qt Builds to Creator as kits (which seems to only be possible
> using qmake), it isn't possible for Creator to easily recognize that my
> module's are built with that kit when loading them.  I hear rumors that it
> is possible, but most of the guys who say that are only working on qtbase
> anyway.
>
> I think that before we kill the qmake based build of Qt, that our own IDE
> should support developing Qt itself.  And I would be happy with some
> "sketchy config" that works with a released version of Qt Creator for now,
> but this shouldn't be good enough to justify killing qmake before a real
> solution is in place.
>
> Regards,
> Andy Nichols
>
> -Original Message-
> From: Development  On Behalf Of
> Stottlemyer, Brett (B.S.)
> Sent: Monday, June 8, 2020 6:48 PM
> To: Alexandru Croitor 
> Cc: Qt development mailing list 
> Subject: Re: [Development] Switch the main "Qt Build System"
>
> Hi Alexandru,
>
> Thanks for the quick reply.
>
> On 6/8/20, 12:09 PM, "Alexandru Croitor"  wrote:
>
> The current CMake configurations can be found in
> qt5.git/coin/platform_configs/qtsvg.yaml (and many other .yaml files there,
> it's just copy-pasted).
>
> Ahh, I didn't understand what these module specific versions were for.  I
> guess you download the dependencies (like qtbase) with the expected sha and
> same config, rather than building again?  That makes sense.
>
> There was an email on the development list about qt 6.0 module
> inclusion.
> https://clicktime.symantec.com/3Y88fCHSqah7h6p9gH8GzbV7Vc?u=https%3A%2F%2Fwiki.qt.io%2FChecklist_for_Qt_6.0_inclusion
>
> Yes, I'm aware.  That's where I see a lot of modules with no response or
> NOT READY as the status.
>
> If the module is not included (no cmake port), you can start using the
> dependencies.yaml mechanism to pin which sha1s of qtbase, declarative, etc
> to use, and continue building against those sha1s with qmake. Of course
> once the .pro files in qtbase are gone, you will be stuck to the last set
> of SHA1s that still have the .pro files. See dependencies.yaml in
> qtquickcontrols2.git for example.
>
> We have a qmake mixing mechanism (build qtremoteobjects with qmake
> against a qtbase built with CMake), but it's not 100% ready yet (the known
> issues are being fixed), and thus modules could continue to build with
> qmake against even newer sha1s, but I wouldn't bet too much on this
> approach (we tried our best to make it work, but there are bound to be
> corner cases even after we fix the known issues).
>
> I'll suggest "qmake mixing" be a prerequisite to flipping the switch to
> cmake.  It is hard enough to port to Qt6 with the binary
> incompatibilities.  If you make the build system side of this too painful
> as well, you risk modules not being carried to Qt6.  I know it is a
> different topic, but I am unable to open a developer build of qtbase (from
> cmake) in QtCreator - it wants to configure the project again (not to
> mention trying to get Ninja in the path for QtC on mac).  This all makes it
> hard to be an "early adopter", but doing the work later means you have to
> tackle all of these issues at once.  Without CI, presumably, after this
> change (at least for modules).
>
> I'm not arguing against the change, just want you guys to keep in mind
> what this is like for those of us that haven't been developing in Qt6 from
> the start.
>
> Thanks,
> Brett
>
> ___
> 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] Switch the main "Qt Build System"

[Jean-Michaël Celerier]

To simplify this step, is there / could there be maybe a
-DQT_BUILD_TOOLS_ONLY that would just generate... well, moc, uic, rcc and a
couple other friends required for a cross-build ?

Best,
Jean-Michaël


On Tue, Jun 9, 2020 at 10:14 AM Alexandru Croitor 
wrote:

>
>
> > On 9. Jun 2020, at 07:22, Bogdan Vatra  wrote:
> >
> > - is it possible to cross compile Qt in one go (just like we do with
> qmake)?
>
> Could you clarify what you mean by "in one go"?
>
> If it's about building host tools as part of the cross-compilation, then
> no. You first have to build a desktop Qt, and re-use that host Qt
> installation for its tools, to cross-compile to another target.
>
> That's been one of the goals for Qt 6 regardless of build system, and has
> been communicated a while ago.
> ___
> 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] Views in APIs

[Jean-Michaël Celerier]

> To have type-erased containers, we need to go back to something like
java.lang.Collection.

C++20 offers coroutines which allows the same things without java-like type
hierarchies though
(and with much more flexibility as you don't even need to have an actual
container existing somewhere - your function's stack
can serve as one just fine :p).

see e.g. https://godbolt.org/z/cEv7Gp - in simple cases it optimizes as
well as as a std::vector.

Well, for Qt 7 maybe :-)


On Thu, May 14, 2020 at 9:00 PM Thiago Macieira 
wrote:

> On Thursday, 14 May 2020 02:33:43 PDT Marc Mutz via Development wrote:
> > On 2020-05-14 02:15, Thiago Macieira wrote:
> > > On quarta-feira, 13 de maio de 2020 01:41:26 PDT Иван Комиссаров wrote:
> > >> std::span Project::productsSpan() const & { return
> > >> d->products; }
> > >> std::span Project::productsSpan() const && = delete;
> > >
> > > Now implement either or both of these functions if internally you have
> > > a
> > > QSet.
> >
> > Now implement QHash roleNames() when
> > internally you have a std::pmr::unordered_map > std::pmr::string>, with all the data allocated from one
> > std::pmr::monotonic_buffer_resource.
> >
> > This does both ways.
>
> No, it doesn't. In both you created a copy on demand.
>
> But you can only *return* said copy if the return type is an owning
> container.
> std::span and the views are not.
>
> > And: you can also have views over associated data structures, they just
> > can't have inline functions because they need to type-erase the
> > container. For an extreme example, consider QAssociativeIterable.
>
> Which is:
> a) a horrible API
> b) misspelling "iteratable"
>
> To have type-erased containers, we need to go back to something like
> java.lang.Collection.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> 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] How bad QList really is

[Jean-Michaël Celerier]

> As starters, there are 85 occurences of QList::takeFirst() in Qt Creator
source code. Replacing these with QVector replaces a O(1) operation
with an O(n) operation.

Apologies if I'm wrong, but isn't QList::erase (and anything derivative)
always O(N) ?
With a lower cost than std::vector for things with sizeof > 8, sure, but
still.
And, given that 98% of QList usage seems to fall into the "good" case of
sizeof<= 8, wouldn't that make zero change when switching to QVector ?

Best,
Jean-Michaël
On Mon, Apr 27, 2020 at 11:29 PM André Pönitz  wrote:

>
> On Mon, Apr 27, 2020 at 11:13:26AM -0400, Matthew Woehlke wrote:
> > On 25/04/2020 10.49, André Pönitz wrote:
> > > We all know the story that began with
> > >
> > >  "We knew for a long time that QList is not a good default
> > >  container, despite what the documentation claims. The problem
> > >  boils down to the fact that for a lot of types T, QList is
> > >  needlessly inefficient by allocating elements on the heap and
> > >  storing pointers to them instead of storing the elements
> > >  in-place, like e.g. QVector does. Sometimes, for large and
> > >  complex types, that might be exactly what you want, but a
> > >  conservative estimate would put that chance at less than 5%." [1]
> > >
> > >
> > > I was curious how this "conservative" estimate of "less than 5%"
> > > manifests in real QList object instances in a real world example.
> >
> > (Remainder elided)
> >
> > Thanks for the analysis! However, it seems the major take-away is that
> > "when QList acts like QVector, all is well"?
>
> No. The major take-away is that in the first reality check on the topic
> 98.5% of the cases QList behaves optimally, and in 1.4% the jury is still
> out.
>
> Even if the jury comes back with a verdict that all the remaining cases
> were better served by QVector (unlikely, see below) a shot-gun
> replacement of QList would at best change 1 out of 70 instances, placing
> the whole activity safely into micro-optimization land.
>
> > It would be interesting to see a comparison that ignores all instances
> > where QList is behaving like QVector.
>
> This would indeed help us to understand how small the micro in this micro
> optimization is, or whether we are actually looking at a pessimization.
>
> As starters, there are 85 occurences of QList::takeFirst() in Qt Creator
> source code. Replacing these with QVector replaces a O(1) operation
> with an O(n) operation. This may or may not be a problem in practice,
> in any case, all such uses would need to be audited. Similarly removeAt,
> removeOne and removeAll have a chance to degrade in performance.
>
> Andre'
>
>
> PS:
>
> > The other problem is that performance isn't the only story. Sometimes,
> > reference stability is desired. AFAIK, the only containers in Qt¹ that
> > provide this currently are QLinkedList and QMap.
> > (¹ I speak of Qt6, specifically. In Qt5, QHash could be added to that
> list,
> > but no more.)
>
> Sure, but that's a different topic.
>
>
> ___
> 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] Proposal: Deprecate QVector in Qt 6

[Jean-Michaël Celerier]

> I however want some generic indexable/iterable type, where it doesn't
care if the final storage is QList or  QVector... When I am working as an
API, I don't want to choose for my users what that type is and make them
pay for conversion. Which I think QList was historically the right choice.
Ideally I want to have a QIterable for processing lists/arrays/vectors. I
think the developer should be able to determine the storage best for their
application, not me.

I believe that all sort of woes come to those wanting to make C++ look more
like Java / C# with their AbstractCollection / IEnumerable ;
every time I've seen people try to go towards that path it has ended in
pain and tears and ultimately reverting to std::vector as the benefits did
not
outweight the drawbacks by a large margin.

C++20 coroutines start making that much more feasible however, like this
for instance and without creation of unnecessary temporary containers:
https://godbolt.org/z/gNsbjc
(it remains to be benchmarked whether the coroutine frame can be optimized
sufficiently well in comparison to returning a container, considering
that both clang and GCC nowadays are able to optimize out new / delete
pairs... I'd be inclined to believe that the compiler has more domain
knowledge
of the coroutine though and thus is able to make better choices).

Maybe something for Qt 8 or 9 ? :p

Best,
Jean-Michaël

On Sat, Apr 25, 2020 at 2:23 AM Jason H  wrote:

>
>
> > Sent: Friday, April 24, 2020 at 4:14 PM
> > From: "Giuseppe D'Angelo" 
> > To: "Jason H" 
> > Cc: development@qt-project.org
> > Subject: Re: [Development] Proposal: Deprecate QVector in Qt 6
> >
> > On 4/24/20 9:03 PM, Jason H wrote:
> > >> In fact, it is-a QList. What's the problem here with its
> naming?
> > >
> > > Because I can't QSringList{"me", "you"}.join() with a QList.
> >
> > I didn't say that it's a typedef for QList, but is-a -- it
> > inherits, precisely to provide that kind of convenience.
> >
> > > Thinking outsize of the box...
> > > It seems that all this is cause d by someone wanting to store a
> pointer to an item in QVector, which may be reallocted and therfore have
> moved.
> >
> > All this => what's this?
> >
> > > It seem then that the only thing to do is to use a traditional QList,
> or return only some kind of ref which will be a stable reference to the
> item.
> > > QStableRef r9 = vector[9];
> > > vector.resize()
> > > // r9 is updated during resize() and still points to that it was meant
> to.
> > > It's not good practice to store a ref to something that can be
> realloated. I don't know how you can prevent people from doing that with
> offering T& operator[](int i);
> >
> > QList today offers exactly that. In array-of-pointers-mode it also
> > offers stability of references.
>
> Yes. I agree. I think the OP kicked this off with a thing about soring
> refs to items in QVector which is relocatable. My post was just to say this
> is a bad idea fro QVector. This is not immediately obvious though. The
> API/docs fail to communicate that storing pointers/refs to items is a bad
> idea. Which then as me agree with you and Lars's current thinking.
>
> I however want some generic indexable/iterable type, where it doesn't care
> if the final storage is QList or  QVector... When I am working as an API, I
> don't want to choose for my users what that type is and make them pay for
> conversion. Which I think QList was historically the right choice. Ideally
> I want to have a QIterable for processing lists/arrays/vectors. I think the
> developer should be able to determine the storage best for their
> application, not me.
>
> Side note:
> It also kicked off a thing in my brain about .NET and the managed runtime,
> where C++ on .NET got ^, the handle operator, which allows dereferencing to
> items given that everything is relocatable due to memory compaction. I
> think it could be a great thing if C++ has such a thing, as I attribute 99%
> of all long boot time lockups on Raspberry Pis to memory fragmentation
> (completely anecdotally) And if C/C+ could offer some kind of memory
> management beyond malloc/free, we could get the next 99% of lockups and
> random crashes avoided.
> ___
> 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] GitHub Pull requests

[Jean-Michaël Celerier]

> otherwise we may end up accepting contributions from Twitter :)

what is the problem if they improve the code  ?

On Tue, Mar 10, 2020 at 3:49 PM Konstantin Tokarev 
wrote:

>
>
> 10.03.2020, 17:42, "Cristian Adam" :
> > Hi,
> >
> > With the “GitHub issues” E-Mail thread we made sure the Issues are gone
> >
> > from the projects.
> >
> > What about Pull requests?
> >
> > For example qtbase has 7 pull requests.  Usually people point out that
> >
> > the Qt project uses a different collaboration method:
> >
> > https://wiki.qt.io/Qt_Contribution_Guidelines
> >
> > What stops us from accepting the contributions via GitHub?
> >
> > Is it:
> >
> > * The CLA
> > * Qt Account
> >
> > For the CLA one can simply add an instance of:
> >
> > https://github.com/cla-assistant/cla-assistant
> >
> > And it’s only one click away.
> >
> > When I contributed to vcpkg, the process of signing the Microsoft
> >
> > CLA was like that, one click.
> >
> > Regarding Qt Account, maybe one can use the GitHub account to
> >
> > create a Qt Account via openid.
> >
> > With GitHub actions (or Azure Pipelines, like vcpkg) we can also validate
> >
> > the pull requests.
> >
> > We should encourage developers to contribute to Qt, not having to learn
> >
> > how to use gerrit, and using a workflow that they are familiar with,
> should
> >
> > be a plus.
>
> I think, lowering barrier of entry at expense of reviewers' convenience
> should
> have its limits, otherwise we may end up accepting contributions from
> Twitter :)
>
> --
> Regards,
> Konstantin
> ___
> 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] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Jean-Michaël Celerier]

> I may need to write that patch myself.

Would you consider instead a patch introducing a builtin that allows a
library to declare attributes they "support" ?
eg something in the taste of __builtin_declare_valid_attribute("qt::emit");

A far cry from attribute creation abilities of languages such as C#[1] or
Java but
better than nothing.

This way typo detection could happen with [[qt::emitt]] for instance (or
more likely people trying [[Qt::emit]] or [[QT::emit]]).

Best,
Jean-Michaël

[1]:
https://docs.microsoft.com/en-us/dotnet/standard/attributes/writing-custom-attributes


On Thu, Feb 27, 2020 at 1:41 PM Ville Voutilainen <
ville.voutilai...@gmail.com> wrote:

> On Thu, 27 Feb 2020 at 09:15, Alex Blasche 
> wrote:
>
> > >In general, implementations can still warn about pretty much whatever
> > >they please, especially considering
> > >that their default modes are not strictly conforming.
> > >
> > >The compilers we plan to support in Qt 6 do warn about unknown
> > >attributes, so the allowance point is kinda
> > >theoretical.
> >
> > Ville, please help me understand sth. If the express intention of
> attributes is that users should be encouraged to have their own, aren't the
> warning policies exhibited by current compilers counter productive to the
> intent of their intended purpose? Or do attributes mostly exist for the
> purposes compilers themselves may face?
>
> They are counter-productive, yes. The compilers overreach, see below.
>
> > Also what's the chance that compiler communities might accept Qt
> specific attributes if for example TQtC were to put relevant patches
> forward?
>
> The chance is very good; I talked about this with the maintainer of
> GCC already, and he was amenable to disabling
> an "unknown attribute" warning if the attribute has a namespace. For
> attributes that don't have namespaces,
> diagnosing unknown attributes allows diagnosing typos, so it's
> unlikely that all such warnings would be axed.
>
> I may need to write that patch myself. In any case, such solutions
> don't help GCC 9.x users or users of earlier
> GCC 10.x versions, in case the patch wouldn't hit GCC 10.
>
> I think the chance of success is similarly good with clang; the case
> for not complaining about namespaced
> attributes is fairly clear. But that change isn't something I have
> time to patch into clang. I haven't looked at
> MSVC or other compilers.
> ___
> 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] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Jean-Michaël Celerier]

> I don't think semantics matter here. It is all about annotation and
readability. With the same arguments we design APIs. While Kai's survey is
inconclusive about the actual solution, it is conclusive in one aspect.
There is a clear majority to have sth in place for annotation/readability
purposes.

You should I think take into account that the whole C++ community manages
to do just fine without annotating calls to std::function (or
$any_other_signal_slot_library_in_the_universe) in the same way - even
though all of the "dangers" can still apply.

On Wed, Feb 26, 2020 at 9:18 AM Alex Blasche 
wrote:

>
>
> > -Original Message-
> > From: Development  On Behalf Of Lars
> > Knoll
>
>
> > I’m not trying to make this only about emit. But it’s the concrete
> problem we’re
> > facing now, and emit is IMO the one keyword where we simply don’t need a
> > replacement because it has no real semantic meaning in C++.
>
> I don't think semantics matter here. It is all about annotation and
> readability. With the same arguments we design APIs. While Kai's survey is
> inconclusive about the actual solution, it is conclusive in one aspect.
> There is a clear majority to have sth in place for annotation/readability
> purposes.
>
> > > Qt relies on macros a lot, and while I have not followed the latest
> Modules
> > development, I'm sure macros pose a problem for a modularized Qt, too
> > >
> > > So while emit is the latest in the line of macro clashes, it's not the
> first and it
> > likely won't be the last. So, please, just removing 'emit' because it's
> easy doesn't
> > solve the problem for `signals` and `slots`.
> > >
> > > Can access specifiers have attributes?
> > > public [[qt::slots]]:
> > > 
> >
> > Why do we need it, if functions can already have attributes?
>
> Because it is in the wrong spot. I want to spot the signal call in a cpp
> file and not a header. I must assume that the reason why we had emit in the
> first place (besides "slots" and "signals") is the same.
>
> > public:
> > [[qt::slot]] void mySlot();
> >
> > protected:
> > [[qt::signal] void mySignal();
>
> I’d love to have this too (in addition to [[qt::emit]])
>
> --
> Alex
>
> ___
> 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] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Jean-Michaël Celerier]

A good inspiration for that feature would be the Just My Code feature of
recent visual studio :
https://docs.microsoft.com/en-us/visualstudio/debugger/just-my-code?view=vs-2019

Best,
Jean-Michaël

On Mon, Feb 24, 2020 at 8:51 AM Shawn Rutledge  wrote:

>
> > On 22 Feb 2020, at 12:57, Ville Voutilainen 
> wrote:
> >
> > On Sat, 22 Feb 2020 at 13:07, André Pönitz  wrote:
> >>> Buy a debugger that can skip code that you didn't write.
> >>
> >> The point was that in a such a situation I, as user, would not even
> >> try to step in when the call is marked with 'emit'. This 'emit' in
> >> a line *is* valuable markup, that saves me time.
> >>
> >> That's unrelated to what the debugger would or could do if I did step
> in,
> >> I just don't need to follow that path.
> >>
> >> [And apart from that: There's no need to *buy* such debugger, e.g. gdb's
> >> 'skip' actually works]
> >
> > It occurs to me that, in case Creator doesn't do that already, we could
> make its
> > debugger UI to automatically tell the underlying debugger to skip
> > moc-generated code,
> > as a default.
>
> I’m probably dreaming, but wouldn’t it be cool if it were possible somehow
> to “step into” each handler function that is connected, while skipping over
> the details of how we get there…. At least for direct connections.
>
> ___
> 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] Migrate QStateMachine from Qt Core

[Jean-Michaël Celerier]

What has lead to considering that they could eventually be removed ?

Couldn't they be split off in a separate library put in the marketplace or
github for instance if they're a thorn ?
No reason to throw away code that works, is there ?



On Thu, Feb 13, 2020 at 10:58 AM Karsten Heimrich 
wrote:

> Hi,
>
> we would like to remove the QStatemachine API’s from Qt Core. We
> identified 2 options to do this:
>
>
>
> * Move into QtScXML and keep both the implementation
>
> * rename the module to reflect that it contains 2 different state machine
> implementations
>
> * Move into Qt5Compat
>
> * in the long run this will lead to deprecation and
> removal of the QStateMachine API’s
>
>
>
> Right now we consider option 1, merging and keeping QStateMachine and
> QScxmlStateMachine. Still, I would like to collect some feedback/ ideas/
> objections, best would be as comments on
> https://bugreports.qt.io/browse/QTBUG-81848
>
>
>
> Thanks, Karsten
>
>
> ___
> 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] thread_local: replacing GCC with Clang for MinGW

[Jean-Michaël Celerier]

I'm using this toolchain to build qtbase, declarative, svg, websockets,
serialport and a few other : https://github.com/mstorsjo/llvm-mingw

I think that it has also been used for webengine.

Jean-Michaël

On Fri, Aug 23, 2019 at 8:16 PM Thiago Macieira 
wrote:

> Restarting the thread since it changed subjects many times and has gone
> back
> and forth.
>
> Simon wrote:
> > I ran into the crash a while ago in the CI. See also
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562 .
>
> That bug report shows that GCC does not properly implement thread_local on
> MinGW 32-bit over 8 years after the publication of the standard and over 4
> years after the feature became available on other platforms.
>
> I am proposing we make the C++11 thread_local feature mandatory and stop
> supporting any compilers that fail to support it.
>
> That would exclude GCC on MinGW 32-bit. 32-bit Windows GCC-compatible-ABI
> support would be provided by Clang.
>
> If this proposal seems acceptable, we need to see if it is technically
> feasible: can Clang/MinGW compile our codebase? And how does one go about
> installing it?
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> 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] HEADS-UP: QStringLiteral

[Jean-Michaël Celerier]

> Try *any* other compiler and you'll see there's no mutex.

Don't __cxa_guard_acquire / release use at least futexes ? I'd wager that
in a non-zero amount of applications, having *any* kind of  syscalls or
locks sprinkled here and there
depending on whether you use "static" or not is not kosher (I'd also wager
that these applications wouldn't be using Qt anyways... except maybe the
ones using that safe renderer thing ?).




On Tue, Aug 20, 2019 at 11:41 PM Thiago Macieira 
wrote:

> On Tuesday, 20 August 2019 14:25:27 PDT Philippe wrote:
> > > There's no mutex.
> >
> > On Visual Studio 2017 15.8.8,
>
> That's a broken compiler, a regression from 2015 and fixed on 2019. Try
> *any*
> other compiler and you'll see there's no mutex.
>
> Same bug that makes static with VS 2017 crash on start.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> 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] Assistant WebKit/WebEngine support

[Jean-Michaël Celerier]

> Feel free to correct/critique my assessment and to add more options if
you see any. Otherwise: chose your poison.

There's also Zeal which is a nice Qt-based documentation browser which
covers much more than the current .qch offering: https://zealdocs.org/ &
https://github.com/zealdocs/zeal

I see it used more and more.

Best,
Jean-Michaël


On Tue, Jun 25, 2019 at 11:54 PM Konrad Rosenbaum  wrote:

> Hi,
>
> On 6/25/19 9:59 PM, Tor Arne Vestbø wrote:
> > On 25 Jun 2019, at 21:30, Konrad Rosenbaum  wrote:
> >> Pardon my lingo,
> > You should be able to communicate your points without that kind of
> lingo. Try better.
> >
> >> It is documentation for developers for crying out loud! Its purpose is
> not to win any design prices, but to educate the developers.
> > Please stop putting up straw-men, it’s not helping this discussion at
> all.
>
> Okay, let's formulate this in a way that hopefully doesn't offend you
> and doesn't seem like a straw-man to you.
>
>
> Qt6 has a couple of options for documentation, none of them are ideal:
>
>
> Option 1: leave everything as is with a QTextBrowser based assistant and
> some tweaks in the qch files.
> Pros: no additional work required; all current features and use cases
> stay supported; good enough for a lot of developers
> Con: looks ugly enough to actually offend visually sensitive developers.
>
>
> Option 2: put some elbow grease into QTextBrowser and make it understand
> some more tags and more CSS.
> Pros: documentation becomes visually more pleasing; minimal dependencies
> by assistant - easy to build and easy to bundle with applications;
> embedding in Creator or KDevelop etc. stays easy to do
> Positive side effect: users will love it, since it becomes much easier
> and flexible to use QTextBrowser in their own applications
> Con: someone actually has to put in the work
>
>
> Option 3: bring back WebKit
> Pros: looks beautiful; uses up less memory than WebEngine
> Cons: someone has to put up lots of work to actually support WebKit;
> uses up lots more memory than QTextBrowser; adds a dependency to
> assistant (makes it less useful for redistribution); embedding in IDEs
> is slightly more complex and adds a dependency
>
>
> Option 4: convert to WebEngine
> Pros: looks great; currently supported browser engine, only little
> porting work
> Cons: horrible memory footprint; acute terminal featuritis; adds lots of
> dependencies (disqualifies it for most/many people redistributing it);
> does not work on all platforms supported by Qt (makes assistant less
> useful or even useless to those users); embedding in IDEs becomes much
> more difficult (dependencies and #ifdef's for unsupported platforms)
>
>
> Option 5: use WebView
> Pros: might look good
> Cons: either looks bad or adds whatever component WebView wants to use
> as a dependency; unpredictable results
>
>
> Option 6: use plain platform browser to show local files
> Pros: minimal footprint; assistant can be retired; guaranteed good
> rendering
> Cons: you never know which browser the user installs; abandon QCH
> format; implementing search becomes a horrible mess of JS and other
> files - requires extensive tool support to generate this - doubtful that
> it will always work; forget embedded viewers - this would require
> WebEngine or WebKit again; some users will hate the fact that assistant
> is missing or at least unsupported
>
>
> Option 7: platform browser plus server process to deliver help via local
> HTTP
> Pros: like Option 6, but search becomes easier to implement
> Cons: like Option 6, except search; someone needs to implement a simple
> HTTP server (not that hard, but requires some work) and a search engine
> (slightly harder, but solvable)
>
>
> My personal favorite would be Option 2 (better QTextBrowser), followed
> by Options 1 (status quo) and 3 (WebKit) in no particular order. But
> since I'm not willing to put in any serious work or pay for it - my vote
> does not count - I'm just a user. ;)
>
> Feel free to correct/critique my assessment and to add more options if
> you see any. Otherwise: chose your poison.
>
>
>
> Konrad
>
>
> ___
> 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] Proposing CMake as build tool for Qt 6

[Jean-Michaël Celerier]

Here's a basic one, with which I managed to compile & link simple stuff -
disclaimer : based on the ideas found in a google search for "keil"
"cmake".
I only tested on linux with wine. God is that compiler invocation ugly :)

Example project I used (with dummy foo.c/bar.c/"space out" subfolder not
attached) :

cmake_minimum_required(VERSION 3.14)
project(foo C)

add_executable(foo
foo.c
"space out/bar.c"
)

target_include_directories(foo
PRIVATE
  "${CMAKE_CURRENT_SOURCE_DIR}"
  "${CMAKE_CURRENT_BINARY_DIR}"
  "space out"
)
target_compile_options(foo
PRIVATE
  COMPACT
)
target_compile_definitions(foo
PRIVATE
  hello
  toto="1"
)

Best,
Jean-Michaël

On Tue, Jun 18, 2019 at 1:44 PM Denis Shienkov 
wrote:

> > Matthew Woehlke
>
> > The difference between QBS and CMake is like the difference between a
> > bright-eyed recruit just out of school and a grizzled veteran.
>
> Ok, then, please, provide a simple toolchain file to use e.g. a bare-metal 
> KEIL C51 [1] compiler. And then, we will to see, how it does in QBS and in 
> CMake. Who will win then?
>
> PS: Of course, my question does not related to Qt build tool, it is a common 
> question. :)
>
> [1] http://www.keil.com/support/man/docs/c51/c51_cm_cmdprompt.htm
>
> BR,
>
> Denis
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>


Keil.cmake
Description: Binary data


KeilLink.cmake
Description: Binary data


KeilCompile.cmake
Description: Binary data
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Jean-Michaël Celerier]

No problem :)

Though I can't help but wonder what is the magical ingredient in build
systems that has the power to generate such vigorous debates over the
internet.

Best,
Jean-Michaël



On Mon, Jun 17, 2019 at 3:12 PM Christian Gagneraud 
wrote:

> On Tue, 18 Jun 2019 at 00:27, Christian Gagneraud 
> wrote:
> >
> > On Mon, 17 Jun 2019 at 23:06, Jean-Michaël Celerier
> >  wrote:
> > >
> > > > The world is not spinning around Qt, sorry for the bad news.
> > >
> > > On that we agree : https://www.jetbrains.com/lp/devecosystem-2019/cpp/
> > > I mean, I had actual CMake classes with a CMake exam on paper 6 years
> ago at the university -- you get a few hundreds of new devs on the job
> market every year out of that one, who *will* know CMake, and won't know
> qmake / qbs / [...].
> >
> > Are you insulting this mailing list?
> > How do you think we made it so far without cmake? Honestly?
> >
> > The very fact you're discussing qmake and qbs just show that you know
> > about them, and that you know what they provide cmake cannot provide
> > (yet).
> >
> > > > I prefer a transparent self-bootstrapped Qt over an explicit two
> stages one.
> > > I (entirely personnally) really do not, - this is anecdotally one of
> the main objections I've heard about Qt (3k questions just about Qt's
> configure in SO ! https://stackoverflow.com/search?q=%5Bqt%5D+configure)
> : not just answering to a standard cmake && make && make install which
> comes with gui discoverability through cmake-gui, embeddability through
> add_subdirectory or C++ package managers such as conan, vcpkg, hunter, etc
> etc. but instead acting like its own microcosm library where you have to
> learn yet another set of commands & invocations if you want to integrate it
> in your existing system.
> >
> > Woah, you're ass is so shinny i can't see the light.
>
> Hi Jean-Michaël,
> I would like to apologise about that one, frustration got me in.
> That wasn't smart from me, I do respect everyone, even when I disagree
> with them.
> I didn't mean to insult you, please forgive me, that was a stupid
> behaviour.
>
> Chris
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Jean-Michaël Celerier]

> Are you insulting this mailing list?
How do you think we made it so far without cmake? Honestly?

No, and I apologize if my wording was so poor as to make you think that
this was the goal. I am just trying to point out that there are more people
who learn & know CMake than people who learn qmake or QBS, and that is in
my opinion the n°1 concern when designing something with as large-reaching
goals as Qt's : how is it possible to ensure that most people can use it
right from the get go, without having to learn another additional language.
Basically, how do you reach the next N million of programmers ?

> The very fact you're discussing qmake and qbs just show that you know
about them, and that you know what they provide cmake cannot provide
(yet).

My personal experience with qmake has been that I have migrated most of my
projects from it to CMake around cmake 3.2 and did not look back (but oh
boy am I in pain whenever I have to work on a qmake project with > 15
files).
With QBS, it has been mainly of reporting build errors when using it with
openFrameworks and eventually reverting back to makefiles because of how
broken it was. But this was two years or so ago, though the taste it left
in my mouth (especially after promising so much) was fairly sour.

> Yes, come on, why do i have to define a custom "toolchain file" each
time someone fart?

I really don't see the difference with defining a new mkspec (though I
don't know if you can put mkspecs outside of qt's mkspecs folder ; it would
certainly be nice if it was the case especially when /usr/lib/qt is
readonly).

> Can't you just understand the good old gnu configure triplet? Or the
concept of sytem/user wide profile? (qbs profile, qmake specs)

That's personal preferences, but I really don't like to depend too much on
$distro-provided development packages.
I already wasted waaay enough time in my life investigating why development
package $foo does not work the same on ubuntu 12.04 vs 14.04 vs 16.04 vs
18.04 vs archlinux vs fedora vs freebsd.
I may also have been unlucky but never had I to only switch to another
compiler triplet to make cross-compiling work as I wanted it to.

> Why does every single project has to provide it's own set of CMake
toolchain files?
Have you ever thought about the problem?

How do other build systems solve this ? qmake uses mkspecs, qbs uses qbs
modules, meson uses a cross-build file...
What happens when I want to cross-compile for a new, unknown target with
qmake or QBS on Ubuntu ?
How can I add features to them if they don't currently support them - e.g.,
a target to generate doxygen files, or to call gcov & generate a coverage
report, or whatever new-fangled way to run link-time optimizations -,
without patching them, and without adding stuff to my project source tree ?
I don't see how the solution can be fundamentally different from CMake's -
except that CMake has a large library of scripts contributed by people out
there.

All the best,
Jean-Michaël

On Mon, Jun 17, 2019 at 2:27 PM Christian Gagneraud 
wrote:

> On Mon, 17 Jun 2019 at 23:06, Jean-Michaël Celerier
>  wrote:
> >
> > > The world is not spinning around Qt, sorry for the bad news.
> >
> > On that we agree : https://www.jetbrains.com/lp/devecosystem-2019/cpp/
> > I mean, I had actual CMake classes with a CMake exam on paper 6 years
> ago at the university -- you get a few hundreds of new devs on the job
> market every year out of that one, who *will* know CMake, and won't know
> qmake / qbs / [...].
>
> Are you insulting this mailing list?
> How do you think we made it so far without cmake? Honestly?
>
> The very fact you're discussing qmake and qbs just show that you know
> about them, and that you know what they provide cmake cannot provide
> (yet).
>
> > > I prefer a transparent self-bootstrapped Qt over an explicit two
> stages one.
> > I (entirely personnally) really do not, - this is anecdotally one of the
> main objections I've heard about Qt (3k questions just about Qt's configure
> in SO ! https://stackoverflow.com/search?q=%5Bqt%5D+configure) : not just
> answering to a standard cmake && make && make install which comes with gui
> discoverability through cmake-gui, embeddability through add_subdirectory
> or C++ package managers such as conan, vcpkg, hunter, etc etc. but instead
> acting like its own microcosm library where you have to learn yet another
> set of commands & invocations if you want to integrate it in your existing
> system.
>
> Woah, you're ass is so shinny i can't see the light.
>
> > > Last comment: Please think about [...] Cmake is not yet ready for that.
> >
> > > embedded Linux
> > Oh come on.
>
> Yes, come on, why do i have to define a custom "toolchain file" each
> time someone fart?
> Can't you just

Re: [Development] Proposing CMake as build tool for Qt 6

[Jean-Michaël Celerier]

> The world is not spinning around Qt, sorry for the bad news.

On that we agree : https://www.jetbrains.com/lp/devecosystem-2019/cpp/
I mean, I had actual CMake classes with a CMake exam on paper 6 years ago
at the university -- you get a few hundreds of new devs on the job market
every year out of that one, who *will* know CMake, and won't know qmake /
qbs / [...].

> I prefer a transparent self-bootstrapped Qt over an explicit two stages
one.

I (entirely personnally) really do not, - this is anecdotally one of the
main objections I've heard about Qt (3k questions just about Qt's configure
in SO ! https://stackoverflow.com/search?q=%5Bqt%5D+configure) : not just
answering to a standard cmake && make && make install which comes with gui
discoverability through cmake-gui, embeddability through add_subdirectory
or C++ package managers such as conan, vcpkg, hunter, etc etc. but instead
acting like its own microcosm library where you have to learn yet another
set of commands & invocations if you want to integrate it in your existing
system.

> Last comment: Please think about [...] Cmake is not yet ready for that.

> embedded Linux
Oh come on.

> qnx
you mean like software companies using Qt do, today ?
https://github.com/mapbox/mapbox-gl-native/blob/master/platform/qt/qnx.cmake

> vxworx

VxWorks ships with CMake so there must be at least some amount of support. (
https://tp.prosoft.ru/docs/shared/webdav_bizproc_history_get/234075/234075/?ncc=1_download=1
)

> iOS

... yes ? https://github.com/sheldonth/ios-cmake
Also, just because CMake now has acquired *official* support for iOS does
not mean that it hasn't been working for a long time. There were people
shipping iOS apps with CMake five years ago - and this is due in part to
CMake having a *large* community, unlike qmake / qbs, which means that even
if CMake does not directly support $FEATURE, chances are that you can find
an aptly-licensed open-source library that you can use to augment your
build with and achieve what you want.
See e.g. all the projects that ship today with
https://github.com/leetal/ios-cmake, https://github.com/ruslo/polly, etc
etc
In contrast, how many people are shipping qmake extensions outside of
QtCore, as a library for anyone to use ?

> android and whatever next os is coming.
Oh come on (bis). CMake has been one of the official android build systems
for close to two years now : https://developer.android.com/ndk/guides/cmake

Also, C++Builder was able to ship and advertise CMake support for Android &
iOS a year ago so there is no reason Qt cannot do the same :
https://community.idera.com/developer-tools/b/blog/posts/new-in-10-2-3-cmake-support-for-ios-and-android

> and whatever next os is coming.

you mean like Fuschia (
https://github.com/Kitware/CMake/blob/master/Modules/Platform/Fuchsia.cmake)
or maybe actual operating systems built with CMake, such as IncludeOS (
https://github.com/includeos/IncludeOS) or ReactOS (
https://github.com/reactos/reactos) ? :-)

Best,
Jean-Michaël

On Mon, Jun 17, 2019 at 11:05 AM Christian Gagneraud 
wrote:

> On Mon, 17 Jun 2019, 20:15 Elvis Stansvik,  wrote:
>
>> Den mån 17 juni 2019 kl 09:12 skrev Christian Gagneraud > >:
>> >
>> > On Mon, 17 Jun 2019, 18:11 Jedrzej Nowacki, 
>> wrote:
>> >>
>> >> On Saturday, June 15, 2019 6:37:24 PM CEST Thiago Macieira wrote:
>> >> > On Saturday, 15 June 2019 02:18:28 PDT Jean-Michaël Celerier wrote:
>> >> > > You can download a CMake static binary (
>> https://cmake.org/download/) that
>> >> >
>> >> > (...)
>> >> >
>> >> > I would prefer that our requirements be present in Linux
>> distributions we
>> >> > declare are supported build environments. If nothing else, our CI
>> will
>> >> > benefit from this.
>> >>
>> >> Let's not pull CI into it. It already
>> >
>> >
>> > Wow! Let's not pull in the system which only goal is to validate the
>> "supported platforms" promise, is it what you mean?
>> > If I need a special cmake to build Qt, then this should be shipped as
>> part of Qt itself, another third-party source tree.
>> > And then it means that I will need to build qt's build system. In other
>> words, I'll have to bootstrap Qt build system.
>> > I thought that it was a big no-no. The main argument to ditch qmake and
>> qbs...
>>
>> Hm, what is the problem with using the official CMake binaries? Isn't
>> that what you'd do on Windows / macOS anyway?
>>
>
> In case you didn't follow the thread, building Qt with cmake requires a
> non-released version of cmake.
>
> The question is:
> By the time qt6 will be out, will the requirement of cmake minimum

Re: [Development] Proposing CMake as build tool for Qt 6

[Jean-Michaël Celerier]

Hello :)

> What makes you think that you can build Qt for any platform with cmake
found
in Ubuntu 16.04 (or any later version) ?

You can download a CMake static binary (https://cmake.org/download/) that
runs fine on Ubuntu 16.04 (or 12.04 or CentOS 6 for that matters) - and it
wouldn't be hard to have a bootstrap script that builds or fetches a
recenter CMake if the local version is not up-to-date - after all, you're
talking about building Qt 6 on a system that already ships with Qt 5.5 so
you're not that concerned with using your distro's packages. That's what
tools like vcpkg do for instance (and that's what Qt itself currently does
- if the status quo was kept, building Qt 6 would start by building Qt 6's
qmake anyways).

> It has the least features and it has the ugliest syntax than the
alternatives qmake and QBS.

It has enough features to be able to implement
https://bugreports.qt.io/browse/QTBUG-73925 and I think that we are all
pretty confident that https://bugreports.qt.io/browse/QTBUG-74612 will work
out. If there are other features request / missing features for the CMake
build system they should be added - so far, I think that the CMake people
have been responsive regarding patches that were needed to achieve the Qt
build system. If there's no one doing the same work for QBS, how can you
expect Qt to migrate to it ?

Also, it is much more maintained and active (
https://github.com/qbs/qbs/graphs/contributors?from=2018-06-15=2019-06-15=c
vs
https://github.com/Kitware/CMake/graphs/contributors?from=2018-06-15=2019-06-15=c)
which should be a prime concern for any software project leveraging another
software project - that is, will it be dead in 5 years. The odds for CMake
are I think much smaller than the odds for qbs.

Finally, CMake's main maintainer has historically be open to alternative
front-end languages for CMake if someone actually puts the work in :
https://cmake.org/pipermail/cmake-developers/2016-January/027379.html ;
what would the state of C++ build systems be if the work and energy that
was put towards QBS was instead put in contributing a similar declarative
frontend to CMake is left as a thought exercice to the reader :)

Best,
Jean-Michaël


On Sat, Jun 15, 2019 at 8:46 AM Bogdan Vatra via Development <
development@qt-project.org> wrote:

> Hi,
>
> În ziua de joi, 13 iunie 2019, la 18:22:14 EEST, Thiago Macieira a scris:
> > On Thursday, 13 June 2019 01:06:06 PDT Bogdan Vatra via Development
> wrote:
> > > Hi,
> > >
> > >   There is one more missing feature to add to your list: build & debug
> > >
> > > builds for msvc in one go (same as qmake does now, a single "make"
> command
> > > will build both targets).
> >
> > I wouldn't call that a hard requirement. Separate builds for debug and
> for
> > release are acceptable, the same way that we've ostensibly had support
> for
> > shared-and-release builds but in practice they're always built
> separately.
> >
> > The only difficult part I see is enforcing the suffix. On Mac we've had
> > problems with this, since a debug-only build is un-suffixed. Maybe it's
> time
> > to rethink the strategy and make the suffix optional altogether (using
> the
> > lib infix feature). On Windows, we should stop enforcing that unoptimised
> > builds be -MDd and make it easy for people to debug into -MD libraries.
> > Hardly anyone ever debugs into Microsoft's libraries...
> >
>
> I think libs built with -MDd are a must to enable debug builds for your
> application. AFAIK (if I'm wrong I apologize) you can't mix debug apps
> with
> release libs.
> So, as long as we need to provide libs, (qml) plugins  for debug & release
> I
> think building them in one go is a must have feature.
>
> > >   Also I wonder when do you plan to release Qt6? Because according to
> > >
> > > Thiago's "what a buildsystem must to have list" he mentioned that the
> > > buildsystem should be at least 2 years in the wild. If the needed cmake
> > > support is not implemented yet, are you going to delay Qt 6 release (I
> > > won't mid to use C++20 in Qt 6 :) ) just to give time to cmake to
> mature?
> > > Or that (part of the) list was just an excuse for TQC to ditch QBS ;-).
> >
> > 2 years in the wild was not for all features, it was for the buildsystem
> > itself and the major features. But we need to build with the version that
> > comes with the host systems that we are targetting (if they ship tools
> like
> > this in the first place; Windows doesn't).
> >
> > That means that the iOS support only needs to be present in whatever
> version
> > of CMake that Homebrew installs. Since Homebrew always has the latest,
> this
> > is not an impediment.
> >
> > But if we want to build on Ubuntu 16.04, then that three year old
> version's
> > CMake needs to be sufficient for a native build of Qt and whatever cross-
> > builds get targeted from Linux (Android and QNX, I'd guess). For Qt 6,
> I'd
> > just recommend raising the minimum to 18.04...
>
>   What makes you think that you can 

Re: [Development] Proposing CMake as build tool for Qt 6

[Jean-Michaël Celerier]

Even if modules were available (and stable) in at least mainline versions
of {clang, gcc, msvc} in a year (which I don't think they will), Qt would
have to get modularized to actually be able to reap the benefits of modules
(given the strong feelings in the "deprecations" thread, we can expect
mid-2050 for that one maybe ? e.g. for now Qt 6 will be AFAIK on a C++17
baseline... if we consider that it took up to Qt 5.7, released in 2016, to
require a C++11 compiler to build, you can see that `import QString;` in
qobject.h is still a decade away :-)).

So I really think that the time saved by PCH today, which is for me at
least a good few minutes per Qt build, is important to keep.
Besides, current implementations of modules aren't faster than a good PCH
(or at least they weren't last time I checked clang's).

Best,
Jean-Michaël

On Tue, Jun 11, 2019 at 5:50 PM Matthew Woehlke 
wrote:

> On 06/06/2019 09.23, Simon Hausmann wrote:
> > Regarding PCH, it seems that right now it would be easiest to
> > include something like https://github.com/sakra/cotire . Patches are
> > welcome to integrate this or alternatively work with upstream CMake
> > for a built-in solution.
>
> Considering that modules are coming, I wonder how much sense it makes to
> keep working on PCH?
>
> --
> Matthew
> ___
> 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] Proposing CMake as build tool for Qt 6

[Jean-Michaël Celerier]

> Looking at the CMake documentation – it looks like a maze.

I would recommend starting at the cmake-buildsystem doc page which gives a
general overview of the concepts of CMake :
https://cmake.org/cmake/help/v3.15/manual/cmake-buildsystem.7.html
It is also available as a man page for unix users (man cmake-buildsystem).
Also multiple IDEs can integrate with CMake's documentation nowadays :
QtCreator (the doc being available in QtHelp format :
https://cmake.org/documentation/), Visual Studio (
https://devblogs.microsoft.com/cppblog/in-editor-documentation-for-cmake-in-visual-studio/).
..
It's pretty nice to be able to do F1 in target_whatever_foobar in QtCreator
and get the relevant help shown :-)

Best,
Jean-Michaël



On Thu, Jun 6, 2019 at 4:42 PM Palaraja, Kavindra 
wrote:

> Thanks for the links.
>
>
>
> Looking at the CMake documentation – it looks like a maze. So definitely,
> content that resembles a “Migration Guide” would be helpful for users.
> Especially if there are cases where there’s no 1-1 mapping from qmake -->
> CMake.
>
>
>
> Yes, the exact link to the CMake version would definitely be necessary.
>
>
>
> Regards,
>
> Kavindra.
>
>
>
> *From: *Simon Hausmann 
> *Date: *Thursday, 6. June 2019 at 16:02
> *To: *"Palaraja, Kavindra" , "
> development@qt-project.org" 
> *Subject: *Re: [Development] Proposing CMake as build tool for Qt 6
>
>
>
> Hi,
>
>
>
> I think our users should eventually end up in area that is currently
> called the "CMake Manual" in the docs. For example through one of the
> various overviews. As far as I can tell that page is currently located at
>
>
>
> https://doc.qt.io/qt-5/cmake-manual.html
>
>
>
>
>
> That page targets application developers and correctly also refers to
> CMake's own manual at
>
>
>
> https://cmake.org/documentation/
>
>
>
> It might make sense to make that a more concrete link to the exactly
> version of CMake that Qt requires at the least. What do you think?
>
>
>
> This page might also benefit from a section or sub-page that provides help
> for qmake users on how to transition to CMake.
>
>
>
> Finally, the existing documentation about how to build Qt from source --
> https://doc.qt.io/qt-5/build-sources.html -- will require changes. It is
> our intention (or at least mine ;-) to transition the internal docs that
> address that, currently located at cmake/README.md, to those pages. We have
> not yet achieved the desired degree of convenience for building Qt with
> CMake though, and we have not reached the target branch yet. But once in
> wip/qt6 I think it might make sense to move things across.
>
>
>
>
>
>
>
> Simon
>
>
>
>
> --
>
> *From:* Development  on behalf of
> Palaraja, Kavindra 
> *Sent:* Thursday, June 6, 2019 15:37
> *To:* development@qt-project.org
> *Subject:* Re: [Development] Proposing CMake as build tool for Qt 6
>
>
>
> Hi,
>
>
>
> Just curious, do you have a link to what the draft documentation for CMake
> looks like?
>
>
>
> qmake's documentation has always been an afterthought. The documentation
> equivalent for CMake should be better than that – at the very least, it
> shouldn’t result in another https://wiki.qt.io/Undocumented_QMake and
> such.
>
>
>
> --
>
> Kavindra.
>
>
>
> *From: *Development  on behalf of
> Simon Hausmann 
> *Date: *Thursday, 6. June 2019 at 13:46
> *To: *"development@qt-project.org" 
> *Subject: *[Development] Proposing CMake as build tool for Qt 6
>
>
>
> Hi,
>
>
>
> In the past months we, some developers from the Qt Company and KDAB,
>
> have made good progress on the port of Qt to use CMake as build tool.
>
> Since the initial prototype, the port has advanced very well and its
>
> current state can be summarized roughly like this:
>
>
>
> * Builds on
>
>   * Windows (desktop)
>
>   * macOS
>
>   * Linux (desktop and embedded)
>
>   * Android (running not tested yet)
>
>
>
> * Static builds and plugins are implemented.
>
>
>
> * Many examples and tests are compiling and running.
>
>
>
> * Several modules outside of qtbase have been ported as well,
>
>   including qtsvg, qtimageformats, qnetworkauth as well as parts of
>
>   qtdeclarative.
>
>
>
> * There are early-warning style CI builds (no tests) running and
>
>   reporting results to patches uploaded to Gerrit.
>
>
>
> * There is tooling in-place to re-generate cmake files from
>
>   .pro/configure.json files, providing a method of dealing with the
>
>   long term maintenance of merging from qmake based Qt (5) branches.
>
>
>
> * Very basic support for compiling applications (not modules) with
> qmake
>
>   against a CMake built Qt.
>
>
>
> Many of the more fine-grained details are tracked in JIRA under an Epic:
>
>
>
> https://bugreports.qt.io/browse/QTBUG-73351
>
>
>
> as well as in the Qt Project Wiki at
>
>
>
> https://wiki.qt.io/CMake_Port
>
>
>
> Detailed steps on how to build Qt with CMake are available at
>
>
>
>

Re: [Development] Deprecation/removal model going into Qt 6

[Jean-Michaël Celerier]

>  If existing package of application cannot be rebuilt from source with
updated
Qt version, it's a sure no-go for distibution. Either Qt update will be
blocked, or
application will be thrown away (or application will be somehow patched by
other
people, without you even knowing about that)

- People nowadays will just use the flatpak / appimage / snap / whatever
version which will be much more up-to date than Debian Stable's Qt 5.7 (!)
or Ubuntu LTS & CentOS 's Qt 5.9 anyways.
- boost has the exact same ABI stability issue (e.g. no ABI / API stability
guarantees at all) and yet distros seem to manage all the C++ software
which uses it without much problems.

My 0.02€
Jean-Michaël


On Sun, Jun 2, 2019 at 4:08 PM Konstantin Tokarev  wrote:

>
>
> 02.06.2019, 17:03, "Manuel Bergler" :
> > Am So., 2. Juni 2019 um 15:50 Uhr schrieb Konstantin Tokarev
> > :
> >>  02.06.2019, 16:34, "Manuel Bergler" :
> >>  > Due to Hyrum's law [0], even with stricter guarantees there will
> >>  > always be someone for which migration is a non-trivial amount of
> work.
> >>  > The only way to avoid that is to change nothing, ever. I personally
> >>  > also don't understand why people would expect getting shiny new
> >>  > features of a new minor release without having to pay a cost of
> >>  > migrating their code over. I believe that as long as the benefit of
> >>  > the new features outweighs the cost of migration then people will be
> >>  > willing to migrate anyway. I myself don't mind the 2 weeks it took so
> >>  > far to upgrade from Qt 5.9 to Qt 5.12 in our project, that's just the
> >>  > cost of progress...
> >>
> >>  In open source world Qt version is not easily chosen by developer.
> >>  If Qt updates are source-incompatible, distributions will stuck with
> old Qt
> >>  as long as possible to avoid massive breakages, and if new version of
> your
> >>  app requeres newer Qt than what is shipped by distribution, users will
> get
> >>  older version which is still compatible.
> >
> > That's why I suggested using inline namespaces. Then even if an
> > application no longer compiles with the new version of Qt it can still
> > link against it.
>
> If existing package of application cannot be rebuilt from source with
> updated
> Qt version, it's a sure no-go for distibution. Either Qt update will be
> blocked, or
> application will be thrown away (or application will be somehow patched by
> other
> people, without you even knowing about that)
>
> --
> Regards,
> Konstantin
>
> ___
> 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] Qt 5 types under consideration for deprecation / removal in Qt 6

[Jean-Michaël Celerier]

Here's a PS1 script that more or less does it (god that language is awful
to use) :

xxd.ps1:
param([String]$path)

$bytes = [System.IO.File]::ReadAllBytes($path);
$size = $bytes.length;

$bytes = (($bytes | %{ "0x" + $_  ; }) | Out-String);
$content = $bytes -replace "`r",", " -replace "`n","" -replace ".{2}$";
$res = "unsigned char foobar[] = { " + $content + " }; + `r`nunsigned int
foobar_len = " + $size + ";`r`n";
echo $res

Feel free to use as you see fit
Best,

Jean-Michaël Celerier
http://www.jcelerier.name


On Sat, Jun 1, 2019 at 6:13 PM Thiago Macieira 
wrote:

> On Saturday, 1 June 2019 03:46:34 PDT André Pönitz wrote:
> > I am getting mildly irritated by those ongoing suggestions (not just
> > yours) to use anything but Qt to get stuff done, even Qt's own tasks.
> > It's sending an odd message.
> >
> > Sure, one can pull e.g. any "plain C++" replacement for QXmlStreamReader
> > for rcc. With the usual non-Qt approaches this means either some other
> > 3rd party dependency or some ad-hoc implementation providing the
> > part of XML parsing rcc actually needs, or to switch over to another
> > .qrc format.
> >
> > At the end of the day, all that would be doable, but *why*?
>
> I'm not suggesting we drop the Qt code from those tools. I'm suggesting
> that
> we un-bootstrap them after we make QtCore not require them at all.
>
> If I can get powershell to produce a C-consumable hex dump of the file, we
> can
> get rid of rcc as a QtCore dependency. But rcc as a tool remains.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> 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] Qt 5 types under consideration for deprecation / removal in Qt 6

[Jean-Michaël Celerier]

To bypass the MSVC limitation I think that you need to use array notation
instead of string literals, with the help of a tool such as xxd.
Apparently powershell has a command to more-or-less do it (format-hex),
with some PS magic it could maybe work without too much dependencies added
on windows...

Best,

On Sat, Jun 1, 2019 at 7:01 AM Thiago Macieira 
wrote:

> On Friday, 31 May 2019 10:13:52 PDT Thiago Macieira wrote:
> > rcc should be un-bootstrapped. The only use inside QtCore is for the MIME
> > type database. We don't need a resource, though it compresses really well
> > (roughly 10:1 with zstd). I'd simply make that a read-only sharable
> > variable, which we can easily create with a C++11 raw string.
>
> https://codereview.qt-project.org/c/qt/qtbase/+/263548
>
> Unfortunately, MSVC doesn't want to cooperate:
>
> .\qmimeprovider_database.cpp(1270): fatal error C1091: compiler limit:
> string
> exceeds 65535 bytes in length
>
> > qfloat16-tables does not link to the bootstrap library (it's pure C++).
> The
> > only reason it's in C++ was so we didn't depend on Perl or Python during
> the
> > qtbase build on Windows (Perl is required on Unix). Also, its output is
> > ALWAYS the same and there is no input, since the constants are specified
> by
> > IEEE 754. I'd actually remove the tool from the build, move it to util/,
> > and add the resulting file to Git.
>
> https://codereview.qt-project.org/c/qt/qtbase/+/263547
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel System Software Products
>
>
>
> ___
> 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] Qt 5 types under consideration for deprecation / removal in Qt 6

[Jean-Michaël Celerier]

> We probably need to keep QRWL around a while longer, since C++ added
shared_mutex only in C++17.

Wasn't it said at the world summit that Qt 6 would base itself on c++17 ?
https://blog.qt.io/blog/2018/06/13/qt-contributors-summit-2018-wrap/

Best,
Jean-Michaël


On Wed, May 29, 2019 at 12:55 PM Mutz, Marc via Development <
development@qt-project.org> wrote:

> Hi,
>
> Here's a list of stuff I consider has served it's purpose and is no
> longer needed, with respective replacements:
>
> = Priority 1 =
>
> == QSharedDataPointer / QExplicitlySharedDataPointer ==
>
> These are basically Qt-internals, and should never have been public in
> the first place. It's _because_ they are public that we have two of
> them, and soon a third one (properly non-public):
> https://codereview.qt-project.org/c/qt/qtbase/+/115213 That commit's
> message also explains what's wrong with the QSDP and QESDP.
>
>
> == Q_FOREACH -> ranged for loops
> (https://codereview.qt-project.org/c/qt/qtbase/+/147363) ==
>
> Q_FOREACH is less readable (because it allows mutating the container
> under iteration), and produces _a lot_ of code. It also is intrinsically
> tied to just a few Qt containers (excluding QVLA). Ranged for loops work
> on anything, incl. a C array. Also, as a macro, it will continue to
> cause problems down the road (e.g. with modules). Being a macro also
> means that it cannot deal with value_types that contain a comma.
>
> === related: Q_FOREVER -> for(;;) ===
>
> Suggested by Lars in ibid. Basically because it's a macro.
>
>
> == Java-style iteration
> (https://codereview.qt-project.org/c/qt/qtbase/+/262344) ==
>
> It's very easy to write quadratic loops with it.remove(), and a review
> of Qt code has shown that some users still use container.remove(), which
> is just as unsafe as with STL iterators. I also noted between 100b/loop
> and 5KiB for four loops of text size savings.
>
>
> == QScopedPointer -> std::unique_ptr ==
>
> Suggested by Thiago on
> https://codereview.qt-project.org/c/qt/qtbase/+/261553
>
> I agree. We now have std::unique_ptr, and it's movable. QScopedPointer
> had the problem that it didn't know what it wanted to be:
> boost::scoped_ptr or std::unique_ptr. A real scoped pointer would not
> offer release(), a unique_ptr would need to provide move semantics.
> QScopedPointer has release(), but no moves (were proposed, but not
> accepted).
>
>
> == QLinkedList -> std::list
> (https://codereview.qt-project.org/c/qt/qtbase/+/261421) ==
>
> Of the Qt containers, this one is the most-unused (in Qt code), as well
> as the one that's furthest behind it's STL counter-part. Whenever I use
> std::list, I use it for splice(), a function that just cannot be added
> to a CoW container. Qt is already almost completely QLinkedList-free.
> Let's bury QLinkedList.
>
>
> == qHash() -> std::hash ==
>
> Suggested by Lars in
> https://codereview.qt-project.org/c/qt/qtbase/+/261819. To be precise,
> he's suggesting to specialise std::hash and have qHash() call std::hash.
>
> Only problem I see so far is that std doesn't provide us with a tool to
> hash composites. E.g. there's no std::hash for std::tuple (which would
> mean we can std::tie the members and hash the result), and only C++17
> adds some kind of raw bits hashing (via std::string_view). We'd need to
> provide these building blocks ourselves, which can be done, but it means
> we'll have at least _some_ qHash()-like functions we need for
> std::hash<> implementations.
>
> Actual problem?
>
>
> == QPaintDevice ==
>
> I'd like this to become a static interface. In very shortened terms:
> everything that has a QPaintEngine *paintEngine() method is a paint
> device. QPainter's ctor would become a template and do the virtual
> dispatch internally, just like Sean Parent's document type in C++
> Seasoning.
>
> This would solve a lot of problems: QWidget would no longer need to use
> multiple inheritance, and QImage and QPixmap would become proper value
> types, without virtual functions that create problems with move
> semantics and swapping.
>
>
> == QRegExp ==
>
> Is QRegularExpression good enough these days? :)
>
>
> == MT plumbing ==
>
> Let's make use of the std facilities to enable checkers such as TSAN to
> work without hacks. It's not Qt's business to reimplement threading
> primitives.
>
> Probably need to keep some stuff around, like QThread, because of the
> interaction with event processing, but before we add a lot of time
> making the following classes play nice with the std, let's perspectively
> remove them:
>
> === QAtomic -> std::atomic ===
>
> It already is just a thin wrapper around std::atomic, so there's not
> much point keeping it.
>
> === QMutex / QReadWriteLock -> std::*mutex* ===
>
> It has too many responsibilities. Where the std knows many different
> mutex classes, Qt folds everything into just two.
>
> We probably need to keep QRWL around a while longer, since C++ added
> shared_mutex only in C++17.
>
> === QMutexLocker -> std::unique_lock 

Re: [Development] CSS styling, XML, HTML etc. (was Re: Assistant WebKit/WebEngine support)

[Jean-Michaël Celerier]

> (of all Qt applications, only a minority use either QSS or CSS)

Are there sources for that ? From what I can see it has plenty of usage.
https://github.com/search?l=C%2B%2B=setStyleSheet=Code

Best,

---
Jean-Michaël Celerier
http://www.jcelerier.name


On Tue, May 21, 2019 at 4:07 PM Shawn Rutledge  wrote:

>
> > On 20 May 2019, at 18:56, Bastiaan Veelo  wrote:
> >
> > On 20/05/2019 17:56, Konstantin Tokarev wrote:
> >> 20.05.2019, 18:27, "Bastiaan Veelo" :
> >>> On 20/05/2019 16:51, Konstantin Tokarev wrote:
> >>> ...
> >> However, it would better to avoid duplicating work with Qt Creator,
> >> which also implements HelpViewer interface with different backends.
> >> Some time ago there was a discussion that such shared interface & plugin
> >> system should belong to Qt Web View module. But that would  probably
> >> require more work to be done.
>
> If there is really a need to use WebEngine, a plugin makes sense.  Sharing
> a plugin between Creator and Assistant makes sense.  But I do worry about
> the runtime memory bloat that it will introduce.
>
> >>> Or do you think that removing WebKit support from Assistant completely
> >>> would be better, if WebEngine shows to be working well?
> >> As for me, I'm totally fine with QTextBrowser
> >
> > I wish that were true for me. We need colours in table cell borders and
> SVG images (and better CSS support would be real nice). This might help,
> but is stalled: https://codereview.qt-project.org/c/qt/qtbase/+/177256
>
> I was just putting some thought into CSS over the last few days, but
> wasn’t aware of that patch.
>
> I don’t like the limitation we have, that CSS can be applied only while
> parsing HTML, because after the parsing is done, there is no DOM: a lot of
> structural information from HTML is lost.  This is a limiting factor for my
> work with supporting Markdown in QTD lately: after you have read HTML, not
> enough information is saved to be able to write markdown as nicely as I’d
> like (it’s mostly possible to work around, but e.g.  results in a
> separate block per line, and  results in an indented plain
> paragraph, so the markdown writer has to reconstruct some of the structure
> by detecting those idiosyncrasies).  And of course there’s no support for
> applying CSS to markdown, precisely because of the fact that it can be
> applied only while the HTML parser is running, and in the markdown case
> there’s no HTML parser instance.  I’m loathe to take the same approach with
> markdown (apply CSS only while parsing), but I’d like to have CSS support
> for it.  For both HTML and Markdown it would be nice if CSS could be
> applied dynamically to an existing QTextDocument.  I don’t see a real
> reason why we shouldn’t be able to, as long as QTD stores enough
> information about the original structure (i.e.  is not just a block
> with a particular font size and style:
> 310daae53926628f80c08e4415b94b90ad525c8f took care of that, because I
> couldn’t realistically get started with markdown support unless the heading
> blocks could at least remember their own heading levels).  Similar fixes
> could gradually turn QTD into something almost like a DOM, and could also
> turn the HTML-writing support into a lot less of a mess (be able to write
> out HTML that looks more like what you read in).  But it’s kindof
> frustrating work: I just keep wondering why stuff like that still needs to
> be done in 2019.
>
> So I wonder if we should gradually fix that, or we would be better off
> replacing the guts of QTD with a proper DOM of some sort.  But of course
> it’s a slippery slope: QTextBrowser should never be as complex as a real
> browser.  So the knee-jerk reaction is to say “forget about it, use
> webengine”; but the other side of the argument is that it’s quite nice to
> have such a compact implementation as QTD/QTB are, and there are so many
> applications where a real browser engine is such terrible overkill.  I
> suspect that Konqueror must have had a time period where it had a suitably
> compact but architecturally better design, but I haven’t dug in deep enough
> to figure that out; several people should already know, anyway.
>
> BTW, there is a movement to ditch qtxmlpatterns and replace it in the one
> use case that matters to Qt Quick (XmlListModel) with some other XML
> parser, something good enough for all use cases in the rest of Qt.  (Based
> on libxml2 maybe?)  So can we perhaps say these things are related: it’s OK
> to support only well-formed XHTML, not loosely-structured HTML, maybe we
> could use the same XML parser for both use cases, to reduce the code size
> and get a real DOM at the same time?  But it 

Re: [Development] QList for Qt 6

[Jean-Michaël Celerier]

> QList is just a linked list

you're in for a rude awakening :-) https://doc.qt.io/qt-5/qlist.html

On Mon, May 20, 2019 at 5:03 PM Jason H  wrote:

>
> > Ok, QList as an alias for QVector takes care of the technical issues I
> > have with using inheritance. It doesn't address my concerns regarding
> > breaking QList behaviour. What purpose is served to call something QList
> > that is in fact a QVector? Please spell it out for me, as I don't see
> > it.
>
> My understanding is that QVector requires contiguous memory, consuming a
> giant block for all the items in the list. QList is just a linked list.
> QVector will fail sooner when memory fragmentation is a problem. I would
> expect systems with long-running processes and limited RAM (i.e. embedded,
> a Raspberry Pi, phone, etc) to encounter this sooner than other systems,
> especially when the size of each object is large. (You could always just
> store pointers though)
>
>
> ___
> 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] CMake Workshop Summary

[Jean-Michaël Celerier]

Although it seems to have been fixed for ninja :
https://gitlab.kitware.com/cmake/cmake/merge_requests/430

On Mon, Feb 25, 2019 at 10:02 AM Jean-Michaël Celerier <
jeanmichael.celer...@gmail.com> wrote:

> > It is not bad, but it is not great either :-). For example one needs to
> _link_
> QtCore before compilation on other things can be started, it is quite
> visible
> on an under-powered machines, where linking takes time.
>
> I think that this would still generally be the case with CMake, there are
> longstanding issues opened about it :
> https://gitlab.kitware.com/cmake/cmake/issues/1
> https://gitlab.kitware.com/cmake/cmake/issues/17528
>
> Best,
> Jean-Michaël
>
>
> On Mon, Feb 25, 2019 at 9:32 AM Christian Kandeler <
> christian.kande...@qt.io> wrote:
>
>> On Mon, 25 Feb 2019 08:13:29 +
>> Jedrzej Nowacki  wrote:
>>
>> > On Friday, February 22, 2019 7:18:36 AM CET Thiago Macieira wrote:
>> > > But do note that our parallelism isn't that bad right now.
>> >
>> > It is not bad, but it is not great either :-). For example one needs to
>> _link_
>> > QtCore before compilation on other things can be started, it is quite
>> visible
>> > on an under-powered machines, where linking takes time. Similar,
>> redundant
>> > synchronization point is on the module level.
>>
>> Also, the examples could have per-app granularity and just start building
>> as soon as the respective module is ready,
>>
>>
>> Christian
>> ___
>> 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] CMake Workshop Summary

[Jean-Michaël Celerier]

> It is not bad, but it is not great either :-). For example one needs to
_link_
QtCore before compilation on other things can be started, it is quite
visible
on an under-powered machines, where linking takes time.

I think that this would still generally be the case with CMake, there are
longstanding issues opened about it :
https://gitlab.kitware.com/cmake/cmake/issues/1
https://gitlab.kitware.com/cmake/cmake/issues/17528

Best,
Jean-Michaël


On Mon, Feb 25, 2019 at 9:32 AM Christian Kandeler 
wrote:

> On Mon, 25 Feb 2019 08:13:29 +
> Jedrzej Nowacki  wrote:
>
> > On Friday, February 22, 2019 7:18:36 AM CET Thiago Macieira wrote:
> > > But do note that our parallelism isn't that bad right now.
> >
> > It is not bad, but it is not great either :-). For example one needs to
> _link_
> > QtCore before compilation on other things can be started, it is quite
> visible
> > on an under-powered machines, where linking takes time. Similar,
> redundant
> > synchronization point is on the module level.
>
> Also, the examples could have per-app granularity and just start building
> as soon as the respective module is ready,
>
>
> Christian
> ___
> 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] Missing documentation in Qt 5.12

[Jean-Michaël Celerier]

I think that option 3 (split by class) would be really nice and more
readable than the current "all members" list

Best,
Jean-Michaël Celerier

On Wed, Dec 19, 2018 at 1:47 PM Martin Smith  wrote:

> I found the problem.
>
> There are a few ways I can fix it. Which is preferred.
>
> 1. Simply merge the inherited members into the list that is already there.
> 2. Merge the inherited members into the list but qualified with their base
> class name.
> 3. list the inherited members from each base class all on the same page
> but separately for each base class.
>
> QWidget members
> ...
> QPaintDevice members
> ...
> QObject members
> ...
>
> 
> From: Development  on behalf of André
> Pönitz 
> Sent: Tuesday, December 18, 2018 8:43:43 PM
> To: Eike Ziller
> Cc: Qt development mailing list
> Subject: Re: [Development] Missing documentation in Qt 5.12
>
> On Tue, Dec 18, 2018 at 11:49:22AM +, Eike Ziller wrote:
> >
> >
> > > On Dec 18, 2018, at 11:25, Konstantin Shegunov 
> > > wrote:
> > >
> > > On Tue, Dec 18, 2018 at 9:39 AM Martin Smith 
> > > wrote: I'll argue with you about it being a p1. If the problem is
> > > confined to the all-members list, it's not a p1 problem because the
> > > information is still there via the inherits links, which are more
> > > useful for seeing what is inherited anyway.
> > >
> > > You can argue with the people that handled it through the tracker, I
> > > don't prioritize bugs. From my point of view, however, it falls
> > > strictly into the P1 category - it's a regression from the last
> > > version, not an edge-case data loss, and it's pretty embarrassing.
> > >
> > > My own opinion is that the all-members list should be removed.
> > >
> > > I think no, unless there's another way to search for a method in the
> > > hierarchy. Allowing for a somewhat contrived example: Say I'm
> > > working with `QTemporaryFile` I know there exists something for
> > > checking about it being readable but I don't know exactly from where
> > > it comes from, then the all-members page is really useful. That
> > > use-case gets even more prominent for classes that implement
> > > interfaces and/or that have multiply inherited (e.g. QLabel's
> > > indirect inheritance from QPaintDevice).
> >
> > This happens to me all the time with classes inheriting from IODevice,
> > layouts like QHBoxLayout, and quite some widgets, where the useful
> > methods are often spread through the whole hierarchy. Clicking up
> > through the hierarchy works, but is not very efficient, the all
> > members list is much more convenient.
>
> Same here.
>
> Especially for "feature discovery" one flat list is the best option.
>
> Andre'
> ___
> 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] Missing documentation in Qt 5.12

[Jean-Michaël Celerier]

I've also noticed the same for QCoreApplication and QApplication :
http://doc.qt.io/qt-5/qapplication-members.html
http://doc.qt.io/qt-5/qcoreapplication-members.html


---
Jean-Michaël Celerier
http://www.jcelerier.name


On Mon, Dec 17, 2018 at 3:29 PM Martin Smith  wrote:

> Are the missing chunks always in the all-members list? In the case of
> QWidget, it inherits QObject and QPaintDevice. Those pages look correct to
> me, but the all-members pages are missing some inherited members. Are there
> other missing chunks?
>
> martin
>
> 
> From: Development  on behalf of Sze
> Howe Koh 
> Sent: Monday, December 17, 2018 12:53:36 PM
> To: Qt development mailing list
> Subject: [Development] Missing documentation in Qt 5.12
>
> Significant chunks are missing from the Qt 5.12 documentation:
> https://bugreports.qt.io/browse/QTBUG-72357
>
> Could we please have a prominent notice on the website informing users of
> this issue (and suggest viewing the Qt 5.11 version as a workaround) until
> a fix lands?
>
>
> Regards,
> Sze-Howe
> ___
> 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] Build system for Qt 6

[Jean-Michaël Celerier]

> Does pkg-config and cmake works on Qnx and Windows? Can you cross
> compile for iOS, tvOS, ... using CMake?
> Has it been ever tried once?

Seriously, it's a google search away: https://github.com/leetal/ios-cmake

> CMake doesn't support (very well) cross-compilation for android on
> Windows for example,

fairly interesting considering that Android Studio uses CMake:
https://developer.android.com/studio/projects/add-native-code

They used to use Gradle but saw the light at some point :-) (or at least
the incredible pain that gradle was inflicting on their end-users).

But in this day and age where docker works everywhere I don't really see
the point in fighting to make windows behave like a proper unix system,
just write a dockerscript that does your cross-compile job.
Also, there's WSL, I suppose that it should work somehow.

> I've never tried, but i'm sure it shouldn't be that hard to add
support for VHDL/Verilog to Qbs, that's the power of modern SW
architectures.

what makes you think that it wouldn't work with CMake too ?
e.g. it supported java for a long time (
https://cmake.org/cmake/help/latest/module/UseJava.html), and C# since 3.8 (
https://cmake.org/cmake/help/latest/module/CSharpUtilities.html)

Here's a simple example of FPGA toolchain (again, 5 seconds of google) :
https://github.com/jamieiles/fpga-cmake

Jean-Michaël

On Mon, Dec 17, 2018 at 8:15 AM Christian Gagneraud 
wrote:

> On Mon, 17 Dec 2018 at 18:38, Thiago Macieira 
> wrote:
> >
> > 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.
> >
> > A good buildsystem should have support for being told where the sysroot
> and
> > cross-compiler are, then execute pkg-config and .cmake file searches
> there.
> > When installing, it also needs to be able to install to a separate
> install
> > root, so it can be packaged. Installing into the sysroot is optional:
> it's
> > only a convenience.
>
> That's sound pretty standard stuff to me.
>
> Does pkg-config and cmake works on Qnx and Windows? Can you cross
> compile for iOS, tvOS, ... using CMake?
> Has it been ever tried once?
> CMake doesn't support (very well) cross-compilation for android on
> Windows for example, although, it pretends to be multi-platform and
> honor/embrace sysroot...
>
> >
> > Of course, this assumes that the libraries to be found do not require
> > executing anything from the sysroot. This is not an issue of the
> buildsystem
> > though: the problem is the dependency itself and would happen regardless
> of
> > buildsystem.
>
> Yes, autoconf got around that with site cache, a lng time ago.
>
> >
> > So, in general, cross-compiling is difficult and error-prone. That's why
> > solutions like Yocto Project attempt at cross-compiling as if it were
> native,
> > via qemu and pseudo. And that's why I don't cross-compile.
>
> I've been cross-compiling and cross-debugging for 20 years, yes it's
> not always easy, but at the end of the day it's always the same
> symptoms, so once you know the arcane and your tools, it's not that
> bad.
> Things get only interesting when you attempt "canadian" cross-build of
> your SDK, where your build machine, your host machine and your target
> machine are 3 different arch/OS (and you do not "cheat" with
> emulators).
> It's very hard, fun (or not) but very rewarding.
>
> Yocto is not the only thing on the planet, there's lot of meta build
> system around that does cross-compile everything and are way easier to
> use, read, write and understand.
>
> You obviously don't do bare metal dev either, as there is not such
> thing as native build, not even emulated since there is no "real" OS.
> Even if there were one, you do not want to feel the pain to
> native-build on a N MHz processor - where n < 100, sometimes < 10.
> I wonder how many days it will take to build a full-featured boot2qt
> from scratch on a native ARM machine.
>
> FYI, you can do bare-metal development with Qbs and QtCreator, and
> that's pretty cool.
>
> I've never tried, but i'm sure it shouldn't be that hard to add
> support for VHDL/Verilog to Qbs, that's the power of modern SW
> architectures.
> And then QtCreator's solid code base (SW arch again?) would help to
> add FPGA deployment and simulation support, adding support for JTAG
> probes, this would even attract bootloader and kernel developers too.
>
> Just look at how LLVM made it in a all-gcc world. Everyone wants to
> use LLVM these days, their architecture was a true revolution (in the
> Open Source world at least) and is the key to their success.
> Would you say in 2018, that LLVM is the wolf? And as such, everyone
> should stick to gcc? No, you  wouldn't, nobody would.
>
> What's important is 

Re: [Development] Build system for Qt 6

[Jean-Michaël Celerier]

Especially considering that the person proposing the change is working 
at google which is where GN comes from. There's some conflict of 
interest here.


On 01/11/2018 12:13, André Pönitz wrote:

On Thu, Nov 01, 2018 at 08:34:34AM +, Simon Hausmann wrote:

>From the same email perhaps it's also worth quoting the first paragraph:
"

first things first: If you're happy with cmake, you can stop reading now.
Nobody is proposing that LLVM moves off cmake, and nobody is proposing
anything that's causing people using cmake more work.
"

Sure, that's how one approaches larger controversial changes, not just
in software development, but also general politics:

1. Promise that everything is optional, and existing uses won't change,
and nobody will be affected unless opted-in. This keeps the initial
outcry a bay. Optionally, start to belittle opposition as inveterate
nay-sayers, as there is clearly no reason to oppose something people
do voluntarily.

2. Once installed, apply salami tactics by extending the scope of the
measure, "add value" to the new system, asked for or not, and let the old
one rot. If needed, little stabs in the back help to speed up the process.

3. At some time the new system will indeed be better in some setups than
the old one, and the opt-in gets opt-out. This is also a good time to
gauge remaining resistance, and either continue with 2 or directly go
to 4.

4. Sweep remaining issues under the carpet and declare the old system dead.


As I said, that's nothing specific to LLVM and Cmake.

The pattern to message "Nobody has any intention to do X" while planning
or even already executing X is so widely used that in the presence of
such a statement it is safer to assume that this is just stage 1 of the
process above than to accept the statement at face value.

Andre'

___
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] Build system for Qt 6

[Jean-Michaël Celerier]

Yes, it's a big requirement for a lot of people using OFX that they be 
able to use also Xcode and / or Visual Studio. But QBS was at some point 
(not sure if still the case) the main one.


On 30/10/2018 22:25, Иван Комиссаров wrote:
Huh? Looks like they are supporting every build system alive 
https://github.com/openframeworks/openFrameworks/tree/patch-release/libs/openFrameworksCompiled/project


30 окт. 2018 г., в 22:14, Jean-Michaël Celerier 
<mailto:jeanmichael.celer...@gmail.com>> написал(а):


OpenFrameworks, a fairly used creative coding framework has been 
using QBS for a few years. My experience with it in that context has 
been quite negative - a year ago it would break on every new QBS 
release, so you had to use an exact QBS version if you wanted to use 
OFX (exhibit A: 
https://forum.openframeworks.cc/t/qtcreator-v4-3-1-qbs-problem/27214), 
so multiple people I know have ended up porting OF to use CMake 
instead : https://github.com/ofnode/of which frankly worked better 
and with less breakage. As always, mileage may vary.



-------
Jean-Michaël Celerier
http://www.jcelerier.name <http://www.jcelerier.name/>


On Tue, Oct 30, 2018 at 10:07 PM Thiago Macieira 
mailto:thiago.macie...@intel.com>> wrote:


On Tuesday, 30 October 2018 13:47:00 PDT Oswald Buddenhagen wrote:
> On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote:
> > On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen
wrote:
> > > doesn't authorize you to impose requirements that make it
basically
> > > impossible to employ qt as a bootstrapping device for a qbs
> > > ecosystem.
> >
> > The whole point was "let Qt not be the guinea pig".
>
> you're essentially presuming that qbs is developed by a potentially
> incompetent external entity.

No. However, I am asking for proof.

> > Show me that the tool can achieve what Qt needs for it to achieve
>
> qtbase//wip/qbs2 speaks for itself.

That's the guinea pig. I am asking for proof by seeing someone
else adopt it.
The tool is now several years old, it ought to have attracted
*someone*.

And even if it hasn't, there are a couple of years left until we
switch for
Qt. The community supporting this tool can find other projects of
moderate
complexity to work with and support.

> > and has enough of a track record of a community to ask for help.
>
> it has enough "community" and intrinsic quality to get things
going.

I'm not disputing it has quality. But it lacks a specific
community I called
for: packagers.

Tell me, has anyone tried to build that branch in the Boot2Qt
context?

> asking for more is completely unreasonable before the community
from
> which the tool originates shows committment by *relying* on it.
and as
> the current situation shows, everyone who didn't trust the
story was
> *right*.

I disagree and I find it completely reasonable to ask. That's why
I did so.

And yes, they were right: if qbs is created for Qt alone, then
they shouldn't
rely on it. Hence the request to show that it can be used by
others and that
there's at least a modest community behind it.

There has been enough time to get more adoption and there's still
time left.
So get someone else to adopt it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com <http://intel.com/>

  Software Architect - Intel Open Source Technology Center



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

___
Development mailing list
Development@qt-project.org <mailto: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] Build system for Qt 6

[Jean-Michaël Celerier]

OpenFrameworks, a fairly used creative coding framework has been using QBS
for a few years. My experience with it in that context has been quite
negative - a year ago it would break on every new QBS release, so you had
to use an exact QBS version if you wanted to use OFX (exhibit A:
https://forum.openframeworks.cc/t/qtcreator-v4-3-1-qbs-problem/27214), so
multiple people I know have ended up porting OF to use CMake instead :
https://github.com/ofnode/of which frankly worked better and with less
breakage. As always, mileage may vary.


---
Jean-Michaël Celerier
http://www.jcelerier.name


On Tue, Oct 30, 2018 at 10:07 PM Thiago Macieira 
wrote:

> On Tuesday, 30 October 2018 13:47:00 PDT Oswald Buddenhagen wrote:
> > On Tue, Oct 30, 2018 at 12:53:48PM -0700, Thiago Macieira wrote:
> > > On Tuesday, 30 October 2018 12:29:46 PDT Oswald Buddenhagen wrote:
> > > > doesn't authorize you to impose requirements that make it basically
> > > > impossible to employ qt as a bootstrapping device for a qbs
> > > > ecosystem.
> > >
> > > The whole point was "let Qt not be the guinea pig".
> >
> > you're essentially presuming that qbs is developed by a potentially
> > incompetent external entity.
>
> No. However, I am asking for proof.
>
> > > Show me that the tool can achieve what Qt needs for it to achieve
> >
> > qtbase//wip/qbs2 speaks for itself.
>
> That's the guinea pig. I am asking for proof by seeing someone else adopt
> it.
> The tool is now several years old, it ought to have attracted *someone*.
>
> And even if it hasn't, there are a couple of years left until we switch
> for
> Qt. The community supporting this tool can find other projects of moderate
> complexity to work with and support.
>
> > > and has enough of a track record of a community to ask for help.
> >
> > it has enough "community" and intrinsic quality to get things going.
>
> I'm not disputing it has quality. But it lacks a specific community I
> called
> for: packagers.
>
> Tell me, has anyone tried to build that branch in the Boot2Qt context?
>
> > asking for more is completely unreasonable before the community from
> > which the tool originates shows committment by *relying* on it. and as
> > the current situation shows, everyone who didn't trust the story was
> > *right*.
>
> I disagree and I find it completely reasonable to ask. That's why I did so.
>
> And yes, they were right: if qbs is created for Qt alone, then they
> shouldn't
> rely on it. Hence the request to show that it can be used by others and
> that
> there's at least a modest community behind it.
>
> There has been enough time to get more adoption and there's still time
> left.
> So get someone else to adopt it.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Build system for Qt 6

[Jean-Michaël Celerier]

> Will CMake allow us to build for, say, QNX, GreenHill, VxWorks, and the
likes?

uhh... yeah? CMake has supported Green Hills for years.

>CMake is not even aware that they are other OS behind WIndows and
Linux Desktop

sorry, that's FUD. CMake has built-in support for Android, macOS, UWP apps
and works just fine on BSDs and other niche OS such as Haiku (full list
here : https://github.com/Kitware/CMake/tree/master/Modules/Platform).
Hell, it's the build system for at least two existing alternative OSes:
ReactOS (https://github.com/reactos/reactos) and IncludeOS (
https://github.com/hioa-cs/IncludeOS).

iOS is curerntly best supported (imho) through
https://github.com/ruslo/polly which is a set of toolchains not unlike
qmake's mkspecs.

---
Jean-Michaël Celerier
http://www.jcelerier.name


On Tue, Oct 30, 2018 at 12:24 PM Christian Gagneraud 
wrote:

> > > On 30 Oct 2018, at 05:00, Christian Gagneraud 
> wrote:
> > > - Any track record that Qbs was not fit for the job? (Please no "we
> > > can't build Qt with it", as you cannot build Qt with anything but
> > > qmake right now)
> >
> > No, of course one could have made it support building Qt. There were
> some missing items like the configuration system and some other things, all
> of those could of course have been implemented.
>
> How CMake will solve the 'configuration' problem. Will CMake allow us
> to build for, say, QNX, GreenHill, VxWorks, and the likes? I doubt!
> Everyone is bragging about open source (me first), but the Qt market
> is medical, automotive and avionics/space industry, isn't it? How will
> CMake cope with that?
> CMake is not even aware that they are other OS behind WIndows and
> Linux Desktop
>
> Just Sayin'.
> Chris
> ___
> 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] Build system for Qt 6

[Jean-Michaël Celerier]

Hi all,
I'd like to point you to a mailing list message of Brad King from a few
months ago about alternative languages for CMake :
https://cmake.org/pipermail/cmake-developers/2016-January/027379.html
(damn, two years actually.. time flies)


> In summary, I think work in this direction should first focus on designing
a declarative (or functional) specification format where most of the project
information can be specified.  Then a cmake-language command can be written
to load and evaluate a specification file (as a transition).  Finally we
could look at replacing the entry-point language with something else.  At
that point we could have closures passed as parameters to the evaluation of
the pure spec in order to get custom generate-time logic.

Brad for those who don't know is one of the main (dare I say *the* main)
CMake contributors (https://www.kitware.com/brad-king/).
So, why not just go and propose the declarative QBS syntax as a front-end
for CMake ? This would make the world a better place. The CMake people
*want* a better language, and for these use cases, QML is certainly much
closer to the solution than others.


---
Jean-Michaël Celerier
http://www.jcelerier.name


On Tue, Oct 30, 2018 at 10:26 AM Christian Gagneraud 
wrote:

> On Tue, 30 Oct 2018 at 22:18, Richard Weickelt 
> wrote:
> >
> > Ich schick's doch nicht an die Liste, ist wenig konstruktiv :-/
> > > No conspiracy here, but i have a few more questions (not related, in
> > > no particular order)
> > > - Did Jake left the QtC due to your early decision to drop qbs? ( I
> > > personally do think that the decision was taken long time ago)
> > > - Did you drop Qbs due to it's "unsolvable" dependency on deprecated
> Qt Script?
> > > - Any track record that Qbs was not fit for the job? (Please no "we
> > > can't build Qt with it", as you cannot build Qt with anything but
> > > qmake right now)
> >
> > Do You remember Tino Pyssysalo's ominous survey on the qbs mailing list
> in
> > June? I asked him explicitly for more transparency about the
> decision-making
> > process about the future of Qbs. Apart from a vague promise, I heard
> nothing
> > back.
>
> ,https://lists.qt-project.org/mailman/listinfo/qbs gives me:
> Secure Connection Failed
> An error occurred during a connection to lists.qt-project.org. SSL
> received a record that exceeded the maximum permissible length. Error
> code: SSL_ERROR_RX_RECORD_TOO_LONG
>
> As reported on qt-interest recently, lists.qt-project.org is serving
> plain HTTP over port 443.
>
> Chris
> ___
> 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] Improving CMake support for static builds

[Jean-Michaël Celerier]

>  but there is no information for the
flags needed to link against system libraries (freetype, harfbuzz,
etc.)

it would be so nice to add them ! currently I have to use the following
chthonic horror:
https://github.com/OSSIA/score/blob/master/base/app/StaticApp.cmake

I think that in Qt the pkg-config files are generated by a perl script,
maybe the same could be used for static builds ?

---
Jean-Michaël Celerier
http://www.jcelerier.name


On Fri, Oct 12, 2018 at 9:12 PM Kyle Edwards 
wrote:

> Hello everyone,
>
> New Qt developer here. I'm trying to improve Qt's support for static
> builds using CMake - specifically, encoding transitive dependencies in
> the *Config.cmake files. I see that these files already have inter-
> module dependencies encoded in the exported targets'
> INTERFACE_LINK_LIBRARIES property, but there is no information for the
> flags needed to link against system libraries (freetype, harfbuzz,
> etc.)
>
> With dynamic builds, this isn't an issue, because the Qt modules
> themselves link against these libraries. However, static builds need
> this information to generate a fully linked binary. I've started a
> patch to add this support, but I'm not very familiar with Qt's
> buildsystem, and I was hoping someone could help me figure out how to
> get the information that I need. The start of my patch is below:
>
> -
>
> diff --git a/mkspecs/features/create_cmake.prf
> b/mkspecs/features/create_cmake.prf
> index 2ed708e..2d5ab55 100644
> --- a/mkspecs/features/create_cmake.prf
> +++ b/mkspecs/features/create_cmake.prf
> @@ -180,6 +180,7 @@ CMAKE_MKSPEC = $$[QMAKE_XSPEC]
>  sorted_deps = $$sort_depends(QT.$${MODULE}.depends, QT.)
>  mod_deps =
>  lib_deps =
> +mod_link_flags =
>  aux_mod_deps =
>  aux_lib_deps =
>  # Until CMake 3.0 is the minimum requirement of Qt 5, we need to
> filter
> @@ -197,6 +198,7 @@ for (dep, sorted_deps) {
>  }
>  CMAKE_MODULE_DEPS = $$join(mod_deps, ";")
>  CMAKE_QT5_MODULE_DEPS = $$join(lib_deps, ";")
> +CMAKE_MODULE_LINK_FLAGS = $$join(mod_link_flags, ";")
>  CMAKE_INTERFACE_MODULE_DEPS = $$join(aux_mod_deps, ";")
>  CMAKE_INTERFACE_QT5_MODULE_DEPS = $$join(aux_lib_deps, ";")
>
> diff --git a/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in
> b/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in
> index 3ed6dd5..a320902 100644
> --- a/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in
> +++ b/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in
> @@ -64,6 +64,11 @@
> macro(_populate_$${CMAKE_MODULE_NAME}_target_properties Configuration
> LIB_LOCATI
>  !!IF !isEmpty(CMAKE_LIB_SONAME)
>  \"IMPORTED_SONAME_${Configuration}\" \"$${CMAKE_LIB_SONAME}\"
>  !!ENDIF
> +!!IF !isEmpty(CMAKE_STATIC_TYPE)
> +!!IF !isEmpty(CMAKE_MODULE_LINK_FLAGS)
> +\"INTERFACE_LINK_OPTIONS\"
> \"${_Qt5$${CMAKE_MODULE_NAME}_LIB_LINK_FLAGS}\"
> +!!ENDIF
> +!!ENDIF
>  # For backward compatibility with CMake < 2.8.12
>  \"IMPORTED_LINK_INTERFACE_LIBRARIES_${Configuration}\"
> \"${_Qt5$${CMAKE_MODULE_NAME}_LIB_DEPENDENCIES}\"
>  )
> @@ -215,6 +220,10 @@ if (NOT TARGET Qt5::$${CMAKE_MODULE_NAME})
>  !!ENDIF
>
>  !!IF !isEmpty(CMAKE_STATIC_TYPE)
> +!!IF !isEmpty(CMAKE_MODULE_LINK_FLAGS)
> +set(_Qt5$${CMAKE_MODULE_NAME}_LIB_LINK_FLAGS
> \"$${CMAKE_MODULE_LINK_FLAGS}\")
> +
> +!!ENDIF
>  add_library(Qt5::$${CMAKE_MODULE_NAME} STATIC IMPORTED)
>  set_property(TARGET Qt5::$${CMAKE_MODULE_NAME} PROPERTY
> IMPORTED_LINK_INTERFACE_LANGUAGES "CXX")
>  !!ELSE
>
> -
>
> I've figured out how to pass information into Qt5BasicConfig.cmake.in
> from create_cmake.prf, but I'm not sure where to get the link flags
> that need to be passed in. Any advice would be appreciated.
>
> Kyle
> ___
> 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] Orphan modules

[Jean-Michaël Celerier]

There are quite a bunch of people using it out there :
https://github.com/search?l=C%2B%2B=QX11Info+NOT+tst_QX11Info+NOT+QT_END_LICENSE=Code


---
Jean-Michaël Celerier
http://www.jcelerier.name


On Thu, Sep 13, 2018 at 1:41 AM Thiago Macieira 
wrote:

> On Wednesday, 12 September 2018 10:09:53 PDT Tor Arne Vestbø wrote:
> > If they do, does the list say anything about whether or not those APIs
> have
> > modern replacements in Qt or other ways to do the same?
>
> There's exactly one class in QtX11Extras: QX11Info.
> http://doc.qt.io/qt-5/qx11info.html
>
> I could see kwin_x11 needing it, but I really don't see all the other
> applications doing so. Do we have a replacement for QX11Info?
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration

[Jean-Michaël Celerier]

For this kind of work I'd recoment QNanoPainter, it's another Qt paint
engine built on top of modern openGL, very efficient for what you want
(polylines) :
https://github.com/QUItCoding/qnanopainter

Best,
---
Jean-Michaël Celerier
http://www.jcelerier.name


On Sun, Sep 2, 2018 at 2:45 PM Uwe Rathmann 
wrote:

> On Thu, 30 Aug 2018 15:47:34 -0700, Thiago Macieira wrote:
>
> > You can always just use QPainter on a QPixmap and paint that pixmap on
> > your QSGPaintedItem. It won't be particularly fast, but it will work and
> > do what you asked.
>
> After some conversation with Denis: the use case of this thread is a
> oscilloscope - drawing a polyline with ~400 points, 10 times a second.
>
> It is possible to reduce the CPU load from 100% to 50% simply by using a
> QOpenGLWidget as plot canvas. With raster we probably never reached 10
> frames, so all we know is that the improvement is more than by factor 2.
>
> The rest seems to be related to the grid lines, and updating the tick
> labels on the axis.
>
> Updating the tick labels 10 times a second does not make much sense as
> nobody can read this. So I would consider this being an issue, that has
> to be solved on application side.
>
> But the grid lines are responsible for ~30% of the remaining CPU load, so
> let's spend some thoughts on this:
>
> drawing them requires a sequence of QPainter::drawLine calls ( maybe
> 10-20 ) with a pen width of 1 in Qt::DotLine style. Changing the style to
> Qt::SolidLine makes this part of the CPU load disappear - actually the
> CPU load becomes the same as when not drawing the grid at all.
>
> So I would guess that the CPU cycles are related to calculating the dots
> for each line before forwarding it to some OpenGL call.
>
> > If you want faster, redesign with OpenGL in mind.
>
> What does that mean for a task like drawing a dotted line and why do you
> consider application code being more effective in finding a fast
> implementation for this ?
>
> I would expect the author/maintainer of the OpenGL paint engine being an
> expert in how to use OpenGL in the most effective way and the job of this
> module should be to keep away those details from the application code.
>
> And what would be the benefit of Qt/Quick for drawing dotted lines ? How
> would it be different/superior compared to writing pure OpenGL code - f.e
> in QOpenGLWidget::paintGL ?
>
> And why should Denis use Qt at all if he is supposed to break down basic
> primitives to pure OpenGL himself ?
>
> Uwe
>
>
> ___
> 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] Apparently dead code: GPU_BLACKLIST and friends

[Jean-Michaël Celerier]

>  Inevitably, I'm contemplating a featurectomy.  Laszlo, who introduced
this for some fragile embedded systems in 2015, doesn't believe it's in
use, I don't see any evidence that it's documented anywhere (so I don't
expect anyone to be using it outside Qt itself *and* I can only work out
how it's supposed to work by reading its code), so I'm hoping no-one
will object to this going, perhaps even as soon as 5.12.

I remember using it to be able to run integration tests on a virtual X11
server in Travis CI.
I'm not the only one :
https://github.com/search?p=1=QTEST_ADD_GPU_BLACKLIST_SUPPORT_DEFS=Code

---
Jean-Michaël Celerier
http://www.jcelerier.name


On Wed, Aug 8, 2018 at 1:23 PM Edward Welbourne 
wrote:

> Hi all,
>
> I notice that QTest includes support, in [0], alongside its BLACKLIST
> files for problematic tests, for a GPU_BLACKLIST file; there are,
> however, no GPU_BLACKLIST files anywhere in our source tree (in any
> currently live branch, from 5.6 to dev).  There's a whole complex
> QTEST_ADD_GPU_BLACKLIST_SUPPORT macro set-up for a hook function named
> gpu_features() to control this; unless that's activated *and* a
> GPU_BLACKLIST file is found, the whole GPU blacklisting feature does
> nothing.
>
> * [0] qtbase/src/testlib/qtestblacklist.cpp
>
> Inevitably, I'm contemplating a featurectomy.  Laszlo, who introduced
> this for some fragile embedded systems in 2015, doesn't believe it's in
> use, I don't see any evidence that it's documented anywhere (so I don't
> expect anyone to be using it outside Qt itself *and* I can only work out
> how it's supposed to work by reading its code), so I'm hoping no-one
> will object to this going, perhaps even as soon as 5.12.
>
> So, if you're using GPU_BLACKLIST files, please speak up now (or forever
> hold your peace); and, if you can think of a good reason why this can't
> be removed from 5.12 - assuming I get round to it before feature freeze
> - please also speak up,
>
> Eddy.
> ___
> 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] Qt 6 buildsystem support requirements

[Jean-Michaël Celerier]

> I would say the only two options in the running are qbs and CMake.

About this, I don't know if C++ community acceptance is a criterion, but :

https://github.com/search?q=cmake

https://github.com/search?q=qbs



On Tue, Jul 31, 2018 at 4:41 PM, Thiago Macieira 
wrote:

> On Monday, 30 July 2018 23:11:54 PDT Denis Shienkov wrote:
> > As for me, is it prefferable variant will be *QBS* (it is best from the
> > best).
> >
> > I'm do not like nor CMake, nor QMake, nor Autotools, nor something else.
>
> I would say the only two options in the running are qbs and CMake.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 6 buildsystem support requirements

[Jean-Michaël Celerier]

Sounds like you have a configuration problem in Qt Creator. I've been using
qtc with the clang code model and CMake projects for over a year on various
C++11/14/17 projects and everything works fine.

$ echo '#include \nint main() { std::string_view s("foo"); }'
> main.cpp ; echo 'project(foo CXX)\nset(CMAKE_CXX_STANDARD
17)\nadd_executable(foo main.cpp)' > CMakeLists.txt

results for me in correct completion of std::string_view in qtc.



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Sun, Jul 22, 2018 at 12:57 PM, Иван Комиссаров  wrote:

>
> 21 июля 2018 г., в 23:04, Thiago Macieira 
> написал(а):
>
> On Saturday, 21 July 2018 10:39:49 PDT Иван Комиссаров wrote:
>
> 1. IDE integration. I really need the IDE know the correct CXX flags for
> each separate file in my project - that is includes, c++ version and so on.
> Currently i’m using a generated CMake file at my work and the integration
> with Qt Creator is awful, i’m using IDE just as a simple text editor -
> syntax highlighting breaks because IDE can’t find some headers (however,
> goto definition works for them).
>
>
> That's already more than what we have for qmake, so I wouldn't put this as
> a
> requirement. It's a nice-to-have.
>
>
> But only qmake works fine with new clang model, other build systems pass
> incorrect parameters to clang so it can’t compile my files (code model
> complains about missing std:: classes/functions, however the code compiles
> so project file is correct)
>
>
> The point is that the tool has to be at least in feature parity with qmake
> and
> that includes cross-compilation and IDE support.
>
> Yes, CMake has much more users than QBS, however, how many of them will
> volunteer to work with CMake’s Qt Creator integration? 5 people? 10?
>
>
> 5 people would be more than what we currently have for either qmake or qbs
> today, so seems ok.
>
>
> That’s true, but despite huge CMake community, Qt Creator’s CMake
> integration still is not in feature-parity with qmake.
> I had a discussion with one of QBS developer about iOS integration in Qt
> Creator and he told that Qt Creator uses some qmake hacks that are not
> viable for QBS (yet). Hacking CMake may be much trickier as codebase is not
> controlled by Qt community.
>
>
> So the question is - is it easier to port QBS to be built without Qt or to
> use CMake with Qt?
>
>
> Again, solving the build is easy. Please look into the requirements at
> (2).
> THAT is a lot harder. And all I'm asking is for experience. I don't want
> Qt to
> be the guinea pig.
>
>
> I used QBS and CMake for building debian packages in 2015 at one of my
> previous works. All you need for QBS is to use usual makefile based
> debian/rules files and replace «make install» with «qbs install».
> Here’s the actual code i used to build my tool (except i replace real
> package/tool names with «projectname») https://pastebin.com/RbPL8GAq
> That’s it. You pointing too much attention to the Linux distros and
> maintainers, which is very important, but you are using wrong arguments.
> Give those maintainers a good tool and they will be happy. And the «good
> tool» is not the same as «tool has been used for at least 2 years». People
> has been using plain makefiles for decades, people has been using autotools
> for years. But i guess anyone agrees that autotools sucks.
> The same is for CMake - people are using it because they don’t have any
> alternative. QBS can become that alternative. In case if it will not be
> buried alive.
> Common, how you can compare the tools if you didn’t even used QBS? I’ve
> been using qmake since 2011 i’ve been using CMake since 2013, i worked both
> with CMake/QBS to create debian packages, i had to work with GYP in 2016,
> now i’m using QBS for all of my projects. So i can *compare* tools not by
> providing abstract requirements, but from the experience of *using *all
> those tools.
>
>
>
> More to the point: I will not be part of the experimentation. Give me a
> mature
> tool.
>
>
> The autotools are mature:)
>
> PS: BTW, in first letter i forgot to mention that the company i’m working
> right now ended up with writing it’s own build tool just because CMake
> didn’t fit all requirements we need from a build tool. We’ve been using
> CMake, then we wrap all the CMake mess in a set of small macroses
> (PROGRAM(name), LIBRARY and so on) and then replaced cmake with the tool
> that understands only those macroses. I don’t know exact reasons why CMake
> was dropped (when i came to the company, the only thing left from CMake was
> the project file names - CMakeLists.txt), however it’s true that CMake has
> a lot of tricky parts when you start using it.
>
> The sam

Re: [Development] Qt 6 buildsystem support requirements

[Jean-Michaël Celerier]

My bad, I thought that you were counting in Kloc of code, not in kilobytes.
That's in my opinion a weird metric for measuring code since indenting
with, say, 4 spaces instead of 1 tab would certainly end up giving wild
differences.

cloc cmake/Source/cmQt*
---
Language files  blankcomment
code
---
C++  5371500
4362
C/C++ Header 5126173
740
---
SUM:10497673
5102
---

I don't know for you, but 5kloc of modern C++ seems to be a fairly small
price to pay to parse all my .cpp automatically for moc macros (no need to
specify headers unlike qmake!), parallel execution of multiple moc /uic /
rcc instances (
https://cmake.org/cmake/help/v3.12/prop_tgt/AUTOGEN_PARALLEL.html), direct
support for multiple files with the same name (e.g. having two files with
Q_OBJECT named Settings.h in different folders won't cause a problem with
cmake, unlike qmake which puts everything in the root build folder by
default and will happilly overwrite a moc_Settings.cpp with another), etc (
https://cmake.org/cmake/help/v3.12/prop_tgt/AUTOMOC.html).

> Playing devil's advocate, please bear with me:

> Because it makes people worry that cmake-lang is too limited, and if you
need to do certain things (*), you need to resort to patch the tool itself.

But, which build system commonly used with Qt doesn't behave like this ?
qmake is cpp + qmake-lang, qbs is cpp + QML. AFAIK meson, waf, scons do not
support automatic moc'ing. At some point, some code has to be injected in
the build tool if you want to add automatic global behaviour - and I'd take
automatic global behaviour everyday over doing stuff like this:
http://mesonbuild.com/Qt5-module.html or
https://scons.org/doc/2.0.1/HTML/scons-user/a8524.html

---
Jean-Michaël Celerier
http://www.jcelerier.name

On Sat, Jul 21, 2018 at 7:07 PM, Ray Donnelly 
wrote:

> On Sat, Jul 21, 2018 at 4:42 PM, Jean-Michaël Celerier
>  wrote:
> > That's fairly disingenuous, if not blatantly false. There are, like, 6
> .cpp
> > files in the CMake repo which provide the Qt-specific commands :
> > https://github.com/Kitware/CMake/tree/master/Source (grep for cmQt).
> >
>
> What is disingenuous, if not blatantly false? Be specific please.
>
> git clone https://gitlab.kitware.com/cmake/cmake.git
>
> du -csh cmake/Source/cmQt*
> 8.0K cmake/Source/cmQtAutoGen.cxx
> 4.0K cmake/Source/cmQtAutoGen.h
>  52K cmake/Source/cmQtAutoGenInitializer.cxx
> 4.0K cmake/Source/cmQtAutoGenInitializer.h
>  24K cmake/Source/cmQtAutoGenerator.cxx
>  12K cmake/Source/cmQtAutoGenerator.h
>  64K cmake/Source/cmQtAutoGeneratorMocUic.cxx
>  12K cmake/Source/cmQtAutoGeneratorMocUic.h
>  20K cmake/Source/cmQtAutoGeneratorRcc.cxx
> 4.0K cmake/Source/cmQtAutoGeneratorRcc.h
> 204K total
>
> I stand corrected, there *used* to be 150K of Qt specific C++ code in
> CMake, but since I last checked it's grown to 204K (or perhaps I
> counted it less well last time?)
>
> And Giuseppe's devil's advocacy does speak to some of my issues with
> CMake (along with it's lack of proper cross compilation support, it
> defaulting to looking in *system* folders (which is never what any
> non-chrooted distro wants).
>
> Qbs is far better IMHO.
>
> > Besides... why would it matter that they are implemented in C++ instead
> of
> > cmake-lang ? If anything, CMake's automoc is in my experience much
> faster to
> > process the whole repo.
> >
> > Richard: so what's this then ?
> > https://github.com/qbs/qbs/blob/2d1de8cc84b258174b2dc0a8080f54
> 9cd9b59b32/src/lib/corelib/buildgraph/qtmocscanner.cpp
> >
> >
> >
> > ---
> > Jean-Michaël Celerier
> > http://www.jcelerier.name
> >
> > On Sat, Jul 21, 2018 at 4:39 PM, Ray Donnelly 
> > wrote:
> >>
> >> CMake has its own 'language' that was retrofitted after the fact,
> evolving
> >> from a simple definition based system.
> >>
> >> So why aren't all these special rules written in that 'language' then?
> 150
> >> odd k of qt c++ hacks is what we get instead.
> >>
> >> On Sat, Jul 21, 2018, 3:26 PM Jean-Michaël Celerier
> >>  wrote:
> >>>
> >>> > How much custom c++ code does it contains for just qt?
> >>>
> >>> which build system which supports automatic calling of moc d

Re: [Development] Qt 6 buildsystem support requirements

[Jean-Michaël Celerier]

That's fairly disingenuous, if not blatantly false. There are, like, 6 .cpp
files in the CMake repo which provide the Qt-specific commands :
https://github.com/Kitware/CMake/tree/master/Source (grep for cmQt).

Besides... why would it matter that they are implemented in C++ instead of
cmake-lang ? If anything, CMake's automoc is in my experience much faster
to process the whole repo.

Richard: so what's this then ?
https://github.com/qbs/qbs/blob/2d1de8cc84b258174b2dc0a8080f549cd9b59b32/src/lib/corelib/buildgraph/qtmocscanner.cpp



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Sat, Jul 21, 2018 at 4:39 PM, Ray Donnelly 
wrote:

> CMake has its own 'language' that was retrofitted after the fact, evolving
> from a simple definition based system.
>
> So why aren't all these special rules written in that 'language' then? 150
> odd k of qt c++ hacks is what we get instead.
>
> On Sat, Jul 21, 2018, 3:26 PM Jean-Michaël Celerier <
> jeanmichael.celer...@gmail.com> wrote:
>
>> > 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 ?
>>
>>
>>
>>
>> ---
>> Jean-Michaël Celerier
>> http://www.jcelerier.name
>>
>> On Sat, Jul 21, 2018 at 3:48 PM, Ray Donnelly 
>> wrote:
>>
>>> As someone who works on a cross platform distribution let me tell you
>>> that cmake is plain terrible. How much custom c++ code does it contains for
>>> just qt? Loads, absolutely tonnes or rubbish.
>>>
>>> On Sat, Jul 21, 2018, 1:49 PM Jean-Michaël Celerier <
>>> jeanmichael.celer...@gmail.com> wrote:
>>>
>>>> > There is a build system that fulfills all of Thiago's points, and it
>>>> is
>>>> already widely used in the Qt community: CMake.
>>>>
>>>> +1, I was flabbergasted when the big objection against CMake in Qt 6
>>>> boiled down to "it does not supports all the architectures that Qt
>>>> supports", so instead of contributing them - or hell, even forking CMake
>>>> for those specific architectures (what are them ? I use cmake for windows,
>>>> mac, linux, android, ios and the toolchain file allows for a lot of
>>>> customization), what, create a new build system from scratch that splits
>>>> the C++ community further ? There would be so much to gain with a better
>>>> relationship between Qt and CMake.
>>>>
>>>> Best,
>>>> ---
>>>> Jean-Michaël Celerier
>>>> http://www.jcelerier.name
>>>>
>>>> On Sat, Jul 21, 2018 at 2:42 PM, Kevin Kofler 
>>>> wrote:
>>>>
>>>>> Bogdan Vatra via Development wrote:
>>>>> > Anyway IMHO is more important to have a clean, nice and easy to use
>>>>> syntax
>>>>> > and to be tooling friendly than 1.b.
>>>>>
>>>>> A custom build system is always a major pain point for distributions.
>>>>> A
>>>>> circular dependency (what Thiago's 1.b forbids) makes it particularly
>>>>> painful. How should we bootstrap new architectures or entirely new
>>>>> distributions if we cannot build Qt due to the circular dependency
>>>>> between
>>>>> Qt and its build tool? This is a showstopper.
>>>>>
>>>>> > GN[1] is another example of build system which didn't care too much
>>>>> about
>>>>> > 1.a,b,c and it still used in quite big projects (e.g. chrome,
>>>>> fuchsia). To
>>>>> > my huge surprise, they managed to move it into a separate repo and
>>>>> remove
>>>>> > all chromium dependencies (yep, a few months ago you had to checkout
>>>>> the
>>>>> > entire chromium repo to build it :) ).
>>>>>
>>>>> GN (and its predecessor Gyp) is universally hated by distribution
>>>>> packagers
>>>>> for its non-standardness, weirdness, lack of documentation (including
>>>>> third-
>>>>> party documentation such as tutorials, an issue inherent to custom
>>>>> build
>>>>> systems) and lack of flexibility (custom build systems are never as
>>>>> powerful
>>>>> as widely-used general-purpose build systems).
>>>>>
>>>>> QtWebEngine is a particular pain to package because it uses TWO custom
>>>>> build
>>>>> systems (QMake and GN).
>>>>>
>>>>> The Chromium mess is also what prompted Spot to write the list of
>>>>> FAILs
>>>>> [https://spot.livejournal.com/308370.html] I have already linked to
>>>>> elsewhere in this thread.
>>>>>
>>>>>
>>>>> There is a build system that fulfills all of Thiago's points, and it
>>>>> is
>>>>> already widely used in the Qt community: CMake.
>>>>>
>>>>> Kevin Kofler
>>>>>
>>>>> ___
>>>>> 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
>>>>
>>>
>>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 6 buildsystem support requirements

[Jean-Michaël Celerier]

> 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 ?




---
Jean-Michaël Celerier
http://www.jcelerier.name

On Sat, Jul 21, 2018 at 3:48 PM, Ray Donnelly 
wrote:

> As someone who works on a cross platform distribution let me tell you that
> cmake is plain terrible. How much custom c++ code does it contains for just
> qt? Loads, absolutely tonnes or rubbish.
>
> On Sat, Jul 21, 2018, 1:49 PM Jean-Michaël Celerier <
> jeanmichael.celer...@gmail.com> wrote:
>
>> > There is a build system that fulfills all of Thiago's points, and it is
>> already widely used in the Qt community: CMake.
>>
>> +1, I was flabbergasted when the big objection against CMake in Qt 6
>> boiled down to "it does not supports all the architectures that Qt
>> supports", so instead of contributing them - or hell, even forking CMake
>> for those specific architectures (what are them ? I use cmake for windows,
>> mac, linux, android, ios and the toolchain file allows for a lot of
>> customization), what, create a new build system from scratch that splits
>> the C++ community further ? There would be so much to gain with a better
>> relationship between Qt and CMake.
>>
>> Best,
>> ---
>> Jean-Michaël Celerier
>> http://www.jcelerier.name
>>
>> On Sat, Jul 21, 2018 at 2:42 PM, Kevin Kofler 
>> wrote:
>>
>>> Bogdan Vatra via Development wrote:
>>> > Anyway IMHO is more important to have a clean, nice and easy to use
>>> syntax
>>> > and to be tooling friendly than 1.b.
>>>
>>> A custom build system is always a major pain point for distributions. A
>>> circular dependency (what Thiago's 1.b forbids) makes it particularly
>>> painful. How should we bootstrap new architectures or entirely new
>>> distributions if we cannot build Qt due to the circular dependency
>>> between
>>> Qt and its build tool? This is a showstopper.
>>>
>>> > GN[1] is another example of build system which didn't care too much
>>> about
>>> > 1.a,b,c and it still used in quite big projects (e.g. chrome,
>>> fuchsia). To
>>> > my huge surprise, they managed to move it into a separate repo and
>>> remove
>>> > all chromium dependencies (yep, a few months ago you had to checkout
>>> the
>>> > entire chromium repo to build it :) ).
>>>
>>> GN (and its predecessor Gyp) is universally hated by distribution
>>> packagers
>>> for its non-standardness, weirdness, lack of documentation (including
>>> third-
>>> party documentation such as tutorials, an issue inherent to custom build
>>> systems) and lack of flexibility (custom build systems are never as
>>> powerful
>>> as widely-used general-purpose build systems).
>>>
>>> QtWebEngine is a particular pain to package because it uses TWO custom
>>> build
>>> systems (QMake and GN).
>>>
>>> The Chromium mess is also what prompted Spot to write the list of FAILs
>>> [https://spot.livejournal.com/308370.html] I have already linked to
>>> elsewhere in this thread.
>>>
>>>
>>> There is a build system that fulfills all of Thiago's points, and it is
>>> already widely used in the Qt community: CMake.
>>>
>>> Kevin Kofler
>>>
>>> ___
>>> 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
>>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt 6 buildsystem support requirements

[Jean-Michaël Celerier]

> There is a build system that fulfills all of Thiago's points, and it is
already widely used in the Qt community: CMake.

+1, I was flabbergasted when the big objection against CMake in Qt 6 boiled
down to "it does not supports all the architectures that Qt supports", so
instead of contributing them - or hell, even forking CMake for those
specific architectures (what are them ? I use cmake for windows, mac,
linux, android, ios and the toolchain file allows for a lot of
customization), what, create a new build system from scratch that splits
the C++ community further ? There would be so much to gain with a better
relationship between Qt and CMake.

Best,
---
Jean-Michaël Celerier
http://www.jcelerier.name

On Sat, Jul 21, 2018 at 2:42 PM, Kevin Kofler 
wrote:

> Bogdan Vatra via Development wrote:
> > Anyway IMHO is more important to have a clean, nice and easy to use
> syntax
> > and to be tooling friendly than 1.b.
>
> A custom build system is always a major pain point for distributions. A
> circular dependency (what Thiago's 1.b forbids) makes it particularly
> painful. How should we bootstrap new architectures or entirely new
> distributions if we cannot build Qt due to the circular dependency between
> Qt and its build tool? This is a showstopper.
>
> > GN[1] is another example of build system which didn't care too much about
> > 1.a,b,c and it still used in quite big projects (e.g. chrome, fuchsia).
> To
> > my huge surprise, they managed to move it into a separate repo and remove
> > all chromium dependencies (yep, a few months ago you had to checkout the
> > entire chromium repo to build it :) ).
>
> GN (and its predecessor Gyp) is universally hated by distribution
> packagers
> for its non-standardness, weirdness, lack of documentation (including
> third-
> party documentation such as tutorials, an issue inherent to custom build
> systems) and lack of flexibility (custom build systems are never as
> powerful
> as widely-used general-purpose build systems).
>
> QtWebEngine is a particular pain to package because it uses TWO custom
> build
> systems (QMake and GN).
>
> The Chromium mess is also what prompted Spot to write the list of FAILs
> [https://spot.livejournal.com/308370.html] I have already linked to
> elsewhere in this thread.
>
>
> There is a build system that fulfills all of Thiago's points, and it is
> already widely used in the Qt community: CMake.
>
> Kevin Kofler
>
> ___
> 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] Dark mode, palettes, styles etc.

[Jean-Michaël Celerier]

> Another easy thing I think we could add to QPalette is the set of (16?)
most-common colors.  That way, when an application really wants something
to be blue, it could use QPalette:Blue, and the theme would be able to
control the brightness and the exact shade of blue.

A good benchmark for this would be to check how it would work with the
Base16 theming framework, based on 16 colors :
https://github.com/chriskempson/base16 ; they can be checked there :
http://chriskempson.com/projects/base16/

There's also Kvantum which is a SVG theme engine for Qt (examples:
https://store.kde.org/browse/cat/123/) ; it would be nice to have it
integrated to Qt directly maybe ? And then use a GPU-based SVG renderer to
only have to do the GPU work once (how far is QtQuick.Shapes from rendering
full-fledged SVG ?).

Best,
Jean-Michaël



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Fri, Jul 6, 2018 at 10:50 AM, Shawn Rutledge 
wrote:

>
> > On 4 Jul 2018, at 16:19, Morten Sørvig  wrote:
> >
> > Hi all,
> >
> > macOS 10.14 is now in (public) beta and we've had some time to test Qt
> on it.
> >
> > ...
> > Dark appearance: In theory, applications should pick up the dark
> appearance via
> > the style and palette. In practice, they may not due to incomplete/buggy
> QPalette
> > and QMacStyle implementations, or hardcoded colors in Qt or the
> application.
> >
> > The current state of the patches for dev/5.12 is that custom-styled
> applications
> > can work well in dark mode, for example Qt Creator with a dark theme.
> >
> > The plan is to disable dark mode support by default in Qt, at least until
> > QMacStyle is fixed. This means that applications will start up using
> standard
> > Aqua theme/colors, also when the desktop is configured for dark mode.
> >
> > The application has the final call here, and can opt in or out by
> setting the
> > NSRequiresAquaSystemAppearance key in the Info.plist file. For example:
> >
> >  NSRequiresAquaSystemAppearance
> >  
> >
> > will indicate that the app _does_ support dark mode, and Qt will get out
> > of the way and not apply its disable. Setting it to true will insulate
> the
> > app against any changes in the Qt default.
>
> I would like to see this feature as a cross-platform feature rather than
> mac-specific.
>
> I missed that news about Apple until now, but I had the idea a few years
> ago anyway that there should be an easy global switch (always within reach,
> not having to paw through system settings) to toggle quickly between light
> and dark themes.  There was the first time I started up my laptop on a
> plane while other passengers were trying to sleep, and got some dirty looks
> because I didn’t have much control over the brightness (the laptop’s
> backlight level couldn’t be reduced enough, and it took some time to open
> up the system settings and switch themes, and then I think I had to log out
> and back in again too.  Creator didn’t have themes at all back then.)  And
> there was a consultancy customer a few years ago who planned to have themes
> with different brightness levels in an embedded application, but AFAIK they
> still haven’t gotten around to it, maybe because we didn’t make it
> particularly easy in Qt Quick.  And actually I tend to switch themes at
> least seasonally: if there’s a lot of sun and I’m trying to hack while
> riding the metro, I can’t see well enough if the theme is too dark, but
> otherwise I like using a dark theme in darker conditions.  So it’s been
> annoying me for years that most applications can’t easily switch (they tend
> to make up for lack of system-wide settings by having their own instead),
> and some desktop environments have inconvenient controls, and/or the theme
> changes don’t necessarily propagate to all apps at once.
>
> But now that Apple is finally doing something, I think the copycats are
> inevitable, so I fully expect to see news that an identical or better
> feature is coming soon to KDE and/or Gnome any day now.  For now there’s
> just “redshift", it seems.  But IMO having a lot of white space that has
> gone dingy in the dark is not as nice as having a theme that looks good
> without having so much white in it.  And so far Apple didn’t put the switch
> in the menubar, but I suppose that’s probably inevitable too: a utility
> will probably show up in the app store, if there’s an API to make it
> possible.
>
> Anyway, to the extent that widgets and controls are drawn with QPalette
> colors, switching the palette globally ought to be easy; and we have
> QEvent::PaletteChange, so applications have already been able to respond
> quickly to system-wide palette changes for ages, right?  But there

Re: [Development] clang-format

[Jean-Michaël Celerier]

> I never seen anything QtCreator had trouble with.

really ?
paste this in a .cpp and indent it :

#define WHATEVER

struct foo
{
WHATEVER

public:
explicit foo();
};

struct bar
{
public:
explicit bar();
};




---
Jean-Michaël Celerier
http://www.jcelerier.name

On Wed, Jun 20, 2018 at 3:08 PM, Allan Sandfeld Jensen 
wrote:

> On Mittwoch, 20. Juni 2018 14:09:20 CEST Ivan Donchevskii wrote:
> > One more thing about clang-format.
> >
> > It might be really nice if we use it as a default formatting tool in Qt
> > Creator. And I really want to experiment with it and see how clang-format
> > can replace the indenter that we currently use (which has a lot of bug
> > reports about broken formatting for example with modern C++).
> >
>
> I never seen anything QtCreator had trouble with. But on the subject,
> there is
> one standard indentation features QtCreator has that clang-format can't
> reproduce. When you line-break an expression, clang-format will indent it
> a
> fixed amount from the beginning of the next line, where QtCreator will try
> to
> find places to line up with from the line above, including indenting from
> the
> last paranthesis For instance:
>
> int a = foobar(x) + foo(looongfunctionname(
>  looongvariablename));
>
> vs
>
> int a = foobar(x) + foo(looongfunctionname(
> looongvariablename));
>
>
> This semantic indentation is not something clang-format can do at the
> moment.
> At least if someone knows how, I would love to know, I have search
> everywhere,
> including the clang-format code.
>
> It is not so bad in this case, but once you have multiple line-break like
> that
> in a long function call, clang-formated code is essentionally just
> unformatted.
>
> In any case if we want to enforce clang-format everywhere, perhaps we
> shouldn't have QtCreator do smarter and more readable indentation that we
> do
> not allow in our repository?
>
> 'Allan
>
>
>
> ___
> 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] RFC: unified data model API in QtCore

[Jean-Michaël Celerier]

> So YAML makes a lot of sense.

https://github.com/yaml/YAML2/wiki/People-Raging-About-YAML
https://users.rust-lang.org/t/why-does-cargo-use-toml/3577/15

I would like to understand what all this discussion is about. What is the
goal for Qt ?

a) allow developers using Qt to have a simple, human-readable (that's the
n°1 feature my users always asked about save and file formats) and easy to
write serialization method ?
b) compatibility with existing formats, e.g. I want to communicate with a
webservice which speaks JSON or whatever
c) maximum performance for e.g. message passing between two processes ?

In any case, every time I ever used JSON it is because it was necessary for
compatibility with existing interfaces - sometimes web APIs, sometimes
human beings who are used to reading JSON. I don't see this going away any
time soon...

In any case, what would be the added value of Qt providing new
serialization formats & APIs, especially wrt exisiting header-only
libraries (rapidjson, nlohmann/json for instance in the json world) which
provide better performance AND compliance than Qt's  ? (again, for json,
https://github.com/miloyip/nativejson-benchmark)

Best,


---
Jean-Michaël Celerier
http://www.jcelerier.name

On Thu, Jun 14, 2018 at 3:13 PM, Thiago Macieira 
wrote:

> On Wednesday, 13 June 2018 23:46:54 PDT Lars Knoll wrote:
> > I’d leave XML out of this. It is difficult to integrate, as it has so
> many
> > special features (entities, CDATA and lot of other things) making it a
> > rather complex specification. But there are a couple of other formats
> that
> > might fit a more generic data model. Yaml comes to my mind as an example,
> > protobuf and flatbuffers might also be possible to stream into such a
> > structure with some additional schema verification.
>
> YAML, like CBOR, was designed with compatibility in mind. In fact, it's
> designed so JSON-YAML conversion is lossless in both directions. So YAML
> makes
> a lot of sense.
>
> I don't know much about PB and FB, but from what I've seen it's meant to
> be a
> serialisation format based on an IDL you describe. It's closer to
> QDataStream
> than to JSON. From what I've seen, it makes no sense to merge those with
> the
> other three than it does XML.
>
> > > I'm skeptical. What do you think?f
> >
> > One option could also be that we have a common implementation, and then a
> > very thin API wrapper for each of the formats on top that will enforce
> the
> > format specific limitations and give you a fully typed API.
>
> That was my original plan. The QCborValue backend can be reused for JSON
> as a
> thin wrapper API. There's just a lot of copy & paste.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QTBUG-43096 - QML instantiation performance decadence

[Jean-Michaël Celerier]

Well, you mention Nest thermostats : those actually run a Linux with 512 mb
of RAM - more than enough for some QtCore goodness.

> Which is why I don't think Qt has a role to play in these types of
devices.

This I don't understand. There would be so much to win in terms of code
reuse - currently I have a QObject hierarchy for desktop and Qt UI
interoperatibility and a raw C++ object hierarchy for embedded ; I'm just
recreating the same stuff twice. It kills me that the embedded devices I
use are powerful enough to run Python and Javascript interpreters but not
some QObjects.

About the allocations, I don't know: running my app under heaptrack shows
that QObjectPrivate is responsible for a great deal of those - way more
than I would like. Besides, this is not so much a problem of memory than a
problem of cache fragmentation. And in semi-powerful devices like Pi you
can really feel these effects if you are trying to push them to the max.

Ideally, there would be something like QObject but which allows full
constexpr or at least static-initialization; since embedded devices
commonly have static object trees which could be built at compile-time. A
QObjectLiteral of some sorts if you want, like QStringLiteral :p





---
Jean-Michaël Celerier
http://www.jcelerier.name

On Sat, May 26, 2018 at 3:17 PM, Thiago Macieira <thiago.macie...@intel.com>
wrote:

> On Saturday, 26 May 2018 09:12:25 -03 Jean-Michaël Celerier wrote:
> > If only there was a way to be able to use Qt without all the PIMPLing and
> > just have QObjectPrivate be a "normal" QObject member !
>
> You'd save maybe 10% of the allocations. Don't forget that the privates
> have a
> lot of internals that allocate memory too, in the form of vectors,
> strings,
> signal-slot connecion tables, etc.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QTBUG-43096 - QML instantiation performance decadence

[Jean-Michaël Celerier]

> Jędrzej had a beautiful proof of concept at some point for QObject to
combine the object and d-pointer allocation into one.
If only there was a way to be able to use Qt without all the PIMPLing and
just have QObjectPrivate be a "normal" QObject member !




---
Jean-Michaël Celerier
http://www.jcelerier.name

On Sat, May 26, 2018 at 2:05 PM, Simon Hausmann <simon.hausm...@qt.io>
wrote:

> Hi,
>
>
> Jędrzej had a beautiful proof of concept at some point for QObject to
> combine the object and d-pointer allocation into one.
>
>
> That's where I had the idea that perhaps this idea could be extended all
> the way to QML, so that the instantiation of a .qml file would collect all
> object and d-pointer sizes at type compilation time and use a bumper
> pointer allocator during instantiation (assuming that we can verify upfront
> that the types support it).
>
>
> The consequence would be one libc malloc for all objects per .qml file and
> pointer based APIs like anchors or gradients would involve no data copying
> at all, as opposed to value based gadget APIs.
>
>
> This would require a static QObject parent-hierarchy and make a few other
> assumptions, but as long as they are the common case and can be detected, I
> think there are ways of making QtQuick elements instantiate faster and use
> less memory.
>
>
>
>
> Simon
>
>
> P.S.: Are you sure the stops: [ ... ] assignment works?
> --
> *From:* Development <development-bounces+simon.hausmann=
> qt...@qt-project.org> on behalf of Uwe Rathmann <uwe.rathm...@tigertal.de>
> *Sent:* Saturday, May 26, 2018 12:30:11 PM
> *To:* development@qt-project.org
> *Subject:* Re: [Development] QTBUG-43096 - QML instantiation performance
> decadence
>
> On Fri, 25 May 2018 22:35:58 +0200, Robin Burchell wrote:
>
> > The first point I would make in reply, though, is
> > that the convenience of creating code with a/b/c are going to be
> > significantly better in my experience.
>
> Code for d) look like this:
> https://github.com/uwerat/qskinny/blob/master/examples/buttons/buttons.qml
>
> IMHO the code for a/b would be very similar, the only one that requires
> more work would be c as you need extra code for creating the button
> itself.
>
> > Let's take
> > another good example from the top of my head: Item::anchors. Behind the
> > scenes, it's implemented as a QQuickAnchors, which is a QObject. Let's
> > turn it into a Q_GADGET, and we're done, right?
>
> No, but please let's stay with gradients, where the answer is yes.
>
> QSkinny offers this class to expose gradients to QML: https://github.com/
> uwerat/qskinny/blob/master/src/common/QskGradient.h
>
> Now when having an control with a property like this:
>
> class MyRectangle : public QQuickItem
> {
> Q_OBJECT
>
> Q_PROPERTY( QskGradient gradient READ gradient
> WRITE setGradient RESET resetGradient NOTIFY gradientChanged )
>
> ...
> };
>
> you can write your QML code this way:
>
> MyRectangle
> {
> gradient {
> orientation: "Vertical"
>
> stops: [
> { position: 0.0, color: "MediumAquamarine" },
> { position: 0.5, color: "..." },
> { position: 1.0, color: "DarkSeaGreen" },
> ]
> }
> }
>
> The equivalent code offered by Qt/Quick needs 4 QObjects - for each
> instance of an item. So when having 100 rectangles these are 400 QObjects
> - good for nothing.
>
> Uwe
>
> ___
> 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
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QTBUG-43096 - QML instantiation performance decadence

[Jean-Michaël Celerier]

> Why does it need to be? I have never needed to subclass QQuickControl,
personally, so I have never brought this topic up.

It's not about subclassing QQuickControl, it's about running code without a
JIT / interpreter. Even if the cost in startup time and performance is
minimal, it is not as fast as raw C++ code - and there's nothing wrong with
wanting Qt to run on a lightbulb... some lightbulbs today have better CPUs
than the ones Qt was originally developed on.

In addition, there's something in which Qt Quick fails quite flat: any kind
of UI that revolves around graphs with a lot of objects - stuff with which
QGraphicsView is perfectly at ease. Look for instance at the model editor
in Qt Creator : they went - rightly - with QGraphicsView.

I tried to port my software (https://github.com/OSSIA/score) to Qt Quick
twice but stuff like showing hundreds of text elements updated concurrently
killed performance, while QGraphicsView has no problem blitting them like
there's no tomorrow. And that's with Qt Quick having a much more restricted
API than QGraphicsScene/View. But of course I'm sad since I have to
reimplement basic widgets in QGraphics* manually and cannot use the pretty
QQC2 ones :p

Even the latest innovation, QML Shapes, is beaten in performance by
existing solutions :
http://kgronholm.blogspot.fr/2017/12/qt-510-rendering-benchmarks.html that
in addition also provide a C++ API.



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Fri, May 25, 2018 at 9:55 PM, Robin Burchell <robin.burch...@crimson.no>
wrote:

> On Fri, May 25, 2018, at 4:31 PM, Uwe Rathmann wrote:
> > But at the time, when Controls 2 has been started everything was on the
> > table and - at least from the outside - it looked like a comfortable
> > situation for making good decisions. And this is what I had expected to
> > happen:
>
> What happens is only what there are enough time and resources to do, plus
> a direction to do it in the first place. It might be that you had attempted
> to drive some of this work yourself (or yourselves), I don't know - but I
> didn't see any discussion about it on this list that I recall, and I don't
> recall anything hitting codereview either, so I have to say that from the
> perspective of the project, I can't see how you could really expect this to
> happen.
>
> > Unfortunately I never noticed any indication pointing into the direction
> > of a better C++ support. In fact the opposite happened: even the very
> > base class of all QC 2 controls is not part of the public API !
>
> Why does it need to be? I have never needed to subclass QQuickControl,
> personally, so I have never brought this topic up.
>
> Assuming you have a valid reason, then I would present my next problem
> with that: it's probably not mature enough. QQC2 is only three years old,
> and it is (still) going through quite a lot of change that is often likely
> not ABI compatible[1]. Sure, it's often _possible_ to work with this stuff
> in a backwards-compatible fashion, but that comes at a strong cost, which
> then requires answering: does the cost of having to work in such a manner
> justify making it public? I would tend to suggest no in that particular
> case from what I know right now.
>
> > The stupid fact is that QML always comes at a cost. Trying to reduce
> > these cost has been successfully done and any further improvements are
> > welcome, but: as long as there is no clear separation between the Qt/
> > Quick graphic stack and QML I disagree, that the "right direction" has
> > already been found.
>
> There is a cost, yes. But I would say it's more a cost/benefit tradeoff.
> Faster prototyping and development cycles at a cost of requiring some of
> your resources to munch on. And, well, this problem isn't just limited to
> QML or QtQuick- if you want to run Qt as it exists today on a lightbulb,
> you're probably getting something wrong in your architectural design. ;-)
>
> Anyway, wrt direction, I assume you are hinting at a scenegraph that is
> less tied to QtQuick. If you are volunteering to help engineer such a
> separation in a way that is maintainable in the long term, and doesn't
> negatively impact performance of the graphics stack's consumer (QtQuick),
> then I have no objections personally, though I'm not really the right
> person to talk to. I would suggest coming up with specific proposals for
> what you want done, talking them over on this list, and then working on
> patches assuming there are no objections.
>
> But if you are asking me personally to separate the scenegraph out, then I
> have no interest in doing so. As I said, I am happy with QML and QtQuick in
> their present form (with hopefully indefinite iterations to improve it over
> time, of course).
>
> [1]: This d

Re: [Development] Rendering only items that are visible in Qt Quick

[Jean-Michaël Celerier]

> Far superior alternatives?

Maybe not "far" superior, but AFAIK QGraphicsScene / QGraphicsView handles
this.



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Fri, Mar 23, 2018 at 2:44 PM, Mitch Curtis <mitch.cur...@qt.io> wrote:

> I'd like to get some discussion going around this:
>
> https://bugreports.qt.io/browse/QTBUG-67274
>
> As I understand it, clipping (the "clip" property) doesn't prevent items
> that aren't visible (in the sense of being out of the viewport, not the
> "visible" property) from actually being rendered.
>
> It would be useful if we had a way to do this with minimal effort from the
> user. I'm thinking of a e.g. a property or flag in QQuickItem that, when
> set, would cause the scenegraph to use the shape (could start off as just
> being a bounding rect) of child items to determine whether or not that item
> is visible with regards to its parents bounding rect. That way, any regular
> old item can benefit from it easily.
>
> Does anyone else have ideas about this?
>
> Comments about how it will never work and I should feel bad for suggesting
> it?
>
> Far superior alternatives?
>
> Please, share your thoughts! :D
> ___
> 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] Stepping down as maintainer

[Jean-Michaël Celerier]

> For example, to allow them to use the commercial license in own purposes,
or, something else. ;)

Are there that many people interested in commercial licenses ? I think that
more people are looking to have *fun* and feel welcome contributing,
especially in the OSS world.

Look for instance how contributions are handled in:
* Rust: https://github.com/rust-lang/rust/pull/49173
* Electron: https://github.com/electron/electron/pull/12301
* Dear ImGui: https://github.com/ocornut/imgui/pull/1638
* Python: https://github.com/python/cpython/pull/6142

Overall, it feels much more frictionless to contribute to these kinds of
project - and it does not really matter if this is true in practice it is
or not: most people don't judge with cold, hard scientific facts, for the
better or worse, especially when considering decisions such as "to which
famous open source project should I contribute?".

Another point is that there is no real Qt ecosystem : it's either
contribute to big entities such as Qt itself & KDE or have a small
forgotten library used by a whole 3 people on github / inqlude / qpm, but
there does not seem to be easy "entryway drug" which can easily discourage
newcomers.

Best,
Jean-Michaël





---
Jean-Michaël Celerier
http://www.jcelerier.name

On Tue, Mar 20, 2018 at 10:35 AM, Denis Shienkov <denis.shien...@gmail.com>
wrote:

> Hi.
>
> Maybe, you can to consider some "yum-yum" for attraction of community
> maintainers?
>
> For example, to allow them to use the commercial license in own purposes,
> or, something else. ;)
>
> 20.03.2018 11:09, Tuukka Turunen пишет:
>
> Hi,
>
> It would be very good to get more contributors and maintainers also from the 
> community and companies who offer Qt services. Lately we have had some 
> community maintainers step down and replaced by people from The Qt Company. 
> This is fine to some degree, but we should also have new persons from the 
> community and ecosystem step up.
>
> Overall the amount of community contributions to Qt is still around the same 
> 30% as it has been. So we have not been getting any better or worse in that 
> regard.
>
> Yours,
>
>   Tuukka
>
> On 19/03/2018, 19.33, "Development on behalf of Sune Vuorela" 
> <development-bounces+tuukka.turunen=qt...@qt-project.org on behalf of 
> nos...@vuorela.dk> 
> <development-bounces+tuukka.turunen=qt.io@qt-project.orgonbehalfofnos...@vuorela.dk>
>  wrote:
>
> On 2018-03-19, Denis Shienkov <denis.shien...@gmail.com> 
> <denis.shien...@gmail.com> wrote:
> > As I can see recently, is is not a good tendence in Qt... Many peoples
> > leaves from Qt.. What happens? Or I'm mistake? :)
>
> Let's do some math.
>
> There is around 160 maintainer positions in Qt (a quick count of  on
> the maintainers wiki page)
>
> Many maintainers are a maintainer as part of their job duties. Not many
> people these days have the same job for more than 5-6 years. If it takes
> 1-2 years to get to a state to become maintainer, that leaves around 4
> years as a maintainer.
>
> If we assume that the maintainer is around for 4 years and there is
> effective 10 months per year, then we should have 4 replacement
> maintainers each month.
>
> I'm not sure I see something worrying in numbers alone.
>
> /Sune
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
> ___
> Development mailing 
> listDevelopment@qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development
>
>
>
> ___
> 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] GSoC 2018 Idea: a widget for 2D/3D image display

[Jean-Michaël Celerier]

> But I found there's no commonly used Qt widget for image display and
interaction, not to mention a standard pipeline for 3D image processing.

Isn't VTK commonly used for this ? AFAIK it has multiple Qt widget
integrations, including QVTKWidget :
https://www.vtk.org/doc/nightly/html/classQVTKWidget.html



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Tue, Mar 13, 2018 at 2:39 PM, 孫夏 <hsia@gmail.com> wrote:

> Hello all,
>
> I am a student interested in participating in Google Summer of Code 2018
> with Qt.
>
> As a Qt user before, I used Qt as the UI framework to develop my
> application in 3D medical image analysis and video processing. But I found
> there's no commonly used Qt widget for image display and interaction, not
> to mention a standard pipeline for 3D image processing.
>
> To my understanding, most 3D image jobs are done as multiple 2D image job.
> So I would like to develop a Qt widget that could display and maintain a 3D
> image dataset. Most commonly used interaction methods and possible APIs
> should also be included. I want to make this widget a standard widget for
> all common 2D/3D images and should include most image and video I/O, for
> example, OpenCV and GDCM.
>
> I wonder whether this idea could be considered as a GSoC project. Or on
> what points may I improve it?
>
> Thank you all.
>
> Best regards,
> Xia Sun
>
> ___
> 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] Deprecation of Qt Quick Controls 1

[Jean-Michaël Celerier]

KDE has some codes that enables simulation of the "native" style through
QtQuickControls 2 if it can be useful :
https://github.com/KDE/qqc2-desktop-style

However, even though Qt Quick Controls (and Qt Quick in general) are both
very nice, I think that a big missing part is CSS-like properties, that is,
properties that would apply to whole subtrees of QML components easily.
Ableton has graciously provided some code for this :
https://github.com/Ableton/aqt-stylesheets but it would be nice to have a
syntaxic solution part of Qt proper...


Best,
---
Jean-Michaël Celerier
http://www.jcelerier.name

On Wed, Feb 7, 2018 at 2:12 PM, NIkolai Marchenko <enmarantis...@gmail.com>
wrote:

> And no, widgets is not an alterlative to proper qml controls on desktop
> when you want custom interface.
> I have an app that uses qml to draw a custom listview for users, it would
> be extremely hard to replicate it with widgets and why should I do that
> when I have qml?
>
> On Wed, Feb 7, 2018 at 4:10 PM, NIkolai Marchenko <enmarantis...@gmail.com
> > wrote:
>
>> I basically can't use Controls 2 in my application because combobox in
>> controls 2 has extremely out of place style for desktop applications, is
>> too bloated and you can't control it enough to make it look more like
>> Controls 1.
>> Admittedly, I almost do not use QML in my apps but I wasn't able to find
>> an easy solution to make combobox tolerable for desktop
>>
>> On Wed, Feb 7, 2018 at 4:06 PM, Helmut Mülner <helmut.muel...@gmail.com>
>> wrote:
>>
>>>
>>> > It should come as no big surprise that we are not working much on Qt
>>> Quick Controls 1.
>>> After some discussions inside The Qt Company, we concluded that it would
>>> make sense to clarify the situation.
>>> We see the value Controls 1 provides - more platform native styling -
>>> but it comes at a high price.
>>>
>>> > […]
>>> > As you can see, the effort is currently split and we'd like to reduce
>>> the attention to the two big areas - Widgets and Quick with Controls 2. This
>>> means we will spend even less time on Controls 1, where we'll only fix
>>> critical issues in the future.
>>>
>>> In my application I mostly use Controls 2 but have to add some controls
>>> from Qt Quick Controls 1, e.g. TableView, SplitView, Calendar, ScrollView.
>>> It would be nice to have these controls available in Controls 2 before you
>>> deprecate Controls 1.
>>>
>>>
>>>
>>> Regards
>>>
>>> Helmut
>>>
>>>
>>>
>>> ___
>>> 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
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] #pragma once

[Jean-Michaël Celerier]

I certainly have been bitten much more times by include guards that were
the same in different files (especially in old libraries where guards look
like #ifdef QUEUE_H because of course there is a single queue.h file in the
whole world, or because someone just copy-pasted the content of a file to
another and forgot changing include guards -- I plead guilty!) than
whatever hypothetic bug in pragma once GCC's implementation may have.

Are there people here who had, just once, a bug due to #pragma once ? I
never met any. Across network drives, with precompiled headers, unity
builds, with MSVC, Clang, GCC, ccache, distcc and Icecream...



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Wed, Jan 24, 2018 at 11:34 AM, Mitch Curtis <mitch.cur...@qt.io> wrote:

>
>
> > -Original Message-
> > From: Ville Voutilainen [mailto:ville.voutilai...@gmail.com]
> > Sent: Wednesday, 24 January 2018 11:25 AM
> > To: Alexander Nassian <nass...@bitshift-dynamics.com>
> > Cc: Mitch Curtis <mitch.cur...@qt.io>; development@qt-project.org
> > Subject: Re: [Development] #pragma once
> >
> > On 24 January 2018 at 12:22, Alexander Nassian <nassian@bitshift-
> > dynamics.com> wrote:
> > > Maybe because it’s not part of the C++ standard?
> >
> > #pragma once is not a replacement for include guards.
>
> Why not?
>
> > It's not part of the C++ standard because it doesn't always work
>
> In which ways? My quick search gave me these:
>
> https://stackoverflow.com/a/1946730/904422
> https://en.wikipedia.org/wiki/Pragma_once#Caveats
>
> There's also this answer that highly recommends against it, but seems
> quite contended in the comments:
>
> https://stackoverflow.com/a/34884735/904422
>
> > and modules are a superior solution anyway.
>
> How so?
> ___
> 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] Undeprecating QString::null

[Jean-Michaël Celerier]

> The "just change" introduces a binary incompatibility - right ?

I don't think it does: the QString is constructed on the caller's side
anyways and your function is always passed a QString object;
if you had an app that linked to qwt and didn't recompile it will just keep
calling QString::null() from its side and pass the resulting object to
your function.

Best,
Jean-Michaël

On Tue, Jan 16, 2018 at 5:22 PM, Konstantin Tokarev 
wrote:

>
>
> 16.01.2018, 19:18, "Uwe Rathmann" :
> > On Tue, 16 Jan 2018 16:47:57 +0100, Olivier Goffart wrote:
> >
> >>  Just change your code to use "= QString()", no #ifdef necessary.
> >
> > The "just change" introduces a binary incompatibility - right ?
> >
> > Please be aware, that Qwt is part of almost any Linux distro - according
> > to sourceforge it has more than 1000 additional downloads every week
> > since many years.
> >
> > All distro maintainers would not only have to upgrade the Qwt packages,
> > but also all packages depending on it - users would have to rebuild.
>
> However, it seems like amount of reverse dependencies of Qwt is rather
> moderate, e.g. in Ubuntu I see
>
>   libqwt6:i386
>   zygrib
>   simon
>   qsapecng
>   qgis
>   nlkt
>   libqwt-dev
>   libqgis-gui2.0.1
>
>
> >
> > Considering the strict compatibility rules you have for Qt you will
> > understand, that this is nothing I would like to do easily.
> >
> > But could you please comment on why this change is an improvement -
> > beyond getting rid of 3-4 lines in qstring.h ?
>
> Because having redundancies in API is bad maybe?
>
> >
> > Thanks,
> > Uwe
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
>
> --
> Regards,
> Konstantin
> ___
> 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] about the Cocoa/Freetype fontengine

[Jean-Michaël Celerier]

> And even then ... how many users complained about window titles looking
blurry when KWin started using QtQuick for rendering titlebars?

isn't this a common complaint actually :
https://www.google.com/search?q=qt+quick+blurry+text ?

But I think that the overall problem is that there are two categories of
software built with Qt :
* apps that integrates with their user's desktop
* apps that look the same everywhere.

In my case I am for instance sometimes developing small UI software with
some buttons, list, etc... and in this case I want the app to integrate
nicely and blend in whatever the OS and the color scheme of the user of the
software.
But the main app I work on is a music software for artists ; these
generally have a *very strong* visual identity. We use our own CSS with
fusion style everywhere with custom fonts, pixmaps, etc etc... and the
software *has* to look the same (as in, pixel-perfect) on every platform
(given same DPI of course). I honestly don't care much about the software
integrating with the host environment; just take a look at famous software
in this category:

* Max/MSP: https://docs.cycling74.com/max7/vignettes/images/project-edit.png
* Ableton Live:
https://img.audiofanzine.com/images/u/product/normal/ableton-live-9-suite-163826.jpg
* TouchDesigner:
http://farm9.staticflickr.com/8531/8680998191_df78973538_b.jpg
* Sonar: https://medias.audiofanzine.com/images/normal/710664.jpg
* AudioMulch: https://static.kvraudio.com/i/b/audiomulch2-2.jpg

etc... in this case it's a good thing to pop out from other software on
your desktop (for very practical reasons, too: when you're on stage
performing a show you don't want to spend time finding where is the window
you have to click on, they all have to appear very distinct if you have
multiple software running)


Best,
---
Jean-Michaël Celerier
http://www.jcelerier.name

On Sat, Dec 30, 2017 at 1:45 PM, René J. V. Bertin <rjvber...@gmail.com>
wrote:

> Nikolaus Waxweiler wrote:
>
> > I think you have to carefully match the rendering of CoreText (and its'
> > darkening algorithm) for users not to notice. At that point, you might
> > as well use CoreText, unless you have something very specific in mind.
>
> Remember that there's also the issue of getting the exact same font metrics
> which is important for certain users.
>
> > People notice different font rendering.
>
> Yes - but they're not likely to complain if the different look also looks
> better. And even then ... how many users complained about window titles
> looking
> blurry when KWin started using QtQuick for rendering titlebars?
>
> > The performance hit is measurable in the rendering benchmark tool
>
> Measurable in a benchmark tool doesn't mean there are performance issues.
> I've
> been using Infinality on a very slow system, without any ill effects.
>
> > consistency. Sit a Core Web font next to some random Google Font font on
> > the internet and they'll look jarringly different, like each used a
>
> If you mean fonts rendered by FreeType with and without Infinality looks
> jarringly different, then yes, that can be the case at regular point sizes
> on
> regular density displays. Which is the whole point: with the result looks
> jarringly better.
>
> > No, incorrectly hits the mark. As soon as your rendered glyph image
> > contains shades of gray, you MUST use linear alpha blending and gamma
> > correction. Everything else is incorrect.
> > The Windows and Mac platform
> > have been doing that for decades, X11 libs never did to my knowledge.
>
> Erm, I'm talking about KDE desktops using Qt4 or better, which have the
> option
> to activate sub-pixel rendering and hinting (which will be on by default
> IIRC).
> Basic X11 font rendering doesn't, indeed. Instead it relied on pre-rendered
> bitmap fonts like for a high-resolution matrix printer. And curiously those
> fonts could be displayed 100% correct - with moiré effects and blurring
> between
> the display phosphor and our retina taking care of making the letters look
> smooth enough to be pleasant. I still use some fonts like that (Monaco in
> particular) in my xterms, that I've been preserving from my PhD days on a
> Mac
> IIx running A/UX 2.0 .
>
> Either way, a long as we're talking about vector fonts rendered on a raster
> display the term correct has a very relative meaning.
>
> > The CFF darkener delivers the best
> > looking results so far, as it only counters the thinning such that the
> > font looks as meaty as before gamma correction.
>
> Again, that's in the eye of the beholder, but I still find that the
> results look
> better with than without the Infinality patch set. The only regression
> (due to
> your CFF darkener or to the FT+FC patches) is in a single fo

Re: [Development] about the Cocoa/Freetype fontengine

[Jean-Michaël Celerier]

:+1: for being able to use fontconfig everywhere. It's painful to have to
make pixel adjustments on each platform because they don't render fonts
exactly the same everywhere. Besides, fontconfig with infinality patches
honestly gives a beautiful rendering, crispier and yet fuller than
everything you can see on othe OSes in my taste.

Best,
Jean-Michaël

On Fri, Dec 29, 2017 at 10:07 AM, René J. V. Bertin 
wrote:

> Sérgio Martins wrote:
>
> > What I meant is that you don't need to touch FT code when adding
> > fontconfig support to macOS. The code already exists and is
> > cross-platform (even worked on QNX). It's just that it's not being
> > used by cocoa QPA.
>
> Hmmm, I guess I'll need to have another look then. It had indeed been my
> hope
> that this would just be a question of adding a few calls into existing code
> (after making sure it's included in the build). Now I'll only need to
> figure out
> what calls and where to make them.
>
> Cheers,
> René
>
> ___
> 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] QtCS 2017 QtCore sessions

[Jean-Michaël Celerier]

> . I would be fine having the same developer experience in C++
even if I had to change name spaces and includes, but doesn't seem usual
practice in C++.


uh... ? I have been polyfilling optional, string_view, any, and variant for
almost three years with boost, or std/experimental/. The API is 99%
compatible to what's in std.



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Sun, Dec 3, 2017 at 5:41 PM, Alejandro Exojo via Development <
development@qt-project.org> wrote:

> On Saturday 02 December 2017 19:11:23 Boudewijn Rempt wrote:
> > > > And, c'mon, std::optional's API is just not going to be topped by
> > > > QOptional. What should they do? snake_case vs. camelCase? That's what
> > > > we need to invest several man-days of development work in, to rename
> > > > the functions and stick a Q in front of the class name?
> > >
> > > There's one thing that a QOptional could do that std::optional can't:
> > > be available for all Qt users
> > > in a time span of a couple of months.
>
> True. And that, in my very humble opinion, highlights a common problem that
> people face in projects in all languages: wanting to use a standard
> functionality that is not yet available in the platforms that you have to
> support. Many other languages are able to "polyfill"/shim
> not-yet-standardized
> classes or functions (even members) in a clean way, by adding a 3rd party
> library and done. I would be fine having the same developer experience in
> C++
> even if I had to change name spaces and includes, but doesn't seem usual
> practice in C++.
>
> > And another thing: be properly documented in a way that people who
> > are not CS phd's can understand. std completely and utterly fails
> > in that. Parts of Qt's docs are bad enough, but there's nothing in
> > cppreference.com that would pass muster for my gsoc students.
>
> I wholeheartedly agree. I understand the argument of the lambda in find_if
> in a
> somewhat intuitive way, but the explanations that one finds there about it
> are
> hugely discouraging to me (full of standardese), even if it's been some
> years
> using C++. It's not rare to see pages documenting a class or function,
> that,
> instead of giving examples of its usage, show instead three possible
> implementations. When you are trying to understand how it's used, or why
> it's
> useful. :-(
>
> And a 3rd point, that not necessarily applies to QOptional if everything is
> templated and inline, but I think still the main blocker for using more
> standard API is the lack of ABI stability. Yes, that's misfeature for some,
> but it's the current rule, so ignoring it is not helping the conversation,
> IMHO.
>
> --
> Viking Software, Qt and C++ developers for hire
> http://www.vikingsoftware.com
>
> ___
> 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] QtCS 2017 QtCore sessions

[Jean-Michaël Celerier]

> (just look at how we have to build Linux binaries with GCC 4.8).

Isn't it possible to use a newer GCC but to tell it to use GCC 4.8's ABI ?
eg to target GCC 4.8, by using -fabi-version=2 -D_GLIBCXX_USE_CXX11_ABI=0


Best,
---
Jean-Michaël Celerier
http://www.jcelerier.name

On Fri, Dec 1, 2017 at 7:26 PM, Thiago Macieira <thiago.macie...@intel.com>
wrote:

> On Friday, 1 December 2017 01:31:18 PST Marc Mutz wrote:
> > > Once those operator<=> are there, what benefit is there in having the
> > > API
> > > public and documented?
> >
> > The spaceship operator solves the problem for qCompareStrings(). One
> > could say we already have all relational operators for all combinations
> > of string-like objects to solve it for the user _now_, but
> > qCompareStrings(), like operator<=>() return the full information, while
> > relational operators only return a subset. You know that, I know. I'm
> > just mentioning it for completeness sake.
>
> Ok, so your case is when you have two string-like objects and you want to
> get
> the ordering result. Since we don't yet have the spaceship operator, you
> have
> to call the compare() function. But you can't do that in clean, generic
> code
> because you don't know if the first argument is an actual QString or
> QStringView, or if it's just a char16_t literal.
>
> Is that it?
>
> Why can't they write
>
> QStringView(s1).compare(s2) ?
>
> > And we have more than qCompareStrings(). How does operator<=> help with
> > qFindString()/qIndexOf() (which is still missing)? Answer: it doesn't.
> > There's no infix notation for find-in-string. And there probably never
> > will be (fancy proposing operator=~, anyone?).
>
> In both cases, explain why we need to provide that. Why can't they write
>
> QStringView(s1).indexOf(s2) ?
>
> > Ah, but you said that the flaw was in the _standard_. But what you show
> > are sub-optimal compiler implementations. There's nothing in the
> > standard that prevents a compiler to implement char_traits::length() as
> > a compiler intrinsic that can have different backends for constexpr and
> > runtime evaluation.
>
> The flaw is in the standard because it does not allow me to implement an
> optimised version using whichever tools I want to.
>
> > So, would the following be acceptable:
> >
> > 1. QSV uses char_traits::length() to calculate the length
> > (that was my initial implementation, but it's constexpr only starting
> > with C++17). Then QSV(Char*) is only constexpr in C++17. I can live with
> > that.
>
> No, because...
>
> > 2. You/Intel work on the compiler vendors to get
> > char_traits::length() implemented as an intrinsic, with SIMD
> > at runtime and compiler magic at compile-time?
>
> We should do that anyway, but depending on it means we'll have performance
> in
> 2021 or later (just look at how we have to build Linux binaries with GCC
> 4.8).
>
> The flaw exists today. My choice for fixing it is to sacrifice the part we
> don't really need: the constexprness.
>
> > Then we fix the problem where it should be fixed, and just piggy-back on
> > the more general solution. And it's easy to sell to QSV users why that
> > ctor is not constexpr until C++17 (and we don't even need any #ifdefery
> > in the implementation).
> >
> > What do you think?
>
> We should fix the standard and we should help fix the implementations. But
> I'm
> not accepting a performance drawback for 3 or more years until then.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Repository request: MaterialWidgets

[Jean-Michaël Celerier]

While most packages are centered QML / QtQuick , some are also
QWidget-based, eg :
https://www.qpm.io/packages/de.skycoder42.qpathedit/index.html

At its core it's just a repository for Qt plug-ins... doesn't even need to
be graphical.

If it can be useful to you, Papyros have a big part of the Material set
implemented in QML : https://github.com/papyros/qml-material .
Maybe you could reuse some algorithms / painting code used there ?

Best,

Jean-Michaël Celerier
http://www.jcelerier.name

On Mon, Oct 30, 2017 at 10:44 AM, iman ahmadvand <iman72...@gmail.com>
wrote:

> Hi Jean-Michaël.
>
> Actually QMP somehow has the air of a QML pkg manager.
> And about the mentioned repo, i should make it clear that MaterialWidgets
> is not just about a theme or style modification, it's a new implementation.
>
> And also my purpose is to have this module ported to Qt.
>
> Regards.
> Iman.
>
> On Mon, Oct 30, 2017 at 11:06 AM, Jean-Michaël Celerier <
> jeanmichael.celer...@gmail.com> wrote:
>
>> Iman: wouldn't this be better in a separate repository ?
>> This way someone who wants to use it does not have to wait 6 months for
>> it to be in a Qt release.
>> You could even have it included in qpm : https://www.qpm.io/ so that us
>> hipsters can just do "qpm install com.iman.materialwidgets" and be happy
>> forever after.
>>
>> For instance here are some already existing styles that you can find on
>> the internet for widgets:
>> https://github.com/diversys/QtHaikuStyle
>> https://github.com/suratovvlad/libqdark
>>
>> Best,
>> Jean-Michaël
>>
>>
>>
>> ---
>> Jean-Michaël Celerier
>> http://www.jcelerier.name
>>
>> On Mon, Oct 30, 2017 at 6:24 AM, iman ahmadvand <iman72...@gmail.com>
>> wrote:
>>
>>> Any reaction ?
>>>
>>> ___
>>> 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] Repository request: MaterialWidgets

[Jean-Michaël Celerier]

Iman: wouldn't this be better in a separate repository ?
This way someone who wants to use it does not have to wait 6 months for it
to be in a Qt release.
You could even have it included in qpm : https://www.qpm.io/ so that us
hipsters can just do "qpm install com.iman.materialwidgets" and be happy
forever after.

For instance here are some already existing styles that you can find on the
internet for widgets:
https://github.com/diversys/QtHaikuStyle
https://github.com/suratovvlad/libqdark

Best,
Jean-Michaël



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Mon, Oct 30, 2017 at 6:24 AM, iman ahmadvand <iman72...@gmail.com> wrote:

> Any reaction ?
>
> ___
> 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] Future of QBS

[Jean-Michaël Celerier]

> nobody is going to port Qt to CMake (if you disagree start a new thread)

https://plus.google.com/+AaronSeigo/posts/fWAM9cJggc8

> a complete CMake build for Qt was already contributed upstream (quite
some time ago) .. and rejected ..



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Fri, Oct 13, 2017 at 4:56 PM, Sergio Martins <sergio.mart...@kdab.com>
wrote:

> Hi,
>
>
> At the QtCS it was mentioned that maybe qbs could use JavaScriptCore and
> std:: types,
> at first I thought this was for making it easy for qbs to be a non-Qt
> project, but then I realized it was for boot-strapping purposes.
>
> I don't know if you have a vision, but given that most other build systems
> suck you can't miss this opportunity for making a great build system for
> everyone, not only for Qt.
>
> Please make something we can easily detach from the qt-project in 10 years
> and have it's own ecosystem.
>
> The qt-project isn't in the business of maintaining JavaScript engines or
> build systems, this model works now because TQC has manpower, but if
> something bad happens in 10 years, then it will be a maintenance burden and
> rot.
>
> So IMHO, no updating QtScript with newer JavaScriptCore and no adapting
> the QML/V4 engine, go straight for pure JavaScriptCore/JerryScript and no
> linking to Qt.
>
> Sincerely, I think you have a great product but are aiming too low. A few
> days ago I had to figure out if I was on a Rel,RelWithDebInfo CMake build
> and ended up having to manipulate strings with TOUPPER, since it's case
> sensitive. It's an horrible experience and syntax which declarative/QML
> solves.
>
> IMHO the qt-project is not in a position to reject Qt building with qbs,
> simply because there's no other implementation, nobody is going to port Qt
> to CMake (if you disagree start a new thread). But what we can discuss is
> if we want to make qbs easier to maintain long-term.
>
>
> P.S: This is my personal opinion, not of KDAB's (haven't discussed it
> internally) and definitely not of Kevin Funk (CMake guy ;))
>
>
> Regards,
> --
> Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322)
> KDAB - The Qt, C++ and OpenGL Experts
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS 2017 QtCore sessions

[Jean-Michaël Celerier]

> (4x difference measured).

wow, good to know.



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Tue, Oct 10, 2017 at 3:33 PM, Thiago Macieira <thiago.macie...@intel.com>
wrote:

> On Tuesday, 10 October 2017 15:04:29 CEST Jean-Michaël Celerier wrote:
> > > ** Wrapping std::{unordered_}map may be acceptable
> >
> > Hmmm... from these benchmarks, QHash seems to regularly beat
> > std::unordered_map so is it really worth it ?
> > =>  https://tessil.github.io/2016/08/29/benchmark-hopscotch-map.html
>
> The motivation for change is not performance, but security. While we don't
> think Qt applications are particularly susceptive to HashDoS attacks, our
> approach here is "we can fix this, we may as well do it".
>
> The reason I'm benchmarking and suggesting SipHash-1-2 instead of the
> standard
> SipHash-2-4 is to avoid a big performance regression.
>
> > Besides, with the Qt implementation the performance is more-or-less
> > consistent across platforms ; if it were to use
> > std containers with moderately advanced algorithms, there could be much
> > more differences depending on the various implementations
> > (the worse offender being std::regex... these damn things just don't work
> > the same on any platform).
>
> We actually have VERY different performance numbers across platforms. QHash
> currently uses the CRC32 instructions on x86 and ARM, which means the
> peformance can change significantly (4x difference measured). The same
> applies
> to the fixed version: the AES instructions are 5x faster than SipHash.
>
> > More generally, since all these containers are header-only due to their
> > templated nature, wouldn't it be interesting and benefiting to the
> greater
> > C++ community to
> > spin them off in their own small header-only utility library ?
>
> That's one big concern for a Qt6 QHash that wraps std:unordered_map. We'll
> need to see what happens.
>
> > Having an explicit choice between COW and no-COW would be valuable in
> many
> > places where people don't want to bring large stuff like whole QtCore but
> > where a few headers are OK imho;
> > offering facades to std:: types with easy, readable Qt-like APIs would
> also
> > be quite nice (ideally with a set of standard-compliant typedefs, eg
> > qt::hash_map... one can dream :p).
>
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QtCS 2017 QtCore sessions

[Jean-Michaël Celerier]

> ** Wrapping std::{unordered_}map may be acceptable

Hmmm... from these benchmarks, QHash seems to regularly beat
std::unordered_map so is it really worth it ?
=>  https://tessil.github.io/2016/08/29/benchmark-hopscotch-map.html

Besides, with the Qt implementation the performance is more-or-less
consistent across platforms ; if it were to use
std containers with moderately advanced algorithms, there could be much
more differences depending on the various implementations
(the worse offender being std::regex... these damn things just don't work
the same on any platform).

More generally, since all these containers are header-only due to their
templated nature, wouldn't it be interesting and benefiting to the greater
C++ community to
spin them off in their own small header-only utility library ?
Having an explicit choice between COW and no-COW would be valuable in many
places where people don't want to bring large stuff like whole QtCore but
where a few headers are OK imho;
offering facades to std:: types with easy, readable Qt-like APIs would also
be quite nice (ideally with a set of standard-compliant typedefs, eg
qt::hash_map... one can dream :p).

Best,


---
Jean-Michaël Celerier
http://www.jcelerier.name

On Tue, Oct 10, 2017 at 2:49 PM, Thiago Macieira <thiago.macie...@intel.com>
wrote:

> [we combined the main and containers session; we did not have time for
> QIODevice]
>
> == Intro ==
> Suggested topics:
> * QIODevice for Qt 6
> * adding std::hash for Qt types
> * expanding the hash seed to 64- or 128-bit
>
> Move to the containers session:
> * use qssize_t
>
> Quick conclusions:
> * QRandomGenerator and providing a PRNG of good quality (Mersenne Twister
> or
> Chacha20)
> ** Yes if our compilers support
> * hashing function update:
> ** Use SipHash-1-2, benchmark 32-bit SipHash
> ** See if Allan is interested in implementing with ARM AES
>
> == Use of standard C++ API ==
>
> We will not add compilers that are worse than what we have today.
> * If all the compilers we have support things like std::mersenne_twister,
> then
> all will
> * We can add hard-fail configure test
> * Should we start migrating from QSharedPointer to std::shared_ptr?
> ** Deprecate
> ** Deprecate QScopedPointer
> * What about API from C++17/20 that we'd like to use?
> ** Try to backport the API into a QtPrivate namespace (if it's been
> standardised) unless we want to add significant functionality a la
> QStringView
> ** If it's not standardised yet, use Qt-style naming
> * API naming
> ** std:: API naming is subtly different from Qt API (hopefully nothing
> that is
> confusing or misleading)
> ** We could try to create wrappers (container.empty() →
> container.isEmpty())
>
> == Modifiers vs getters for QString/QStringView/QByteArray ==
> We don't want people to write:
>   str = std::move(str).simplified()
> We want instead:
>   str.simplify()
>
> So we want to add the full set of modifiers.
>
> Do we want to add freestanding functions that may operate on std::string
> and
> other string types?
> * Like qSimplify()
> * Polluting namespace
> * They'd all need to be inline and some could be big
> * freestanding brings in ADL and could introduce unexpected isues
> * We think members are cleaner and we don't want to add these
>
> * However, we already have some of those! qStartsWith
> ** Global namespace *and* documented
> ** foo.startsWith(bar) vs qStartsWith(foo, bar)
> ** Same conclusion, probably mark \internal, namespace them
> *** But review the changes to see what our arguments were on making them
> public
>
> == QStringView ==
> * NEVER return QStringView (but QRegularExpression wants to)
> ** Consequence of "never return a reference" (but containers do)
> ** Lifetime issues
> auto s = lineedit.text().left(n);
> s valid?
> * We can be flexible on having exceptions:
> ** The API needs to be specifically designed for dealing with references
> ** Clear naming, such as QRegularExpression::captureView()
>
> Discussion not finished
>
> == Containers ==
> You cannot have all three:
> # Implicit sharing
> # Performance
> # Data-compatibility with std:: containers
>
> QList:
> *  [https://codereview.qt-project.org/194984 QUIP 9]
>
> Conclusions:
> * If we have QStringView, QArrayView, QByteArrayView, we don't need
> fromRawData()
> * We use qssize_t everywhere
> ** Check if we want to rename it to "qssize" (bikeshed warning!) : https://
> codereview.qt-project.org/#/c/208050/
> * Investigate C++ contract assertions
>
> Containers relevant:
> * QArrayData-based containers: QString, QByteArray, QVector
> ** Backed by the same template implementation (QArrayDataPointer)
> ** They grow to 3*

Re: [Development] Seeking advise using git and code review

[Jean-Michaël Celerier]

> After pushing my changes, the sanity bot found some typos in my commit
message. Now, how would I proceed? Do I change the commit message? If so,
how would I do that?

IIRC you do your modifications, do a git commit --amend, keep the same code
review ID in the commit message and push the new set of changes

> How could I find reviewers for my changes to QTextDocumentWriter?

https://wiki.qt.io/Maintainers

you can also come and ask on IRC

Best,



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Wed, Oct 4, 2017 at 8:55 AM, Daniel Savi <daniel.s...@gaess.ch> wrote:

> Hello everybody
>
> I've just pushed my first commit to QtGui, trying to follow the
> contribution guidelines posted here http://wiki.qt.io/Qt_Contribut
> ion_Guidelines. Now I have some questions regarding the process. It seems
> that I have done it at least partly wrong ;-)
>
> The codereview to my changes is as follows: https://codereview.qt-project.
> org/#/c/207540/
>
> After pushing my changes, the sanity bot found some typos in my commit
> message. Now, how would I proceed? Do I change the commit message? If so,
> how would I do that?
>
> Another probably more serious problem: I've checked out the source for
> 5.10 and created a branch "myfix5.10" and used "git checkout myfix5.10".
> Then I mad a diff to my locally changed files in another directory and
> patched the files from 5.10 in a temporary folder. After checking that the
> patched files looked how they should, I copied them back to the original
> folder. Then I did a "git commit -a". When checking the branch with "git
> branch", I found that I was on a detached head now. I couldn't go back to
> the branch, because git told me that I would lose my changes. So I pushed
> them anyway. Now, my submit type in Gerrit is "cherry pick". What should I
> have done, when encountering the detached head state? Is the "cherry pick"
> type a problem?
>
> Third and last, I didn't know how to find reviewers so I picked some
> almost randomly from the git log and added the QtGui maintainer, too.
> Probably not such a good idea? How could I find reviewers for my changes to
> QTextDocumentWriter?
>
> Sorry for the lengthy post.
>
> ___
> 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] Pointer Handlers will be Tech Preview in 5.10

[Jean-Michaël Celerier]

Why not just Drag, Tap, Pinch ? (for Drag it'd have to be in a different
namespace than the actual QtQuick.Drag though)

Best,

---
Jean-Michaël Celerier
http://www.jcelerier.name

On Wed, Sep 27, 2017 at 7:56 PM, J-P Nurmi <jpnu...@qt.io> wrote:

> On 27 Sep 2017, at 17:35, Shawn Rutledge <shawn.rutle...@qt.io> wrote:
>
>
> On 27 Sep 2017, at 16:52, J-P Nurmi <jpnu...@qt.io> wrote:
>
> On 9 Aug 2017, at 14:10, Shawn Rutledge <shawn.rutle...@qt.io> wrote:
>
> […] So far we only have
>
> TapHandler - […]
> DragHandler - […]
> PinchHandler - […]
>
>
>
> Hi Shawn,
>
> Why are these types called “handlers”? Because we use term “event handler”
> for those methods that you override in C++? IMHO “handler” type names
> belong to the same category with “utils” and “helpers”, type names that you
> give to internal helper classes when you don’t bother coming up with better
> names. You have implemented a gesture framework with support for taps,
> pinches, drags, and swipes, so why not call these types “gestures”?
>
>
> The gesture is what it handles.  The reason the object exists is to handle
> events.
>
>  A TapHandler _handles_ the tap _gesture_.
>
> (subject verb object)
>
> If we just replace that one word with yours:
>
>  A TapGesture handles the tap gesture.
>
> doesn’t sound right to me.
>
>
> Why?
>
> The problem IMO is mainly that we have the habit of calling a Javascript
> block bound to a signal a handler.  E.g. a TapHandler could have an
> onTapped: { … } Javascript block, and what do you call that: the
> TapHandler's onTapped handler?  We could be more old-fashioned and start
> calling bound Javascript functions callbacks (they are just functions after
> all), but it's too hard to break the habit.  Or we could try to think of
> another unique noun with similar meaning for the handler classes.
>
>
> To the point. :) We may use the handler term in many contexts, but what is
> a handler, really? Most Qt classes handle something, but I’m glad we don’t
> have too many handlers. I’m not saying the name doesn’t make sense. You
> could stick that suffix to almost any class and it would make sense, and
> that’s exactly why I put it in the same category with utils and helpers. I
> was just hoping we could have nicer names. That’s all. These things are
> commonly recognized as gestures.
>
> Responder maybe, to use macOS terminology?
>
> Maybe Recognizer, I think I like that.
>
>
> Sounds familiar. Oh, QGestureRecognizer, QPinchGesture, QTapGesture,
> QSwipeGesture… :)
>
> --
> J-P Nurmi
>
>
> ___
> 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] New approach to hi-dpi and coordinate system for layouts in Qt 6

[Jean-Michaël Celerier]

> making it impossible to specify 'a one/two pixel border'

Correct me if I am wrong, but isn't this what QPen::setCosmetic is used for
?

Best,
Jean-Michaël



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Thu, Sep 21, 2017 at 11:37 AM, Stephen Kelly via Development <
development@qt-project.org> wrote:

>
>
> Hi,
>
>
>
> Qt 5 has several approaches to attempting to size/scale a UI when moving
> between screens which have
>
> different APIs.  There is a summary here:
>
>
>
> https://vicrucann.github.io/tutorials/osg-qt-high-dpi/
>
>
>
> The approaches available currently either
>
>
>
> 1) scale everything after rendering (eg with SetProcessDPIAware())
>
> 2) scale coordinates to screen metrics before rendering
> (QApplication::setAttribute(Qt::AA_EnableHighDpiScaling))
>
>
>
> The first approach gives a blurry result because of up/down scaling and is
> not satisfying.
>
>
>
> The second approach scales all coordinates, making it impossible to
> specify 'a one/two pixel border' without that getting scaled too.
> Additionally, the AA_EnableHighDpiScaling will only apply integer scaling,
> so on a screen with 150% scaling, the widget is scaled to 200%.
>
>
>
> Adding a floating-point based API would not be a solution because it would
> result in painting artefacts.  This is an important point.  An approach
> like that won't satisfy designers.  The approach in
>
>
>
> https://codereview.qt-project.org/#/c/157174/
>
>
>
> resolves a scaling issue but does not address painting artefacts.
>
>
>
> So, we need to find flexible and imaginative solutions.
>
>
>
> I've had a discussion on IRC with Morten, who worked on QUIP-8.  That QUIP
> doesn't (yet?) go as far as approaches to addressing the problem, so I am
> writing here to see if there is wider interest in the topic.  One of the
> points he made is that some users are happy with the current state of Qt
> APIs and behavior, or would be happy with downsampling after rendering
> (blurry).
>
>
>
> I don't know how widespread that acceptance would be, but I've worked on
> several teams where it would not be acceptable.
>
>
>
> The underlying problem is that the Qt APIs do not provide a way to specify
> the units to use in layouts AND to combine values with those units.  We
> need to be able to specify coordinates which will be scaled to an
> appropriate number of pixels on the screen, but also to be able to specify
> coordinates in exact pixels (common for things like having a 'one/two pixel
> border' etc).  Then, Qt should compute the actual number of pixels to paint
> based on the current screen.
>
>
>
> The approach we discussed (this is only the ideas-stage, remember!) with
> Morten is to change APIs which specify layouts to use a new unit-sensitive
> coordinate type instead of int.  This new QCoordinate type stores values in
> both points and pixels and has a toPixels method which computes the
> required pixel value for the screen.
>
>
>
> https://gist.github.com/anonymous/d08e0e79b05237a765e23849bbe2a78d
>
>
>
> QCoordinates can be created with C++11 user-defined literal niftyness:
>
>
>
>   auto coord = 34_pt + 4_px;
>
>
>
> This also implies a requirement to have QSize/QPoint etc equivalents based
> on QCoordinate.  We haven't put much thought into this code duplicatation
> etc, focusing only on whether we can solve the problems with this approach
> (or another approach?) at all.
>
>
>
> A disadvantage of the QCoordinate approach is that the values are not
> comparable to each other without a screen.  So operator<() can't be
> implemented for example, but a separate purposeful API would be needed for
> things like that.
>
>
>
> One of the issues raised so far is that this QCoordinate stores only
> pixels and points, but not other units which may be wanted, such as
> physical units like centimeters.  Morten noted that there are not many
> known use-cases for such units and that they mean little if a projector is
> in use.
>
>
>
> This is of course a Qt 6 change, and now is approximately the time to
> discuss Qt 6 changes.  I don't know if anyone will be in Berlin who wants
> to discuss this at QtCS.  Shout if you want to discuss this there and I'll
> see if I can go over for it.
>
>
>
> Thanks,
>
>
>
> Stephen.
>
>
>
> ___
> 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] [fix]: Assistant (and others) burning CPU because of #f27d1ccbb24ec2fd4098f2976503478831006cc8 ?

[Jean-Michaël Celerier]

> Today, that QObject::schedule is achieved by (ab)using
QTimer::singleShot(0, func).

There have been interesting discussions on StackOverflow about this :

https://stackoverflow.com/questions/21646467/how-to-execute-a-functor-or-a-lambda-in-a-given-thread-in-qt-gcd-style
https://stackoverflow.com/questions/24142450/qtimersingleshot-and-qmetamethodinvoke

Best
Jean-Michaël



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Wed, Aug 30, 2017 at 11:31 AM, Giuseppe D'Angelo <
giuseppe.dang...@kdab.com> wrote:

> Il 30/08/2017 11:28, Morten Sørvig ha scritto:
>
>> There is also the option of creating new API that better covers the use
>> case of
>> running a pice of code once when control returns to the event loop. In
>> use this
>> could look something like this:
>>
>> QCocoaMenu::scheduleUpdate()
>> {
>>  if (m_updateScheduled)
>> return;
>>  m_updateScheduled = true;
>>
>>  this->QObject::schedule([_updateScheduled, m_nativeMenu](){
>> m_updateScheduled = false;
>>  [m_nativeMenu update];
>>  });
>> }
>>
>
> Today, that QObject::schedule is achieved by (ab)using
> QTimer::singleShot(0, func). I'd encourage a better named API.
>
> My 2 c,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908
> KDAB - Qt, C++ and OpenGL Experts
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt and IoT infographic

[Jean-Michaël Celerier]

> Research shows NO ONE deploys Arduino for real products. It's a maker toy,
stuff hobbyists use to make one-off things and some professional makers use
for initial prototyping. When they get serious, Arduino goes out the window
and they get real boards.

Sure, but if you can't start prototyping with Qt there's not much chance
you're going to switch to Qt when your prototype is running and you have to
start working towards the actual product.

Besides, this comes a bit as disdainful. I work in music research and
*everything* embedded uses Arduinos, Pi, Beaglebones or similar. If you
have seen interactive artistic installations in museums, outdoor
expositions, or contemporary concerts, there is a huge chance there's a Pi
or an Arduino running somewhere. Sure, there aren't "products" that end up
produced thousand times and sold on the counter or at Moser, but they are
shows, expositions, etc. which generate revenue all the same, for the
artists, museums, etc. and need programmers to get the stuff running and
banging sound.



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Tue, Aug 29, 2017 at 9:05 PM, Thiago Macieira <thiago.macie...@intel.com>
wrote:

> On Tuesday, 29 August 2017 10:35:05 PDT Jason H wrote:
> > I think the ideal tech solution here is not to do one or the other,
> rather
> > both, in a layered approach. Use the HTTP/REST and provide a translation
> > layer to CoAP. They make a statement about it being really close, so it
> > shouldn't be that hard to proxy down/up to a full-on REST server?
>
> My colleagues in Intel Finland already have that. Using Node.js though.
>
> > I'm not saying re-write apache or node anything like that. (Although node
> > libraries in QML would be great!) I'm only suggesting that we make Qt
> able
> > to trivially provide data to the web in both a conceptually easy and easy
> > to implement way.
>
> FamousLastWords™
>
> > There is a pretty big gulf between MCUs and the IoT.
> > Yeah, I've got Aurduino (even a uCSimm), various Pis and BeagleBoards,
> but
> > with the Pi Zero at $5, it's the same price as an Arduino, and it runs Qt
> > no problem.
>
> Research shows NO ONE deploys Arduino for real products. It's a maker toy,
> stuff hobbyists use to make one-off things and some professional makers use
> for initial prototyping. When they get serious, Arduino goes out the window
> and they get real boards.
>
> The Pi Zero doesn't cost *you* $5 if you want to make modifications. It
> costs
> $5 only due to the volume discount of the seller. If you want to modify the
> board, like for example depopulate it and remove some things you don't
> need,
> your price may actually rise instead of going down.
>
> > The calculus that has to be made is if IoT will be in
> > quantities where costing < $5 but more than pennies will inhibit a
> market.
>
> I think it will. I think we'll see on smart devices's "smartness" costing
> $0.50. But those are the tiny MCUs we've been talking about.
>
> The gap between those and the 512-MB devices is huge.
>
> > I think IoT is not currently suffering from that as most IoT things I
> think
> > of are luxury projects where a $5 CPU isn't cost prohibitive. Meanwhile,
> > you've got the whole Moore's law thing going on. If it takes Qt 3 years
> to
> > whittle down to fit on a board, or just quadruple the resources, then
> it's
> > a wash. I don't see Qt reaching down much lower than a Raspberry Pi Zero.
>
> Agreed, I don't see it reaching much lower than that either. Like I said, I
> think 32 MB RAM and 1 GB storage is a reasonable, albeit already difficult
> target.
>
> But I don't see the power of the devices going up. Instead, we'll see the
> other effect of Moore's Law: the price for the same capacity go down. So
> what
> costs $0.50 today will cost $0.125 in 3 years.
>
> > The future of IoT development isn't reaching down, its gluing things
> > together with a minimal level of effort while prices on the more advanced
> > stuff plummet and capabilities increase. There maybe a market for a
> > lower-end CPUs reaching into the MCU space, but I just don't see Qt going
> > there.
>
> Right. I don't think Qt needs to run on the MCU space.
>
> Qt needs to *consume* the data provided by the MCUs. And yes, it needs to
> provide data for larger integration.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt and IoT infographic

[Jean-Michaël Celerier]

> If you're going to communicate with a tiny MCU connected over a mesh
network
like 6LoWPAN/Thread, you won't be using TCP. Much less HTTP.

What makes me a bit sad is that if Qt's not doing it, then we end up having
to put up with bloated stuff like Node.JS on beagleboard or raspberries :
https://www.postscapes.com/javascript-and-the-internet-of-things/ which are
now more and more used.
Hell, sometimes people use python of all languages on constrained CPUs.
It's a niche that Qt *could* fill, and fill better than the alternatives.




---
Jean-Michaël Celerier
http://www.jcelerier.name

On Mon, Aug 28, 2017 at 10:01 PM, Thiago Macieira <thiago.macie...@intel.com
> wrote:

> On Monday, 28 August 2017 12:26:55 PDT Jason H wrote:
> > > > 2. ZeroConf should be a standard thing. Where's Qt's support?
> > >
> > > Right now, in KF5 (kdnssd).
> >
> > And who puts/[wants to put] KDE on IoT?
>
> a) it's just one library. KF5 was designed as multiple, smaller,
> independent
> libraries that can be added to Qt programs. That's one of the reasons we
> won't
> add a .zip file API to Qt -- just use KF5Archive.
>
> b) and who puts Qt on IoT? If we're going to challenge that, then we may as
> well challenge the answer to KF5-on-IoT.
>
> > > > 3.  IoT generally use web services, namely RESTful APIs. Where's Qt's
> > > > support for writing a RESTful server?
> > >
> > > Timur began working on an simple HTTP server. This is a controversial
> > > decision, since we've long said that Qt should not be the tool for
> > > server-side programs.
> >
> > It shouldn't be that controversial. We're just observing MVC and pushing
> it
> > from single-process to multi-process. We're not pushing Qt for the web
> per
> > se, just making it an equal citizen.
>
> Servers are much more complex beasts than clients. Almost every single
> vulnerability found in the Internet is related to servers.
>
> Just think of the fact that QTcpSocket has an unlimited buffer. Does this
> spell "denial of service" to you?
>
> > > But I dispute your assertion that it should be "web services". That's
> why
> > > I
> > > want to work on CoAP, which is much simpler than HTTP. It's still REST,
> > > but
> > > not web.
> >
> > Yes, and paint yourself into a corner of the internet again. While CoAP
> and
> > REST are both mentioned on the web page, but it also says: "From a
> > developer point of view, CoAP feels very much like HTTP. Obtaining a
> value
> > from a sensor is not much different from obtaining a value from a Web
> API."
>
> If you're going to communicate with a tiny MCU connected over a mesh
> network
> like 6LoWPAN/Thread, you won't be using TCP. Much less HTTP.
>
> No, UDP, DTLS and CoAP are much more important at this stage of IoT than
> HTTP
> servers.
>
> > I don't see why full-on-HTTP shouldn't be supported. You (the customer)
> > might be focused on IoT, but why restrict the other users to it as well?
> > Just go for full-on HTTP. I'm not against CoAP, but please don't raise
> > hurdles for those that don't need it.
>
> I'm not saying we shouldn't, but there's a matter of priorities and
> resources.
> We can reasonably easily write a CoAP client *and* server, with multicast
> support, for 5.11. This will allow you to communicate with the MCU-class
> IoT
> devices, which should correspond to something like 80 to 90% of the 200
> billion that are expected.
>
> An HTTP server will not happen for 5.11. It's MUCH more complex and will
> require a lot more reviewing. At best, expect an early technology preview
> at
> that time, subject to API change (and not in qtbase).
>
> > Over time the number of examples/demos where Qt consumes web services has
> > grown dramatically, but Qt apps haven't really ever been able to provide
> > the internet with services. Like it or not, the internet is a bus that
> > enables modern society. And the data locked in my Qt programs can't
> easily
> > contribute to that.
>
> That's by choice. Qt applications are meant to be clients to those
> services,
> not servers.
>
> > > > b. Remove
> > > > the GL dependency for QML, so that QML can function as a way to make
> a
> > > > headless HTTP server that makes it trivial to map HTTP requests to
> > > > QObjects
> > > > or QML Elements**.
>
> > > No, QtGui, no GL, no X11, nothing.
> >
> > I seem to remember a big deal about QtQuick 2.0 requiring GL? perhaps
> that's
> > just for Items? If I'm mistaken, then I am very happily 

Re: [Development] Qt and IoT infographic

[Jean-Michaël Celerier]

> I seem to remember a big deal about QtQuick 2.0 requiring GL? perhaps
that's just for Items? If I'm mistaken, then I am very happily mistaken!

QtQuick != QML. QML is a programming language and runtime for said
language, QtQuick is a scene graph. It's possible* to use QtQuick without
QML and QML without QtQuick.

* apparently QQuickWindow has some ties to the QML engine but in my
experience you can just create new QQuickItem from c++ and add them as
child of the rootItem and it works.



---
Jean-Michaël Celerier
http://www.jcelerier.name

On Mon, Aug 28, 2017 at 9:26 PM, Jason H <jh...@gmx.com> wrote:

> > Sent: Monday, August 28, 2017 at 11:38 AM
> > From: "Thiago Macieira" <thiago.macie...@intel.com>
> > To: development@qt-project.org
> > Subject: Re: [Development] Qt and IoT infographic
> >
> > On Monday, 28 August 2017 07:01:07 PDT Jason H wrote:
> > > Onto my criticisms of Qt wrt IoT:
> > >
> > > 2. ZeroConf should be a standard thing. Where's Qt's support?
> >
> > Right now, in KF5 (kdnssd).
>
> And who puts/[wants to put] KDE on IoT?
>
>
> > > 3.  IoT generally use web services, namely RESTful APIs. Where's Qt's
> > > support for writing a RESTful server?
> >
> > Timur began working on an simple HTTP server. This is a controversial
> > decision, since we've long said that Qt should not be the tool for
> server-side
> > programs.
>
> It shouldn't be that controversial. We're just observing MVC and pushing
> it from single-process to multi-process. We're not pushing Qt for the web
> per se, just making it an equal citizen.
>
> > But I dispute your assertion that it should be "web services". That's
> why I
> > want to work on CoAP, which is much simpler than HTTP. It's still REST,
> but
> > not web.
>
> Yes, and paint yourself into a corner of the internet again. While CoAP
> and REST are both mentioned on the web page, but it also says: "From a
> developer point of view, CoAP feels very much like HTTP. Obtaining a value
> from a sensor is not much different from obtaining a value from a Web API."
>
> I don't see why full-on-HTTP shouldn't be supported. You (the customer)
> might be focused on IoT, but why restrict the other users to it as well?
> Just go for full-on HTTP. I'm not against CoAP, but please don't raise
> hurdles for those that don't need it.
>
> Over time the number of examples/demos where Qt consumes web services has
> grown dramatically, but Qt apps haven't really ever been able to provide
> the internet with services. Like it or not, the internet is a bus that
> enables modern society. And the data locked in my Qt programs can't easily
> contribute to that.
>
> > > b. Remove
> > > the GL dependency for QML, so that QML can function as a way to make a
> > > headless HTTP server that makes it trivial to map HTTP requests to
> QObjects
> > > or QML Elements**.
> >
> > QML does not have a GL dependency. Or, for that matter, a graphical one.
> >
> >  ldd $QTLIBDIR/libQt5Qml.t.so.5
> > linux-vdso.so.1 (0x7ffe33fcf000)
> > libQt5Network.t.so.5 => /home/tjmaciei/obj/qt/qt5/qtbase/lib/
> > libQt5Network.t.so.5 (0x7fcaa427a000)
> > libQt5Core.t.so.5 => /home/tjmaciei/obj/qt/qt5/qtbase/lib/
> > libQt5Core.t.so.5 (0x7fcaa3bfd000)
> > libpthread.so.0 => /lib64/libpthread.so.0 (0x7fcaa39df000)
> > libdl.so.2 => /lib64/libdl.so.2 (0x7fcaa37db000)
> > libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x7fcaa3453000)
> > libm.so.6 => /lib64/libm.so.6 (0x7fcaa3141000)
> > libc.so.6 => /lib64/libc.so.6 (0x7fcaa2d9b000)
> > libz.so.1 => /lib64/libz.so.1 (0x7fcaa2b84000)
> > libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0
> (0x7fcaa2916000)
> > libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0
> > (0x7fcaa24a9000)
> > libsystemd.so.0 => /usr/lib64/libsystemd.so.0
> (0x7fcaa2215000)
> > libicui18n.so.59.1 => /usr/lib64/libicui18n.so.59.1
> > (0x7fcaa1d88000)
> > libicuuc.so.59.1 => /usr/lib64/libicuuc.so.59.1
> (0x7fcaa19d)
> > libpcre2-16.so.0 => /usr/lib64/libpcre2-16.so.0
> (0x7fcaa1762000)
> > libdouble-conversion.so.1 => /usr/lib64/libdouble-
> conversion.so.1
> > (0x7fcaa1551000)
> > libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0
> (0x7fcaa123b000)
> > libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7fcaa1024000)
> > /lib64/ld-lin

Re: [Development] Qt and IoT infographic

[Jean-Michaël Celerier]

> 3.  IoT generally use web services, namely RESTful APIs.
Cutelyst has been a nice project for writing web services in Qt:
https://github.com/cutelyst/cutelyst/wiki/Tutorial_02_CutelystBasics

> a. QML needs an official web runtime, that is, make QMLWeb or one of the
similar projects officially supported so it can be used for UI in
browsers*, and,

+1 * 1
or merge the webassembly patches (
https://codereview.qt-project.org/#/c/178543/), whatever, but it would be
so good to run Qt apps in client side web browser


Best,
---
Jean-Michaël Celerier
http://www.jcelerier.name

On Mon, Aug 28, 2017 at 4:01 PM, Jason H <jh...@gmx.com> wrote:

>
>
> > Sent: Thursday, August 24, 2017 at 5:00 PM
> > From: "Thiago Macieira" <thiago.macie...@intel.com>
> > To: development@qt-project.org
> > Subject: [Development] Qt and IoT infographic
> >
> > Re the inforgraphic at
> >   https://info.qt.io/whitepaper-building-the-internet-of-things
> >   (not the paper because it's asking information I won't give before I
> get it)
> >
> > First of all, I like that Qt Company is taking this seriously. You can
> improve
> > those graphics with target numbers for 2020, which are talking about 200
> > billion devices connected (I think the analysis is from Gartner).
> >
> > My criticism is what I *don't* see in this: local communication. Cloud
> > communication *should* be secondary in IoT. In fact, few devices should
> > communicate with the Cloud, hopefully only those that have hardened
> security
> > and where the user can control the privacy settings on. In a given smart
> home,
> > you should be able to count how many of those exist in the fingers of
> one hand.
> >
> > So where's the information about local network discovery and
> communication?
> > Where's the strategy on common protocols and data models? Publish and
> > subscribe of notifications?
> >
> > Please see this article from Monday that is relevant to this topic:
> > http://www.zdnet.com/article/sonos-accept-new-privacy-
> policy-speakers-cease-to-function/
> >
> > See also my comment: https://plus.google.com/+ThiagoMacieira/posts/
> goErhFrhzoS
> >
> > The infographic makes a spectacular error in this area. It says "Your
> data,
> > your code, your cloud". Well, no: that's your code and it may be your
> cloud,
> > but it's most definitely not your data. It's someone else's data.
> >
> > And now you know why I'm working on QtNetwork and want to implement DTLS.
> >
> > PS: it also says "Artificial Intelligence" in "The Backbone" part. How
> is that
> > relevant to Qt or where is it exposed in Qt?
> >
> > --
> > Thiago Macieira - thiago.macieira (AT) intel.com
> >   Software Architect - Intel Open Source Technology Center
>
>
> 1. That URL takes me to a form I must complete despite being logged in
> with my Qt account.
>
> Onto my criticisms of Qt wrt IoT:
>
> 2. ZeroConf should be a standard thing. Where's Qt's support?
> 3.  IoT generally use web services, namely RESTful APIs. Where's Qt's
> support for writing a RESTful server?
> 4. Qt has often neglected web architecture.  While I agree the web as a
> platform is terrible, and it's only ever been done right once (Wt), it's
> what we're stuck with. Qt has been amazing for making embedded apps, but
> fails at providing access to those apps over HTTP/S protocol. From QML's
> lack of Web Browser support, to the amount of work required to provide
> access via HTTP/S to QObjects, it's hard for me to take Qt seriously as a
> IoT platform.
> a. QML needs an official web runtime, that is, make QMLWeb or one of the
> similar projects officially supported so it can be used for UI in
> browsers*, and,
> b. Remove the GL dependency for QML, so that QML can function as a way to
> make a headless HTTP server that makes it trivial to map HTTP requests to
> QObjects or QML Elements**.
>
> * The new 5.10 WebGL feature is nice, and amazing, but still leaves a lot
> to be desired. You really need to be able to partition the IoT offering as
> web service and UI. With WebGL, they are too tightly coupled. It does have
> merit for people who want to web-enable a device that supports one user at
> a time, but that is only a subset of IoT devices.
> ** If removing it is too hard an alternative engine may be provided.
>
> Until those conditions are met, you're better off not using Qt. At least
> not by itself. Which is where your problem lies. Now you have to have a C++
> developer and a web backend developer and a web UI developer. For 99% of
> the market, you only get to hire someone who has two of those three skills.
>
>
>
>
>
>
> ___
> 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] Qt and IoT infographic

[Jean-Michaël Celerier]

> So where's the information about local network discovery and
communication?
Where's the strategy on common protocols and data models? Publish and
subscribe of notifications?

(adding a vote for support of Zeroconf in Qt :
https://bugreports.qt.io/browse/QTBUG-30823)

I think that the Pub - Sub support is covered in part by the recent MQTT
addition :
https://blog.qt.io/blog/2017/08/14/introducing-qtmqtt-protocol/

though one would hope that each IoT *protocole du jour* won't have its own
separate implementation
and instead there can be some generic that implements pub-sub, a bit like
QIODevice.

Best,

---
Jean-Michaël Celerier
http://www.jcelerier.name

On Thu, Aug 24, 2017 at 11:00 PM, Thiago Macieira <thiago.macie...@intel.com
> wrote:

> Re the inforgraphic at
>   https://info.qt.io/whitepaper-building-the-internet-of-things
>   (not the paper because it's asking information I won't give before I get
> it)
>
> First of all, I like that Qt Company is taking this seriously. You can
> improve
> those graphics with target numbers for 2020, which are talking about 200
> billion devices connected (I think the analysis is from Gartner).
>
> My criticism is what I *don't* see in this: local communication. Cloud
> communication *should* be secondary in IoT. In fact, few devices should
> communicate with the Cloud, hopefully only those that have hardened
> security
> and where the user can control the privacy settings on. In a given smart
> home,
> you should be able to count how many of those exist in the fingers of one
> hand.
>
> So where's the information about local network discovery and communication?
> Where's the strategy on common protocols and data models? Publish and
> subscribe of notifications?
>
> Please see this article from Monday that is relevant to this topic:
> http://www.zdnet.com/article/sonos-accept-new-privacy-
> policy-speakers-cease-to-function/
>
> See also my comment: https://plus.google.com/+ThiagoMacieira/posts/
> goErhFrhzoS
>
> The infographic makes a spectacular error in this area. It says "Your data,
> your code, your cloud". Well, no: that's your code and it may be your
> cloud,
> but it's most definitely not your data. It's someone else's data.
>
> And now you know why I'm working on QtNetwork and want to implement DTLS.
>
> PS: it also says "Artificial Intelligence" in "The Backbone" part. How is
> that
> relevant to Qt or where is it exposed in Qt?
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development