Feature request: Bring main window to front when opening new PDF

Hello Jürgen,

can you be more specific about the version of qpdfview you are using? Is it version 0.3.1 from the Debian or Ubuntu repositories? The reason for asking is that this should be implemented in later versions and if qpdfview's windows is not activated that we need known which window manager you are using to diagnose the problem. (Using X11, a program can only request to get its window into the foreground, the window manager decides whether this will happen or not.)

Best regards, Adam.

Hi Adam,

Thanks for getting back on this so quickly.

I used 0.4.3 until yesterday and upgraded to 0.4.6 this morning right before reporting this issue. I was wondering if it was already "fixed" or implemented by chance.

Since it still doesn't work on my platform it may have to do with the environment. I'm using Ubuntu 13.10 on my latop and haven't changed any of the core components. Just added more applications over time.

How can I provide you with more details? Please let me know and I'll do my best.

Yours
Jürgen

Hello again,

I am redirecting Benjamin's answer here for Jürgen's benefit. I agree
that it is probably not the packages. But we also did not touch that
particular functionality for a long time as well, so I wonder whether
something else in Debian's stack changed that we have to adapt to.

Just to make sure, can anyone not running Debian or Ubuntu or any of its
derivatives confirm this? If so, it should definitely become a bug
report, possibly blocking the release of version 0.4.7.

Best regards, Adam.

P.S.: Background is that I can not reproduce this running the daily
builds in openSUSE 12.3/KDE and Arch/Xfce...

Am 13.11.2013 22:26, schrieb Benjamin Eltzner:
> Hi,
>
> I can confirm Jürgen's observation with the newest dailydeb on Ubuntu
> 12.04 as well es Debian unstable with KDE 4.11. In KDE the window icon
> will flash to sign activity but the window will in both cases not by
> brought to the front. When running with --unique from the command
> line, there are no messages but the window behaves exactly the same.
>
> (In KDE a very funny effect can be seen, where clicking on the second
> file will lead to the bouncy "loading cursor" and a task called
> "qpdfview" in the task bar appearing and staying for some 5 seconds,
> all the while causing some 20% CPU activity. I could not investigate
> that in detail yet, but I will keep you posted.)
>
> As I did not apply any patches in the more recent versions of the
> packages, I do not think that the problem stems from the packages.
>
> Cheers,
> Benjamin
>
>
> Am 13.11.2013 21:17, schrieb Adam Reichold:
>> Hello again,
>
>> things will be complicated from here on as I currently don't have
>> access to a machine running Ubuntu. I am hoping that our resident
>> Debian/Ubuntu expert Benjamin Eltzner will read this via the
>> mailing list and will hopefully a more substantial idea...
>
>> Since the documents are opened, meaning D-Bus integration seems to
>> work, I can only recommend to double check any window manager
>> settings concerning focus and arrangement. Other than that, I don't
>> have a clue.
>
>> More information could possibly be obtained by running the program
>> from the command-line (using the "--unique" option) and looking for
>> any diagnostic messages.
>
>> Sorry and regards, Adam.
>
>> Am 13.11.2013 20:31, schrieb Jürgen Haas:
>>> Question #239147 on qpdfview changed:
>>> https://answers.launchpad.net/qpdfview/+question/239147
>>>
>>> Status: Needs information => Open
>>>
>>> Jürgen Haas gave more information on the question: Hi Adam,
>>>
>>> Thanks for getting back on this so quickly.
>>>
>>> I used 0.4.3 until yesterday and upgraded to 0.4.6 this morning
>>> right before reporting this issue. I was wondering if it was
>>> already "fixed" or implemented by chance.
>>>
>>> Since it still doesn't work on my platform it may have to do with
>>> the environment. I'm using Ubuntu 13.10 on my latop and haven't
>>> changed any of the core components. Just added more applications
>>> over time.
>>>
>>> How can I provide you with more details? Please let me know and
>>> I'll do my best.
>>>
>>> Yours Jürgen
>>>
>
>
>

Hello again,

