Using 3.7, when I add config directives for two virtual screens in an two
monitor Xinerama configuration, it seems to be no different than when I
don't have the configuration directive at all. This behavior has been
reported here before.
Poking at the code, it looks like InitVirtualScreens() is called before
the configuration file is parsed which would explain what I see since
there's no attempt to create them after the config file read.
Moving the call after the config parsing causes things to work.
I've run into a few other issues that I fixed with the attached patch:
- shadow menus on the right screen open the shadow on the left screen
- shadow menus on the left screen open on top of the window
- windows on the right screen disappear after startup
I've also run into the following issues that I'm trying to sort out in
my copious spare time (some I may have introduced with my patch):
- occupy all needs to pick a virtual screen and stick with it,
at least if the window is mapped.
- occupy all on the right screen sometimes never works, though can be
made to work under some conditions if the window is iconified
- sometimes windows don't show up in text icon box (haven't tried
graphical icon box)
- kill/restarts and f.twmrc cause windows to disappear from workspaces
but will reappear after successive restarts
- kill/restarts+f.twmrc cause windows to map to +0+0 in the virtual
workspace
- pop windows (such as mozilla/firefox windows) pop up almost off
screen if on the right window
- with different sized virtual screens the textual icon manager opens
straddling screens (haven't checked the graphical icon manager)
- icon manager opens on the root window and is always on top when
using virtual screens
- windows that de-iconify themselves (such as a gaim window) will
sometimes de-iconify on the wrong screen
One thing I have noticed is that Xinerama support was coded with the
assumption that the right screen has it's true geometry relative to the
root, but virtual screens were implemented with virtualroots which are
going to have relative geometries.
Another thing is that with the virtual root, things like xwininfo and
other things that let you click on a window get confused because the
parent is not the root. The end result is they show ctwm windows (the
virtual root or the workspace manager in my case). This seems to be a
problem with other virtual window managers as well that use the same
approach. It looks like gnome has standardized the naming conventions
for the atoms for workspaces, so it may be possible to get the X people
to tweak things like xwininfo to accommodate that or include it in their
own standards. (maybe they have in recent history, I'm less certain).
Some features I'd like to see and may even code:
- ability to drag a window from one virtual screen to another
and have it move to the other workspace.
- ability to have :0.0/:0.1 simulation as far as virtual workspaces
go but preserve the xinerama geometry (ie, no virtual root). This
should almost certainly be a configurable option
I've made some progress on the first one, but haven't attempted the
second, nor have I really started on the bug list above.
I have made no attempt to deal with workspaces that are on top of each
other rather than next to each other, though this is permissible in X.
I have two environments. An ATI firemv 2200 card doing their simulated
Xinerama (I have a firegl v5000 that I haven't gotten to work after
minimal effort) that's got two flatpanels of 1920x1200 connected to it
that I use primarily.
I've got my old system (I used to have a :0.0/:0.1 setup on) that has an
old Matrox g450 that does 2048x1536 and 1920x1536 in Xinerama mode and
2048x1536 in :0/:1 mode that I've been working on ctwm with.
Both are running NetBSD/i386 3.0 (-STABLE) with x.org.
I'm also running into another issue that used to show up on the matrox
card but is showing up almost immediately after startup on the ATI card.
gtk 1 or 2 -based applications (gaim/firefox/mozilla) will sometimes
have windows light-blue out for some of their subwindows and even over
chunks of text (they probably correspond to subwindows in the browser).
Moving over them causes them to redraw, moving off causes them to go
blue again. On the matrox card, this was black and only after X being
up for a week or two. Sometimes killing and restarting would make it go
away. olvwm doesn't seem to have this problem on the ATI card, though
I've only tried it minimally so I can't say if it's window-manager
related, but I figured I'd mention it in case someone pipes up.
Has anyone else spent time with Xinerama+Virtual Screens that may
be able to add any insight? I'm familiar with Window Manager and X
concepts but have worked little with window managers, so this has been
a lot of time trying to figure out how everything works together, and a
lot less time actually fixing these problems. :)
thanks,
-Todd
diff -dru ctwm.orig/add_window.c ctwm-3.7/add_window.c
--- ctwm.orig/add_window.c 2005-06-21 01:35:18.000000000 -0400
+++ ctwm-3.7/add_window.c 2006-04-21 09:06:05.000000000 -0400
@@ -114,6 +114,7 @@
static int PlaceX = 50;
static int PlaceY = 50;
static void CreateWindowTitlebarButtons(TwmWindow *tmp_win);
+void DealWithNonSensicalGeometries(Display *dpy, Window vroot, TwmWindow *tmp_win);
static void splitWindowRegionEntry (WindowEntry *we,
int grav1, int grav2,
@@ -1223,6 +1224,9 @@
tmp_win->frame_x = 0;
tmp_win->frame_y = 0;
}
+
+ DealWithNonSensicalGeometries(dpy, vroot, tmp_win);
+
tmp_win->frame = XCreateWindow (dpy, vroot, tmp_win->frame_x, tmp_win->frame_y,
(unsigned int) tmp_win->frame_width,
(unsigned int) tmp_win->frame_height,
@@ -2516,3 +2520,48 @@
}
}
+/*
+ * This is largely for Xinerama support with VirtualScreens.
+ * In this case, windows may be on something other then the main screen
+ * on startup, or the mapping may be relative to the right side of the
+ * screen, which is on a different monitor, which will cause issues with
+ * the virtual screens.
+ *
+ * It probably needs to be congnizant of windows that are actually owned by
+ * other workspaces, and ignore them (this needs to be revisited), or perhaps
+ * that functionality is appropriate in AddWindow(). This needs to be dug into
+ * more deply.
+ *
+ * this approach assumes screens that are next to each other horizontally,
+ * Other possibilities need to be investigated and accounted for.
+ */
+void DealWithNonSensicalGeometries(Display *dpy, Window vroot, TwmWindow *tmp_win)
+{
+ Window vvroot;
+ int x,y;
+ unsigned int w,h;
+ unsigned int j;
+ virtualScreen *myvs, *vs;
+ int dropx = 0;
+
+ if(! vroot)
+ return;
+
+ if(!(XGetGeometry(dpy, vroot, &vvroot, &x, &y, &w, &h, &j, &j)))
+ return;
+
+ myvs = getVScreenOf(x, y);
+
+ for(vs = myvs->next; vs; vs = vs->next) {
+ dropx += vs->w;
+ }
+
+ for(vs = Scr->vScreenList; vs && vs != myvs; vs = vs->next) {
+ dropx -= vs->x;
+ }
+
+ if(tmp_win->frame_x > 0 && tmp_win->frame_x > w) {
+ tmp_win->frame_x = tmp_win->frame_x - dropx;
+ }
+
+}
diff -dru ctwm.orig/ctwm.c ctwm-3.7/ctwm.c
--- ctwm.orig/ctwm.c 2005-06-21 01:35:18.000000000 -0400
+++ ctwm-3.7/ctwm.c 2006-04-21 09:05:18.000000000 -0400
@@ -742,9 +742,6 @@
InitMenus();
InitWorkSpaceManager ();
- InitVirtualScreens (Scr);
- ConfigureWorkSpaceManager ();
-
/* Parse it once for each screen. */
if(cfgchk) {
if(ParseTwmrc(InitFile)==0) {
@@ -761,6 +758,9 @@
ParseTwmrc(InitFile);
}
+ InitVirtualScreens (Scr);
+ ConfigureWorkSpaceManager ();
+
if (ShowWelcomeWindow && ! screenmasked) MaskScreen (NULL);
if (Scr->ClickToFocus) {
Scr->FocusRoot = FALSE;
@@ -861,6 +861,7 @@
{
if (children[i] && MappedNotOverride(children[i]))
{
+
XUnmapWindow(dpy, children[i]);
SimulateMapRequest(children[i]);
}
@@ -1275,10 +1276,12 @@
mask |= CWBorderWidth;
}
+/*
if (tmp->vs) {
xwc.x += tmp->vs->x;
xwc.y += tmp->vs->y;
}
+*/
if (tmp->winbox && tmp->winbox->twmwin && tmp->frame) {
int xbox, ybox;
diff -dru ctwm.orig/menus.c ctwm-3.7/menus.c
--- ctwm.orig/menus.c 2005-06-21 01:35:19.000000000 -0400
+++ ctwm-3.7/menus.c 2006-04-21 09:05:18.000000000 -0400
@@ -582,6 +582,7 @@
}
else
{
+
Draw3DBorder (mr->w, Scr->MenuShadowDepth, y_offset,
mr->width - 2 * Scr->MenuShadowDepth, Scr->EntryHeight, 1,
mi->normal, off, True, False);
@@ -1684,9 +1685,10 @@
MenuOrigins[MenuDepth].y = y;
MenuDepth++;
- if (Scr->Root != Scr->CaptiveRoot)
+ if (Scr->Root != Scr->CaptiveRoot) {
+ XReparentWindow (dpy, menu->shadow, Scr->Root, x, y);
XReparentWindow (dpy, menu->w, Scr->Root, x, y);
- else
+ } else
XMoveWindow (dpy, menu->w, x, y);
if (Scr->Shadow) {
XMoveWindow (dpy, menu->shadow, x + SHADOWWIDTH, y + SHADOWWIDTH);
Received on Fri Apr 21 15:33:52 2006
This archive was generated by hypermail 2.1.8 : Sun Apr 23 2006 - 06:45:10 CEST