Re: [ctwm] ctwm-3.8b? ctwm-3.9?
Kai wrote: On 08/20/2009 03:15 PM, Aaron Sloman wrote: Unfortunately monontone has a terrible bug: unlike wget, it loses all information about when the files were created, so I don't know how old this system is. Given that Monotone is a version control system, I'd expect mnt log or a similar command to show you the list of changes. That would give you the date you're looking for. And so it does! 'mnt log' tells me that files changed since 2007 are: Date: 2009-06-13T06:42:13 | menus.c Date: 2009-06-13T06:10:55 | workmgr.c Date: 2008-10-28T14:27:17 | menus.c Date: 2007-12-29T16:08:28 | workmgr.c (There's much more in the output.) I'll have to look more closely if I ever want to understand all the detail in the log output. Many thanks. Aaron http://www.cs.bham.ac.uk/~axs
Re: [ctwm] ctwm-3.8b? ctwm-3.9?
On Fri, Aug 21, 2009 at 12:47:05AM +0100 I heard the voice of Aaron Sloman, and lo! it spake thus: It turns out that monotone also loses the information. This isn't really accurate. It's all there (as it would have to be, to fulfill its purpose), it just doesn't set mtime on the files. And it shouldn't a VCS doing that is bogus for various reasons (the most obvious being that it screws up make). ...if you know what 'vcs' is, which I don't -- Sorry! http://en.wikipedia.org/wiki/Version_control_system It sounds like you're thinking of mtn as if it were something like a FTP client (or FTP server, depending). It's not really for downloading or dealing with files; as a VCS, its meant to deal with _history_. You didn't download the files, you downloaded the whole[0] history of the ctwm project. It's a side effect of that, that you can checkout the tree as it existed at any arbitrary point of its history (specifically, you checked it out as of the latest change that's been checked in, which at the moment is an adjustment to OpaqueResizeThreshold I made in June). There isn't any 3.9-devel release or snapshot to download, that's just what every revision since the 3.8a release was made calls itself, since it has to call itself SOMEthing. Trying to talk about all the ways of examining history would be way out of place here, but the simplest is just 'mtn log', which gives you a log of the changes to the project. 'mtn log $FILE' lets you limit to a single file. Various args to 'mtn diff' let you look at the specific changes made in a [set of] revision[s], maybe limited to a single file. Et cetera. Hitting the mtn docs would be the place for details. I had hoped that the standard specification would simply determine a list of operations required, which could be installed without read any code that will invoke them. But perhaps EWMH is not clear enough for that. I haven't looked at it. Well, it may. I've only glanced at it. But it's a huge list; it's likely that only one or two of the properties are important here. [0] Not really; any revision history prior to using mtn (or maybe CVS before that; I'm not sure how much Richard imported) isn't in the repo, though it does have very coarse-grained release imports back to ctwm 1.1. But close enough. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] ctwm-3.8b? ctwm-3.9?
Matthew D. Fuller fulle...@over-yonder.net wrote: On Wed, Aug 19, 2009 at 11:11:03PM +0100 I heard the voice of Dave, and lo! it spake thus: Anyone got any pointers on what is causing flash to get annoyed with ctwm in this way? I s'pose the most likely thing is that it's trying to ask the WM some question, and ctwm doesn't give it an answer. I know, that's probably too specific... :) The Extended Window Manager Hints spec[0] is probably the most likely place to find something it's trying for that ctwm lacks. I seem to recall seeing something which pointed in that direction several months ago. But I lacked the expertise (and time) to follow it up. One way to check that would be to try with fvwm (2.4.x) and see if it still fails, then try with EWMH-enabled fvwm (http://fvwm-ewmh.sourceforge.net/ or 2.5). That would give you a quick touchstone as to whether the issue is likely to lie there. When considering alternatives to ctwm, and before I settled on Openbox, I briefly tried a recent version of fvwm (default version for Fedora) and full screen flash worked OK. I suspect it was fvwm 2.5 (the current version on my F10 machine is fvwm-2.5.26-2.fc10.i386). That implies that something like the code required for full screen flash is in recent versions of fvwm. I don't know if it would be straightforward for a C programmer (which I am not!) to port the relevant bit of code to ctwm. Is there a repository of the patches which have been made since the last release? You can get them out of the monotone repository. Where is that? Google gives no information about a repository with anything later than 3.8a. Neither does the cwtm page, as far as I can tell. There's a blurb on the page about pulling down a copy. I've attached a quickdirty slice of the log since the ctwm-3.8a tag. I recently found this, while searching for an update on ctwm: http://tigerdyr.wheel.dk/ctwm-archive/2147.html It mentions the latest update of ctwm (3.9devel) From: Richard Levitte richard_at_levitte.org Date: Tue, 06 Jan 2009 21:03:42 +0100 (CET) In message 20090106155024.GA26649_at_fermat.math.technion.ac.il on Tue, 6 Jan 2009 17:50:24 +0200, Nadav Har'El nyh_at_math.technion.ac.il said: nyh Recently I upgraded my Linux system from Fedora 7 to Fedora 10. nyh One of the changes which annoyed me was that suddenly, nyh full-screen-mode mplayer (mplayer -fs) no longer worked, and just nyh showed a small window as usual. I looked at all the usual nyh suspects (nvidia driver, xorg, XVideo extension, etc.) but none nyh of those seemed to be broken. nyh nyh Finally, I found the real problem: full-screen mode in recent nyh versions of mplayer does not work on ctwm (3.8a) :( What version is that? I used the following mplayer package for Debian with the latest update of ctwm (3.9devel): : ; apt-show-versions mplayer mplayer/unstable uptodate 1:1.0.rc2svn20080706-0.1 I have none of your problems... Not trying to invalidate your experience, mind. I'm just trying to see what we're up against and why. Also, I think you'll find mplayer defaults in /etc/mplayer, maybe there are things you should look into there... Cheers, Richard -- Richard Levitte richard_at_levitte.org However, no amount of searching with google led to any other information about ctwm (3.9devel) and where to get it. I concluded it must be something specific to Debian, which I don't use, so gave up. The latest version I have been able to find is 3.8a, which I was using before I switched. As far as I can tell the official ctwm page http://ctwm.free.lp.se/ was last modified on Fri Mar 30 00:03:44 2007 It contains a link to a debian ctwl cite, which is broken: http://packages.debian.org/stable/x11/ctwm.html Does Richard read messages from this list? Aaron http://www.cs.bham.ac.uk/~axs
Re: [ctwm] ctwm-3.8b? ctwm-3.9?
On Thu, Aug 20, 2009 at 11:22:58AM +0100 I heard the voice of Aaron Sloman, and lo! it spake thus: That implies that something like the code required for full screen flash is in recent versions of fvwm. I don't know if it would be straightforward for a C programmer (which I am not!) to port the relevant bit of code to ctwm. I suspect not very. Porting would probably be figuring out what fvwm does that affects this case, then rewriting it in ctwm (i.e., not really a 'port' so much at all). The two are a looong way from a common ancestor. Where is that? Google gives no information about a repository with anything later than 3.8a. Neither does the cwtm page, as far as I can tell. It's not very loud about announcing itself, but it's there. http://ctwm.free.lp.se/monotone-crash-course.html However, no amount of searching with google led to any other information about ctwm (3.9devel) and where to get it. It's not a release, just what the dev head calls itself. I run with local changes, so mine says % ~/work/ctwm/fullermd/ctwm -version 3.9devel-fullermd.1 Does Richard read messages from this list? Well, he answered one in May, so he's presumably still kicking, at least occasionally. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] ctwm-3.8b? ctwm-3.9?
However, no amount of searching with google led to any other information about ctwm (3.9devel) and where to get it. I concluded it must be something specific to Debian, which I don't use, so gave up. The newest package in Debian is 3.7, so I ended up building ctwm from the newest sources on the official page (3.8a). The latest version I have been able to find is 3.8a, which I was using before I switched. As far as I can tell the official ctwm page http://ctwm.free.lp.se/ was last modified on Fri Mar 30 00:03:44 2007 It contains a link to a debian ctwl cite, which is broken: http://packages.debian.org/stable/x11/ctwm.html This should be : http://packages.debian.org/stable/ctwm (or testing or unstable, depending on which version you use) Does Richard read messages from this list? I'd hope so :) Is there a bug-tracker for problems found and possibly to vote on which need/want fixing first in ctwm? -- I FOR without NEXT signature.asc Description: Digital signature
Re: [ctwm] ctwm-3.8b? ctwm-3.9?
On Thu, Aug 20, 2009 at 02:15:04PM +0100 I heard the voice of Aaron Sloman, and lo! it spake thus: Unfortunately monontone has a terrible bug: unlike wget, it loses all information about when the files were created, so I don't know how old this system is. I'm not really sure what you mean by this. For one thing, most of the files were probably created 10 or 15 years ago, so that doesn't seem a useful question; there probably haven't been any new files in a couple releases :) You can use log or annotate or other such VCS operations to find out what changes were made when, if you care about details. If the thrust of your question is more general up to dateness, though, you grabbed the dev head; you're as up to date as anybody, until the next sporadic commits (and then you just do the pull/update dance, as you'd do comparable ops in any VCS). Alas, full screen flash, Not unexpected; I'd be quite surprised, actually, if it acted any differently than the last release. None of the changes since then get near the realms that would probably have to get touched for that. Unfortunately, fixing it will probably require somebody seeing and caring about it to knuckle down and trudge through it. EWMH is the most likely culprit as mentioned, but that'll take some digging (first, you check the flash source... ;). I for one couldn't even take a first stab at it, since I neither have nor want flash on my system (and couldn't easily get it if I did for that matter, my platform not being showered with blessings from our Mudbrick Overlords). -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] ctwm-3.8b? ctwm-3.9?
Matthew D. Fuller fulle...@over-yonder.net asked: [AS] Unfortunately monontone has a terrible bug: unlike wget, it loses all information about when the files were created, so I don't know how old this system is. [MDF] I'm not really sure what you mean by this. Apologies. It was not really relevant to ctwm: I object generally to people who copy files or directories using cp, instead of cp -p (or rsynch, or tar) because that loses useful historical information shown by 'ls -l', 'ls -lt', etc. In contrast, wget, by default, keeps the information when it fetches files, though browsers, e.g. firefox, typically don't (when you 'save as'). It turns out that monotone also loses the information. After downloading a package I like to use 'ls -lt' to see how old the files are and which ones were most recently changed. But that's impossible with monotone -- at least as I used it (blindly following instructions!) Anyhow, that gripe has nothing to do with ctwm and I should not have let it intrude. For one thing, most of the files were probably created 10 or 15 years ago, so that doesn't seem a useful question; there probably haven't been any new files in a couple releases :) The files that I have for ctwm-3.8a were all dated Feb 16 2007, though I appreciate that many of them must be much older. But ls -lt could have shown me which files had changed since then. Anyhow, it's all academic, as the changes I was hoping for don't exist! You can use log or annotate or other such VCS operations to find out what changes were made when, if you care about details. ...if you know what 'vcs' is, which I don't -- Sorry! If the thrust of your question is more general up to dateness, though, you grabbed the dev head; you're as up to date as anybody, until the next sporadic commits (and then you just do the pull/update dance, as you'd do comparable ops in any VCS). I think I must have inadvertently given the impression of being more knowledgable than I actually am about such things. sorry! Alas, full screen flash, Not unexpected; I'd be quite surprised, actually, if it acted any differently than the last release. None of the changes since then get near the realms that would probably have to get touched for that. Unfortunately, fixing it will probably require somebody seeing and caring about it to knuckle down and trudge through it. EWMH is the most likely culprit as mentioned, but that'll take some digging (first, you check the flash source... ;). I had hoped that the standard specification would simply determine a list of operations required, which could be installed without read any code that will invoke them. But perhaps EWMH is not clear enough for that. I haven't looked at it. I for one couldn't even take a first stab at it, since I neither have nor want flash on my system (and couldn't easily get it if I did for that matter, my platform not being showered with blessings from our Mudbrick Overlords). OK. I'll have to stick with Openbox for now. It's not too bad. Thanks for the information. Aaron http://www.cs.bham.ac.uk/~axs
[ctwm] ctwm-3.8b? ctwm-3.9?
Is a new release planned? I love stable software (!) but there have been patches since February 2007 when 3.8a was released. I have not had time to keep up with them--and would love to see if some minor problems I've seen recently were already fixed. Others are probably in the same boat. Thanks, Rudy
Re: [ctwm] ctwm-3.8b? ctwm-3.9?
I reluctantly concluded that ctwm was dead -- e.g. full screen flash doesn't work and I see no sign that anyone intends to fix it. I can't, alas. So I've switched to Openbox. I am not the only one. I was wondering about that with flash and thought it was just that the flash plugin was ruined in some way... :/ Anyone got any pointers on what is causing flash to get annoyed with ctwm in this way? I'd be happy to hack at it to try and fix this if I can be pointed in vaguely the right direction (I'll have a go without, but it will take a bit longer). I would prefer to go back to ctwm if someone does bring it up to date, as I found it slightly more tailorable to my tastes than OpenBox. I also have a patch to support the virtual screens in ctwm better to go with Xinerama and to stop alt-tab (well, the window ring) from including windows on other virtual screens, which I need to clean up and then will post to this list. Is there a repository of the patches which have been made since the last release? -- d Too many brackets signature.asc Description: Digital signature
Re: [ctwm] ctwm-3.8b? ctwm-3.9?
On Wed, Aug 19, 2009 at 11:11:03PM +0100 I heard the voice of
Dave, and lo! it spake thus:
Anyone got any pointers on what is causing flash to get annoyed with
ctwm in this way?
I s'pose the most likely thing is that it's trying to ask the WM some
question, and ctwm doesn't give it an answer. I know, that's probably
too specific... :)
The Extended Window Manager Hints spec[0] is probably the most likely
place to find something it's trying for that ctwm lacks. One way to
check that would be to try with fvwm (2.4.x) and see if it still
fails, then try with EWMH-enabled fvwm
(http://fvwm-ewmh.sourceforge.net/ or 2.5). That would give you a
quick touchstone as to whether the issue is likely to lie there.
Is there a repository of the patches which have been made since the
last release?
You can get them out of the monotone repository. There's a blurb on
the page about pulling down a copy. I've attached a quickdirty slice
of the log since the ctwm-3.8a tag.
[0] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html
--
Matthew Fuller (MF4839) | fulle...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
-
Revision: 68e77386ee3796cd86bcaac20be26654903ae525
Ancestor: 32e82b4d69b074f91592b02fc06655333021e7e4
Author: fulle...@over-yonder.net
Date: 2009-06-13T06:42:13
Branch: free.lp.se:X.ctwm
Modified files:
menus.c
ChangeLog:
Treat OpaqueResizeThreshold = 1000 (the default setting) as infinity,
and always OpaqueResize without doing the math to figure if we're over
the threshold.
-
Revision: 32e82b4d69b074f91592b02fc06655333021e7e4
Ancestor: db710969dfa5d7225c4825c75aee971fb4572f8b
Author: fulle...@over-yonder.net
Date: 2009-06-13T06:10:55
Branch: free.lp.se:X.ctwm
Modified files:
workmgr.c
ChangeLog:
Fix an completely insane mis-sizing of the occupy window.
When WMgr{Vert,Horiz}ButtonIndent aren't set in the config file, the
occupy window's vertical and horizontal spacing are never initialized.
But they're still used later on for scaling the occupy window, which can
lead to it getting sizes like:
height=1010580661 width=-252644963
which has bad side effects. So initialize them.
-
Revision: db710969dfa5d7225c4825c75aee971fb4572f8b
Ancestor: 1e6f9162d40262426c038e8d6317a9ebb9302e2c
Author: fulle...@over-yonder.net
Date: 2008-10-28T14:27:17
Branch: free.lp.se:X.ctwm
Modified files:
menus.c
ChangeLog:
Drop a comment about future work that should be done on the
OpaqueResize'ing stuff.
-
Revision: 1e6f9162d40262426c038e8d6317a9ebb9302e2c
Ancestor: a8cae659665e273b3e4176d24da78ddfe0e33371
Author: fulle...@over-yonder.net
Date: 2008-10-28T14:24:35
Branch: free.lp.se:X.ctwm
Modified files:
menus.c
ChangeLog:
In certain [admittedly specialized] situations, calculating whether we're
over the OpaqueResizeThreshold can cause overflows of the variables we're
holding info with. Work around it in two different ways; firstly,
increase the size of the variables, and secondly, rearrange the
calculations to yield much smaller results by using floating point
operations. The added overhead from the FP is likely to be considerable
in computer terms, but utterly meaningless in human terms.
-
Revision: a8cae659665e273b3e4176d24da78ddfe0e33371
Ancestor: b88a44503137a614ee5d1975e2d13967225ac045
Author: rhia...@falu.nl
Date: 2007-12-29T16:08:28
Branch: free.lp.se:X.ctwm
Modified files:
workmgr.c
ChangeLog:
Fixes [rt.lp.se #134] ctwm crashed by ClickToFocus function
Make sure that a TwmWindow always gets set up with a valid VirtalScreen
pointer, even if there is no workspace manager.
-
Revision: 2908d36e5ff6dd239c46e45b4a47c70137421375
Ancestor: fbb60d5fda71bf951cf83aff31e3ff8a38c5b9c6
Author: fulle...@over-yonder.net
Date: 2007-11-22T23:18:20
Branch: free.lp.se:X.ctwm
Deleted entries:
alloca.c
ChangeLog:
I don't see any evidence that alloca.c was ever used. It probably
shouldn't be. And even if it were, it's setup to only be used on non-gcc
or gcc versions less than 2. Cast it loose.
-
Revision: c13f0ceb0494f3e8c3597df5aeaedf460f46f216
Ancestor: 93cd0f835730be71d5d34d311e8c5c27c373b32f
Author: Martin Blais bl...@furius.ca
Date: 2007-12-03T06:01:12
Branch: free.lp.se:X.ctwm
Modified files:
workmgr.c
ChangeLog:
A statement that shouldn't be commented.
-
Revision: 93cd0f835730be71d5d34d311e8c5c27c373b32f
Ancestor:
