search

zjes / lxqt-appswitcher

GNU Lesser General Public License v2.1
5 stars 6 forks source link

Selecting applications on different virtual desktops not working as expected with Openbox and Xfwm #5

Closed pmattern closed 8 years ago

pmattern commented 8 years ago

With "Filter by desktop" disabled in lxqt-config-appswitcher selecting a window located on another virtual desktop doesn't work as expected with Openbox and Xfwm4.

Regarding Openbox the only visible action is the desktop corresponding to the selected window getting highlighted in plugin-desktopswitch but a switch to that other desktop does not take place. Behaviour is depicted in this screenshot lxqt-appswitcher_change-virtual-desktop_plugin-desktopswitch-highlight taken after a window on virtual desktops 2 had been selected by lxqt-appswitcher on virtual desktop 1. Virtual desktop 1 is still the active one as can also be seen from its dark background (compare to 3 and 4). The selected window does get moved to the foreground which gets evident only after switching desktops manually, though. If the window in question had been minimized before it does not get restored, rather its button in plugin-taskbar gets highlighted only like in this screenshot taken on virtual desktop 2 lxqt-appswitcher_change-virtual-desktop_plugin-taskbar-highlight Using Xfwm4 the selected window simply gets moved to the virtual desktop lxqt-appswitcher was invoked on, it does get restored if it had been minimized before. It doesn't matter whether compositing, Compton with Openbox or inherent compositor of Xfwm, is available.

To some degree the behaviour when windows on a different virtual desktop are chosen may be a matter of taste. But as long as it isn't configurable I think switching to the other desktop, restoring the window if minimized and moving the window to the foreground should be the default behaviour. This is the default behaviour of the window switchers of Openbox, KWin and Xfwm4 as well as of lxqt-appswitcher in conjunction with KWin.

Seen running a59993d on up to date Arch Linux x86_64 or i686, hence KWin 5.5.4, Openbox 3.6.1 and Xfwm 4.12.3.

zjes commented 8 years ago

Possible fixed in aa8f871, now i can test it only in openbox. Can you test in other WMs?

pmattern commented 8 years ago

In eda930d both aspects of the problem as depicted above are fixed, both with Openbox and Xfwm, the behaviour of KWin remains the same as far as this issue is concerned.

Unfortunately a regression was introduced - the UI of lxqt-appswitcher may stop displaying. So far I've seen the problem only with Qt browsers, in particular Otter Browser, and Openbox. It doesn't matter wether or not compositing (Compton) is active. Also, it isn't 100% reproducible. The appswitcher itself is still functional as can be seen by applying its keyboard shortcuts blindly. Once it appeared the problem persists until lxqt-appswitcher is launched the next time, no matter wether in the current session or by launching another session. Steps to reproduce working most of the time:

  1. Make sure more than one virtual desktop is available and no windows are opened automatically upon starting an LXQt session. Configure the browser to come up with two distinguishable windows upon launch.
  2. Start a new LXQt session.
  3. Start the browser on virtual desktop one, keep in mind which of the two windows is active but don't do anything else.
  4. Switch to virtual desktop two by clicking in plugin-desktopswitch.
  5. Select the window that had not been active before by running lxqt-appswitcher.
    This will trigger a return to desktop one and the selected window will be in foreground. But the UI of lxqt-appswitcher doesn't come up any longer most of the time.

Sometimes the problem appears at once, sometimes steps 4 and 5 have to be repeated several times, and sometimes it cannot be seen at all...

zjes commented 8 years ago

I'll try to reproduce this. But i have few questions. 1) In d63b3bd was small fix with timer. Maybe it already solve this problem? 2) Can you try to switch to this window tru panel's taskmanager? Result will be same? 3) In eda930d was made that appswitcher with empty apps list doesn't show anymore (before was gray square) Maybe this window have no setted desktop property _NET_WM_DESKTOP? (you can check it with xprop)

pmattern commented 8 years ago

Due to issues with my Arch Linux VMs used so far I had another look at that whole thing on an Arch Linux system running "bare metal" but configured the same otherwise. This is eventually the more helpful approach anyway but revealed some differences. Most importantly the disappearance of LXQt application switcher's UI isn't a regression but can be seen as of a59993d already. Also, it can be seen with all kinds of different windows relying on different widget toolkits. QTerminal, qps, PCManFM-Qt, lxqt-config-sesion, gvim, LibreOffice, Firefox and Chromium were used to test. Looking back QTerminal may not have been the most suitable choice as it happens to have some focussing issues which haven't been tracked down so far. Results in detail

commit Openbox Xfwm KWin
a59993d Selecting a window on another desktop has it lifted to the foreground but a switch to the other desktop does not take place. If the window happens to be minimized it does not get restored, rather, its button in plugin-taskbar gets highlighted only. It doesn't matter wether or not Compton is running. (So same result as in first comment.) Selecting a window on another desktop moves the window to the current one. Same result when the window is minimized, no impact of compositing. (So same result as in first comment.) The "regression" / absence of LXQt application switcher's UI can be seen sporadically when compositing is disabled. Failed to reproduce when exactly it takes place. No impact of window size.
aa8f871 Disappearance of LXQt application switcher's UI as depicted in my previous comment all the time, that is no impact of window size or compositing. Basically correct behaviour / problem of a59993d can no longer be seen. LibreOffice, lxqt-config-session and PCManFM-Qt windows happen to lose focus after being selected. Didn't manage to figure out when exactly this takes place. Same as a59993d.
d63b3bd Disappearance of LXQt application switcher UI takes places less frequently. Otherwise same as aa8f871. Same as aa8f871. Same as a59993d.
1bd3bf2 Same as d63b3bd. Same as aa8f871. Same as a59993d.

If desktops are switched by plugin-desktopswitch and windows by plugin-taskbar only the UI never disappears. According to xprop value of _NET_WM_DESKTOP(CARDINAL) was correctly reflecting the respective virtual desktop's number starting with 0 all the time. When the UI is absent and the usual Alt+Tab gets hit windows that do react to the Tab key behave the same as if the letter gets pressed on its own. This is different when the UI is working normally. I figure things should be pretty easy to reproduce now. Otherweise you may want to let me know which OS you're using so that I can have a look at it, too.

zjes commented 8 years ago

This, maybe, the best test report that I ever seen. :) I will try to discover problem. Thank you. P.S. I use debian testing with qt5.5 and LXQt from master.

pmattern commented 8 years ago

Disappearance of LXQt application switcher's GUI as described above can very well be reproduced with 1bd3bf2 on Debian testing running in a KVM/QEMU virtual machine here, all components except LXQt application switcher from the official repositories.

zjes commented 8 years ago

Yes, I can reporoduce it. This is strange problem. All reports that switcher window is visible, in right position etc. Very strange. I working on it.

zjes commented 8 years ago

Possible fixed in eedf255.

pmattern commented 8 years ago

Problem seems to be fixed in eedf255. For now I looks like this issue can get closed.

zjes commented 8 years ago

Ok. Thank you