Re: [ctwm] Imakefile and install paths
On Sat, Apr 26, 2014 at 06:55:12PM +0200 I heard the voice of Rhialto, and lo! it spake thus: So I would propose to commit the OnTopPriority things first, and then separately eradicate the WindowBoxes. They were probably never used anyway given their unfixed issues. I always feel a little sad yanking features that even often work. But I don't know nuffin' about WindowBoxes. I passed them by in the manpage once and thought huh, interesting, sounds like it could be useful for something, and then promptly forgot all about it until you mention them just now. So, _I_ wouldn't notice them disappearing. No idea whether anyone else would, though. Google doesn't point out anything but the source tree, but how many people's configs does Google have? My gut says if they prevent or significantly complicate something we know someone DOES want, or they're really unusable for anything, whack 'em. If it's more along the lines of will interact poorly when used with, I'm a little more inclined to keep 'em around in case someone is. Absent somebody speaking up and saying hey, I'm using that, I'd say your judgement. Not sure you'd wanna kill it just for being ugly and incomplete. But if it's getting in your way, well, sorry little WindowBox, you were just in the wrong file at the wrong time ;) -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
[ctwm] Imakefile and install paths
Traffic reminds me, I wanted to bring this up. A couple months back, I was converting the FreeBSD port of ctwm over to staging, which basically involves 'make install' putting the files somewhere else than where they will actually be on an installed system. This mostly went as uneventually as could be hoped, but I did find one issue in the Imakefile that needed fixing. http://svnweb.freebsd.org/ports/head/x11-wm/ctwm/files/patch-Imakefile?revision=340372view=markup I _think_ that's actually a bug that should just be fixed upstream, as DESTDIR is meant as the install fakeroot, and CONFDIR/PIXMAPDIR already include the full path relative to real root. But I'm not an expert in what Imake means by various things, so I figured I should get another pair of eyes on it before I pushed it upstream. So, anybody know a reason it's wrong? -- 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] Time for someone else to take over...
On Tue, Apr 22, 2014 at 01:05:26PM +0200 I heard the voice of Richard Levitte, and lo! it spake thus: I guess that interest is pretty damn non-existent then... [...] Deadline: mid may, I plan on pruning away free.lp.se and all that's included in it in the weekend of may 17-18. Ah, well, I read it as more a hey, I'm not really doing anything here, somebody who is feel free to pick it up than a get it away, get it away, kill it! 8-} While I don't get time to do much, I do maintain an interest (hey, I've even pushed up 2 commits already this year! ;). I can certainly take over web site handling. Probably mailing lists too. Code repo may be another story. I don't feel like I know mtn well enough to feel comfortable hosting it. A little browsing around only turns up one seemingly-live 3rd party hosting site. So maybe it would be time to VCS-migrate as part of the process. Richard mentioned the github mirror; it's a couple commits behind, but that's presumably trivial to update. I'm not a big git fan, but it's out there and there are lots of hosting options. I do love bzr, which has several hosting options, but while somewhat more lively than mtn, it's not by leaps and bounds sadly. I'm not aware of any existing ctwm momentum or users pushing hg, which seals up the triumvirate of the common DVCSen (in my experience, anyway). So with hg not being pushed at all, bzr probably only by me, and mtn not obviously attractive from the project management direction, it seems like we may wind up with git by default :| Well, at least it's not CVS... -- 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] Time for someone else to take over...
On Tue, Apr 22, 2014 at 09:40:50AM -0400 I heard the voice of Allen S. Rout, and lo! it spake thus: I see that the mailing list archive site is dead. That's a shame. On the plus side, gmane at least has stuff going back 11 years or so. http://dir.gmane.org/gmane.comp.window-managers.ctwm -- 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] Location of official CTWM source repository?
On Tue, Feb 12, 2013 at 06:36:28PM -0500 I heard the voice of Michael O'Donnell, and lo! it spake thus: Is the official CTWM source repository accessible? It doesn't seem to be directly linked, but the first part of http://ctwm.free.lp.se/monotone-crash-course.html still gives good info for getting it (at least, that still seems to be where I'm getting stuff from). -- 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] serious bug of xterm on ctwm
On Thu, Oct 25, 2012 at 12:20:21PM +0200 I heard the voice of Nadav Har'El, and lo! it spake thus: Anybody ever see this bug? Can't say that I have (and I also have xterm 285, and have no troubles from it). Maybe you could poke at xwininfo -root -tree or something to see if there's a hint about where a window should be but isn't? -- 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] serious bug of xterm on ctwm
On Thu, Oct 25, 2012 at 03:39:17PM +0200 I heard the voice of Nadav Har'El, and lo! it spake thus: The missing window that supposedly ctwm put up and disappeared is 0x8b. It's not listed in xwininfo -root -tree. All of ctwm's children appear to have the 0x14 ids. Mmm. Well, you said it's there for a while when you start up; see if you can find it then. Might give a hint of where it came from. xterm returns to working. But restarting ctwm, doesn't return this property. So perhaps I was wrong, and ctwm isn't at all the one which adds this wrong property for me? It appears (?) that ctwm adds _WIN_SUPPORTING_WM_CHECK, but NOT _NET_SUPPORTING_WM_CHECK. Indeed; I don't have a _NET_ anything. _NET_SUPPORTING_WM_CHECK is a EWHM property; x-ref http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2577320. And ctwm doesn't do any EWMH stuff. -- 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] [ANNOUNCE] CTWM 3.8.1 released
On Sat, Jan 07, 2012 at 12:08:43AM +0100 I heard the voice of Rhialto, and lo! it spake thus: I learned to use exec startx instead of just plain startx, for security reasons. [...] With exec startx there is no such possibility. I use `startx ; lock -np` for such things myself :) -- 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] [ANNOUNCE] CTWM 3.8.1 released
On Thu, Jan 05, 2012 at 11:11:37AM +0100 I heard the voice of Richard Levitte, and lo! it spake thus: I'm releasing ctwm 3.8.1, [...] For future releases, let's stick with dotted decimal numbers, and not have another X.Ya. I had to swing a big hammer for FreeBSD because the package version comparison routines consider 3.8a to be greater than 3.8.1 (8a being greater than 8). -- 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] Evaluating our requirements
On Sun, Jan 08, 2012 at 10:45:32PM -0500 I heard the voice of Stefan Monnier, and lo! it spake thus: 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. Well, hence reasonably competent, rather than complete :) Total support is fairly uncommon in any mainstream compilers. Large subsets are common across most current compilers (VS being the major exception, to my knowledge). And most of the things that strike me as useful in ctwm would fit within that fairly well. The additional integral types (particularly fixed size) are topping my mind right now, but things like block scoped declarations would be useful too. OTOH, if somebody has a good reason to use complex types in ctwm, I want to see how (in much the same way that I want to see how you blow up a continent with pop tarts, pipe cleaners, and excess dryer lint, anyway). In contrast, a lack of that fairly common subset would be more expected in obsolescent systems (AIXV3, say). Clarifying how much real pain drawing the line in various places causes actual users is what I want to draw out here. -- 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] Putting a development diff on the website.
On Tue, Jan 03, 2012 at 11:11:53AM +0100 I heard the voice of Rhialto, and lo! it spake thus: That made me think it would be better to just have a cumulative patch for everything since ctwm-3.8a. And in turn that made me wonder if it would make sense to just put such a diff on the website, next to the release itself. Instead of a diff, why not just do a tarball instead? We could call it ctwm-3.8.1.tar.gz, see... -- 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?
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?
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?
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?
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:
[ctwm] Silly occupy window...
Today I moved to a new workstation, so I got all the fun of setting up new monitor and video card and all that fun X stuff. But post-move, a minor ctwm issue showed up; calling f.occupy pulled up the occupy window like normal, except I didn't see any buttons, and the window was several dozen times as large as my screen in every direction. Um. Whoops? This tracks back to a few variables that are never initialized, unless some options that I didn't know existed are in the config file. Presumably it always got zero'd memory on my old system, so I never noticed (and probably on most other people's systems, 'cuz otherwise THEY'D have noticed). I've pushed a fix for it; attached is the 2-line patch in case anybody else runs into it. -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. # # old_revision [db710969dfa5d7225c4825c75aee971fb4572f8b] # # patch workmgr.c # from [8ea886eb10be3f1bdf3ae7010f4eb36cbe9382c5] #to [ea9dbcb2897548e5721e6a6cd2da57223c2dfaad] # --- workmgr.c 8ea886eb10be3f1bdf3ae7010f4eb36cbe9382c5 +++ workmgr.c ea9dbcb2897548e5721e6a6cd2da57223c2dfaad @@ -143,6 +143,8 @@ void InitWorkSpaceManager (void) Scr-workSpaceMgr.occupyWindow-geometry = NULL; Scr-workSpaceMgr.occupyWindow-columns = 0; Scr-workSpaceMgr.occupyWindow-twm_win = (TwmWindow*) 0; +Scr-workSpaceMgr.occupyWindow-vspace= Scr-WMgrVertButtonIndent; +Scr-workSpaceMgr.occupyWindow-hspace= Scr-WMgrHorizButtonIndent; Scr-workSpaceMgr.curColors.back = Scr-Black; Scr-workSpaceMgr.curColors.fore = Scr-White;
Re: [ctwm] [rt.lp.se #135] Bugfix for ctwm
On Tue, Oct 28, 2008 at 09:38:42AM -0500 I heard the voice of Matthew D. Fuller, and lo! it spake thus: 3) 1000. This is what ctwm initializes it to if there's no setting sitting around in a config file. We can assume that it's infinity. 3a) = 1000. Just in case somebody gets the idea that $REALLYBIGNUM should be used. I find myself leaning toward (3). Well, it's been about 8 months since I posted this. I choose to take silence for acceptance of my brilliance, so I've pushed (3a). -- 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] [rt.lp.se #135] Bugfix for ctwm
On Fri, Aug 22, 2008 at 07:22:52AM -0500 I heard the voice of Matthew D. Fuller, and lo! it spake thus: Give this a try if you can; if it works right for you (no reason it shouldn't), and nobody has objections, I'll commit it in a few days. Well, OK. A few days, 2 months, it's about the same thing, right? Anyway, it's committed now. This should be revisited to add either a flag or a special Threshold value to avoid the issue entirely and always OpaqueResize, especially since I suspect that's the very common case anyway. What's the feeling on the matter? I think adding a new keyword for Always would be an unnecessarily verbose way around it. 3 options present themselves for special Threshold values. 1) 0. It's possible that there's some side effect of setting OpaqueResize that some people desire, without wanting windows to actually ResizeOpaque'ly, though I can't think of what it could be. 2) 100. Assume 100% really means 100%. This could cause issues in the case of resizing bigger than the presumptive screen size, when somebody really does want to wireframe past that. 3) 1000. This is what ctwm initializes it to if there's no setting sitting around in a config file. We can assume that it's infinity. 3a) = 1000. Just in case somebody gets the idea that $REALLYBIGNUM should be used. I find myself leaning toward (3). -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] [rt.lp.se #135] Bugfix for ctwm
On Fri, Aug 22, 2008 at 04:37:58PM +0200 I heard the voice of Rhialto, and lo! it spake thus: Now how much this means in practice is difficult to predict. One useful rule I apply is that if something relatively slow happens directly as a result of user action, it doesn't matter, since humans are even slower. Well, that was my main support. This happens, once, at the beginning of a resize operation. It wouldn't happen at randomish times, doesn't happen in any sort of loop, and doesn't impose any ongoing cost except when initiating that one operation. And compared to the cost of DOING the opaque resize (or even drawing the wireframe for a non-opaque)... It could cost a million cycles, and probably not even be measurable. Noticeable isn't even a question. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] [rt.lp.se #135] Bugfix for ctwm
Tim, For large root window sizes, Scr-rootw * Scr-rooth * Scr-OpaqueResizeThreshold overflows a 32 bit signed integer. OK, now I just have to know; what the heck kinda root window size do you run to pull that off? In a glance at Newegg, the 30 widescreen LCD's run 2560x1600; that leaves that equation at around a fifth of the total necessary to overrun a int32. Heck, Wikipedia's list of resolutions shows the 'smallest' resolution that could blow up signed is probably WHSXGA (who comes up with these designations?) at 6400x4096. The change looks reasonable; I'll take a closer look shortly and integrate it. Of course, for testing, I may need to borrow your monitor for a year or two... ; Would you like a ctwm patch for antialiased freetype fonts? Well, we'd like a ctwm patch for just about anything you can think of. Sounds like it'd be lot harder to get reviewed though; the number of people who understand font rendering is a lot smaller than those of us that can hack basic algebra.8-} -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] [rt.lp.se #135] Bugfix for ctwm
Tim, For large root window sizes, Scr-rootw * Scr-rooth * Scr-OpaqueResizeThreshold overflows a 32 bit signed integer. OK, now I just have to know; what the heck kinda root window size do you run to pull that off? In a glance at Newegg, the 30 widescreen LCD's run 2560x1600; that leaves that equation at around a fifth of the total necessary to overrun a int32. Heck, Wikipedia's list of resolutions shows the 'smallest' resolution that could blow up signed is probably WHSXGA (who comes up with these designations?) at 6400x4096. The change looks reasonable; I'll take a closer look shortly and integrate it. Of course, for testing, I may need to borrow your monitor for a year or two... ; Would you like a ctwm patch for antialiased freetype fonts? Well, we'd like a ctwm patch for just about anything you can think of. Sounds like it'd be lot harder to get reviewed though; the number of people who understand font rendering is a lot smaller than those of us that can hack basic algebra.8-} -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] [rt.lp.se #134] ctwm crashed by ClickToFocus function turning on
On Sat, Dec 22, 2007 at 03:38:37PM +0100 I heard the voice of Rhialto, and lo! it spake thus: So I do think that Tmp_win-vs == NULL is indeed a bug. Somehow ctwm seems to think the window isn't on-screen. I wonder if it has something to do with being a transient window (which doesn't have occupation, without that option set, which isn't in the given rc file). -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] Depth-arrangement of windows is not preserved?
On Wed, Dec 05, 2007 at 08:56:06AM +0100 I heard the voice of Richard Levitte, and lo! it spake thus: You do realise that we've left the realm of technological precision and entered the realm of human subjectivity (something that C obviously allows!) a long time ago, don't you? :-) Well, we did that the moment we started talking about code standards. Coding standards are all about catering to human subjectivity. If technological precision is your baseline, you just write in machine code; everything from symbolic assembly on up is about talking to humans rather than machines. And if the compiler accepts it, it's sufficiently precise (it may well be _wrong_, but at least it's precisely wrong :). So you're zeroing in on the ++ and believe that says everything, eh? Well, that combined with the name... a 'tally' is a count, and incrementing is what you do with a counter. So I suggest that we keep talking but also start building a document that can slowly evolve to something we all (or at least those who care) can agree upon. I agree with that, but this bypath of it seems pretty solidly beaten into the ground. I don't know that we can either establish better where our individual lines of clarity are, and they don't seem likely to agree, so... One way to resolve endless disputes is to actually leave the point of discussion open or leave it as a recommendation. In the next significant block of time I can steal for ctwm stuff, I'll try to go through this and the other branches of the discussion, nail down the points of agreement, and try to come up with something on the points of disagreement that at least allows reasonable consistency. Probably won't be before at least next week, though :| Some things can more easily vary without causing a mess. e.g., these details of if() internals, for all that they drive me up a wall, don't make the code as a whole much more unreadable than it would be without, and having the style mixed doesn't detract much from reading through the code. Others can't; mixed indent or brace styles are Big Trouble In Little Readability, so they have to be nailed down a little more precisely. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] Depth-arrangement of windows is not preserved?
On Tue, Dec 04, 2007 at 07:58:02AM +0100 I heard the voice of Richard Levitte, and lo! it spake thus: I don't agree with that, as tally clearly has a boolean intent. Ah, but it doesn't; it's ++'d, not =1'd. Clearly it's a counter, not a boolean. if (!tally) could as well be if (buf[0] == '\0') But it could as well be if (!buf[0]) too. Where do you draw the line? That's misuse of a tristate value. It can't be used as a boolean. This is a case where I agree with you. Well, but I see it (as well as the above) as the same case. It most certainly can be used as a 'boolean' in the C if() manner, since it returns something that can get treated as a number. And I've seen it so used more times than I have the stomach lining to recall. It's more amenable to such treatment than a pointer, come to that; it's only a tri-state, not a 2**32 (or 2**64, for that matter)-state If you know C (and no, your brain doesn't have to be a C compiler), the meaning is obvious. Well, I like to think I know C. I've been doing it since before I did any other language (well, except BASIC, but I did the 12-step program and recovered from that after I picked up C. I swear I haven't touched it since!). But that construct never sat well with me; it always makes my brain lurch. fullermd a fair number of C coding standards I've seen mandate no fullermd explicit comparison for obvious predicates, and require the fullermd comparison when it's not). Actually, I like that. Now, all we need to clear is what constitutes the grey area of what is obvious and what is not. Oh, well, that's the crux of the disagreement, isn't it? ;) To me, if it's not fairly obviously (to the glance) and correctly (to code tracing) boolean, it doesn't belong bare in a conditional. Variables/functions with names like isallowed or can_access() meet the first criterion (and hopefully meet the second, or the implementor gets the Board Of Education across the back). Statements around binary comparison operators like == and meet both. If CtwmSetVScreenMap()'s 'tally' were called something like 'hasnames', it would satify the first condition. And if it were =1'd instead of ++'d, it would satify the second. It would still be an unnecessary variable, of course :] To me, though, things like pointers and non-bistate numeric types fail both; that they work is a side effect (intentional though it may be) of C's lacking a real boolean type and so treating other types as if they implicitly were such. I suspect that we've plowed this furrow pretty well by now, though. I think we're doomed to disagree. Worse, I think I'm outvoted :(. So, do you want to declare a Project Style on it, or leave it open? I'd suggest at least bounding marks on both sides, even if the middle is left to discretion. e.g.: - DO NOT use explicit tests on obvious predicates: if(user_can_change(this)==1) /* BAD */ if(user_can_change(this))/* GOOD */ - DO use explicit tests on functions that don't return intentionally (and obviously?) boolean values: while((tmp = get_next_window())) /* BAD */ while((tmp = get_next_window()) != NULL) /* GOOD */ if(!strcmp(x, y)) /* BAD */ if(strcmp(x, y)!=0) /* GOOD */ - [everything else] Probably should move on to the other (and largely most substantive) style questions... -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] SaveWorkspaceFocus
On Mon, Dec 03, 2007 at 05:29:45AM +0100 I heard the voice of Richard Levitte, and lo! it spake thus: Are those lines supposed to stay? At a glance, taking them out doesn't jump out at me as a necessary part of the feature. But I haven't had time to really look in-depth. (yeah, I know, I'm picking nits, but if can keep the code a little bit cleaner, it's probably gonna be a win in the long run) +1. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
[ctwm] Re: mtn-isms
On Fri, Nov 23, 2007 at 02:40:06PM +0100 I heard the voice of Richard Levitte, and lo! it spake thus: One way, a bit complicated but still workable: I would simply have kept hacking and committing into free.lp.se:X.ctwm in a separate database (ctwm.fullermd) [...] Mmm. The downside of that is making a repo for every new [concurrent] branch. That's awful heavy-weight. Even simple, though, is to just keep one database, but then hack away as needed, maybe in a separate workspace, commit whenever you feel like, and when you're done, pull from guardian, merge and push. But the downside of THAT is that I can only do one thing at a time, have to run it to completion before touching anything else, and a poorly-timed push will end up putting that incomplete stuff out in the world as another head on the branch to mess with other people. I don't much like that either :| How do other mtn-using projects do this? Presumably, cert-less revisions are a sufficiently Bad Thing(tm) that it's not an intended result (otherwise, -viz would treat them a little better). Certainly working one thing to completion at a time defeats the whole point of branching. I don't believe the standard workflow involves creating a new repo for every transient branch. And I have a really hard time believing every mtn-using project just grows an ever-increasing number of branches. That would be nuts; I've got plenty of rather small projects where that list would run to 50 or 80 branches, with all but 1 or _maybe_ 2 of them being defunct and pointless. And some of them would be _completely_ worthless, because they were branches that were made to try something that turned out to be a bad idea, and so were discarded without ever being merged. And that leaves completely aside the nastiness of globally-unique naming of the branches, avoiding which is one of the big plusses of the D in DVCS. If it's gonna be globally visible, or even eternally locally visible, I could never make a X.ctwm.compiler_errors; it would have to be X.ctwm.fullermd.compiler_errors.200710 or something even more painfully unwieldy and potentially misleading like that. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] Crash fix for when WorkSpaces not defined
On Fri, Nov 23, 2007 at 04:26:01AM +0100 I heard the voice of Richard Levitte, and lo! it spake thus: In message [EMAIL PROTECTED] on Fri, 23 Nov 2007 02:00:33 +0100, Rhialto [EMAIL PROTECTED] said: I pulled a new monotone repository and looked at it with monotone-viz, and something weird is going on. Maybe it's a monotone bug, or it may be with monotone-viz. Actually, it's less weird than you might think. I assume that Matthew did some hacking in a branch of his own, but since that branch is most probably not among those he's allowed to write to, the revisions themselves come over, but the branch certs do not. So basically, the edge between e07ab7de496e218dc324fe3a9cb66d85dde116d8 and a97d0dcc8eaf6e94ce9190d98913789d9dbbd37f represent the move from the ctwm branch to Matthew's private hackng branch, and the edge between 6eb1af5f822cafe715c4e46f37ea3bc808e7a5f5 and 4da54949171b2cc1c5f467318daf87b683a77d9b represent the move back into the ctwm branch. Yes, the entire run from a97d0dcc up through 4da549 happened in my private branch. While mtn isn't the way I went for my own stuff, working with a DVCS has well trained me to make throwaway branches for anything that looks likely to take more than 1 commit to do. I'm not sure what viz is showing breakage for, though; eyeballing the ancestry, it's unbroken, and I thought propagate would add on the X.ctwm branch certs. This is the boundaries of my mtn understanding, though. My workflow goes something like: - I have an 'upstream' repo which is what I pulled from guardian, and what I push back via. - I have a 'fullermd' repo into which I pulled just the X.ctwm branch from my 'upstream' repo, and in which I do my work. Then I propagate from my working branch into that X.ctwm, do a 'push' from there (which pushes that X.ctwm back to the 'upstream' repo), then go over to upstream and push it to guardian. The reasoning behind this is that such branches are throwaway; once they've done their job, they should just be tossed in the bitbucket since they don't have any further reason to exist. But once the branch sneaks out of my repo into upstream, it's eternal; I may get into the plumbing and delete it, but it'll reappear next time somebody else re-syncs. This way, the branches don't leak upstream, and when too many of them start showing up I can just rm the repo and re-create it (well, except that it also has the branch that I use for the local changes in my running ctwm... I guess I'll have to make a third repo for that when I get around to dumping this). So I have to go through extra hoops to keep my branches from leaking upstream. mtn docs don't tell me near enough to figure out appropriate ways of setting patterns (they barely tell me that there ARE patterns and how to see them) for syncing; I'm not even sure you CAN specify multiple levels of allow/deny. And anyway, it'd just accumulate unnecessary and distracting clutter over time. Thus, a bunch of contortionism. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] Crash fix for when WorkSpaces not defined)
On Fri, Nov 23, 2007 at 11:35:52AM +0100 I heard the voice of Richard Levitte, and lo! it spake thus: It's not a problem, it's the way mtn-viz is designed. It only displays revisions from the selected branches, plus entering and exiting revisions of propagates. Matthew's private revisions do not have branch certs (except in his database), and therefore belong to no branch, and are therefore unselectable (and undisplayable) by mtn-viz. Well, OK (and in my database, they're not on X.ctwm, they're on free.lp.se:X.ctwm.compiler_errors, so even a viz on X.ctwm there wouldn't show them?). But if prop doesn't do so (why not?), how WOULD I have brought those changes in so that they got certs for the X.ctwm branch? I mean, they're SUPPOSED to be on that branch now, right? Shouldn't they be noted as such? -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] Depth-arrangement of windows is not preserved?
On Fri, Nov 23, 2007 at 02:37:47AM +0100 I heard the voice of
Richard Levitte, and lo! it spake thus:
I generally agree. There's a lot of baggage, and I suspect some of
it comes all the way from twm itself.
At least. I think some of it rode with William the Conqueror ;)
I agree. To make it easy, we could add something similar to this
(but with C instead of C++ style comments) at the end of each file:
[to mull over]
Similarly, cramming two statements on one line like
i = 0; j = 0; is usually more hinderance than help.
Not sure I agree in all cases.
Well, I use them occasionally too. But saving 1 vertical line is such
a small gain that the first time it makes me mentally double-take,
it's already become a net loss.
I try to keep lines at sub-80, but there are cases where doing so
becomes butt ugly. Those are often better kept long.
Oh, certainly; formatting rules should never get in the way of making
code readable. But I don't think most of the violations of the 80-col
rule in the code base are the result of such considerations.
Yes, more well placed comments good! Anyone feeling like
documenting a piece of code somewhere with comments? By all the
mighty gods, don't let anything stop you!
It's one thing that's vaguely on my todo list. I'd have to do all the
figuring-out work for any real new stuff I have in mind anyway, so...
Cleaning up code and adding comments is so much easier than actually
trying to unravel X11 to figure out how to add the capabilities I
occasionally wish for anyway ;)
- We have too damn many global variables.
True, but they do serve a purpose.
Oh, absolutely. Global variables are very useful. But we've got a
wildly profane number of them, and I have a hard time believing that
even a quarter of them really belong.
Well, I'd like to differenciate between statements (such as if)
and functions. The former gets a space, the latter not. That goes
along with the BSD KNF style.
I've never seen that differentiation to bring me any value. I
mentally file it in the same category with the people carrying pikes
around to jam into the unwary who put ()'s on return statements.
Now, what exactly is wrong with else if?
Oh, it's not 'else if'; it's the cuddling.
} else if((foo(bar) baz) != (~FOO | baz)) {
As an Allmanite, I'd just write
}
else if((foo(bar) baz) != (~FOO | baz))
{
Sticking KR, you end up with
}
else if((foo(bar) baz) != (~FOO | baz)) {
which looks ugly (just not as ugly as the cuddled).
I generally agree, except CamelCase seems to be the general X11
style. I've no problem adapting to that.
Theoretically, if we were to underscore all our functions, then the
difference would have the bonus of making it instantly clear which
functions are ours and which are Xlib. But I wouldn't recommend a
wholesale renaming; just a rule to stick by for new stuff, and maybe
occasionally shifting around the old.
The former is yet one of those things that make me cringe. I can't
see how it's hard to search the latter...
When grep yields me a couple screenfulls of results for a function,
it's awful hard to find which one is the definition.
- Implicit comparisons as boolean (e.g., if(x) instead of
if(x!=NULL) and equivalents for numerics) bad.
Why?
Because they rely on side effects of conversion to a boolean
expression, and they don't make it clear exactly what you're testing
unless you already know exactly what the expression yields. With
explicit 0 and !=NULL, you do. And it can matter with signed
values; !=0 and 0 are two different assertions, but both evaluate
to true.
- I don't like multi-line comments that start on their first
line...
Why?
They feel unbalanced, unless you end them on their last line, which
looks ugly too.
Ugly (with or without the leading * on following lines):
/* Make sure our WorkSpaceWindow is properly initialized.
* Otherwise we'll get uninitialized fields in it in
* situations. */
Unbalanced:
/* Make sure our WorkSpaceWindow is properly initialized.
* Otherwise we'll get uninitialized fields in it in
* situations.
*/
Much better:
/*
* Make sure our WorkSpaceWindow is properly initialized.
* Otherwise we'll get uninitialized fields in it in
* situations.
*/
- We should probably have less commented out code.
I assume you're not talking about conditional code...
No, I mean pure commented out or #if 0'd code. See e.g.,
workmgr.c:1471
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
Re: [ctwm] Crash fix for when WorkSpaces not defined
On Fri, Nov 23, 2007 at 10:23:09AM +0100 I heard the voice of Rhialto, and lo! it spake thus: Yes, I'd assume it would appear unbroken to you, since you made the commits into your repository. Well, no, I'm looking at it in my 'upstream' repo, the same one I push to guardian; it never had the dev branch, only the X.ctwm propagate result. I don't have mtn-viz though; I have enough weird languages installed on my system already (OCaml? Haskell? What the heck? Is there some weird kool-aid they force-feed you when you start developing a VCS?). But I'm looking at log, and I don't understand why anything would be disconnected. There aren't any breaks in the ancestry chain. log doesn't show anything unusual. So I'm not sure what piece -viz is looking for that's missing. What connecting piece isn't there? -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
[ctwm] Re: mtn-isms
On Fri, Nov 23, 2007 at 01:41:35PM +0100 I heard the voice of Richard Levitte, and lo! it spake thus: Ah, and the following explains it: So, the question is, what should be done differently to avoid these broken bits (or at least pitfalls) in the future? Surely there's some answer less annoyingly manual than setting certs on a bunch of revisions one at a time (and hoping not to miss any). -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] Compiler warning fixes for review
On Mon, Oct 29, 2007 at 08:45:04PM -0500 I heard the voice of
Matthew D. Fuller, and lo! it spake thus:
See attached patch.
Well, hearing no objections, I've reread the patch enough to convince
myself that it's right (or at least, where wrong, the old code was at
least as wrong). So, this is pushed. At least one actual bug (var
used before defined) is fixed, as well as some potential latent ones
on platforms where sizeof(int) != sizeof(long), and some general
warning-petting beyond that. The most likely source of problems will
come from lex/yacc output code.
There remain a large hunk of warnings when strict-aliasing is enabled,
mostly around X{Find,Save}Context(). A large number can also be found
with -Wsign-compare that I didn't have the heart to get into. Maybe
next round...
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
[ctwm] Crash fix for when WorkSpaces not defined
When no WorkSpaces {} are defined in your .ctwmrc, parts of the
structure used to track them aren't initialized properly in the code.
This can lead to crashes when those pointers are dereferenced; I came
across it in the TwmWindows menu. I've pushed up a fix for this;
see attached patch.
I have a sneaky suspicion there are more such land mines scattered
through the code :|
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
#
#
# patch workmgr.c
# from [cbbb225102a852d23956bec573e7e10b61620c54]
#to [2d59af82aea7cee7cc29bb3db7f77be30fcb3fed]
#
--- workmgr.c cbbb225102a852d23956bec573e7e10b61620c54
+++ workmgr.c 2d59af82aea7cee7cc29bb3db7f77be30fcb3fed
@@ -168,8 +168,14 @@ void ConfigureWorkSpaceManager (void) {
virtualScreen *vs;
for (vs = Scr-vScreenList; vs != NULL; vs = vs-next) {
- WorkSpaceWindow *wsw = (WorkSpaceWindow*) malloc (sizeof
(WorkSpaceWindow));
- wsw-twm_win = (TwmWindow*) 0;
+ /*
+* Make sure this is all properly initialized to nothing. Otherwise
+* bad and undefined behavior can show up in certain cases (e.g.,
+* with no Workspaces {} defined in .ctwmrc, the only defined
+* workspace will be random memory bytes, which can causes crashes on
+* e.g. f.menu TwmWindows.)
+*/
+ WorkSpaceWindow *wsw = (WorkSpaceWindow*) calloc (1, sizeof
(WorkSpaceWindow));
wsw-state = Scr-workSpaceMgr.initialstate; /* BUTTONSSTATE */
vs-wsw = wsw;
}
Re: [ctwm] Crash fix for when WorkSpaces not defined
On Thu, Nov 22, 2007 at 08:44:27PM +0100 I heard the voice of Richard Levitte, and lo! it spake thus: Ehummm, I think it's time we take a look in the bugs database and try to fix some of the things (or dismiss it). Yeah, I was doing a little looking back over bugs and unresolved list posts when I got sidetracked by my Xnest-ed test ctwm blowing up every time I scrolled past my TWM Windows menu entry. Funny how that throws you off your stride. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
[ctwm] Signal handler messes
We've got problems in the signal handlers. Signal handlers seem to be set in 3 files. The good news: - util.c is all safe - menus.c is safe ctwm.c, however, is a different story. - SIGCHLD handler is safe, yay. - SIGHUP handler is doing a fprintf() which isn't async-signal-safe. Fortunately, that's merely cosmetic and can be pretty easily yanked. - SIGSEGV/BUS (Crash()) catcher is doing a lot of fprintf()'s, which aren't safe (but are merely informative and could be dropped). However, it's also calling out both indirectly and directly to Xlib functions(!!!) which have to be about the LEAST async-signal-safe functions you could find in the wild. - SIGINT/QUIT/TERM handler (Done()) commits all the above atrocities, and heaps on top the potential of calling out to *SOUND* playing functions. Caramba! The SIGHUP handler can be trivially made safe. The Crash() handler, I think, should just be removed; the clean cleanup stuff can't be done in the signal handler, and can't possibly be safely done at that point anyway since we're already in an ill-defined state. The begging of the user to send a stack trace can't be done safely in the signal handler, and the trace is likely corrupted already by jumping around the signal handlers. Done() probably needs to be switched to just calling _exit(2) (not exit(3)). A somewhat more involved possibility would be to set a flag we can check to do the more clean-like shutdown off in the main loop (which is probably the better choice, but is more work). Thoughts? -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] Ctrl-Return lost w/ ctwm 3.8a
On Tue, May 01, 2007 at 05:17:30PM -0400 I heard the voice of [EMAIL PROTECTED], and lo! it spake thus: I just tried 3.8a (XPM USEM4 GNOME I18N) and the Ctrl-Return isn't recognized anymore and isn't caught by ctwm for the altkeymap. It's just taken as a regular Return character. [months later] I'm unable to reproduce this in a little testing here. Mapping Return or Ctrl-Return to pulling up a menu works just fine with the current head in 'root' context or in 'all'. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] [rt.lp.se #133] Sticky NumLock for the pointer but not the keyboard
On Sun, Jul 01, 2007 at 07:25:27PM +0200 I heard the voice of Jens Schweikhardt via RT, and lo! it spake thus: Clicking the left button on the root window makes root/button m2 appear, even though NumLock is off (as per NumLock LED and per keyboard symbols). Is this a bug in ctwm? I wouldn't expect it to be; that info would all be getting passed through the X server to get to ctwm. In some quick testing here, I can't reproduce it; works just as expected for me. I'm using Pause remapped to Num Lock: % grep -A2 Pause ~/.xmodmap ! Pause - numlock keycode 0x6E = Num_LockBreak addmod2= Num_Lock -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] [rt.lp.se #134] ctwm crashed by ClickToFocus function turning on
On Sun, Aug 12, 2007 at 08:23:20PM +0200 I heard the voice of
佐藤 純弘 via RT, and lo! it spake thus:
to reproduce this,
1. run ctwmrc with attched .ctwmrc
2. then get no-title bar window popup
easiest way is using Firefox, go basic authenticated page
then enable to get password popup
3. click button to close popup (OK / Cancel /etc/)
4. ... then ctwm crash, get core.
I get a slightly different trace. Whether that's due to code changes,
or corruption from signal handlers, I don't know.
Mine is bombing out in events.c:2681, which is:
XTranslateCoordinates(dpy, Tmp_win-vs-window, [...]
Examination of the core in gdb shows that Tmp_win-vs is NULL, hence
the SEGV. The attached patch seems to prevent the crash here, but I
have no idea whether it's a correct fix, or just invalid in a
non-crashing way; it's very much shotgunned. Olaf may know better?
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
#
# old_revision [1dfd5be037e9fb09f9aee3d938dcca2848aa7744]
#
# patch events.c
# from [39f3358ff082d672b599845150ceab6806a03603]
#to [faecee097f0d8826210e043688de7642c4b3814d]
#
--- events.c39f3358ff082d672b599845150ceab6806a03603
+++ events.cfaecee097f0d8826210e043688de7642c4b3814d
@@ -2675,10 +2675,14 @@ void HandleButtonRelease(void)
if(xl 0 || yt 0 || xl Scr-rootw || yt Scr-rooth) {
int odestx, odesty;
int destx, desty;
- Window cr;
+ Window cr, tsrc;
virtualScreen *newvs;
- XTranslateCoordinates(dpy, Tmp_win-vs-window,
+ if(Tmp_win-vs!=NULL)
+ tsrc = Tmp_win-vs-window;
+ else
+ tsrc = Scr-Root;
+ XTranslateCoordinates(dpy, tsrc,
Scr-XineramaRoot, xl, yt, odestx, odesty, cr);
newvs = findIfVScreenOf(odestx, odesty);
Re: [ctwm] Modifying the modifiers for bindings...
On Wed, Jun 06, 2007 at 03:42:32PM +0200 I heard the voice of Richard Levitte, and lo! it spake thus: Well, with my new syntax suggestion, it's still possible to retain the old syntax for a while, possibly with BIG LETTER WARNINGS that the old syntax is going to disappear with version 4.0. I tend to like BIG LETTER WARNINGS, especially when something is going to continue being valid, but start meaning something different. Especially when it's something relatively subtlely different that will be hard to figure out if you don't already know the answer. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] Modifying the modifiers for bindings...
On Thu, Jun 07, 2007 at 09:10:02AM +1000 I heard the voice of Anthony Thyssen, and lo! it spake thus: All the modifiers are single letters, They're not, actually; I use control and meta in my rc file (and 'title' and 'window' and such for the location too, come to that). -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] Font sizes off in ctwm-3.8
On Mon, Apr 30, 2007 at 05:42:25AM -0400 I heard the voice of Stefan Monnier, and lo! it spake thus: 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 gotten a chance to try and dig it out, though. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
[ctwm] [PATCH] Icon manager not catching on to deiconification
In 3.8a, I noticed today that de-iconifying a window in one workspace (when it occupies multiple) doesn't update the status on the icon manager in other workspaces. Boy, that's clear. Let's try again: I have an xterm occupying two workspaces. In one workspace, I iconify and deiconify it. The icon manager shows it deiconified (no X on the left). I switch to the other workspace. The xterm is still deiconified, but the icon manager has the X showing it iconified. Tracking around the history shows that it appeared in rev d3f2af2a654ab0ce5003140e3704ebc924d555e2. It looks to be just a typo in the code shifting-around. Attached patch[0] fixes it for me. [0] Is there some way I can't find to make mtn export a rev in transmittable format, instead of just the diff? -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. # # # patch menus.c # from [511aee8c768cc6b109bf8e59c1b1e9729078c2db] #to [5fb6bfd5fa020af6294336144a2920563451c007] # --- menus.c 511aee8c768cc6b109bf8e59c1b1e9729078c2db +++ menus.c 5fb6bfd5fa020af6294336144a2920563451c007 @@ -4052,7 +4052,7 @@ static void ReMapOne(TwmWindow *t, TwmWi WList *wl; for (wl = t-list; wl != NULL; wl = wl-nextv) - XUnmapWindow(dpy, t-list-icon); + XUnmapWindow(dpy, wl-icon); } t-isicon = FALSE; t-icon_on = FALSE;
Re: [ctwm] closing occupy window causes crash
On Tue, Feb 13, 2007 at 08:53:56PM +0100 I heard the voice of Rhialto, and lo! it spake thus: On the other hand I do notice that Expose events don't always repaint the Occupy window. (I notice it because I attached a menu to an extra title bar button, and when the menu disappears the occupy window below it isn't repainted, IF the menu had not obscured the part below the workspace). This sounds like the Occupy window problem I've posted about once or twice. I'll try to find some time to test it out before/after over the next few days if nobody beats me to it. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] [rt.lp.se #129] Funny behaviour of Occupy Window
On Tue, Jan 23, 2007 at 12:06:31AM +0100 I heard the voice of Olaf Seibert via RT, and lo! it spake thus: Do the following steps to see some funny behaviour of the Occupy window: Speaking of funny behavior of the Occupy window, has anybody ever seen anything like my post ~1.5 years ago about odd sized Occupy windows not [re]drawing? I'm still stuck with manually sizing them up a pixel or two every time I start ctwm so that they show up. Subject: Terribly odd Occupy window... Date: Sun, 5 Jun 2005 03:06:42 -0500 Message-ID: [EMAIL PROTECTED] Or: http://tigerdyr.wheel.dk/ctwm-archive/1560.html -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] Depth-arrangement of windows is not preserved?
On Fri, Dec 22, 2006 at 05:35:00PM +0100 I heard the voice of Rhialto, and lo! it spake thus: For an example of the style that I like, see what DisplayWin() in workmgr.c. Just to be contrary, I find that to be just about the _worst_ possible style. I indent with tabs, and highly dislike indenting with spaces, but surely the worst of both worlds it indenting with *BOTH*. The code is then only remotely readable with an 8-char tabstop. With my standard 4-char tabstops, it only seems to indent every _other_ block. With a 2-char tabstop, it indents a long ways, then outdents a little, then indents another long ways, then outdents a little, then... Related, tabs for alignment (e.g. on the variable declarations at the top of the function) are IMAO the wrong place to use tabs as well. (I don't care for KR braces, or for spaces between function names and args either, but those are more minor details) -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
[ctwm] Re: What's up with the ctwm website?
On Thu, Aug 24, 2006 at 01:37:09AM +0200 I heard the voice of Richard Levitte - VMS Whacker, and lo! it spake thus: It wasn't the router, it was a crashed apache. It's back up now. Hm, I'm not seeing it... % telnet ctwm.free.lp.se 80 Trying 82.183.134.65... telnet: connect to address 82.183.134.65: Operation timed out telnet: Unable to connect to remote host -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
[ctwm] Re: Will upgrade monotone some time next week
On Sat, May 20, 2006 at 12:48:45PM +0200 I heard the voice of Richard Levitte - VMS Whacker, and lo! it spake thus: If you have any question, please ask and I'll help you as much as I can. I took this as an opportunity to try this again; I've had horrible luck getting monotone to work at all, finally tracked down to b0rkedness in the boost libraries. The problem now, I find, is that the database somehow seems to still want to use repository.lp.se as the server to connect to when I do a `mtn pull` from the working dir. Since I know I didn't do the initial pull from there, I presume it's inheriting that info somehow, but I'm not sure how to change it. The online help and manpage don't seem to give me any hints... -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
[ctwm] Re: [repository.lp.se #114] Folding menus
On Mon, Jan 30, 2006 at 03:54:43PM +0100 I heard the voice of J.O. Aho, and lo! it spake thus: Why make the meny that big in the first place? I like to have submenus so that I don't have any big ones. I have a menu with all the xlock modes on it (for no particularly good reason, other than that the idea stuck me once). I ended up writing a perl script to parse the xlock mode list output and generate a set of more'd submenus with 25 modes on each. It comes out to 5 of 'em, each of which is a bit less than half the height of my screen. (Actually, it doesn't generate ctwm menus as output, it generates perl definitions of ctwm menus, since I build them with a perl script on the fly, but who wants to get THAT nutty? ;) -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
[ctwm] Re: Small installation issues, and a f.resize bug
On Sun, Jan 29, 2006 at 01:45:06PM +0100 I heard the voice of Richard Levitte - VMS Whacker, and lo! it spake thus: You mention the auto* tools, and although they are good and tested, the result is definitely not portable outside of the Unix family or operating systems, and there are much more that have X11. As well, not everybody is a big fan of auto*... * README should explain that if you want to install the manual page (and who doesn't?), you should also do make install.man in addition to make install. Again, the idea of doing make install.man went the way of the dodo, but if ctwm keeps it we should at least document it. From everything I can find (the worst thing with imake is it's *utter* *lack* *of* *documentation*!), that's the way it's supposed to be, probably to avoid reinstalling the man pages multiple times on a shared filesystem in a heterogenous environment. Changing it would require some hackery in higher-level build systems, too. For instance, FreeBSD ports knows that Imake-managed build systems use install.man to install manpages, so it will do the install.man as part of its install process already. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ANNOUNCE] Releasing ctwm 3.7 beta4.
On Thu, May 05, 2005 at 09:58:30AM +0200 I heard the voice of Richard Levitte - VMS Whacker, and lo! it spake thus: Release of ctwm 3.7 beta 4. A little slower this time :| FreeBSD port updated to b4. http://www.over-yonder.net/~fullermd/dl/ctwm-b4-port.tar.gz -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ANNOUNCE] Releasing ctwm 3.7 beta2.
On Tue, May 03, 2005 at 05:02:49PM +0200 I heard the voice of Richard Levitte - VMS Whacker, and lo! it spake thus: Release of ctwm 3.7 beta 2. FreeBSD port updated (heck with the patches, they're 3/4 of the size of the whole port anyway). http://www.over-yonder.net/~fullermd/dl/ctwm-b2-port.tar.gz -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [repository.lp.se #107] Multiple Bugs found on ctwm 3.7a5 (from cvs)
On Tue, Apr 19, 2005 at 11:28:58AM +0200 I heard the voice of Richard Levitte via RT, and lo! it spake thus: [EMAIL PROTECTED] - Tue Apr 19 08:37:01 2005]: Well, speaking purely for myself, I *LIKE* the predictable placement. Do you actually get that behavior with 3.7a6? Anthony's complaint is that two xterms in a row will have them at the exact same spot. I just fired up 8 terms in a row (xterm ; xterm ; etc) and they cascaded normally. I s'pose there could be a race condition in the timing somewhere that my machine isn't fast enough to hit, but I've never seen it happen, even when popping up 20 or 30 cities at a time in Freeciv. I think Anthony just abused ctwm in a previous life, and it's taking revenge now 8-} -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet
Re: 3.7-alpha6 is out!
On Wed, Apr 13, 2005 at 07:39:37AM +0200 I heard the voice of
Richard Levitte - VMS Whacker, and lo! it spake thus:
In message [EMAIL PROTECTED] on Tue, 12 Apr 2005 17:11:38 -0500, Matthew
D. Fuller [EMAIL PROTECTED] said:
fullermd Faster mirrors would probably be a big plus, as I'm getting
fullermd 10k/s,
10k/s? There's something else bogging on the way between you and my
server. I get around 75k/s from a very well connected size
(stacken.kth.se). It may be that some other traffic was going on as
well, it sometimes happens that I download some big thing to check
out, and that sometimes affects traffic quite a lot.
Yeah, it's about what I'd expect out of 256k, not 1m. Of course,
there's an awful lot of net between here and there; 25 hops or so,
with ~160ms RTT's. If my memory is working (always questionable :),
that's around the same speed I got a few months back, too. I just did
another run, and got about the same:
[0:42:08] mortis:/tmp
(ttypd):{381}% fetch http://ctwm.free.lp.se/preview/ctwm-3.7-alpha6.tar.gz
ctwm-3.7-alpha6.tar.gz100% of 787 kB 11 kBps 00m00s
So I s'pose it's a permanent condition of this particular network
path, sadly.
fullermd http://www.over-yonder.net/~fullermd/dl/ctwm-a6-patch.gz
Uhmm, that's a patch of a FreeBSD, with patches of patches... OK,
I'll look it through and see what I'll do with it...
Oh, yes. It's a patch of the ctwm port (at least, what the ctwm port
was a day or three ago; pretty sure it hasn't changed) to pull 3.7-a6.
And some of the patches in the port have changed, so it patches the
patches. Think of it as security by obscurity ;
I've built and installed a6 from it, and it seems to be working right.
Not of much interest to people who don't use the FreeBSD port,
though...
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet
Re: [repository.lp.se #51] ctwm(1x) bug-report: no international chars. allowed in rc-files
On Sun, Feb 27, 2005 at 02:13:59AM +0100 I heard the voice of Richard Levitte via RT, and lo! it spake thus: In Imakefile, check what happens when I18N is defined. It's undefined by default. Actually, I think the default is silly, so I'd like to ask the general public if there would be any negative effects if I18N was defined by default. The FreeBSD port has built with I18N turned on for 2 years and change. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet
Re: What release to do
On Tue, Feb 22, 2005 at 10:00:16AM +0100 I heard the voice of Michael Widerkrantz, and lo! it spake thus: You realize that the children of the GTK phantom windows (that is, all visible windows in GTK applications) seen from a ctwm point of view has been indistinguishable from transients until 3.7? That is, if you use TransientHasOccupation that will also allow you to use f.occupy on GTK windows. I did. But that causes all sorts of other problems, such as transients then ALWAYS opening in the same workspace they first opened in, instead of the workspace I'm in now. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet
Re: What release to do
On Wed, Feb 23, 2005 at 10:04:48AM +1000 I heard the voice of Anthony Thyssen, and lo! it spake thus: Matthew D. Fuller on wrote... | ... so I can f.setoccupy Mozilla finally. I can't find f.setoccupy in the 3.7a5 manpage If it is not documented, it basically may as well not exist for non-development users Heck, f.setoccupy doesn't even exist for development users. f.occupy does, though, so everything but my brain should keep working 8-} -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet
Re: What release to do
On Mon, Feb 21, 2005 at 03:06:05PM +0100 I heard the voice of Richard Levitte - VMS Whacker, and lo! it spake thus: In message [EMAIL PROTECTED] on Mon, 21 Feb 2005 15:48:41 +0100 (CET), [EMAIL PROTECTED] said: dl Again, sorry for the outburst. Hmm, OK, I need som clarity here. I recall that there were some problems with Gnome and KDE, are those no more? I don't have the time to test with those desktop systems myself, so please help me bring clarity in my mind. It was my understanding (just from the list, since I don't use 'em either) that whatever problems there were, were in 3.6 as well, so while it may be a bug, it's not a regression. Something that should be fixed, perhaps, but not an argument against 3.7 qua 3.7. Of course, I could be all wet; if they ARE regressions, then they do need to be smacked down. But ISTM that _that_ is the question to be answered. If 3.7a5 is good enough to go to beta or release state, even with the stuff I don't check, I'm all for it! I'm using CTWM 3.7a5 myself, just as it is without any desktop system, and I'm quite happy with it for now. I'd back it. I went from 3.6 to 3.7a5 without having to change anything in my rc file, and everything worked just fine. And it certainly seems a step forward, even if only for being able to deal with those stupid phantom GTK windows so I can f.setoccupy Mozilla finally. There's plenty of parts of the code that I don't exercise at all, though, so that may not mean much. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet
Re: [repository.lp.se #104] Bug in ctwm-3.6
On Sun, Feb 20, 2005 at 12:06:10PM +0100 I heard the voice of Peter Flystam via RT, and lo! it spake thus: I've found what I think is a bug in the source distribution of ctwm-3.6 that is available at There's a number of these in 3.6. AFAIK, they're all resolved in the 3.7 alpha. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet
Re: [repository.lp.se #104] Bug in ctwm-3.6
On Sun, Feb 20, 2005 at 01:46:32PM +0100 I heard the voice of Richard Levitte - VMS Whacker via RT, and lo! it spake thus: In message [EMAIL PROTECTED] on Sun, 20 Feb 2005 05:39:31 -0600, Matthew D. Fuller [EMAIL PROTECTED] said: fullermd There's a number of these in 3.6. AFAIK, they're all fullermd resolved in the 3.7 alpha. True, but I think it might be wise to transfer some of those to 3.6 and make a bug fix release. It's been long overdue, really. And I could also transfer things that are known to work... I think we should have a bug fix release called 3.7 8-} -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet
Re: CTWM 3.7 alpha4 is out.
On Wed, Mar 05, 2003 at 02:26:46PM +0100 I heard the voice of Richard Levitte - VMS Whacker, and lo! it spake thus: In message [EMAIL PROTECTED] on Wed, 5 Mar 2003 08:05:17 -0500, Michael George [EMAIL PROTECTED] said: george This is the classic scenario that all of us have used or still use (I george do the same as you do, except I don't have ctwm as the last thing, george since I occasionally test other window managers, and would like to do george so without being logged out). george george I've found the best, why would I switch? :) In my case, because I enjoy playing around. Also, it's good to know the enemy :-). Heck, that's what Xnest is for :P (or just starting up another full X server) -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet
Re: [cvs.lp.se #14] [PATCH] Multi-entry lists, configuration check mode
On Fri, Feb 21, 2003 at 09:00:13AM +0100 I heard the voice of
Richard Levitte - VMS Whacker, and lo! it spake thus:
In message [EMAIL PROTECTED] on Fri, 21 Feb 2003
08:46:31 +0100, Claude Lecommandeur [EMAIL PROTECTED] said:
claude.lecommandeurWouldn't the best solution to have support for
claude.lecommandeur decent (perlish) regular expressions :
claude.lecommandeur
claude.lecommandeur ^(foo|bar)$ value
claude.lecommandeur
claude.lecommandeurregex can do this.
Hmm, in certain cases, that would mean using part of the GNU C
Library, which is licensed under the LGPL. What would that mean for
me, distribution-wise?
I don't think it matters; you're _already_ using part of the GNU C
Library in certain cases (i.e., on any system with glibc :). The
regex(3) functions from Henry Spencer aren't [L]GPL'd, and there's also
the choice of PCRE; either, as far as I can tell, are mostly BSD-style
licensed.
I actually did momentarily consider using regular expressions when I
wrote the original patch, but I dismissed it as absurd overkill (and for
_ME_ to pass up on overkill is unusual ;) and just went for
comma-seperated.
Now, one idea is to go to |-seperated lists inside ()'s; sort of
hand-implementing just the (a|b|c) part of regular expressions. Thus,
the code would treat foo as it does now, but special-case if the entry
started with a '(' as a |-seperated list. That would work; would take
about 5 minutes to update the code for, would make it perhaps more
obvious what it's doing... And anybody who makes a window class whose
name starts with '(' deserves what they get ;-p
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
The only reason I'm burning my candle at both ends, is because I
haven't figured out how to light the middle yet
Re: [cvs.lp.se #14] [PATCH] Multi-entry lists, configuration check mode
On Fri, Feb 21, 2003 at 12:11:14AM +0100 I heard the voice of Richard Levitte via RT, and lo! it spake thus: I like the configuration checking mode! It's applied. Cool 8-) It's saved my bacon more than once when I did something stupid like forgetting a in the middle of the config file... I also took a look at the comma-separated tokens patch, but didn't like it. I'd prefer if the syntax was like this: foo,bar value I understand that it's more challenging to make it that way, since that requires some hackery in gram.y. I'll ponder over this, but if you want to work on it in that direction, I'm willing to look at an updated patch. Hm. Let me take a little stream-of-consciousness wander on this... First off, it doesn't matter _that_ much to me. I Got Mine (tm) so to speak; my goal was to be able to have Netscape (4.x), AND Mozilla, AND Opera, AND occasionally other browsers, just all be lumped together in one Web Browsers icon manager. It works, I'm happy. Now, going beyond that; I can certainly see how it's perhaps a bit hairy; what if your window class had a ',' in it? Bad style, IMO, but it can happen. I have stylistic issues with the syntax you listed, though. The big thing is that a line is a set of atoms, seperated by whitespace. Each atom is enclosed with 's. Beyond that, the parser doesn't care. Now, you're making one of the atoms also consist of atoms seperated by ,'s. You're breaking the Zero, One, Many rule; why 2 levels of delineation? Why can't I (generic 'I') do 3, or 8? At that point, you're almost getting to the point where you would prefer something like XML or Lisp-type S-expressions (hmmm 8-). Now, all THAT aside, I can't say I really have a better idea than a list of comma-seperated elements in a list being an atom of a set of space-seperated elements in a list, that wouldn't require more massive re-working. It might give me a good excuse to finally break down and really learn yacc. Whether I'll actually have time to really look into it, certainly before 3.7 is cut, is another matter entirely... -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet
