Re: [Development] QFreedesktopApplication
On Monday, 25 April 2022 03:16:05 PDT Ilya Fedin wrote: > Also, personally I stopped using QtDBus in my projects due to > QTBUG-63884 and the fact it's unmaintained for 6 years. I still have the code that implements the new-style connect in https://gitlab.com/thiagomacieira/qtbase/-/commit/ a5314c7a8b11a8e6bee8ecf1c4dba112378e532b Yes, it's unmaintained because I don't have time for it either. And because Windows threading made me give up. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QFreedesktopApplication
About the gapplication, I assume it's sth about "man gapplication", see also http://manpages.ubuntu.com/manpages/impish/man1/gapplication.1.html . - SYNOPSIS gapplication help [COMMAND] gapplication version gapplication list-apps gapplication launch APPID gapplication launch APPID [FILE...] gapplication list-actions APPID gapplication action APPID ACTION [PARAMETER] DESCRIPTION gapplication is a commandline implementation of the client-side of the org.freedesktop.Application interface as specified by the freedesktop.org Desktop Entry Specification. gapplication can be used to start applications that have DBusActivatable set to true in their .desktop files and can be used to send messages to already-running instances of other applications. It is possible for applications to refer to gapplication in the Exec line of their .desktop file to maintain backwards compatibility with implementations that do not directly support DBusActivatable. gapplication ships as part of GLib. - If it is correct, you are talking to support it in Qt side. And in your change, https://codereview.qt-project.org/c/qt/qtbase/+/407263 , it is about to expose those functions from gio/gapplication.h into Qt. As a Qt client app, it should support those features via DBus, perhaps QtDBus can't satisfy this request, which you have mentioned https://bugreports.qt.io/browse/QTBUG-63884 . Perhaps you could leave a comment there to explain your use case for it. That's my understanding for today. I agree with Thiago in his reply. And about KDE, found sth like https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/11 , "Use DBus activation for applications that are dbus activatable", perhaps related with this topic. See also: * https://specifications.freedesktop.org/desktop-entry-spec/1.1/index.html Desktop Entry Specification * https://specifications.freedesktop.org/desktop-entry-spec/1.1/ar01s07.html D-Bus Activation * https://github.com/GNOME/glib/blob/main/gio/gapplication.h * https://docs.gtk.org/gio/class.Application.html Best regards, Liang From: Development on behalf of Ilya Fedin Sent: Monday, April 25, 2022 12:16 PM To: development@qt-project.org Subject: Re: [Development] QFreedesktopApplication On Sun, 24 Apr 2022 20:01:10 -0700 Thiago Macieira wrote: > Then this should be implemented regardless of whether glib is used. > > We also need to know whether the KDE equivalent is being used and > avoid confusing the launcher by emitting twice. As I said, it's opt-in... > I don't agree with the value. > > Implement it directly with Qt resources. The reason I implemented that is I don't have enough time/motivation to implement all the four or even three specs by hand. I just need a way to interate existing library with Qt... Also, personally I stopped using QtDBus in my projects due to QTBUG-63884 and the fact it's unmaintained for 6 years. ___ 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] QFreedesktopApplication
On Sun, 24 Apr 2022 20:01:10 -0700 Thiago Macieira wrote: > Then this should be implemented regardless of whether glib is used. > > We also need to know whether the KDE equivalent is being used and > avoid confusing the launcher by emitting twice. As I said, it's opt-in... > I don't agree with the value. > > Implement it directly with Qt resources. The reason I implemented that is I don't have enough time/motivation to implement all the four or even three specs by hand. I just need a way to interate existing library with Qt... Also, personally I stopped using QtDBus in my projects due to QTBUG-63884 and the fact it's unmaintained for 6 years. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QFreedesktopApplication
On Sunday, 24 April 2022 10:06:12 PDT Ilya Fedin wrote: > It's a part of the Desktop Entry Specification[1]. It's used by most > gtk & KDE applications. gtk ones use GApplication, KDE ones use > KDBusService. Then this should be implemented regardless of whether glib is used. We also need to know whether the KDE equivalent is being used and avoid confusing the launcher by emitting twice. > > In fact, if it is a D-Bus API, should we have it even if the GLib > > event dispatchers aren't active? > > Well, the point it's not just org.freedesktop.Application. GApplication > also provides multiple notification protocol implementations and > integration between them and the o.fd.Application spec (as I mentioned > before). It's the main reason I need GApplication as libnotify is really > outdated and there's no other alternative (except of KDE libs-dependent > KNotifications and implementing all the specs by hand which are not > real alternatives IMO). GApplication provides implementations of > multiple nice specifications at once and integrates them, so I thought > why not to use it when it's available... I don't agree with the value. Implement it directly with Qt resources. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QFreedesktopApplication
On Sun, 24 Apr 2022 19:43:09 +0200 Kevin Kofler via Development wrote: > So if Qt implements the same D-Bus interface using GApplication, will > that not break the KDE applications that use the existing > KDBusService? No, I made the uniqueness opt-in via setFlags > And why is using the KNotifications framework not an option for you? > Yes, it depends on a few other KDE frameworks, so what? Do we really > need to reinvent all KDE frameworks functionality within Qt? KNotifications has the following required dependencies: KWindowSystem KConfig KCoreAddons Canberra/Phonon Nothing like this is required by glib and, moreover, it's present on most if not all desktop systems (and nothing wrong if it's not present on the system, the pointer returned by nativeInterface will be nullptr and the applciation can just disable the associated features). ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QFreedesktopApplication
Ilya Fedin wrote: >> On another note, just what is org.freedesktop.Application? There are >> ZERO references to it on freedesktop.org. If this isn't well-defined, >> should we adventure into it? If this is a D-Bus API, then the >> questions above about accessing the interface and implementing the >> server side of it apply: can we have it without a front-end API? > > It's a part of the Desktop Entry Specification[1]. It's used by most > gtk & KDE applications. gtk ones use GApplication, KDE ones use > KDBusService. So if Qt implements the same D-Bus interface using GApplication, will that not break the KDE applications that use the existing KDBusService? > Well, the point it's not just org.freedesktop.Application. GApplication > also provides multiple notification protocol implementations and > integration between them and the o.fd.Application spec (as I mentioned > before). It's the main reason I need GApplication as libnotify is really > outdated and there's no other alternative (except of KDE libs-dependent > KNotifications and implementing all the specs by hand which are not > real alternatives IMO). GApplication provides implementations of > multiple nice specifications at once and integrates them, so I thought > why not to use it when it's available... And why is using the KNotifications framework not an option for you? Yes, it depends on a few other KDE frameworks, so what? Do we really need to reinvent all KDE frameworks functionality within Qt? Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QFreedesktopApplication
On Sun, 24 Apr 2022 07:53:49 -0700 Thiago Macieira wrote: > Hello Ilya > > Please explain why we need this API in the first place. If an > application requires a Qt event loop that links to GLib and use > GMainLoop, then they can easily link to glib directly themselves and > access GApplication. So why isn't this an option? > > Is it because it's not a nice, Qt-ish C++ API? Would creating a > library that wraps this and a few other GLib APIs solve this problem? > > Or does it need access to internals in Qt? If so, what ones? Yeah, it needs access to Qt internals for startup notifications (which are required to not to hit WM's focus prevention mechanism). > Or, inversely, does Qt need to do something so GApplication is > accessible? There's no match to "GApplication" in qtbase today. Would > adding this code without a front-end API suffice? The key methods are beforeEmit/afterEmit, they're protected, but there's a problem that it's necessary to run some user code after GApplication construction and before g_application_run as g_application_quit requires re-construction of the GApplication instance to run it again, so it's all in processEvents and setFlags/setConstructedHandler/setFinalizeHandler from public interfaces are required at least. > Have you investigated what happens to existing Qt + GLib hybrid > applications when your code gets added? I don't know any... Do you? > On another note, just what is org.freedesktop.Application? There are > ZERO references to it on freedesktop.org. If this isn't well-defined, > should we adventure into it? If this is a D-Bus API, then the > questions above about accessing the interface and implementing the > server side of it apply: can we have it without a front-end API? It's a part of the Desktop Entry Specification[1]. It's used by most gtk & KDE applications. gtk ones use GApplication, KDE ones use KDBusService. > In fact, if it is a D-Bus API, should we have it even if the GLib > event dispatchers aren't active? Well, the point it's not just org.freedesktop.Application. GApplication also provides multiple notification protocol implementations and integration between them and the o.fd.Application spec (as I mentioned before). It's the main reason I need GApplication as libnotify is really outdated and there's no other alternative (except of KDE libs-dependent KNotifications and implementing all the specs by hand which are not real alternatives IMO). GApplication provides implementations of multiple nice specifications at once and integrates them, so I thought why not to use it when it's available... [1] https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#dbus ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QFreedesktopApplication
On Saturday, 23 April 2022 23:05:58 PDT Ilya Fedin wrote: > Hello, I was asked to write here about QFreedesktopApplication[1]. My main > intention was to get nice GApplication APIs that implement a number of XDG > standarts to be accessble by Qt applications. The main thing is running the > GApplication instance, although I made a number of wrapping APIs to use > org.freedesktop.Application-related APIs without linking to glib for the > application. Handlers for GApplication constructor/destructor, > org.freedesktop.Application handlers, the control of command line > processing by GApplication including its option parser and single instance. > I also made integration with startup notifications and it's possible to add > XDG activation token integration. What is not covered by these wrappers, > but still interesting is > g_application_send_notification/g_application_withdraw_notification, so one > can easily send notification using > org.freedesktop.Notifications/org.freedesktop.portal.Notification/org.gtk.N > otifications without implementing all the APIs by hand. And, moreover, > GNotification is integrated with GApplication/org.freedesktop.Application > and can use its actions. > [1] https://codereview.qt-project.org/c/qt/qtbase/+/407263 Hello Ilya Please explain why we need this API in the first place. If an application requires a Qt event loop that links to GLib and use GMainLoop, then they can easily link to glib directly themselves and access GApplication. So why isn't this an option? Is it because it's not a nice, Qt-ish C++ API? Would creating a library that wraps this and a few other GLib APIs solve this problem? Or does it need access to internals in Qt? If so, what ones? Or, inversely, does Qt need to do something so GApplication is accessible? There's no match to "GApplication" in qtbase today. Would adding this code without a front-end API suffice? Have you investigated what happens to existing Qt + GLib hybrid applications when your code gets added? On another note, just what is org.freedesktop.Application? There are ZERO references to it on freedesktop.org. If this isn't well-defined, should we adventure into it? If this is a D-Bus API, then the questions above about accessing the interface and implementing the server side of it apply: can we have it without a front-end API? In fact, if it is a D-Bus API, should we have it even if the GLib event dispatchers aren't active? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QFreedesktopApplication
Hello, I was asked to write here about QFreedesktopApplication[1]. My main intention was to get nice GApplication APIs that implement a number of XDG standarts to be accessble by Qt applications. The main thing is running the GApplication instance, although I made a number of wrapping APIs to use org.freedesktop.Application-related APIs without linking to glib for the application. Handlers for GApplication constructor/destructor, org.freedesktop.Application handlers, the control of command line processing by GApplication including its option parser and single instance. I also made integration with startup notifications and it's possible to add XDG activation token integration. What is not covered by these wrappers, but still interesting is g_application_send_notification/g_application_withdraw_notification, so one can easily send notification using org.freedesktop.Notifications/org.freedesktop.portal.Notification/org.gtk.Notifications without implementing all the APIs by hand. And, moreover, GNotification is integrated with GApplication/org.freedesktop.Application and can use its actions. I apologize that I send this third time, but I can't find how to switch my mail client in plain text format... Hope it will be OK this time. [1] https://codereview.qt-project.org/c/qt/qtbase/+/407263 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QFreedesktopApplication
Hello, I was asked to write here about QFreedesktopApplication[1]. My main intention was to get nice GApplication APIs that implement a number of XDG standarts to be accessble by Qt applications. The main thing is running the GApplication instance, although I made a number of wrapping APIs to use org.freedesktop.Application-related APIs without linking to glib for the application. Handlers for GApplication constructor/destructor, org.freedesktop.Application handlers, the control of command line processing by GApplication including its option parser and single instance. I also made integration with startup notifications and it's possible to add XDG activation token integration. What is not covered by these wrappers, but still interesting is g_application_send_notification/g_application_withdraw_notification, so one can easily send notification using org.freedesktop.Notifications/org.freedesktop.portal.Notification/org.gtk.Notifications without implementing all the APIs by hand. And, moreover, GNotification is integrated with GApplication/org.freedesktop.Application and can use its actions. [1] https://codereview.qt-project.org/c/qt/qtbase/+/407263___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] QFreedesktopApplication
Hello, I was asked to write here about QFreedesktopApplication[1]. My main intention was to get nice GApplication APIs that implement a number of XDG standarts to be accessble by Qt applications. The main thing is running the GApplication instance, although I made a number of wrapping APIs to use org.freedesktop.Application-related APIs without linking to glib for the application. Handlers for GApplication constructor/destructor, org.freedesktop.Application handlers, the control of command line processing by GApplication including its option parser and single instance. I also made integration with startup notifications and it's possible to add XDG activation token integration. What is not covered by these wrappers, but still interesting is g_application_send_notification/g_application_withdraw_notification, so one can easily send notification using org.freedesktop.Notifications/org.freedesktop.portal.Notification/org.gtk.Notifications without implementing all the APIs by hand. And, moreover, GNotification is integrated with GApplication/org.freedesktop.Application and can use its actions. [1] https://codereview.qt-project.org/c/qt/qtbase/+/407263___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
