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] Policy on updating translatable strings in patch releases
Thanks for the reply. I think barring any other comments I'll go ahead and stage the patch :) Mårten. > -Original Message- > From: Alex Blasche > Sent: fredag 22. april 2022 16:31 > To: Mårten Nordheim ; Development Mailing List > ; localizat...@qt-project.org > Subject: RE: Policy on updating translatable strings in patch releases > > > > -Original Message- > > From: Development On Behalf Of > > Mårten Nordheim > > > I'm wondering about the policy on updating translatable strings in > > patch- releases. > > Our policy, as far as I know, only says that updating these strings > > should not happen for a release after string-freeze. However, recent > > bug-reports[0] have revealed that some changes made in Network > > triggers pre-existing error messages which are wrong given the new code, > causing confusion for users. > > > This is why I am hoping to update and clarify these messages[1]. But > > since they are translatable (and this is long after string-freeze for > > 6.3 and even longer for > > 6.2) I was wondering if we have a policy (formal or informal) in place for > this. > > I don't know of any written down rule stating the exceptions around the > string freeze. This might be due to the very limited impact of such a break. > > > Do we treat situations like this as a bug and make an exception > > (though extra effort will be required for translations in patch > > releases to have Qt fully > > translated) or do we limit such patches to 'dev' only? > > I'd answer this with common sense. The impact of breaking string freeze on > user code is extremely low. English is a rather common language. > If a string change is due to a bug (especially wrong error string) let's go > for > the string freeze break. I think all of us have had applications throwing up > some English error code/description in otherwise translated applications. > > I would not consider it justified as part of a bug where we change a UI > element to have a nicer label or description. Maybe I lack imagination, but I > cannot think of a string freeze break reason other than an error code. > > -- > Alex ___ 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
