Re: [Development] Licensing of qtbase

[Tino Pyssysalo]

On 3.8.2022, 15.21, "Development on behalf of Benjamin TERRIER" 
mailto:development-boun...@qt-project.org> 
on behalf of b.terr...@gmail.com> wrote:

On Wed, 13 Jul 2022 at 13:05, Florian Bruhin 
mailto:m...@the-compiler.org>> wrote:

https://www.qt.io/product/features?hsLang=en#js-6-3 lets you see the
individual components of Qt and what license they are available as.

> That's some high level of FUD and BS.
> If I select LGPLv3, all Qt tools are greyed out (moc, qmake, Qt Creator, 
> etc.).
> Sure these tools are themselves not licensed under LGPLv3, but nothing 
> prevents them from being used for LGPLv3 projects.

Indeed. If using means running here, GPLv3 sets no limitations for running the 
unmodified version of the SW. Limitations are related to the modified SW. And 
GPLv3 is compatible with LGPLv3, but then the combination will be 
GPLv3-licensed.

I did not put these license details on the features page. Small clarification 
would not hurt.

> Ang given the text at the top of the page:
Please select a [...] license model, [...] programming language to see, what 
items are available for that selection.
> it will clearly make some people think that one cannot use these tools with 
> LGPLv3 projects.
> Especially because when selecting a language it will filter based on which 
> languages can be used with a tool, not which languages a tool is developed 
> with.

I agree this is a little bit counter-intuitive. In one place we talk about 
development licenses and in another place using the SW. I will try to clarify 
this.

--
Tino Pyssysalo
Maintainer of Qt features page
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Setting custom buffer size with Wayland

[Ilya Fedin]

I'm trying to force my window to follow aspect ratio. On other systems
this is possible by changing position/size progrmatically, but Wayland
doesn't let to change window position. I heard that it's possible to
achieve what I want by passing a buffer less than surface size. I
tracked QWaylandShmBuffer size up to QWidgetRepaintManager that just
sets QWidget size. Indeed, if I use private API and change the
data->crect directly, I can change buffer size without changing surface
size. The problem is it works only with raster widgets, I can't find a
way to do the same with OpenGL widgets. I tried to change
QPlatformBackingStoreOpenGLSupport::composeAndFlush so it uses QWidget
size (thanks god I can override the implementation with
QPlatformBackingStoreOpenGLSupportBase::setFactoryFunction), but it
seems this changes only the texture size, but not the buffer size as the
content moved from top left corner to the bottom left corner. Anyway,
even if I found how to change buffer size with it, it won't be valid
with Qt 6.4 anymore due to RHI. Can anyone give a light of how can I
achieve that with OpenGL with both 6.3/6.4 (even if with patching Qt, I
want to see that it's possible at least)? Can we have a
(semi-)public API for that?
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing to add (CPU) architecture maintainers

[Thiago Macieira]

On Wednesday, 3 August 2022 08:52:09 PDT Marius Kittler wrote:
> Actually it is not very exciting to see these screenshots because it looks
> just like on x86_64 :-)

That's a *good* thing. If they looked different, that would point to a bug -- 
usually endianness issues.

> I suppose that the Qt project does not provide a CI for those archs is not
> generally a problem. Distributors like (open)SUSE nevertheless make it work
> and also invest their own effort into testing.

Thank you, it's appreciated. I expect IBM/Red Hat would also be interested in 
POWER and S/390, for some reason...

Like I said in my email, we don't have the resources or knowledge to fix 
architectural-specific issues in those platforms, much less apply performance 
improvements. But we will accept patches in case we break anything.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering



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

Re: [Development] Windows plugin customisation: QWindowsKeyMapper

[Laszlo Papp]

Got it working:
https://github.com/lpapp/examples/blob/main/qt-native-event-filter/main.cpp

Thanks.

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

Re: [Development] Proposing to add (CPU) architecture maintainers

[Marius Kittler]

