Re: kdereview - xdg-desktop-portal-kde

2017-05-05 Thread Elvis Angelaccio 
On mercoledì 3 maggio 2017 13:11:26 CEST Jan Grulich wrote:
> On středa 3. května 2017 11:28:45 CEST Elvis Angelaccio wrote:
> > On mercoledì 3 maggio 2017 07:00:14 CEST Jan Grulich wrote:
> > > > > > > Do you have xdg-desktop-portal installed?
> > > > > > 
> > > > > > Yes.
> > > > > 
> > > > > Make sure that xdg-desktop-portal is running, it should be started
> > > > > automatically by flatpak, but you never know.
> > > > 
> > > > How do I check it? Is it a process that I should see?
> > > > 
> > > > > Also try to run xdg-desktop-
> > > > > portal-kde with debug enabled using:
> > > > > QT_LOGGING_RULES=xdg-desktop-portal-kde*.debug=true
> > > > > /path/to/xdg-desktop-
> > > > > portal-kde.
> > > > 
> > > > This just prints "Desktop portal registered successfuly", which I
> > > > guess
> > > > is
> > > > ok.
> > > > 
> > > > As soon as the test app freezes (instead of opening the file dialog),
> > > > I
> > > > get
> > > > this in my journalctl: https://paste.kde.org/phcnn4uxn
> > > 
> > > I guess you have to make sure that xdg-desktop-portal-kde is installed
> > > to
> > > correct location. I have it in:
> > > -
> > > /usr/share/dbus-1/services/org.freedesktop.impl.portal.desktop.kde.servi
> > > c
> > > e - /usr/share/xdg- desktop-portal/portals/kde.portal -
> > > /usr/libexec/xdg-desktop-portal-kde
> > > 
> > > 
> > > I guess based on the log that the dbus service is important to have in
> > > correct place.
> > 
> > Thanks, this helped a bit. I had a relative path in the Exec entry of the
> > .service file. Using an absolute path fixes the file dialogs, though I
> > still don't get native notifications.
> 
> Any debug output from xdg-desktop-portal-kde or xdg-desktop-portal?

Nevermind, I reinstalled my kde runtime and now notifications work fine...

Speaking of notifications, in notification.cpp I noticed:

// TODO KNotification has no option for default action

but that's no longer true as of KNotifications 5.31: https://cgit.kde.org/
knotifications.git/commit/?id=8b161b971fae41e60a2d8093843c3fbae2429c07

Other than that, looks good to me :)

Cheers,
Elvis

> 
> > Btw it seems archlinux is using /usr/lib rather than /usr/libexec (the
> > gnome portal installs /usr/lib/xdg-desktop-portal-gtk).
> > 
> > > > > > >> Another thing, shouldn't we renamed it to
> > > > > > >> xdg-desktop-portal-plasma?
> > > > > > >> (at least the repository/package, which is what the end user is
> > > > > > >> going
> > > > > > >> to install).
> > > > > > > 
> > > > > > > Not sure, gnome folks use xdg-desktop-portal-gtk because it's
> > > > > > > only
> > > > > > > gtk
> > > > > > > related and not tied to Gnome, but we use both Qt and KDE
> > > > > > > Frameworks
> > > > > > > so
> > > > > > > I
> > > > > > > decided to go for xdg-desktop-portal-kde, there is nothing
> > > > > > > really
> > > > > > > Plasma
> > > > > > > specific.
> > > > > > 
> > > > > > The point is to integrate flatpak Qt applications with Plasma, no?
> > > > > > (plasma file picker, plasma notifications, etc.)
> > > > > > Or I can use this portal also to integrate a Qt application with,
> > > > > > say,
> > > > > > LXQt?>

How to launch .desktop files properly?

2017-05-05 Thread Lubos Lunak 

 Hello,

 specifically in this case, how should ksmserver properly launch autostart 
apps, when they are specified by their .desktop files?

 When the autostart launching code was moved from klauncher to ksmserver by 