if nobody could reproduce this outside of Debian/Ubuntu (instead just nobody trying), I'd argue that it is an issue specific to Debian and kin, nevertheless it needs to be resolved.

Since the window is "blinking", I suppose the activation part of raising and activation works and just the raising action is ineffective. Benjamin, since you can reproduce it, could try to debug into the method "MainWindowAdaptor::raiseAndActivate" at line 2347 of "mainwindow.cpp"? Just to make sure it is called and maybe check if the order raising and activating is somehow important or anything? If you find the time but need any help with this, please contact me via Jabber.

Best regards, Adam.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I now observed random occurance of similar bugs for some but not all
other programs in Debian unstable with KDE 4.11. For qpdfview, the
first document that is opened brings the (new) window to the front,
the second makes it blink while the third and all following documents
do not effect any reaction.

Cheers,
Benjamin

On 16.11.2013 07:56, Adam Reichold wrote:
> Question #239147 on qpdfview changed:
> https://answers.launchpad.net/qpdfview/+question/239147
>
> Adam Reichold posted a new comment: Hello again,
>
> if nobody could reproduce this outside of Debian/Ubuntu (instead
> just nobody trying), I'd argue that it is an issue specific to
> Debian and kin, nevertheless it needs to be resolved.
>
> Since the window is "blinking", I suppose the activation part of
> raising and activation works and just the raising action is
> ineffective. Benjamin, since you can reproduce it, could try to
> debug into the method "MainWindowAdaptor::raiseAndActivate" at line
> 2347 of "mainwindow.cpp"? Just to make sure it is called and maybe
> check if the order raising and activating is somehow important or
> anything? If you find the time but need any help with this, please
> contact me via Jabber.
>
> Best regards, Adam.
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBAgAGBQJShypnAAoJEK27BRz67lmpOYAQAJHBmpxHuwNg+9A2d21qJjgr
A8cAFwHJ2DPNhx3GSKP4fNZO4kKbvREv2fRwGuW5vJwvXBKyJSvELIiGn/p8sGsV
vGhYhPfAJa3jcbELyERLBSHcpyceHmA8ahtToIaPkYQD7pbhU+wEPSYuGK+o+uA2
r1SeKlZRtgV1KA9knGF7P+b2YzyGhgGVJiiGzGEybVdqejxgChtEkhc1vzUEmyXS
S8OYzxVU6BCuHiN6HhrpEvsoykhcjJBDrZQKKntRsAOCl8WqIq2enljYb9Lqb1tU
EV7iCQXTU0cYr/xOyu+uw9o9bAemH5Qik2RMi8SGBA3vukTV7feQUX1DAFdsiYJd
D4MXAS620kWo6XveLzPP/4bliOPJLvTaUalVZ9FgTyOxbVFjXXe5Bn8VT/K8pI6e
yeTHjR7nHLYXUgAwdoH2FNY/k4oV0NweZoufaHv9HYvEufaxrzvCvHD5zaVKzDUS
AmM90lce7F3Mwq9Afex0MKqrn9RF1awNPHLeP1AArdw1rFUknJiZCSyWxuhmLGhH
gpjhp8KxEI7f0Y559lCRCo7OBD7FGs8C7PjCa8els3moiIy9hXfiOuQw+cQllBgO
Mcr7tCLezI42iIAnlfRdlTMmu03f8VoHdlWR4wg0eDwiXOqE6/wZU8be6QBEJmd9
hDiOwj+41/4yeQlCeNe2
=vTBc
-----END PGP SIGNATURE-----

Ok, so do I understand you correctly, that it probably isn't a
qpdfview-specific issue and I should not try to change the code before
the underlying problem is known? (And hold back on version 0.4.7...)

