"Matthew D. Fuller" <[email protected]> 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