Am Mittwoch, 3. August 2022, 16:35:16 CEST schrieb Thiago Macieira:
> POWER and S/390 are very IBM-specific. They're still active, but I don't
> think we have much relevance in that market. And Sparc has ceased being
> active. For those three I don't think we can hope to expect any kind of
> performance improvements. And since we don't have them in the CI at all, we
> can't even confirm they still build. I think they will go to the "we'll
> accept patches" bin, as opposed to Alpha patches.

SUSE Linux Enterprise is supporting PowerPC and s390x and that's also tested 
in an automated way. Those tests are covering Qt as well (by testing KDE and 
various Qt applications).

I cannot provide any links for SLES testing because it is internal. However, 
the openSUSE distribution is built for those architectures as well and there 
is a small amount of tests visible in openSUSE's openQA instance.

For instance, that's how Plasma and Qt Designer look on ppc64le:
https://openqa.opensuse.org/tests/2493405#step/libqt5_qtbase/20

I could not find that graphical test scenario for s390x on the public instance 
but that's how the installer (that also uses Qt) looks on s390x:
https://openqa.opensuse.org/tests/2491744#step/welcome/1

Actually it is not very exciting to see these screenshots because it looks 
just like on x86_64 :-)

Note that those tests are conducted regularly, see https://
openqa.opensuse.org/group_overview/4 and https://openqa.opensuse.org/
group_overview/34.

I suppose that the Qt project does not provide a CI for those archs is not 
generally a problem. Distributors like (open)SUSE nevertheless make it work 
and also invest their own effort into testing.

Best Regards
Marius


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

Re: [Development] Proposing to add (CPU) architecture maintainers

[Allan Sandfeld Jensen]

On Mittwoch, 3. August 2022 16:35:16 CEST Thiago Macieira wrote:
> On Wednesday, 3 August 2022 04:56:41 PDT Marc Mutz wrote:
> > - ARM
> > - x86 (Thiago would be the obvious candidate, if he's in for it)
> 
> I agree. I already do this anyway, so it's just formalising something that
> exists.
> 
> > - MIPS
> > - POWER
> > - RISC-V
> > - S390
> > - Sparc
> > 
> > I would expect maintainers to be comfortable approving[1] assembly code
> > for their platform, work (or orchestrate work) towards feature-parity
> > with Qt's x86 support, and ideally getting the architecture into our CI
> > or else making sure locally that the architecture builds and tests pass.
> > 
> > [1] Maintainers need to be Approvers, but I think we can grow an
> > architecture maintainer into a Qt project Approver, because I don't
> > think we'll find arch maintainers for all archs from the current set
> > of Approvers.
> > 
> > What do you think?
> 
> I think we're not going to find anyone for any of the other platforms in the
> short term. Maybe RISC-V because it's getting a lot of share-of-mind --
> it's something that even I have an interest on (lack of hours in the day is
> the problem). And if we poke at Imagination folks we can get someone to
> review MIPS code. Interestingly, if you go to mips.com right now, the big
> banner is about RISC-V...
> 
> POWER and S/390 are very IBM-specific. They're still active, but I don't
> think we have much relevance in that market. And Sparc has ceased being
> active. For those three I don't think we can hope to expect any kind of
> performance improvements. And since we don't have them in the CI at all, we
> can't even confirm they still build. I think they will go to the "we'll
> accept patches" bin, as opposed to Alpha patches.

Yeah most of the architectures except x86_64, aach64, armhf and wasm are all 
effectively unmaintained. I doubt we could find maintainers. The only frequent 
and reliable user I know of of the uncommon archs is Debian, and that is 
basically just compile testing it and opening bugs if it doesnt compile, and 
only for mips*, ppc64 and s390x. I have previously fixed fatal bugs in big 
endian handling, that nobody had reported for years.

Best regards
Allan


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

Re: [Development] Proposing to add (CPU) architecture maintainers

[Thiago Macieira]

