Tdesktop: Can the Linux client use GTK FileChooser?

[orschiro]

Hi all,

Great work on the Linux Desktop client. Thanks so much!

I have one question:

Currently, the client uses a very impractical and rather ugly file choosing window.

Would it for the client be possible to use the native GTK File Chooser?

See this example of how this could look using when opening a file, for instance in Chrome:

Thankfully,

Robert

[mareg]

:+1:

[ManuelSchneid3r]

Technically this is nonsense, since tgram is powered by Qt. In case of the desirable goal to dynamically link on linux this would introduce unneccesary dependencies.

Normally qt styles are consistent with gtk. But somehow the author decided to set the qt style to win. This affects the systray menu too. This issue is the result of #987

[orschiro]

@ManuelSchneid3r

Thanks for pointing that out! I haven't changed or customised the Qt settings. I am using the defaults as provided by elementaryOS.

I have asked the question on elementaryOS StackExchange how to change the default style.

[ManuelSchneid3r]

I am not experienced with this, but there is an option "-style" which is gereral to all qt applications. Unfortunately it is not working. After further reading, I guess this is due to the fact that the author wrote its own style (checkbuttons, slider,etc), which is based on the win style. The ugly xp parts have to be parts that he has not overridden yet.

[l4rzy]

This software use Qt toolkit with static linking lib, Qt/C++ classes is inherited and changed from Qt5 original classes , so the style option will not work except the developer add style option to it.

[auchri]

Discuss further at #987 :)

[ManuelSchneid3r]

These are not dups. #987 is about the style of the application this one is about the filechooser type.

[telegramdesktop]

@ManuelSchneid3r They both are about the file chooser style.

[ManuelSchneid3r]

Sorry, but no :grin: I'm the author of #987. #987 is about the style in general. The context menu of the systray icon is affected, too. I even found out where the style gets removed.

[Lesik]

I'm just going to copy-paste my comment from https://github.com/telegramdesktop/tdesktop/issues/987 here because it's more relevant here:

Everybody seems to be talking only about looks. Sure, looks are important, but it's not just about looks. Functionality is also impaired!

For example, mounted network drives, or "favourite places" are not shown in Telegram's file picker, although they exist in the native file picker. Another thing is that there is no file preview of the selected file on the right side. These are useful things and it's really annoying to not have those in the desktop client.

[TotalKrill]

This should be the issue for the filechooser ONLY. For the general looks and theming, I think #987 is better.

@ManuelSchneid3r Have you looked into the filechooser being the QT-widget version? Do you have any pointers of where to look?

[telegramdesktop]

When I tried to build Qt with gtk file chooser support it ended up in linking the gtk library (because of my static linking of Qt I guess), which is not acceptable, because builds should have ability to launch even on systems without gtk. Perhaps this should be done by dynamic loading of some plugin or I need to dynamic check-n-load gtk and write my own file chooser wraps instead of Qts.

[TotalKrill]

@telegramdesktop I agree that GTK can not be a requirement. How much have you patched QT? It seems many of these problems would be solvable by allowing both dynamic and static linking of QT, and this would be easier if there were no need for a patched QT.

[ManuelSchneid3r]

This line in my applications procuces a native filedialog

It is a pretty vanilla Qt QFileDialog::getOpenFileName call, no styles nothing fancy.

I have no reference, but afaik Qt uses the native dialogs if not disabled explicitely. There is really no need to link GTK. Qt decides if it is necessary, like it does with the native GTK renderer. Maybe this is related to the static linking.

[telegramdesktop]

@ManuelSchneid3r well, that line in my application does not :) I guess it is static linking indeed.

[suy]

I would review how the app is statically linked. See the page on plugins and review the section about static linking and the platform plugin. Normally that platform plugin takes care of using the native file dialog, AIUI. If you link statically, and the platform plugin has to be loaded statically as well, that might require statically linking GTK+. Or so I understood...

[AndydeCleyre]

@telegramdesktop can you speak to @totalkrill's question? Any chance we can get off that patched qt sometime soon, and what are we getting out of it in the meantime?

[telegramdesktop]

@AndydeCleyre You're getting out a working application :) All the text rendering is done using private Qt apis.

[AndydeCleyre]

@telegramdesktop ha, yes, I do get a lot out of this project. Thank you. Are there there particular deficiencies in the standard Qt text rendering methods?

[Veske]

Why is this issue closed? Problem still persists, no?

[philiparvidsson]

I'm also curious why this issue is closed. This needs to be solved or at the very least left as an open issue until it is solved.

[ManuelSchneid3r]

Have you ever thought of rewriting the frontend using QML? The UI of this application much to flexible and does seldomly use (nonstyled) widgets at all. This is a perfect usecase for QML. I'd bet that this would reduce the codebase about tons of LOC, solve dozens of issues and further remove the need for patched UI libs.

[AndydeCleyre]

@auchri Why is this closed?

[john-preston]

In the latest 0.9.57 version gtk file chooser should be used if it is available. Please check.

[AndydeCleyre]

Woo hoo!

It's not as optimal as the native Qt file picker, in Qt environments, but it's a _huge_ improvement over the . . . thing it was before. Thanks!

[Veske]

For me the updater does not update it from 0.9.56 to 0.9.57. It's not official release yet?

[AndydeCleyre]

@Veske The next official release after 0.9.56 is 0.10.0, which happened today. You can see that at https://desktop.telegram.org/ . Are you using Windows?

[KAMiKAZOW]

Why on earth do I now have the GTK file chooser under KDE Plasma 5? I rather have the old one back (preferably the native KDE one, though)

[ghost]

@KAMiKAZOW same here. Telegram is using Qt but the file picker is a GTK one.

I'm using Plasma 5.13 right now

[alxlg]

Why not using xdg-portal to use whatever the system has as file picker?

[john-preston]

@alxlg How is it done?

[KAMiKAZOW]

Why not using xdg-portal to use whatever the system has as file picker?

Qt uses the system file picker anyway unless one hardcodes the GTK one for no reason.

[Johnnynator]

Why not using xdg-portal to use whatever the system has as file picker?

Qt uses the system file picker anyway unless one hardcodes the GTK one for no reason.

Teletram uses qt 5.6.2 by default which only uses portals for Flatpak if at all. Qt 5.12 was afaik the first version to use portals always if they are supported.

@john-preston xdg-portal is just a dbus interface https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.impl.portal.FileChooser

[alxlg]

@john-preston iirc @grulja got Telegram Desktop using xdg-desktop-portal here: https://github.com/grulja/org.telegram.desktop

With xdg-desktop-portal's File Chooser the app ask to the system to show a file picker and then the selected file is sent to the app

[grulja]

Telegram shouldn't be definitely using portals outside Flatpak/Snap. You should use whatever file dialog is provided by the loaded platform theme. Portals are also implementation of platform theme and they are used automatically when Flatpak or Snap is detected.

[alxlg]

@grulja why only in Flatpak/Snap? OK they were thought for sandboxing, but is there another way to get the system file dialog? By that I mean that the system provides it and the app is totally unaware of what is used.

This is important even for Qt apps like Telegram in Plasma because the KDE file dialog is not the Qt one.