Onboard sometimes moves to off-screen position when switching desktops.

Bug #1092166 reported by marmuta
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Onboard
Fix Released
Undecided
Unassigned

Bug Description

From Question #217025:

Hi. I made the following script (assigned to an easystroke movement) to show onboard 0.98 in my current desktop:

dbus-send --type=method_call --dest=org.onboard.Onboard /org/onboard/Onboard/Keyboard org.onboard.Onboard.Keyboard.Hide
dbus-send --type=method_call --dest=org.onboard.Onboard /org/onboard/Onboard/Keyboard org.onboard.Onboard.Keyboard.Show

...

For example, if onboard is unhidden in Desktop 1 and I call my script in Desktop 2, I expect that onboard hides in Desktop 1 and unhides in Desktop 2. That worked fine in onboard 0.98, but it doesn't work in 0.99 (onboard 0.99 remains unhidden in Desktop 1 and hidden in Desktop 2).

Revision history for this message
marmuta (marmuta) wrote :

Hmm, perhaps not a bug after all. I've tried to reproduce with docking off, force-to top off and sticky bit off. Then after switching desktop, it doesn't seem too strange that the keyboard sits somewhere out of view, i.e. off-screen. Need more information.

Revision history for this message
David López (david-lopez-upct) wrote :

My desktop is 1366x768, and I have a 50px bar at the top of the screen, and 20px margins at left and right sides.

# gsettings list-recursively org.onboard.window

org.onboard.window background-transparency 92.0
org.onboard.window docking-edge 'bottom'
org.onboard.window docking-enabled true
org.onboard.window docking-shrink-workarea true
org.onboard.window enable-inactive-transparency true
org.onboard.window force-to-top false
org.onboard.window inactive-transparency 87.0
org.onboard.window inactive-transparency-delay 1.0
org.onboard.window keep-aspect-ratio false
org.onboard.window resize-handles ''
org.onboard.window transparency 64.0
org.onboard.window transparent-background false
org.onboard.window window-decoration false
org.onboard.window window-state-sticky false
org.onboard.window.landscape dock-expand true
org.onboard.window.landscape dock-height 295
org.onboard.window.landscape dock-width 700
org.onboard.window.landscape height 292
org.onboard.window.landscape width 1325
org.onboard.window.landscape x 19
org.onboard.window.landscape y 474
org.onboard.window.portrait dock-expand true
org.onboard.window.portrait dock-height 200
org.onboard.window.portrait dock-width 600
org.onboard.window.portrait height 200
org.onboard.window.portrait width 600
org.onboard.window.portrait x 100
org.onboard.window.portrait y 50

Revision history for this message
marmuta (marmuta) wrote :

Thanks David, I was about to look into this bug again, but I can't reproduce it anymore. I've fixed a couple of loosely related issues today and those fixes apparently helped with this bug too. Whenever you find the time please try trunk and let me know how it goes.

Changed in onboard:
status: New → Fix Committed
Revision history for this message
David López (david-lopez-upct) wrote :

I've just build trunk 1222 and I'm afraid I can't see any difference in this bug

# gsettings list-recursively org.onboard.window
org.onboard.window background-transparency 92.0
org.onboard.window docking-edge 'bottom'
org.onboard.window docking-enabled false
org.onboard.window docking-shrink-workarea true
org.onboard.window enable-inactive-transparency true
org.onboard.window force-to-top false
org.onboard.window inactive-transparency 87.0
org.onboard.window inactive-transparency-delay 1.0
org.onboard.window keep-aspect-ratio false
org.onboard.window resize-handles ''
org.onboard.window transparency 64.0
org.onboard.window transparent-background false
org.onboard.window window-decoration false
org.onboard.window window-state-sticky false
org.onboard.window.landscape dock-expand true
org.onboard.window.landscape dock-height 295
org.onboard.window.landscape dock-width 700
org.onboard.window.landscape height 292
org.onboard.window.landscape width 1325
org.onboard.window.landscape x 19
org.onboard.window.landscape y 474
org.onboard.window.portrait dock-expand true
org.onboard.window.portrait dock-height 200
org.onboard.window.portrait dock-width 600
org.onboard.window.portrait height 200
org.onboard.window.portrait width 600
org.onboard.window.portrait x 100
org.onboard.window.portrait y 50

Revision history for this message
marmuta (marmuta) wrote :

Thanks. I had tested with those settings too, docking-enabled false, force-to-top false, window-state-sticky false. In compiz I could reproduce the issue before christmas, now no more. I'll do the tests in Arch then.

Changed in onboard:
status: Fix Committed → In Progress
Revision history for this message
David López (david-lopez-upct) wrote :

I've noticed something in trunk 1990. The issue appears only if docking is enabled, or if it was enabled in the current session; if I start my tablet with docking disabled and I don't change its status onboard works fine.

Revision history for this message
marmuta (marmuta) wrote :

This is very close to one of the things I worked on yesterday. The transitioning (move animation) code wasn't aware of the new position when docking was enabled, so the keyboard would sometimes switch back to the undocked position. With inactive transparency timer it would even flicker between docked and undocked position a couple of times. As you wrote, this only happened after changing the docking toggle.
I'll test on Arch anyway later for the XInput issues, so I'll try it again there.

Revision history for this message
marmuta (marmuta) wrote :

So yes, there is something else going on, I can reproduce this bug in OpenBox on Arch and I understand the problem, but don't have a good fix yet. I'll try again tomorrow. Ideally I'd like ...Show alone to be sufficient.

There seems to be a simple workaround at least: waiting after hide until the keyboard is completely hidden seems to help. Something like ...Hide; sleep 0.3; ...Show.

Revision history for this message
marmuta (marmuta) wrote :

Fixed, I believe (again). I finally found a minimal invasive way to assure the keyboard shows in the current desktop. There are two, completely different mechanisms at work now, one for Compiz/Unity and a new, explicit one for all other window managers.

D-Bus Show() alone should be sufficient now. The preceding D-Bus Hide() call isn't necessary anymore, it doesn't hurt either, though.

Changed in onboard:
status: In Progress → Fix Committed
Revision history for this message
David López (david-lopez-upct) wrote :

Tested in rev. 1268 and it is fixed. And no need of 'sleep 0.3' trick, only with the Show dbus call works perfecly smooth. Thanks.

Revision history for this message
Francesco Fumanti (frafu) wrote :

Hi,

I have uploaded a snapshot of the current development status of Onboard containing a fix for this bug and other new features to our main PPA:
https://launchpad.net/~onboard/+archive/ppa

The snapshot is available for raring and for saucy.

Have a nice day.

Changed in onboard:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.