Work with official QT

[ItachiSan]

This issue is opened in order to avoid in future the usage of a patched QT version.
The general idea would be to:

• Use system FCTIX QT plugin as many Linux distros can offer this plugin, else it can be compiled as dependency
• Avoid patching of QT stuff or send stuff upstream, in order to have a pure environment
  I would like to have feedback from developers and in case upload some code to patch stuff.

[john-preston]

1. as I understand I can't use it while linking Qt statically: "Note that the QPluginLoader cannot be used if your application is statically linked against Qt. In this case, you will also have to link to plugins statically"
2. no way to link dynamically to Qt (even if you avoid all the patches I use), because my text rendering code is based on the internal code of Qt, not the public interface provided, so I can't rely that the internal methods still exist and do the expected thing.

[YtvwlD]

I think the idea would be to link dynamically.
I don't really understand what's the problem here. I already have QT installed on my system. Why can't Telegram use it?

[ItachiSan]

@john-preston can't be the Telegram Desktop code refactored to use the official text rendering methods...?

@YtvwlD because Telegram Desktop use a patched version of QT5, so the methods in the official QT5 are different to the ones present in the patched version.

[jhasse]

This would also fix that the file dialog doesn't use my theme:

[YtvwlD]

Currently, nothing uses the system theme.

[AndydeCleyre]

@john-preston

my text rendering code is based on the internal code of Qt, not the public interface provided

What's the big advantage here? Lots of users and package maintainers would love for this to use official Qt, dynamically linked. So what is so advantageous about relying on patches and unreliable internal code that makes this worth it?

[john-preston]

@AndydeCleyre Well, when it was first made, I was working on a fast holding in memory + rendering of big amounts of text parts with graphic emoji, so that one message history can hold tens of thousands of text messages (I've tested up to 100 000) and window resize (which triggers the resize of all the messages to count the new window height) should work without lagging and scrolling should be smooth with instant switches between different conversations with big amounts of messages (tdesktop holds all the loaded messages in memory, local database for messages is not yet supported, so it needs all that) with acceptable memory consuming. I don't know how to achieve this using just Qt public interface.

[plinnell]

I can tell you as a developer for a project written in Qt since 2001, the patching of Qt by an application is a very bad idea. See: http:www.scribus.net We also deal with text rendering issues and have our own canvas because of the need to manipulate objects beyond text.

As a long time Linux user (15 years) and having packaged Linux applications for more than 10, not using Distro provided Qt over time is going to be an unholy, difficult to maintain mess. What happens when the patched Qt needs a security patch ? and Qt does get them ;) You are creating your own technical debt and a relatively young project needs to avoid this especially in the early days.

It seems most of what you are trying to fix, could be fixed by pulling in fcitx-qt5-devel, which provides the input capabilities for CJK.fcitx is pretty well supported on most recent distros.

Requiring a patched Qt is a very strong barrier to get your application into Linux distros. I'm one of the Factory maintainers for openSUSE and this would more than likely be rejected to be part of the distro, especially statically linking Qt and/or having your own patched Qt. I'm pretty certain Fedora/RedHat would say the same thing. Moreover, even if you apply patches, separating them out to different platforms is a best practice.

Now enough ranting. I do hope your team considers using https://openbuildservice.org to do your Linux packaging. It is cross distro and has many automation features which can ease package builds and provides infra for distribution. It can be hooked into Jenkins and speaks native git for pulling sources to build.

[gavv]

I totally agree with @plinnell. Also, patched Qt was the main reason why telegram source package was rejected by Gentoo developers. Bundled dependencies are usually very unwelcome by any distro maintainers and Linux community.

[WhyNotHugo]

@plinnell @gavv I don't think there's any rejection to actually stop patching Qt.

As far as I've understood, it's just that the devs haven't been able to get things working as expected with the upstream Qt, and nobody's offered another working solution (in the form of a PR). So rather than "up for debate", I think this issue is actually "awaiting patches".

[guoyunhe]

@gavv Some people already submited some pull request to use existing fcitx-qt5-devel package rather than patch the whole fcitx binding. But these pull requests have never been accepted.

[john-preston]

@guoyunhe fcitx is the small thing in the patch, it just got there because the patch was already in place.

The main problem is the text-with-emoji recounting/rendering, which uses private Qt apis.

I see no way in not using it trying to make fast-enough and not-so-memory-consuming text-with-emoji processing for tdesktop. And even if there is such way, which I don't know, it will be a huge amount of work to move the existing code base to that another way.

