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