[1], it replaced the launching by simply using QProcess, which caused a 
number of problems such as not parsing the Exec line properly (fixed by [2]), 
ksmserver discarded all stderr of launched apps instead of them going to 
~/.xsession-errors, and launched apps getting killed by SIGPIPE under 
specific circumstances. I got bitten by these and simply fixed it with [3] by 
using KRun::runApplication(), as AFAIK that is the proper way to launch 
something using a .desktop file. Seeing that others had these problems as 
well (the bugreports mentioned in the commit message for [3]), I backported 
it after some time. And, after 5.9.5 got out, bug #379254 ([4]) has been 
reported, about desktop startup taking too long. It turns out that some 
distros ship broken autostart .desktop files, KRun shows a blocking error 
dialog (under ksplash) and that blocks the whole startup. To make this even 
worse, it's not very obvious why the error shows up, and even if it were, 
kcm_autostart actually completely ignores global autostart files.

 Now, does somebody know how this should be done properly? QProcess has poor 
defaults for fire-and-forget launching of apps (bye-bye stderr, hello 
SIGPIPE). KProcess is better, but there's still a lot of what KRun/klauncher 
do that would need to be copy: All the .desktop file parsing and 
KProcess setting up, kdeinit, KAuthorized, X-KDE-RunOnDiscreteGpu. Not that I 
know if all of this matters much nowadays, but if it wasn't needed, then why 
KRun still does it, and one way or another all the manual setup would be 
lame. I've also looked at KToolInvocation::startServiceByDesktopPath(), which 
talks to klauncher directly, but there I'm not sure what the status with 
klauncher is (I mean, if the autostart code hadn't been moved, there wouldn't 
be any of this), and also while the function is technically not deprecated, 
its documentation has @deprecated suggesting to use QProcess (ugh) or KRun.

 So I guess that leaves KRun and just making sure it optionally doesn't show 
the blocking dialog, such as adding "QString* error = nullptr"? Or does 
somebody have a better idea? And if not, is it ok to just commit this change 
to kio repository, or are there nowadays any special rules for library 
commits now that there are zillion git repos?


[1] 
https://cgit.kde.org/plasma-workspace.git/commit/ksmserver?id=d9883511c92e448b3441d994170fa1d43eea4ff2
[2] 
https://cgit.kde.org/plasma-workspace.git/commit/ksmserver?id=889be45e893425273d545a73edc42c4bbead446d
[3] 
https://cgit.kde.org/plasma-workspace.git/commit/ksmserver?id=0377d6a992725e0b0b469b87d17343fa3730b829
[4] https://bugs.kde.org/show_bug.cgi?id=379254

-- 
 Lubos Lunak

Re: kdereview - xdg-desktop-portal-kde

2017-05-05 Thread Elvis Angelaccio 
On mercoledì 3 maggio 2017 07:00:14 CEST Jan Grulich wrote:

> > > > > 
> > > > > Do you have xdg-desktop-portal installed?
> > > > 
> > > > Yes.
> > > 
> > > Make sure that xdg-desktop-portal is running, it should be started
> > > automatically by flatpak, but you never know.
> > 
> > How do I check it? Is it a process that I should see?
> > 
> > > Also try to run xdg-desktop-
> > > portal-kde with debug enabled using:
> > > QT_LOGGING_RULES=xdg-desktop-portal-kde*.debug=true
> > > /path/to/xdg-desktop-
> > > portal-kde.
> > 
> > This just prints "Desktop portal registered successfuly", which I guess is
> > ok.
> > 
> > As soon as the test app freezes (instead of opening the file dialog), I
> > get
> > this in my journalctl: https://paste.kde.org/phcnn4uxn
> 
> I guess you have to make sure that xdg-desktop-portal-kde is installed to
> correct location. I have it in:
> - /usr/share/dbus-1/services/org.freedesktop.impl.portal.desktop.kde.service
> - /usr/share/xdg- desktop-portal/portals/kde.portal -
> /usr/libexec/xdg-desktop-portal-kde
> 
> 
> I guess based on the log that the dbus service is important to have in
> correct place.

Thanks, this helped a bit. I had a relative path in the Exec entry of the 
.service file. Using an absolute path fixes the file dialogs, though I still 
don't get native notifications.

Btw it seems archlinux is using /usr/lib rather than /usr/libexec (the gnome 
portal installs /usr/lib/xdg-desktop-portal-gtk).


