> Welcome to the new ctwm mailing list!
Yay!
Stefan
> - If I had my druthers[1], I'd stick everything in bzr[2], and
> probably tap Launchpad for primary hosting. That'd let us setup
> team access easily enough. Could setup a local HTTP dumb-server
> mirror beside the website as fallback.
I like Bzr as well, but its future looks rather blea
> I've been wondering about the changes related to Animating and
> _XA_WM_END_OF_ANIMATION. I don't use animations, so I'm not sure what's
> broken with them and how this fixes it.
The problem with animations is that if the X server is too slow to keep
up, the whole system becomes completely unusa
>> I've been meaning to clean it up for inclusion for several years now,
>> but never got the motivation high enough to actually do it.
> Sounds good! I'd like to see that patch, even if not fully cleaned up.
Hmm... I have it in a local branch, but my monotone fu is down to zero
these days. Could
>> | would be if it were possible to keep track of the stacking order
>> | without explicitly asking the X server with XQueryTree().
> I've been thinking about that a bit. Really keeping track of stacking
> order changes is quite difficult, given the various sorts of re-ordering
> that can take
> While running lxpanel with ctwm I can click on the network icon
> included, and access NM. But I can't see why I can't just invoke
> 'nm-applet' in a ctwm menu option. I have done some searching on the
> internet, but probably have not phrased the question correctly.
AFAIK there's no NM client w
> I changed my LANG setting from en_US.UTF-8 to C and now everything works
> correctly. I'm not well-versed enough in what the LANG variable does to
> know how that affected things -- I'll have to research some. I'll also
> have to test and see if using one of the iso8859's might be safe...
The
> fair conformance to C89. What systems do we care about that don't
> have reasonably competent C99 support?
"C99 support" is unclear: e.g., AFAIK, gcc doesn't fully support C99,
tho it has supported many parts of it for quite a while.
Stefan
> Anyway, it doesn't fully work with this option either, but it helped me
> identify the problem in more detail: AlwaysOnTop is the culprit.
I think I know this bug. So, I'm probably to blame for it, and many
times at that: I wrote the AlwaysOnTop code, I bumped into this bug, and
I even fixed it
> 1. Focus follows mouse in combination with RaiseDelay is buggy. This
>has been known for a long time, but it seems to hard to fix. This
>causes application menus and popups of many apps to malfunction
>(they disappear behind the main window, making access impossible).
Yes, and AFAIK
> But Gnome resets the resources at some point near the end of its
> startup, and it is very very difficult to tell when it happens.
> actually it seems to do it a number of times, not just once
What I do to work around this brain damage is to tell gnome-session to
run my .xinitrc file, which
When I try
M-: (set-frame-position (selected-frame) 500 500) RET
in Emacs, the window is moved to position +500+500 with the various
window-managers I've tested, but not with my trusty old ctwm.
Emacs's code seems to just do a XMoveWindow, so I figured the bug is
probably on ctwm's side. I l
monnier> I have a strong suspicion that this is linked to some nasty Gnome or
monnier> XKBsomething intrusion, but since I know nothing about that, I'm at
monnier> a loss.
monnier>
monnier> Does someone here have an idea where I might want to start looking for
monnier> a solution?
> How about a t
I have setup a "WM modifier", more specifically I use my lower-left
corner "ctrl" key for it. The way I do it is to remap it via xmodmap to
Hyper_L and then set it (via xmodmap again) to "mod5".
Then I have in my .ctwmrc some bindings such as:
Button1 = m5 : window|icon|title|frame : f.function
> It's quite possible that the following revision directly contains the
> change that affected you: 84588e8426c83b9d905d528ce6c093141439510e
> Otherwise, the changes concerning locale changes are:
> f2abcc859cca628f2b368c51e6451063743bce8d
> 063e316d67e823a9d9c8e8b732e585b3455eb198
> cf86cef35ea8
monnier> >> and the icon manager has more space around the window
monnier> >> names so the buttons take up more real-estate (and this
monnier> >> space is not regularly distributed: the text ends up
monnier> >> slightly lower than before).
monnier>
monnier> > FWIW, I've seen this when I start up c
>> and the icon manager has more space around the window names so the
>> buttons take up more real-estate (and this space is not regularly
>> distributed: the text ends up slightly lower than before).
> FWIW, I've seen this when I start up ctwm in a UTF-8 (rather than C)
> locale. I haven't gotte
I'm finally trying to merge my ctwm hacks (until now only merged up to
ctwm-3.7) into a monotone branch synced up to the latest and greatest.
I'm basically done, except for the fact that I get oddly large fonts in my
workspace manager and oddly large space around my text in window titles and
in t
>> >> Well, I still have my OnTopPriority stuff, but I don't think anyone
>> >> has the time/energy to work on it soon,
>> [...]
>> > It would also be nice for switching workspaces, when mapping and unmapping
>> > windows could be done in stacking order to minimize Expose events.
>>
>> You mean "i
>> Well, I still have my OnTopPriority stuff, but I don't think anyone has the
>> time/energy to work on it soon,
[...]
> It would also be nice for switching workspaces, when mapping and unmapping
> windows could be done in stacking order to minimize Expose events.
You mean "it *is* nice".
> I'm in a bit of a cleaning frenzy, and now that I've cleaned up I18N,
> I'm on to the next, X11R6 (or USE_SESSION in Imakefile.local).
> My question is, is there any reason NOT to defined USE_SESSION / X11R6?
> If that's the case, I'll clean that out.
> After that, I wanna to a release run, in
> Does anyone know of programs that use real "group leader" windows? GTK
> programs have some "fake" group leader window, one that isn't reported
> to the window manager and therefore is considered not to exist. As you
> may remember their existence caused some grief, because group member
> windows
> I think there was a message a long while ago about how you could
> somehow make a program's windows end up in a workspace specified
> through en environment variable or some other command line construct.
Are you think of "-xrm ctwm.workspace:Foo" ?
If so, it probably won't help since -xrm is eve
>> For what it's worth, I think this part of the FFM behavior should be
>> changed. The focus should only change in response to mouse movements,
>> not in response to window movements.
> I'm not sure you should be completely strict in that. If a window that
> has focus is moved to the back with n
> *** Ctwm uses a focus-follows-pointer, so the focus moves from the old
> *** window to whatever is now below the pointer (the popup window).
> *** The next three events - FocusOut, FocusIn and KeymapNotify, are all
> *** related to this focus change.
For what it's worth, I think this part of the
> A final note concerns having xterms in as many workspaces
> as desired. I have 10 workspaces on most of my platforms:
> ones for "Mail", "Programming", "Writing", "Broswer",
> and so on. I wanted at least two xterms in each w-space,
> but ctwm kept putting everythi
>> I've now changed my version of the code to map/unmap "optimally"
>> (map first, front to back, then unmap, back to front) and it's now
>> faster than ever and minimizes flicker. ;-)
> Shiny!
> Is there a patch I can download?
Well, you have to understand that I've been carrying my own hacked
>> In 3.6 when you changed from one workspace to another, CTWM first drew
>> a large window covering all active windows on the workspace, then drew
>> all the windows active on the new workspace behind the covering window
>> and finally removed the covering window.
> Interesting. I'll have to tim
> In theory, the order in which windows are mapped can be better: from
> front to back. That way, a window is never first shown then completely
> or partially obscured by another one. However I have not checked if that
> information is easily available at the right place or if the order is
> easily
> In 3.6 when you changed from one workspace to another, CTWM first drew
> a large window covering all active windows on the workspace, then drew
> all the windows active on the new workspace behind the covering window
> and finally removed the covering window.
Interesting. I'll have to time it t
Switching workspaces with 3.7alpha5 is significantly slower
than it was with 3.6 on my Mac (with XDarwin).
I see all the windows being re-placed one after the other.
Does anyone have some idea to what it could be due?
Stefan
The subject says it all.
The patch below fixes it for me, but there's probably cleaner way to do it.
Stefan
Index: events.c
===
RCS file: /u/monnier/cvsroot/ctwm/events.c,v
retrieving revision 1.1.1.13
diff -u -u -b -r1.1.1
I have some (old) patch(es) to submit, and was wondering:
should patches still use the old K&R style or can it use ANSI-style in
function definitions?
Stefan "who'd prefer ANSI style, since it allows better checking
and his code uses them"
33 matches
Mail list logo