[AndydeCleyre]

@john-preston is it relatively simple to make a branch that uses Qt's slow/mem-heavy methods? How bad is it?

[john-preston]

@AndydeCleyre I don't know, how to make that in an easy way. You need to move all the SourceFiles/ui/text/text_.. on something completely different, that uses only public Qt API.

[john-preston]

@AndydeCleyre I guess you need to create a separate QTextDocument object for each displayed text piece and wrap all the methods that work with Text() right now to work with those documents.

[pschichtel]

What about upstreaming the changes? If your controls are in fact that much more efficient than the standard Qt ones, I guess a lot of other applications could benefit from them as well.

[john-preston]

@pschichtel I'm pretty sure this can't be done :( They're not general controls in any way, just very app-specific pieces of code. Perhaps the approach that was used there could be generalized some how but it is a huge amount of work in its own and after that I still doubt that any of it will be merged to Qt.

[pschichtel]

@john-preston Are entire controls implemented in the Qt patches? I thought more about the optimizations you did. Or you could add in public APIs for the private ones you are using and upstream them.
This all sounds like hacking around limitations of a library instead of just removing the limitations from the library, I don't like that.

[WhyNotHugo]

Is is somehow possible to make those "private Qt APIs" public upstream? Has this even been discussed?

[AndydeCleyre]

This is by far the most important bug in this project, and I would contribute to a bug bounty for it.

[Schekolda]

So, will you stop using patched QT?

[stek29]

https://aur.archlinux.org/packages/telegram-desktop-systemqt-notoemoji/ may help (from #3129)

[KireinaHoro]

As well as https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=telegram-desktop-systemqt .

[AndydeCleyre]

Can someone write here what the deal is with those "systemqt" packages? What works and what doesn't?

[stek29]

Distributing Telegram with native Qt would result in the need to provide different TG builds for the different Qt versions

It shouldn't. At least when done properly.

[orschiro]

let distro maintainers build TG with native Qt (if they will) and TG devs continue providing static build unified for all distros

Let's take Ubuntu as an example. It doesn't provide Telegram Desktop in its official repositories. But as far as I know there is a Snap as well as Flatpak for TD. Does this make a difference to the argument?

[gasinvein]

Use of patched Qt is a strong argument against adding Telegram to official repositories. Maybe if Telegram would work with distro's native Qt, there will be no need in Snap or Flatpak for it.

[loimu]

Let's take Ubuntu as an example. It doesn't provide Telegram Desktop in its official repositories.

Really? What's that then?

[orschiro]

@loimu forget what I just said. Don't even know how I missed that. And I was sure it didn't have the package the last time I was looking for it in the official repos. 😅

[shibotto]

ebuilds for Gentoo are available too https://github.com/reagentoo/gentoo-overlay/tree/master/net-im/telegram-desktop
I've been using this for a couple of weeks and not a problem so far.

[gasinvein]

So, as for now, Fedora (rpmfusion), openSUSE, Arch, Gentoo, Debian/Ubuntu and even Flathub, all patch Telegram to avoid linking statically with modified Qt. Did I miss someone?

[3v1n0]

We don't do it in the snap so far, since I want to do same as upstream... But of course, that would be probably better.

[balsoft]

So, as for now, Fedora (rpmfusion), openSUSE, Arch, Gentoo, Debian/Ubuntu and even Flathub, all patch Telegram to avoid linking statically with modified Qt. Did I miss someone?

You missed NixOS 😄

[mikken]

Gentoo only has statically linked official binary package for Telegram Desktop.
The one above is a third-party package.

[ilya-fedin]

I'm not sure if this issue is valid, since dropping patches wouldn't have the effect that most of people want here: to use system Qt by the official binary.

1. Official binary supports Ubuntu 12.04+, what means that official binary will should link to Qt with version that is provided by that distro. I'm not sure if it even provides Qt 5, but if it provides, it would be something like 5.0.0, which will lack most of Qt APIs used by tdesktop
2. Telegram will lose one of it's main pros: just unpack binary and run it. Users will need to find Qt libraries in their repos (which are named very differenly across distributions and splitted differently too), check if they're new enough, etc, etc.

And most of Qt apps that provides official binaries doesn't use system Qt in their builds too: Viber, WPS Office, XnView MP, Calibre

Probably this issue should be closed as wontfix.

[emanuelserpa]

I think that the issue was about compiling the Telegram Desktop (not about the official binary) code to work in the distributions with the official/main qt and Telegram used a modified qt to compile and to compile it we needed patches like in https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=telegram-desktop-systemqt (that later become the official telegram-desktop package).

Now every distribution has telegram in the repositories and, at least here on Arch Linux, I don't see any patch in the PKGBUILD.

I don't know if I'm right, though.

[portaloffreedom]

@ilya-fedin You got this completely wrong: the issue is not with the binary distribution but with the possibility to compile the binary with the Qt dynamic libraries. Telegram was (still is? I don't know) doing weird and unnecessary modification to the Qt library and it made very difficult for distribution to include telegram in their own distro while removing unnecessary duplicated libraries.

Also, the number of people on linux that download precompiled open source programs from websites is close to zero.
Also, I would like telegram-desktop to be 46MB, not 400+MB.
Also, wayland support.

To sum it up: the official binary can include the Qt libraries, I don't think people have problems with that. But please don't fork Qt for useless features so that it would only make the application 10 times bigger in our computers for the sake of it, while removing compatibility for new stuff e.g. with new wayland.

Make your life easier, leave Qt development to upstream.

[ilya-fedin]

I think that the issue was about compiling the Telegram's Desktop

tdesktop imported distropatches in January, it can be compiled with system Qt in most of distros

[ilya-fedin]

You got this completely wrong: the issue is not with the binary distribution but with the possibility to compile the binary with the Qt dynamic libraries.

Maybe some people here talking about compiling in distributions, but I see that the first post is about using system Qt in official bianry to work with fcitx, so that I assume that issue is about the official binary (anyway, distribution part is not valid anymore)

[ilya-fedin]

Also, wayland support.

Official binary supports wayland, just use QT_QPA_PLATFORM=wayland like with any other Qt app

[portaloffreedom]

@ilya-fedin I'm sorry if I reacted a bit too harsh but I wanted to make it clear what the problem for half of the people was with distro packages.

All of this is old stuff back when it was a problem. Now it's not any more and if package maintainers have problems again with something similar they can file a new bug or reopen this one.
Given everything that I've said I think this bug can be safely closed now.

[ilya-fedin]

To sum it up: the official binary can include the Qt libraries, I don't think people have problems with that. But please don't fork Qt for useless features so that it would only make the application 10 times bigger in our computers for the sake of it, while removing compatibility for new stuff e.g. with new wayland.

Make your life easier, leave Qt development to upstream.

Qt patches never were a barrier for this. Actually, on linux patches were used and are using to backport fixes from newer Qt. The barriers were is that build system had hardcoded paths to static libraries and Qt private APIs usage by tdesktop. The first is fixed by migrating from gyp to cmake, the second... Well, it is not fixed and I have a feel that this is impossible without the full rewrite of tdesktop, like @john-preston said, but it is workarounded by including some parts of Qt in tdesktop from distropatches

[emanuelserpa]

I think that the issue was about compiling the Telegram's Desktop

tdesktop imported distropatches in January, it can be compiled with system Qt in most of distros

Yeah, looks like everybody used downstream patches in January still

archlinux/svntogit-community@23eff2b#diff-91e904bd64036c9c236ce84542f97781

Now: https://github.com/archlinux/svntogit-community/blob/packages/telegram-desktop/trunk/PKGBUILD

Can I ask if you guys still use the downstream qt for the official binary?

[ilya-fedin]

archlinux/svntogit-community@23eff2b#diff-91e904bd64036c9c236ce84542f97781

The next commit xd

archlinux/svntogit-community@0917e48#diff-91e904bd64036c9c236ce84542f97781

Can I ask if you guys still use the downstream qt for the official binary?

Probably my previous message answers that

[emanuelserpa]

Probably my previous message answers that

So, the second part (I don't know what it is) is "fixed" by a patch that workaround the "limitations" of the mainline qt, right?

Then the fix is officially compiling with the patches and moving on.

[ilya-fedin]

So, the second part (I don't know what it is) is "fixed" by a patch that workaround the "limitations" of the mainline qt, right?

By adding the qt_functions.cpp from distropatches that contains private functions that is not exposed by Qt libs
A month ago it is moved to lib_ui and renamed: https://github.com/desktop-app/lib_ui/blob/master/ui/text/qtextitemint.cpp

Then the fix is officially compiling with the patches and moving on.

What do you mean? 🤔

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.