> > > > >> Another thing, shouldn't we renamed it to
> > > > >> xdg-desktop-portal-plasma?
> > > > >> (at least the repository/package, which is what the end user is
> > > > >> going
> > > > >> to install).
> > > > > 
> > > > > Not sure, gnome folks use xdg-desktop-portal-gtk because it's only
> > > > > gtk
> > > > > related and not tied to Gnome, but we use both Qt and KDE Frameworks
> > > > > so
> > > > > I
> > > > > decided to go for xdg-desktop-portal-kde, there is nothing really
> > > > > Plasma
> > > > > specific.
> > > > 
> > > > The point is to integrate flatpak Qt applications with Plasma, no?
> > > > (plasma file picker, plasma notifications, etc.)
> > > > Or I can use this portal also to integrate a Qt application with, say,
> > > > LXQt?>
> > > > 
> > > > > Jan
> > > > 
> > > > Elvis

kde-open5 bug help needed

2017-05-05 Thread Andrea Scarpino 
Hi all,

I hit a bug[1][2] in kde-open5 when using
QDesktopServices::openUrl(myUrl) to open the system browser.

The issue is that, since myUrl redirects to another page, kde-open5
(used under the hood by QDesktopServices because
XDG_CURRENT_DESKTOP=KDE is set) "fetches" the redirection url and then
open the browser at the redirected url; for my workflow this is bad
because myUrl generate a cookie and then you have no such cookie when
the browser starts.

I debugged the flow and I understood that since
redirectionHandlingEnabled is enabled by default, this[3] statement in
transferjob.cpp handles the redirection.
Then I disabled the redirection in krun.cpp[4] (invoked under the hood
by kde-open5), but this broke kde-open5 because it "never ends", but
instead waits for some event.
I suspect foundMimeType() should be call (which is triggered when
mimetype signal is emitted[5], but with
redirectionHandlingEnabled=false this switch case[6] is never
triggered and then mimetype signal isn't emit.

What should be the workflow without redirection? Any KIO hacker out there? :-)

I'm also on #kde-devel.

Thank you!

[1] https://bugs.kde.org/show_bug.cgi?id=354246
[2] https://bugs.kde.org/show_bug.cgi?id=364662
[3] https://cgit.kde.org/kio.git/tree/src/core/transferjob.cpp#n114
[4] https://cgit.kde.org/kio.git/tree/src/widgets/krun.cpp#n1147
[5] https://cgit.kde.org/kio.git/tree/src/widgets/krun.cpp#n1151
[6] https://cgit.kde.org/kio.git/tree/src/core/slaveinterface.cpp#n250

-- 
Andrea

Re: kdereview - xdg-desktop-portal-kde

