turkeyliner.blogg.se

1. PROBLEMS WITH XQUARTZ WINDOW SIZE UPDATE
2. PROBLEMS WITH XQUARTZ WINDOW SIZE PATCH
3. PROBLEMS WITH XQUARTZ WINDOW SIZE WINDOWS

If, for whatever reason, the root window size is not updated by the time we get our size changed event, this would help: Unless the log is not from the test case described in the ticket? I would expect to see "sending updated screen size to server: WxH", twice: one for each resolution change.

PROBLEMS WITH XQUARTZ WINDOW SIZE UPDATE

There may be more than one screen, and we want to send the full display size, not just the screen that has changed.Īlso, from the logs, I see that we correctly set the screen size to 1650x1050 on connection (circa 21:25:16,***) and then we are notified that the screen resolution has changed (at around 21:25:28,***) and we correctly update the vfb size to 640x480.īut I see no trace in this log sample of the change back to 1650x1050, having the /trimmed/ client debug log would help. Tue, 09:45:40 GMT - Antoine Martin: owner, status, description changedĬhanged from Antoine Martin to Antoine Martin #update the max packet size (may have gone up): nd("desktop_size", root_w, root_h, self.get_screen_sizes()) Log.debug("sending updated screen size to server: %sx%s", root_w, root_h) + def _screen_size_changed(self, screen):

PROBLEMS WITH XQUARTZ WINDOW SIZE PATCH

21:25:16,639 setting key repeat rate from client: 500ms delay / 33ms interval 21:25:16,621 mmap is enabled using 128MB area in /tmp/ 21:25:16,621 Python/Gtk2 Linux client version 0.9.4 connected from 'sauna' 21:25:16,619 Handshake complete enabling connection 21:25:16,371 New connection received: SocketConnection(/home/lindi/.xpra/sauna-7) The xpra server log shows how xpra continues to think that the resolution is 640x480 even after it has been set back to normal: The only workaround I have found so far is to disconnect and reattach xpra. Only a 640x480 pixel area in the upper left corner of each window is accessible.

PROBLEMS WITH XQUARTZ WINDOW SIZE WINDOWS

in gnome System->Preferences->Monitors)Īll parts of xpra windows can be accessed with mouse change resolution of the client machine to 640x480 temporarily.

We're using the GNOME desktop and Qt 4.8.x.Here is another bug from Timo (with patch) reported as is from I'm sure someone somewhere thought this was a reasonable restriction, but our customers disagree.Ī developer here has spent days searching and experimented trying to find a way to work around this behavior programmatically, or better yet, tell the window manager to stop doing that. Basically, as long as the user makes the change by dragging and resizing the window, the window manager respects it, but an application that programmatically sets it gets overridden. When we attempt to restore a saved layout containing a window that spanned monitors, the window manager reduces its size and repositions at as it sees fit. What we've found is that the window manager is enforcing a policy on windows that are programmatically set and forcing them not to span across divide between two monitors. Our configuration uses a single virtual X display spanning all monitors, and the users can manually position and size windows across the monitors as desired.

On Linux, we're having problems restoring windows when a window spans multiple monitors. The application is cross-platform, and on Windows, everything is fine. The application has multiple windows and we support a layout system where our users can save the application layout and restore it later. We're using Red Hat Linux 6.4, and our application is built using Qt.