marco / mate-session-restore misplaces windows

Bug #1845822 reported by arQon
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
marco (Ubuntu)
New
Undecided
Victor Kareh

Bug Description

In the 19.10 Beta:

session restore is moving all windows placed at the bottom of the screen up by ~8 pixels, and moving all windows placed at the right-hand edge of the screen left by ?about? the same amount. 19.04 didn't have this problem.

A window that was "docked" in the top right corner appeared on the left-hand edge of the screen after restarting. I added that one just to test how broken things were, so I don't know what 19.04 would have done.

Leaving that extra (terminal) window in (and moving it back to the RHS) and running mate-session-save before restarting, it came back on the RHS this time, but inset by 8px or so, i.e. suffering from the same bug as the (caja) window in the bottom right corner.

I've grabbed the session file, which I expect will make it clear whether the bug is in the saving or the loading phase of things. My guess is it's simply being given bad information about the screen size, but either way this should help in it down:

.config/marco/sessions/1075926a43f24e4a8156972156333320900000017420063.ms
<marco_session id="1075926a43f24e4a8156972156333320900000017420063">
  <window id="10b7bfab3d63fe69a8156665080747555500000010060046" class="Caja" name="desktop_window" title="x-caja-desktop" role="" type="desktop" stacking="0">
    <sticky/>
    <workspace index="0"/>
    <geometry x="0" y="0" width="1920" height="1200" gravity="NorthWestGravity"/>
  </window>
  <window id="10b7bfab3d63fe69a8156665080747555500000010060046" class="Caja" name="caja" title="gtk-3.0" role="" type="normal" stacking="1">
    <workspace index="0"/>
    <geometry x="791" y="470" width="1111" height="662" gravity="NorthWestGravity"/>
  </window>
  <window id="10ba099975741208a2156971173831900000000015080051" class="Mate-terminal" name="mate-terminal" title="~/.themes/Lucid" role="mate-terminal-window-3439--635772611-1569711738" type="normal" stacking="2">
    <workspace index="0"/>
    <geometry x="-10" y="457" width="132" height="38" gravity="NorthWestGravity"/>
  </window>
  <window id="10ba099975741208a2156971173831900000000015080051" class="Mate-terminal" name="mate-terminal" title="~" role="mate-terminal-window-2059--929891136-1569727427" type="normal" stacking="3">
    <workspace index="0"/>
    <geometry x="829" y="-10" width="132" height="38" gravity="NorthWestGravity"/>
  </window>
</marco_session>

Revision history for this message
arQon (pf.arqon) wrote :

Launchpad made a bad guess on the package, and ignored my change to it on the submission. :)

affects: mate-screensaver (Ubuntu) → marco (Ubuntu)
Revision history for this message
arQon (pf.arqon) wrote :

Some more info, without which that session file isn't much use:

The display is 1920x1200. Ignore the bottom edge, since that has a panel on it.

The caja window is @ 791 x, + 1111 w = 1,902. The x="-10" for a window on the LHS means the borders are that wide (even though they clearly aren't, so there's some other adjustments going on for whatever reason) so that's 1912, and the 8px guess was dead on.

I'll upload a screenshot as well.

Revision history for this message
arQon (pf.arqon) wrote :
Revision history for this message
arQon (pf.arqon) wrote :

I got tired of putting them back in the right place, and after the next reboot I noticed that they actually KEEP moving up (and left, when possible) each time. Funky. :)

Victor Kareh (vkareh)
Changed in marco (Ubuntu):
assignee: nobody → Victor Kareh (vkareh)
Revision history for this message
arQon (pf.arqon) wrote :

I take it Victor is no longer involved with the project.

For whoever picks this up: when I discussed this with him at the time, he knew exactly what had caused the bug: he'd "hacked the window borders wider so that they could still be grabbed properly after gtk3 broke that" - I assume by padding the bounding rect etc - but wasn't adjusting them back from that when saving them for session restore.

Revision history for this message
Victor Kareh (vkareh) wrote :

Hi arQon - I haven't had time to deal with this (it's been a few years - yikes!).

It's still in my to-do list, but I've been also working on and off on a rewrite of large portions of marco (and I've had to restart a few times). If someone else can pick this up in the meantime, that'd be good.

Norbert (nrbrtx)
tags: added: focal hirsute impish
Revision history for this message
arQon (pf.arqon) wrote :

wb. :) I'll try to tackle it, but my health's not that great right now.

IMO one should really prioritize fixing "easy" bugs ahead of doing massive rewrites to things, but you don't work for me, so... :)

The bug's already made it into one LTS. It would be pretty ridiculous for it to still be there in 22.04 as well. But we'll see how it goes.

Revision history for this message
arQon (pf.arqon) wrote :

"How it went in 22.04" was "not well", obviously :P, but I'm looking to update my 18.04 boxes and this was a blocker for them, so I finally got round to fixing it.

The fix appears to be trivial (marco was using copypasted code instead of the existing function it should have been calling) and has clearly worked, but I have no idea what may or may not be using the ->extents hack that was in there, so verifying that piece would be good.

Note that the patches are against the 1.26.2 tag, because (a) that's what we're using; and (b) the registry changes in 1.27 mean the trunk coredumps, so the code couldn't be tested otherwise. They should merge across cleanly though.

You'll notice there's an additional patch in there, which addresses a related bug, but the two can be applied independently.

tags: added: jammy
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "marco_1-26-3.patches.7z" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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