On Wednesday, 3 August 2022 04:56:41 PDT Marc Mutz wrote:
> - ARM
> - x86 (Thiago would be the obvious candidate, if he's in for it)

I agree. I already do this anyway, so it's just formalising something that 
exists.

> - MIPS
> - POWER
> - RISC-V
> - S390
> - Sparc
> 
> I would expect maintainers to be comfortable approving[1] assembly code
> for their platform, work (or orchestrate work) towards feature-parity
> with Qt's x86 support, and ideally getting the architecture into our CI
> or else making sure locally that the architecture builds and tests pass.
> 
> [1] Maintainers need to be Approvers, but I think we can grow an
> architecture maintainer into a Qt project Approver, because I don't
> think we'll find arch maintainers for all archs from the current set
> of Approvers.
> 
> What do you think?

I think we're not going to find anyone for any of the other platforms in the 
short term. Maybe RISC-V because it's getting a lot of share-of-mind -- it's 
something that even I have an interest on (lack of hours in the day is the 
problem). And if we poke at Imagination folks we can get someone to review 
MIPS code. Interestingly, if you go to mips.com right now, the big banner is 
about RISC-V...

POWER and S/390 are very IBM-specific. They're still active, but I don't think 
we have much relevance in that market. And Sparc has ceased being active. For 
those three I don't think we can hope to expect any kind of performance 
improvements. And since we don't have them in the CI at all, we can't even 
confirm they still build. I think they will go to the "we'll accept patches" 
bin, as opposed to Alpha patches.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering



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

Re: [Development] Licensing of qtbase

[Benjamin TERRIER]

On Wed, 13 Jul 2022 at 13:05, Florian Bruhin  wrote:

>
> https://www.qt.io/product/features?hsLang=en#js-6-3 lets you see the
> individual components of Qt and what license they are available as.
>
>
That's some high level of FUD and BS.
If I select LGPLv3, all Qt tools are greyed out (moc, qmake, Qt Creator,
etc.).
Sure these tools are themselves not licensed under LGPLv3, but nothing
prevents them from being used for LGPLv3 projects.

Ang given the text at the top of the page:

> Please select a [...] license model, [...] programming language to see,
> what items are available for that selection.
>
it will clearly make some people think that one cannot use these tools with
LGPLv3 projects.
Especially because when selecting a language it will filter based on which
languages can be used with a tool, not which languages a tool is
developed with.

Anyway, I think the easiest way to get info about Qt license is
https://doc.qt.io/qt-6/licensing.html for general information and
https://doc.qt.io/qt-6/qtmodules.html#gpl-licensed-addons for checking
modules that are not available under LGPLv3.

BR
Benjamin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Proposing to add (CPU) architecture maintainers

[Marc Mutz]

Hi,

I'm hitting a wall on architecture-specific patches that aren't x86 (or, 
to a lesser extent, ARM). I don't know who's responsible for the MIPS 
assembly we have in QtCore,  nor who to talk to to get qYieldCpu 
implemented for architectures other than x86 and ARM 
(https://bugreports.qt.io/browse/QTBUG-103010).

Honestly, I also feel that x86 gets dis-proportionally more love than 
other archs (incl. ARM), because Intel supports Thiago's work (whether 
by paying for his work or just by having access to experts, I don't want 
to speculate here, as it doesn't matter in the end).

So, I'd like to propose to create a set of CPU architecture maintainers 
a la the platform maintainers we already have. As per 
qprocessordetection.h, we purport to support the following architectures:

- Alpha (commented out, architecture is dead, anyway)
- ARM
- AVR32 (commented out)
- Blackfin (commented out)
- x86 (incl. AMD64)
- Itanium (architecture is dead, though)
- MIPS
- POWER
- RISC-V
- S390/X
- SuperH (commented out)
- Sparc
- WebAssembly (special case: archtecture == platform)

So, we'd need maintainers for the following platforms, or declare the 
platform unsupported:

- ARM
- x86 (Thiago would be the obvious candidate, if he's in for it)
- MIPS
- POWER
- RISC-V
- S390
- Sparc

I would expect maintainers to be comfortable approving[1] assembly code 
for their platform, work (or orchestrate work) towards feature-parity 
with Qt's x86 support, and ideally getting the architecture into our CI 
or else making sure locally that the architecture builds and tests pass.

[1] Maintainers need to be Approvers, but I think we can grow an 
architecture maintainer into a Qt project Approver, because I don't 
think we'll find arch maintainers for all archs from the current set
of Approvers.

What do you think?

Thanks,
Marc

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