On Sat 16 Dec 2006 at 00:08:21 +0100, Richard Levitte via RT wrote:
> Good catch. Incidently (out of interest, since I'm involved in
> monotone as well), how did
> annotate work for you, and what monotone version do you use?
I recently installed monotone 0.30 because that's what's in my package
management system (pkgsrc). I had to migrate the database but that
seemed to work ok. Annotate works fine, I think that this is the first
time I really used it, I more or less just assumed (since I use cvs more
often) that it would exist, and voila, it did :-)
> > Speaking of patches, I just installed the latest version, and suddenly
> > the background colour of the active workspace in the WorkspaceManager
> > broke again... does anyone remember what the previous fix was and if it
> > maybe was reverted or re-broken?
>
> If you remember approximately when you introduced that change, it
> shouldn't be too hard to
The version I was running previously was compiled on 31 january, which
looks to be when I fixed the AutoRelativeResize bug. It seems the
problem is already present in the next revision,
f0b709dcd5269fb88b748a2e5d54e259d0f66881. I just tried that out in a
captive ctwm. (By the way, captive windows appear in a strange place,
when you are not stanting in the default workspace. And if you switch
active workspaces in the captive window, the captive window itself
changes its workspace. Really weird and it makes testing somewhat more
annoying. Oh and another thing: when one initiates f.hypermove from
within the captive window, the mouse cursor is restrained to within the
captive window. I don't remember it doing that.).
Reverting to e109b01dd00816d0809b92ddf7a0367f45f1f2bd shows the current
workspace again properly highlighted in the WorkspaceManager (well, the
background colour works, the border colour doesn't and ISTR that it once
worked even when the background didn't...)
I'd bet that this is related to the remark on f0b709dc... which says
- InitVirtualScreens() and ConfigureWorkSpaceManager() were called too
early
This ConfigureWorkSpaceManager() seems rather elusive since from the
diffs the change appears to be fairly simple, and it made trouble before...
For clarity, I have this in my .ctwmrc:
MapWindowCurrentWorkSpace {
# border_color [background] [foreground] [bitmap]
"Red" "Yellow" "Black"
}
and that is the bit that doesn't take effect.
Hmmm I see a (different?) bug in WMapCreateCurrentBackGround(): it is
supposed to loop through all virtualScreens but may call return from
within the loop, and leave the remaining virtualScreens untouched.
WMapCreateDefaultBackGround() has the same problem.
But it is related: WMapCreateCurrentBackGround() is called when the
config file is read, and stores the colours/bitmap. However, now that
ConfigureWorkSpaceManager() is called later, the virtualScreens don't
exist yet, so there is no place to store them, and they are lost.
So, what I see now in ctwm.c:
else
{
ParseTwmrc(InitFile);
}
InitVirtualScreens (Scr);
ConfigureWorkSpaceManager ();
but ParseTwmrc should (at least for the MapWindowCurrentWorkSpace
directive) be called *after* InitVirtualScreens() and
ConfigureWorkSpaceManager()... how to fix this?
What was it exactly that made you move these two calls later? Can that
be split off into a separate function? [this is the main remaining
issue]
Or maybe (but that seems too much of a hack right now),
WMapCreateCurrentBackGround() and WMapCreateDefaultBackGround() should
do something different to store their settings, so that they can be
applied to all virtual screens later.
And, yet something else (sorry, I am just typing all this while I am
inserting debugging code and trying things/thoughts out)
gcc -O2 -fno-strict-aliasing -I/usr/pkg/include -I/usr/X11R6/include
-DCSRG_BASED -D__AMD64__ -DFUNCPROTO=15 -DNARROWPROTO -DUSEM4 -DGNOME
-DXPM -DJPEG -DX11R6 -DI18N -c workmgr.c
workmgr.c: In function `CreateWorkSpaceManager':
workmgr.c:263: warning: passing arg 3 of `GetPropertyFromMask' from
incompatible pointer type
That is easily fixed, I see. Shall I commit the changes for the little
things already without waiting for a resolution for the main issue?
> figure out. Can I recommend mtn-viz?
> http://oandrieu.nerim.net/monotone-viz/ I find it to be a very
> helpful tool.
Essential, I would say. Without its visualisation one would lose
overview completely.
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- You author it, and I'll reader it.
\X/ rhialto/at/xs4all.nl -- Cetero censeo "authored" delendum esse.
