Support #ifdef FLATPAK_BUNDLE

Remember, just because you request it, that doesn't mean you'll get it.

Moderator: GZDoom Developers

Support #ifdef FLATPAK_BUNDLE

Postby Eonfge » Sat Apr 25, 2020 5:15 am

Hey all,

I've been supervising the Flatpak distribution for some time, and throughout that process I have stumbled upon a few issues that I now manually patch in the distribution. These are minor changes, like ensuring that the right user-directory is prompted and ensuring that there is no conflict with KDE users. As it stands, I would have no trouble integrating submitting these changes upstream, but it does imply that you actually want these changes and that you have no objection supporting these changes using a CMAKE option.

Proposal support
add the following parameter to cmake property:
-DFLATPAK_BUNDLE=YES

supporting the following:
#ifdef FLATPAK_BUNDLE

Adding changes
- Redirect user to proper Flatpak config folder
https://github.com/flathub/org.zdoom.GZ ... tion.patch

- Remove kdialog which causes issues because of a environment variable
https://github.com/flathub/org.zdoom.GZ ... /kde.patch

Open question
Do you, Graf Zahl, Rachael, and others, approve of this addition?

If you do, I can prepare a pull request
Eonfge
 
Joined: 10 Sep 2019
Github ID: https://github.com/eonfge
Operating System: RedHat-like Linux (RHEL, Fedora, CentOS, etc) 64-bit
Graphics Processor: nVidia (Modern GZDoom)

Re: Support #ifdef FLATPAK_BUNDLE

Postby Rachael » Sat Apr 25, 2020 5:58 am

Go for it. As long as it does not affect anything we directly support, and you do it cleanly, following coding guidelines, there is no issue with this.

Please submit your work as a pull request.
User avatar
Rachael
Admin
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Support #ifdef FLATPAK_BUNDLE

Postby Chris » Sat Apr 25, 2020 7:16 am

Eonfge wrote:- Remove kdialog which causes issues because of a environment variable

This will affect the gnome/gxmessage path too, won't it? Since it also uses an environment variable to detect which to use.

Honestly I'm not really happy with how those message boxes are handled on Linux, because there's no way to accurately tell which of those message apps should be used for the user's system or is otherwise available. The most basic fallback, xmessage, is part of X11 and thus will always be there (at least until X11 is no longer used on Linux), but it's also the ugliest and completely archaic. I'm not really up on the XDG standard for what applications or tools are available to display these kinds of messages given the user's desktop, but I'd maybe look in that direction. There might be dbus interfaces for that too.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: Support #ifdef FLATPAK_BUNDLE

Postby Eonfge » Sat Apr 25, 2020 9:42 am

Chris wrote:
Eonfge wrote:- Remove kdialog which causes issues because of a environment variable

This will affect the gnome/gxmessage path too, won't it? Since it also uses an environment variable to detect which to use.

Honestly I'm not really happy with how those message boxes are handled on Linux, because there's no way to accurately tell which of those message apps should be used for the user's system or is otherwise available. The most basic fallback, xmessage, is part of X11 and thus will always be there (at least until X11 is no longer used on Linux), but it's also the ugliest and completely archaic. I'm not really up on the XDG standard for what applications or tools are available to display these kinds of messages given the user's desktop, but I'd maybe look in that direction. There might be dbus interfaces for that too.


Good you mention that. The message boxes are actually the thing that gives me trouble.

Because you are right, there was no way to know which technologies are available for end users, until Flatpak. With the new packaging format, it can make use of whichever messages system we want. Most basically, you bundle any UI framework you want without extra hassle. Right now, I only use the default framework, thus I use xmessage. On KDE based systems, that will then be translated to kdialog, as a fallback.

The reason that I have issues with it right now, is that the 'KDE specific' solution crashes because I have not actually packaged GZDoom as a KDE application. Issue ensures:
https://github.com/flathub/org.zdoom.GZDoom/issues/10

My proposal: Remove kdialog when I do a Flatpak build because such a workaround is now actually harmful.

Also, I'm sorry to bring it to you all, but the GNOME_DESKTOP_SESSION_ID environment variable is deprecated and my system (Fedora 31) doesn't even have it any more. I have not tested this on other distributions, but it's save to say that it's a dead end. So, perhaps it would be nice to look at the current Linux messaging system altogether. Do you have any ideas about that?
Eonfge
 
Joined: 10 Sep 2019
Github ID: https://github.com/eonfge
Operating System: RedHat-like Linux (RHEL, Fedora, CentOS, etc) 64-bit
Graphics Processor: nVidia (Modern GZDoom)

Re: Support #ifdef FLATPAK_BUNDLE

Postby Chris » Sat Apr 25, 2020 10:49 am

Eonfge wrote:Also, I'm sorry to bring it to you all, but the GNOME_DESKTOP_SESSION_ID environment variable is deprecated and my system (Fedora 31) doesn't even have it any more. I have not tested this on other distributions, but it's save to say that it's a dead end. So, perhaps it would be nice to look at the current Linux messaging system altogether. Do you have any ideas about that?

SDL2 has a very basic API to display a message box dialogs (in its own window, not a user-allocated screen/window). Though it's using its own visual style, not like Qt or GTK or anything, and may be too limited to do what GZDoom would need.

Alternatively, GZDoom has an option to build with GTK support, currently to make an IWAD selector. Someone who knows GTK might be able to create message boxes with it, without using an external app. Unfortunately that person's not me. Maybe in the future, I've been thinking about learning GTK since Qt's free/open source future may be running into problems, but we'll see.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: Support #ifdef FLATPAK_BUNDLE

Postby Eonfge » Sun Apr 26, 2020 8:48 am

Hey, I added a base implementation of FLATPAK_BUNDLE
https://github.com/coelckers/gzdoom/pull/1077

I also included the current manual patches that I do for Flatpak. In the future, I might be able to streamline the UI more, since we can then safely rely on GTK functionality. Test version of Flatpak with the upstream patches:
Code: Select allExpand view
flatpak install --user https://dl.flathub.org/build-repo/18261/org.zdoom.GZDoom.flatpakref
Eonfge
 
Joined: 10 Sep 2019
Github ID: https://github.com/eonfge
Operating System: RedHat-like Linux (RHEL, Fedora, CentOS, etc) 64-bit
Graphics Processor: nVidia (Modern GZDoom)


Return to Feature Suggestions

Who is online

Users browsing this forum: No registered users and 1 guest