Gwenview hangs on startup with Kdeconnect

[dreamersbrow]

Hello,
I have noticed that when I have my phone connected with kdeconnect, gwenview hangs for several seconds before starting. I saw that there has been a bug fix for this here -> https://bugs.kde.org/show_bug.cgi?id=411196 but in comment #27 someone says that Kubuntu 20.04 ships with 19.12 gwenview and that someone would have to request that the Kubuntu team backport the fix into 19.12.

I was wondering how one would go about requesting a backport of this fix?

Thanks for your help.

[GreyGeek]

I have KDEConnect installed on both my Kubuntu 20.04 and my GS10. I had noticed that Gwenview 19.12.3 did take 15-20 seconds to load an image. Either one of the recent updates, and I'm sorry to say I don't know which one, or my purging apport, apparently fixed the problem because when I used Gwenview yesterday the application popped open in under a second, with the image. I also purged kdenlive and installed Blender. KDEConnect communicates perfectly with my GS10.

[dreamersbrow]

Thanks for your response @GreyGeek,

I have my system up-to-date and have masked apport but am still experiencing the hang. If I unpair my phone, images are opened in less than a second. Do you know of a place to request a backport of the fix I mentioned?

[jlittle]

I've been affected by this. Frustrated that the fix is there, but we may not get it till 20.10, I investigated compiling from source. Finding the right repository took a while, but then it was straightforward:

$ sudo apt install build-essential git
$ sudo apt build-dep gwenview
$ git clone https://invent.kde.org/graphics/gwenview.git
$ cd gwenview
$ cmake .
$ make
$ sudo make install

The cmake and make steps did lots, and took a while, giving quite a few warnings. I thought the make install would install to /usr/local, but it overwrote the previous version; make install/local was perhaps what I wanted.

So, now I'm running gwenview 20.07.70, and the hang does not occur. It's still a little bit slow using gwenview to look at images on the phone.

[wonder]

I have the same problem/issue, I have gwenview 19.12 and yes, when I have my phone connect with kde connect, I have the same issue.
I have the backports, but I think I need wait to upgrade gwenview by backports of kubuntu...

At the moment, I go to try the solution indicate @jlittle, because at the moment, my only solution is: Disconnect my phone from kdeconnect, and when need kdeconnect, connect my phone.

Until I have this problem, some upgrades was solved the issue, but other upgrades (or updates) return this issue in gwenview.

Today, at day today, kubuntu 20.04 with backports, gwenview and kde connect have this issue.

Regards.

[GreyGeek]

The one thing that can make an app on Kubuntu "appear" to hang is that when it accesses the smartphone (GS10 in my case) a dialog on the phone asked if I want to allow the connection or not. The problem is that the dialog does not pop over and can remain hidden with no indication that it is awaiting a reply. Even if you've previously connected your phone and KDEconnect is paired to your phone that dialog request appears the first time you connect for the current day. It may be that Dolphin or KDEconnect is timing out waiting for a response from the dialog request on the smartphone.

[wonder]

But in this case, the application on my phone (in my case, an HTC u11) has all the permissions and its "modus operantis" is exactly the same (gwenview and kde connect) as when I was using kubuntu 18.04, which, there was not this problem.
Coincidentally the other day, a friend of mine, who knows that I only use kubuntu, and therefore, kde, told me that he had this same problem, if I knew anything, I said yes.
He doesn't use kubuntu, he uses fedora.
Since installing kubuntu 20.04 I have had this problem, and once I solved it (or so I thought) changing the composer from opengl 3.1 to 2.0, it was automatically solved, if I went back to opengl 3.1 the problem continued.
Then the problem returned, and the composer opengl theme had nothing to do with it.
I don't know where the cause may be, but if I have my mobile paired to kde connect, even though I had my phone turned off, gwenview suffers from this problem, my only solution is to unlink it.

Until I have this problem, some upgrades was solved the issue, but other upgrades (or updates) return this issue in gwenview.

Today, at day today, kubuntu 20.04 with backports, gwenview and kde connect have this issue.

Regards.

[wonder]

I've been affected by this. Frustrated that the fix is there, but we may not get it till 20.10, I investigated compiling from source. Finding the right repository took a while, but then it was straightforward:

$ sudo apt install build-essential git
$ sudo apt build-dep gwenview
$ git clone https://invent.kde.org/graphics/gwenview.git
$ cd gwenview
$ cmake .
$ make
$ sudo make install

The cmake and make steps did lots, and took a while, giving quite a few warnings. I thought the make install would install to /usr/local, but it overwrote the previous version; make install/local was perhaps what I wanted.

So, now I'm running gwenview 20.07.70, and the hang does not occur. It's still a little bit slow using gwenview to look at images on the phone.

A "stupid doubt";
With this update, are installed overwrote the previous version, ok, when received a update by backports (for example) this new version are update?

[jlittle]

A "stupid doubt";
With this update, are installed overwrote the previous version, ok, when received a update by backports (for example) this new version are update?

Your doubts are quite reasonable. Using btrfs, I've developed the bad habit of plunging ahead, a damn the consequences attitude, because I can back out changes in a minute or two. I expected the usual cmake default of /usr/local to be used, but it used /usr and overwrote the Kubuntu 20.04 version. It was ok, so I didn't bother to back it out. I had to use Stack Overflow to brush up on cmake, and I'd now suggest changing the cmake line to

$ cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr/local .

(I am assuming /usr/local/bin is in your $PATH; that's the *buntu default.) Then the 20.04 version is still there, and you can run it using /usr/bin/gwenview if you like, and sudo make uninstall will remove the new version.

I also suggest using the -j switch to make, with the number of threads your processor can run; I use make -j8. This reduces the compile time drastically, from over 5 minutes to 1¼ minutes on my computer.

[wonder]

Thanks for your reply !

Your doubts are quite reasonable. Using btrfs, I've developed the bad habit of plunging ahead, a damn the consequences attitude, because I can back out changes in a minute or two. I expected the usual cmake default of /usr/local to be used, but it used /usr and overwrote the Kubuntu 20.04 version. It was ok, so I didn't bother to back it out. I had to use Stack Overflow to brush up on cmake, and I'd now suggest changing the cmake line to

$ cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr/local .

Humm... BTRFS I don't use, but I think in use this...btrfs usage more resources? (but this question, is better in other thread )
In your case, was used /usr and overwrote the Kubuntu 20.04 version, in this case, when arrives a update of this version, at you enter this update and update the version?
Is this that I wan, install this new version for can use gwenview and kde connect, and when arrive the new version via backports or kubuntu bakports, update this new version.

(I am assuming /usr/local/bin is in your $PATH; that's the *buntu default.) Then the 20.04 version is still there, and you can run it using /usr/bin/gwenview if you like, and sudo make uninstall will remove the new version.

Yes, I don't change any about the default, but if I go to /usr/local/bin are empty. In /usr/bin are all applications.
Like you suggest, I made with /usr/local.

I also suggest using the -j switch to make, with the number of threads your processor can run; I use make -j8. This reduces the compile time drastically, from over 5 minutes to 1¼ minutes on my computer.

Thanks for this !