[ctwm] Depth-arrangement of windows is not preserved?
Since I installed the latest version from monotone, I notice that the depth arrangement (a.k.a. stacking order) of windows tends to change, if you move away from a workspace and come back. Typically the windows have a preferred arrangement that they get, it is not really random. It doesn't seem to matter how I changed the arrangement (via clicking on the titlebar, or f.warpring, or whatever I tried). In the WorkspaceManager window, the previous (correct) arrangement is still visible, which then doesn't match with the real version. Does anyone else notice that, or is it just my config? The first revision it occurs in is 40dcbfa64305f8c883f35ffefa623fc213dd1e02 om 2006-05-21T20:25:25 by [EMAIL PROTECTED] I tried reverting some bits relating to XReparentWindow(), which surely messes up the stacking order (the manpage says so). That doesn't seem to have helped though. If nobody has an idea, I'll file it with the bug tracker in a while. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- You author it, and I'll reader it. \X/ rhialto/at/xs4all.nl-- Cetero censeo authored delendum esse.
Re: [ctwm] [rt.lp.se #124] Captive window/workspace oddities
On Sat 16 Dec 2006 at 15:56:05 +0100, Rhialto via RT wrote: A few oddities regarding workspaces and captive ctwm windows: - If you start a captive ctwm (ctwm -w) the new window will often move off to some other workspace right away. - If you use the WorkSpaceManager window inside the captive window, it will not only switch the visible workspace inside the captive window, it will also change the captive window's own workspace. - If you use f.adoptwindow to get an outside window into the captive window, its workspace will be preserved even inside the captive window, i.e. it may not appear in the currently visible workspace. (This may or may not be considered a feature.) - Opaque move of windows inside the captive window is broken - it shows the window at some offset (the same as the captive window position it seems) while moving. This may be sincd kovert's changes, since it changed a lot of stuff regarding root windows. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- You author it, and I'll reader it. \X/ rhialto/at/xs4all.nl-- Cetero censeo authored delendum esse.
Re: [ctwm] Depth-arrangement of windows is not preserved?
Found it. Gratuitous calls to XReparentWindow(), due to virtual
screens.
Can somebody please explain to me (and to the manual page!) how virtual
screens are supposed to work (conceptually)? What is their relation to
workspaces? The manpage uses them as synonyms. Can I test them with
captive windows? Can someone think about and reply to the comments I put
in the CHANGES file?
Apologies to the people who use/need them, but personally I'd rather rip
them out completely, since they mess up a lot of stuff. Really.
Proposed patch (including some cleanup of horrible layout; the meat is
around the calls to XReparentWindow()):
#
# old_revision [c9d55f94ff451e3433418942745f3b423665914e]
#
# patch CHANGES
# from [1528a7a23da608e5ed0808513f0777fc83c3d6ab]
#to [5ab433a15ec4c9254e10dce0d45cbc1b0c168ded]
#
# patch add_window.c
# from [ccf9dbbb842ae20d02cf3b4bdb1a32450dcd0781]
#to [850b6c6be10c800e02729eaa04095b830b255936]
#
# patch twm.h
# from [3e6e0a4e490b895b1227c13aeb6b8341a2108e05]
#to [cff6f00ee1666cfedf1c26090a31ab2984898704]
#
# patch workmgr.c
# from [7cfcd5ceb2faada1894fda33e1b558cd120537b8]
#to [33f0ea1748e6dc148b4218d5fa4166f606377aef]
#
--- CHANGES 1528a7a23da608e5ed0808513f0777fc83c3d6ab
+++ CHANGES 5ab433a15ec4c9254e10dce0d45cbc1b0c168ded
@@ -1534,3 +1534,22 @@ VirtualScreens {
This is basically change #7 above done right.
[Olaf Rhialto Seibert]
+
+9 - Re-introduced TwmWindow.oldvs, used to avoid calling
+ XReparentWindow() when possibe (it messed up the stacking order
+ of windows). However, maybe the use of .vs should be rethought a
+ bit: in Vanish() it is now set to NULL with the old value kept
+ in .oldvs. However the window is still a child of the same vs.
+ Maybe it is better not to set it to NULL and then, when *really*
+ changing the virtual screen, .vs can be used instead of .oldvs.
+
+ This whole virtual screen thing is unexplained in the manual,
+ which even uses it as a synonym for workspace already in the
+ introduction paragraph. (There also does not seem to be a way
+ now to test virtual screens in captive windows) I suspect that
+ all this causes lots of confusion, and when cleared up, can
+ simplify the code a lot.
+
+ I also fixed up the horrible indentation in the functions
+ where I changed something.
+ [Olaf Rhialto Seibert]
--- add_window.cccf9dbbb842ae20d02cf3b4bdb1a32450dcd0781
+++ add_window.c850b6c6be10c800e02729eaa04095b830b255936
@@ -266,6 +266,8 @@ TwmWindow *AddWindow(Window w, int iconm
tmp_win-wspmgr = iswman;
tmp_win-iswinbox = iswinbox;
tmp_win-vs = NULL;
+tmp_win-oldvs = NULL;
+tmp_win-savevs = NULL;
tmp_win-cmaps.number_cwins = 0;
tmp_win-savegeometry.width = -1;
@@ -594,6 +596,7 @@ TwmWindow *AddWindow(Window w, int iconm
} else
#endif
SetupOccupation (tmp_win, 0);
+tmp_win-oldvs = vs;
/*=*/
tmp_win-frame_width = tmp_win-attr.width + 2 * tmp_win-frame_bw3D;
--- twm.h 3e6e0a4e490b895b1227c13aeb6b8341a2108e05
+++ twm.h cff6f00ee1666cfedf1c26090a31ab2984898704
@@ -415,6 +415,7 @@ struct TwmWindow
unsigned int width, height;
} savegeometry;
struct virtualScreen *vs;
+struct virtualScreen *oldvs;
struct virtualScreen *savevs;
#ifdef X11R6
--- workmgr.c 7cfcd5ceb2faada1894fda33e1b558cd120537b8
+++ workmgr.c 33f0ea1748e6dc148b4218d5fa4166f606377aef
@@ -962,9 +962,9 @@ void Occupy (TwmWindow *twm_win)
if ((y + yoffset) Scr-rooth) y = Scr-rooth - yoffset;
Scr-workSpaceMgr.occupyWindow-twm_win-occupation = twm_win-occupation;
-if (Scr-Root != Scr-CaptiveRoot)
+if (Scr-Root != Scr-CaptiveRoot) {
XReparentWindow (dpy, Scr-workSpaceMgr.occupyWindow-twm_win-frame,
Scr-Root, x, y);
-else
+} else
XMoveWindow (dpy, Scr-workSpaceMgr.occupyWindow-twm_win-frame, x, y);
SetMapStateProp (Scr-workSpaceMgr.occupyWindow-twm_win, NormalState);
@@ -1262,11 +1262,11 @@ static void Vanish (virtualScreen *vs, T
XWindowAttributes winattrs;
unsigned long eventMask;
-if (vs tmp_win-vs (tmp_win-vs != vs)) return;
+if (vs tmp_win-vs tmp_win-vs != vs)
+ return;
if (tmp_win-UnmapByMovingFarAway) {
-XMoveWindow (dpy, tmp_win-frame, Scr-rootw + 1, Scr-rooth + 1);
-} else
-if (tmp_win-mapped) {
+ XMoveWindow (dpy, tmp_win-frame, Scr-rootw + 1, Scr-rooth + 1);
+} else if (tmp_win-mapped) {
XGetWindowAttributes(dpy, tmp_win-w, winattrs);
eventMask = winattrs.your_event_mask;
Re: [ctwm] Depth-arrangement of windows is not preserved?
Mmmm, Rhialto, you have write access to the repo, so if your patch works, I suggest committing and pushing so we can all try. I have noticed that random rearrangement of windows, but I've been too lazy to get bothered with it ;-). As to indentation, maybe it's time we get into some kind of agreement. As far as I can see, there's the original twm indentation (which I suspect, but am unsure of, is X11 indentation), some GNU indentation and a few more variants that I didn't recognise. Might be time to write in stone what it should be and suggest the proper emacs and vim macros to keep them that way. I'm open for suggestion, and can arrange for that to happen, if we all find it important enough. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis
Re: [ctwm] Depth-arrangement of windows is not preserved?
On Fri 22 Dec 2006 at 10:51:21 -0600, Matthew D. Fuller wrote:
Just to be contrary, I find that to be just about the _worst_ possible
style. I indent with tabs, and highly dislike indenting with spaces,
but surely the worst of both worlds it indenting with *BOTH*. The
code is then only remotely readable with an 8-char tabstop. With my
standard 4-char tabstops, it only seems to indent every _other_ block.
With a 2-char tabstop, it indents a long ways, then outdents a little,
then indents another long ways, then outdents a little, then...
Let me explain. Tabs are historically 8 worth spaces. There is too much
text based on that to ever be able to change that. However, an indent of
4 (often) looks better. Therefore many programmer's editors (including
Vim, Emacs, even MS Visual Studio) can dynamically mix tabs and spaces
such that indents are 4 and tabs are 8 (using tabs at the start of the
line and possibly 4 extra spaces after them). Unfortunately this is
indeed going to look bad if you set tabs to 4, but then so is a lot of
other text. Of course, we could ban tabs and always use spaces, but
that will need a lot of reminding people I expect.
A partial solution might be to use tabs only for indentation and nowhere
else. It would foil any other lining up that people might want to do
though.
Related, tabs for alignment (e.g. on the variable declarations at the
top of the function) are IMAO the wrong place to use tabs as well.
Most of this stuff can easily be reformatted with the indent program.
It has more options than ls to select all these things.
(I don't care for KR braces, or for spaces between function names and
args either, but those are more minor details)
As long as the braces aren't the ugly GNU style, half-indented! Eew!
while
{
something;
}
some more...
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- You author it, and I'll reader it.
\X/ rhialto/at/xs4all.nl-- Cetero censeo authored delendum esse.
Re: [ctwm] Depth-arrangement of windows is not preserved?
On Fri, Dec 22, 2006 at 05:35:00PM +0100 I heard the voice of Rhialto, and lo! it spake thus: For an example of the style that I like, see what DisplayWin() in workmgr.c. Just to be contrary, I find that to be just about the _worst_ possible style. I indent with tabs, and highly dislike indenting with spaces, but surely the worst of both worlds it indenting with *BOTH*. The code is then only remotely readable with an 8-char tabstop. With my standard 4-char tabstops, it only seems to indent every _other_ block. With a 2-char tabstop, it indents a long ways, then outdents a little, then indents another long ways, then outdents a little, then... Related, tabs for alignment (e.g. on the variable declarations at the top of the function) are IMAO the wrong place to use tabs as well. (I don't care for KR braces, or for spaces between function names and args either, but those are more minor details) -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] Depth-arrangement of windows is not preserved?
In message [EMAIL PROTECTED] on Fri, 22 Dec 2006 17:35:00 +0100, Rhialto [EMAIL PROTECTED] said: rhialto Done. I was being careful, just in case somebody would say rhialto Nooo! You can't do that because of The more the merrier, and wait until you discover the power of 'mtn disapprove' when executed by someone else ;-). That said, I will not approve of disapproval wars... rhialto Due to the mixing of styles some parts of the code are very rhialto difficult to understand (for me, at least). Yes, there are times when I've had that same difficulty. I'll see if I get some time to see this over some time after Christmas. Right now, it's time to be with family and woman for a bit. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis
Re: [ctwm] Depth-arrangement of windows is not preserved?
On Fri 22 Dec 2006 at 23:34:03 +0100, Richard Levitte - VMS Whacker wrote: Olaf, did you do the indentation in DisplayWin manually, or with something somewhat automatic? Do you use emacs or vi (and puh-leaaase, no editor war, ok?)? I don't need an editor war any more than you :-) I did the indentation semi-automatically, first using Vim's re-indent command (=), and then splitting some lines of the form if (foo) bar; and joining some where } else if (...) was not on one line. No doubt my settings for hard tabs at 8 and soft tabs of 4 has been taken into account. Once we settle on some layout, I'm sure I can make some vim settings that do all or most of the work for it without thinking about it. Similarly for settings for the indent program. As long as what we choose can be automatically produced, it is easy :-) Cheers, Richard -Olaf. -- ___ Olaf 'Rhialto' Seibert -- You author it, and I'll reader it. \X/ rhialto/at/xs4all.nl-- Cetero censeo authored delendum esse.
