[Development] Nominating Dennis Oberst for approver rights

[Alexey Edelev via Development]

Hi all,

I would like to nominate Dennis Oberst for approver rights in the Qt project.

Dennis joined in 2022 and did a great job in various Qt subprojects, providing 
strong patches and insightful reviews. I personally appreciate his 
contributions to QtGrpc, which he continues to make.

Changes owned:
* https://codereview.qt-project.org/q/owner:dennis.obe...@qt.io

Changes commented/voted on:
* https://codereview.qt-project.org/q/commentby:dennis.obe...@qt.io

Regards,
Alexey.


Alexey Edelev

Software Engineer

Qt Group
Erich-Thilo-Str. 10 12489
Berlin, Germany

alexey.ede...@qt.io

www.qt.io

[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/Qt-Group-logo-black-1.png]
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/facebook-x2-right.png]

[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/twitter-x2.png] 
 
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/linkedin-x2.png]
 
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/youtube-x2.png] 

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

Re: [Development] Changing Qt's Binary Compatibility policy

[Thiago Macieira]

On Wednesday 29 May 2024 16:54:33 GMT-3 Narolewski Jakub wrote:
> Sorry for chiming in uninvited but isn't this how the Qt Online Installer
> thingy works?

Very carefully.

It's built on a reasonably old Linux distribution, the oldest of all of them 
that are still supported. It also builds with all or almost all third-party 
content bundled, instead of depending on system libraries, and some features 
disabled where system libraries would be required (for example, journald 
integration, zstd compression support, etc.).

Your Linux distribution's packages are superior builds in almost every aspect, 
except that of being run in other distributions.

Because the pre-built binaries from download.qt.io contain bundled third-
parties that do get a couple of security advisories per year, you must be able 
to rebuild the binaries on a moment's notice. So don't trust the binaries you 
download from download.qt.io except for development: for your releases, you 
should build Qt from source.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCAI Fleet Engineering and Quality


smime.p7s
Description: S/MIME cryptographic signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changing Qt's Binary Compatibility policy

[Narolewski Jakub]

Sorry for chiming in uninvited but isn't this how the Qt Online Installer
thingy works?

I know that with it I can install some prebuilt Qt distribution on my Linux
- openSUSE Tumbleweed - and I kinda always assumed that the actual build
host could be a different distro.
I never really gave it much thought to be honest. Maybe there is some kind
of matching mechanism somewhere in there during the download process.

--

Best regards / Pozdrawiam serdecznie
Narolewski Jakub
Software Developer


śr., 29 maj 2024 o 21:29 Thiago Macieira 
napisał(a):

> On Wednesday 29 May 2024 00:30:12 GMT-3 Kevin Kofler via Development wrote:
> > There is, however, one use case you are overlooking, and that is binaries
> > compiled on one distribution and run on another.
>
> That's not supported at all and that has nothing to do with Qt. Unless the
> two
> distributions are coordinating and testing each other's binaries, it's not
> guaranteed to work and is in fact a recipe for disaster. But if they are
> coordinating, then the problem you're talking about doesn't exist.
>
> Some distributions have adopted the no-direct-external-access support and
> others have not. In order to run against a Qt that was compiled with it,
> you
> must compile your software with it too, otherwise the loader will refuse
> to
> start your application.
>
> I don't understand why some distros explicitly disable that support. It
> might
> be because they wanted to retain compatibility with the negligible amount
> of
> Qt 6 software that existed before the option was introduced. But now
> they're
> locked into it for the duration of Qt 6.x.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Principal Engineer - Intel DCAI Fleet Engineering and Quality
> --
> 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] Changing Qt's Binary Compatibility policy

[Thiago Macieira]

On Wednesday 29 May 2024 00:30:12 GMT-3 Kevin Kofler via Development wrote:
> There is, however, one use case you are overlooking, and that is binaries
> compiled on one distribution and run on another.

That's not supported at all and that has nothing to do with Qt. Unless the two 
distributions are coordinating and testing each other's binaries, it's not 
guaranteed to work and is in fact a recipe for disaster. But if they are 
coordinating, then the problem you're talking about doesn't exist.

Some distributions have adopted the no-direct-external-access support and 
others have not. In order to run against a Qt that was compiled with it, you 
must compile your software with it too, otherwise the loader will refuse to 
start your application.

I don't understand why some distros explicitly disable that support. It might 
be because they wanted to retain compatibility with the negligible amount of 
Qt 6 software that existed before the option was introduced. But now they're 
locked into it for the duration of Qt 6.x.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCAI Fleet Engineering and Quality


smime.p7s
Description: S/MIME cryptographic signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Behavioral change with font metrics

[Eskil Abrahamsen Blomfeldt via Development]

Hi,

I have a pending change which I would like to get into Qt 6.8 which will change 
default line heights of fonts in some cases, so I thought I would mention it 
here to hear if people have objections. Since it does change text layouts in 
some cases, it also adds a fallback mechanism to previous behavior, both per 
font with a style strategy in QFont and an application attribute. Some users 
will notice this and manually have to change their code if they are unhappy 
with the changes, but in practice it is a correctness fix.

https://codereview.qt-project.org/c/qt/qtbase/+/563751

Background is this:

In OpenType fonts there are three different sets of metrics providing the 
vertical metrics of the font

  *
The ascender/descender/lineGap in the HHEA table (predates OpenType)
  *
The winAscent/winDescent in the OS/2 table
  *
The typoAscender/typoDescender/typoLineGap also in the OS/2 table

Microsoft's approach is typically to add new fields to OpenType rather than 
risk breaking legacy software, so the format is kind of convoluted due to this. 
In most fonts the HHEA values will match the typo* values, but older 
implementations of the font system had platform-specific handling of these (as 
the spec says), so to ensure backwards-compatibility, Microsoft added the 
additional sets.

The winAscent/winDescent are used for clipping the glyphs, so they need to be 
set so that no glyph in the font is higher than winAscent+winDescent. Often the 
sum will match typoAscender-typoDescender+typoLineGap, but not always. The 
clipping requirement makes them less suitable for typography, since there's no 
way to add e.g. glyphs that are taller than the line height of the font. But 
many applications still used winAscent+winDescent for line heights, including 
Microsoft's own GDI. So to make it possible to keep the default of 
winAscent+winDescent for existing fonts but still allow fonts to expand beyond 
this, they later added the USE_TYPO_METRICS flag to the OS/2 table, which is 
supposed to be set if the typo* metrics are valid to use.

In Qt 5 we would have platform-specific handling of this:

  *
Windows would use winAscent+winDescent as default, unless USE_TYPO_METRICS was 
set, in which case the typo* metrics were used
  *
FreeType would use the typo* metrics if available
  *
macOS would use the original metrics in HHEA, even if the OS/2 table is present 
in the font, typically matching the typo* metrics.

Users were complaining about inconsistent layouts between platforms, and in Qt 
6.0 we tried to consolidate, by making all platforms use the OS/2 data if 
available, and prefer typo* metrics if the USE_TYPO_METRICS was set and win* 
metrics if not.

We early found out that this was not a viable plan on macOS, because some fonts 
that are only used on macOS have OS/2 tables with invalid data in them. So we 
changed macOS to use the platform values again instead. This typically matches 
the typo* values granted that those are set correctly, because there is no 
reason for these to be different. But we kept the changed default on FreeType, 
so that this now matches Windows.

Some recent discussions has made me regret this decision, though. The OpenType 
spec
 very clearly states:

Some legacy applications use the usWinAscent and usWinDescent values to 
determine default line spacing. This is strongly discouraged. The sTypo* fields 
should be used for this purpose.

So despite GDI choosing the backwards compatible route, the recommendation is 
to always use the typo* metrics for line spacing. This means that modern font 
systems that are not limited by compatibility concerns will use this, and this 
in turn means that fonts will be designed with this in mind. Font designers 
will often neglect to set the USE_TYPO_METRICS flag even if the typo* metrics 
are preferable, because the fonts work fine on FreeType and DirectWrite 
applications.

Now, the conservative approach would be to do what Microsoft did and keep the 
current default + add an opt-in for the correct behavior. But I fear becoming a 
primarily compatibility-driven toolkit can be inhibiting, like it is for GDI, 
so I would rather like to default to correctness, following the recommendation 
in the spec and introduce an opt-out for those users who want to get back the 
original behavior.

So that's what my change currently does. By default, macOS will still use HHEA 
(so font designers still need to make sure those are in sync with the other 
metrics) but Windows and FreeType will both now prefer the typo* metrics, even 
if the USE_TYPO_METRICS flag is unset. If PreferLegacyLineMetrics is set, then 
all platforms (including macOS) will use typo* metrics if USE_TYPO_METRICS is 
set and win* metrics otherwise, granted that the OS/2 table exists in the font. 
(I think changing macOS to correspond to the others here is ok, since it's a 
manual opt-in.)

Some users will see that t