2017-05-05 Thread Elvis Angelaccio 
On martedì 2 maggio 2017 17:26:41 CEST Jan Grulich wrote:
> On úterý 2. května 2017 15:22:23 CEST Elvis Angelaccio wrote:
> > On Tue, May 2, 2017 at 3:09 PM, Jan Grulich  wrote:
> > > On úterý 2. května 2017 14:19:04 CEST Elvis Angelaccio wrote:
> > >> On Tue, May 2, 2017 at 12:36 PM, Jan Grulich  
wrote:
> > >> > On úterý 2. května 2017 12:21:31 CEST Aleix Pol wrote:
> > >> >> On Tue, May 2, 2017 at 12:15 PM, Albert Astals Cid 
> 
> wrote:
> > >> >> > El dimarts, 2 de maig de 2017, a les 7:22:04 CEST, Jan Grulich va
> > >> > 
> > >> > escriure:
> > >> >> >> On pondělí 1. května 2017 22:59:44 CEST Albert Astals Cid wrote:
> > >> >> >> > El divendres, 21 d’abril de 2017, a les 8:10:36 CEST, Jan
> > >> >> >> > Grulich
> > >> >> >> > va
> > >> >> >> 
> > >> >> >> escriure:
> > >> >> >> > > Hi,
> > >> >> >> > > 
> > >> >> >> > > I would like to request review of xdg-desktop-portal-kde [1].
> > >> >> >> > > We
> > >> >> >> > > would
> > >> >> >> > > like
> > >> >> >> > > to make it part of Plasma releases, see [2].
> > >> >> >> > > 
> > >> >> >> > > What is xdg-desktop-portal-kde:
> > >> >> >> > > It's a KDE implementation of Flatpak portals backend [3],
> > >> >> >> > > currently
> > >> >> >> > > with
> > >> >> >> > > support of AppChooser, FileChooser, Notification and Print
> > >> >> >> > > portals.
> > >> >> >> > > 
> > >> >> >> > > One mentioned issue on plasma-devel mailing list was usage of
> > >> >> >> > > Qt's
> > >> >> >> > > private
> > >> >> >> > > print API. This will most likely go away if I find out it's
> > >> >> >> > > useless,
> > >> >> >> > > otherwise I'll have to keep it as it's used to set CUPS
> > >> >> >> > > properties
> > >> >> >> > > which
> > >> >> >> > > are not available to the outside world.
> > >> 
> > >> Hi, doesn't seem to work here. If I click Open in your test app I get:
> > >> 
> > >> qt.qpa.qflatpakplatform.FileDialog: File dialog: selectedNameFilter()
> > >> qt.qpa.qflatpakplatform.FileDialog: File dialog: selectedFiles()
> > >> qt.qpa.qflatpakplatform.FileDialog: File dialog: show()
> > >> qt.qpa.qflatpakplatform.FileDialog: File dialog: initializeDialog()
> > >> qt.qpa.qflatpakplatform.FileDialog: Initial values:
> > >> qt.qpa.qflatpakplatform.FileDialog:Multiple files:  true
> > >> qt.qpa.qflatpakplatform.FileDialog:  Accept label:  "Open
> > >> (portal)"
> > >> qt.qpa.qflatpakplatform.FileDialog:   Window title:  "Flatpak
> > >> test - open dialog"
> > >> qt.qpa.qflatpakplatform.FileDialog: Save/Open:  Open
> > >> qt.qpa.qflatpakplatform.FileDialog:  Name filters:  ("plain
> > >> text document (*.txt *.asc *,v *.doc)", "PNG image (*.png)")
> > >> qt.qpa.qflatpakplatform.FileDialog: MimeTypes filters:
> > >> ("text/plain", "image/png")
> > >> qt.qpa.qflatpakplatform.FileDialog: Initial directory:
> > >> "file:///home/elvis" qt.qpa.qflatpakplatform.FileDialog: File dialog:
> > >> exec()
> > >> qt.qpa.qflatpakplatform.FileDialog: Couldn't get reply
> > >> qt.qpa.qflatpakplatform.FileDialog: Error:  "Did not receive a reply.
> > >> Possible causes include: the remote application did not send a reply,
> > >> the message bus security policy blocked the reply, the reply timeout
> > >> expired, or the network connection was broken."
> > >> 
> > >> but I don't see any file dialog (the app just freezes). Not sure if
> > >> related, but I also have xdg-desktop-portal-gtk installed.
> > > 
> > > Do you have xdg-desktop-portal installed?
> > 
> > Yes.
> 
> Make sure that xdg-desktop-portal is running, it should be started
> automatically by flatpak, but you never know. 

How do I check it? Is it a process that I should see?

> Also try to run xdg-desktop-
> portal-kde with debug enabled using:
> QT_LOGGING_RULES=xdg-desktop-portal-kde*.debug=true /path/to/xdg-desktop-
> portal-kde.

This just prints "Desktop portal registered successfuly", which I guess is ok.

As soon as the test app freezes (instead of opening the file dialog), I get 
this in my journalctl: https://paste.kde.org/phcnn4uxn

> 
> > >> Another thing, shouldn't we renamed it to xdg-desktop-portal-plasma?
> > >> (at least the repository/package, which is what the end user is going
> > >> to install).
> > > 
> > > Not sure, gnome folks use xdg-desktop-portal-gtk because it's only gtk
> > > related and not tied to Gnome, but we use both Qt and KDE Frameworks so
> > > I
> > > decided to go for xdg-desktop-portal-kde, there is nothing really Plasma
> > > specific.
> > 
> > The point is to integrate flatpak Qt applications with Plasma, no?
> > (plasma file picker, plasma notifications, etc.)
> > Or I can use this portal also to integrate a Qt application with, say,
> > LXQt?> 
> > > Jan
> > 
> > Elvis