xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.


Opened 9 years ago

Closed 9 years ago

Last modified 6 months ago

#161 closed defect (fixed)

Resizing xterm no longer snaps to correct size

Reported by: Martin Ebourne Owned by: Antoine Martin
Priority: major Milestone: 0.4
Component: core Version: trunk
Keywords: Cc:

Description

Not sure when this started but it is present in current head. Resizing an xterm locally snaps the window size to a multiple of the character width/height in the window. This used to work the same over xpra but now the window is resized to any pixel and the window padded with an annoying white gap to fill any spare pixels (it is very visible with a black xterm background).

Change History (7)

comment:1 Changed 9 years ago by Antoine Martin

Status: newaccepted

Hmmm, I don't doubt what you are saying (as there are a number of bugs related to window dimensions already), but I cannot see this particular problem here (or maybe just not noticing it).

Would you mind adding some details about this bug so I can reproduce it?
ie, OTOH:

  • distro, X11 server and xterm version
  • window manager used
  • screenshots?

etc..

comment:2 Changed 9 years ago by Martin Ebourne

Fedora 14, good old gnome 2 running compiz. It's not just xterm, emacs does it too.

I've bisected the bug down to r275 which is when it breaks.

comment:3 Changed 9 years ago by Martin Ebourne

looking in the log on the server running head, as I resize the xterm I see this:

Uh-oh, our size doesn't fit window sizing constraints: 759x629 vs 755x619
Uh-oh, our size doesn't fit window sizing constraints: 765x638 vs 761x632
Uh-oh, our size doesn't fit window sizing constraints: 776x649 vs 773x645
Uh-oh, our size doesn't fit window sizing constraints: 782x654 vs 779x645
Uh-oh, our size doesn't fit window sizing constraints: 788x661 vs 785x658
Uh-oh, our size doesn't fit window sizing constraints: 800x672 vs 797x671
Uh-oh, our size doesn't fit window sizing constraints: 805x676 vs 803x671
Uh-oh, our size doesn't fit window sizing constraints: 807x679 vs 803x671
Uh-oh, our size doesn't fit window sizing constraints: 809x681 vs 809x671
Uh-oh, our size doesn't fit window sizing constraints: 812x683 vs 809x671
Uh-oh, our size doesn't fit window sizing constraints: 814x686 vs 809x684
Uh-oh, our size doesn't fit window sizing constraints: 816x688 vs 815x684

etc

In case it matters, I have "Sever RandR no - 3840x2560" according to session info.

comment:4 Changed 9 years ago by Antoine Martin

Great work, I did not dare to ask you to bisect it, but you did it anyway!

r275 was committed as part of #40 (see comment:12)

Is undoing the first part enough?:

--- src/wimpiggy/window.py	(revision 976)
+++ src/wimpiggy/window.py	(working copy)
@@ -634,6 +634,7 @@
             self._update_client_geometry()
 
     def _sanitize_size_hints(self, size_hints):
+        return
         if size_hints is None:
             return
         for attr in ["max_size", "min_size", "base_size",

Or do you also need this:

--- src/xpra/server.py	(revision 1056)
+++ src/xpra/server.py	(working copy)
@@ -562,7 +562,7 @@
                     ("max_aspect_ratio", "maximum-aspect"),
                     ]:
                     v = getattr(hints, attr)
-                    if v is not None and v>=0 and v<(2**32-1):
+                    if v is not None:
                         hints_metadata[metakey] = getattr(hints, attr)
             return {"size-constraints": hints_metadata}
         elif propname == "class-instance":

I do remember something about having problems on 64-bit servers with 32-bit clients (or was it the other way around?), where the values needed clipping. But r275 looks wrong in any case because it does not clip them: it simply discards negative and overflowing values instead of "sanitizing" them as it claims to do.
I'll have to verify which of those attributes allow negative values.

comment:5 Changed 9 years ago by Martin Ebourne

The xpra/server.py change is all that is needed to fix this bug. My server is 32 bit and client 64 bit but that turns out not to be relevant as I can reproduce this locally on the 64 bit host over shm.

On bisect, git or hg would be a lot better (actually a lot better all round) but it's manageable with svn. Maybe I should use a git-svn bridge. :)

comment:6 Changed 9 years ago by Antoine Martin

Resolution: fixed
Status: acceptedclosed

applied in r1085

oh, and no idea why I didn't see the bug when I tried, it is quite visible with:

xterm -bg black -fg white
Last edited 9 years ago by Antoine Martin (previous) (diff)

comment:7 Changed 6 months ago by migration script

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/161

Note: See TracTickets for help on using tickets.