Am 16.11.2013 09:18, schrieb Benjamin Eltzner:
> Hi,
>
> I now observed random occurance of similar bugs for some but not
> all other programs in Debian unstable with KDE 4.11. For qpdfview,
> the first document that is opened brings the (new) window to the
> front, the second makes it blink while the third and all following
> documents do not effect any reaction.
>
> Cheers, Benjamin
>
>
> On 16.11.2013 07:56, Adam Reichold wrote:
>> Question #239147 on qpdfview changed:
>> https://answers.launchpad.net/qpdfview/+question/239147
>
>> Adam Reichold posted a new comment: Hello again,
>
>> if nobody could reproduce this outside of Debian/Ubuntu (instead
>> just nobody trying), I'd argue that it is an issue specific to
>> Debian and kin, nevertheless it needs to be resolved.
>
>> Since the window is "blinking", I suppose the activation part of
>> raising and activation works and just the raising action is
>> ineffective. Benjamin, since you can reproduce it, could try to
>> debug into the method "MainWindowAdaptor::raiseAndActivate" at
>> line 2347 of "mainwindow.cpp"? Just to make sure it is called and
>> maybe check if the order raising and activating is somehow
>> important or anything? If you find the time but need any help
>> with this, please contact me via Jabber.
>
>> Best regards, Adam.
>
>
>

> Ok, so do I understand you correctly, that it probably isn't a
> qpdfview-specific issue

It certainly looks like that to me but I could be mistaken, of course.

> and I should not try to change the code before
> the underlying problem is known? (And hold back on version 0.4.7...)

I do not think it does any harm if you go through the code and look for
potential problems. However, in my opinion this should not be a blocker
for 0.4.7 unless somebody confirms the problem for a non-debianish system.

As a further peculiarity i would like to add the observation that for
qpdfview 0.4.6 on debian testing with XFCE the window is brought to the
front as intended. As Jürgen claims to have the problem with version
0.4.6 and not daily builds, a regression can probably be ruled out.
Instead the problem seems to be present in Debian's KDE stack and
Ubuntu's Unity stack while absent in Debian's XFCE stack. Does that make
any sense at all?

Cheers, Benjamin

Let me add some details from my end:

I have update to the beta version 0.4.7beta1 and still have the same issue. With this I can confirm what Benjamin reported on Nov-16:

> ... For qpdfview, the
> first document that is opened brings the (new) window to the front,
> the second makes it blink while the third and all following documents
> do not effect any reaction.

This is exactly what I can see on my system.

As it was mentioned somewhere in the thread, I just went through another test with LibreOffice and tried the behaviour there. Office is just always activating the main window when ever there is a new document opened through a double click on a document. Not sure if that helps for the analysis of this problem, but I thought it's worth mentioning.

Jürgen

To add to this, I've had the same problem running Elementary OS 0.2 (based on Ubuntu 12.04). I think it's an issue with how QT interacts with certain window managers; a quick Google suggests other people have had the same problem. Unfortunately, I couldn't fix it by adding any of the suggested work-arounds to MainWindowAdaptor::raiseAndActivate().

The problem could probably be fixed by calling X11 directly -- xdotool has no problem activating the qpdfview window -- but I don't know if it's possible to fix it within QT.

To follow up, the issue is due to what window managers call "focus stealing prevention" -- essentially, when an application requests focus from the background, the WM refuses. Using xdotool solves this by talking to X directly, but I'm don't know if that's a good idea in general?

Interfacing with X11 directly is probably a possibility to force the issue, but I would prefer not to take that route since it makes platform integration more complicated, especially as Qt5 tries hard to isolate applications from the underlying windowing system, and it also sounds like breaking the windows manager's focus stealing prevention in the first place. If the user (or his window manager if it is not configurable in that regard) decides not to let applications steal the focus this way, then we should not do that, shouldn't we? Phrased differently, does your window manager have such a setting and which effect does it have if you disable focus stealing prevention?

Yeah, that was my thought too. I couldn't find a setting to turn off focus stealing prevention in Elementary 0.2, but the new release 0.3 is based on Ubuntu 14.04, and the problem seems to be fixed there; it's probably a WM bug rather than anything to do with qpdfview.

I am still seeing this behavior in Ubuntu 18.04 with QPDFView version 0.4.14, where the window doesn't steal the focus, if you open another PDF document.

I am still seeing this behavior in Ubuntu 20.04 native with QPDFView 0.4.18, where opening a document doesn't bring QPDFView into focus.