On Tue, Jan 24, 2017 at 10:10:58AM -0500 I heard the voice of
[email protected], and lo! it spake thus:
>
> I'm rather curious as to why twm is mentioned? True, it's reflective
> of ctwm's roots, but why in the version string?
At the moment, because I wasn't really inspired to pull it out. I've
certainly severed a lot of our [mostly cosmetic] ties to twm lately,
but I left that one alone. Not that I'm particularly attached to it,
just didn't bother with the extra churn.
It does sorta fit analogously to how we set TWM_TYPE for the m4
defines, so you can still conceptually use the same .twmrc for
multiple different twm descendents at the same time. Even twm, though
in that case you'd have to do the processing step manually...
> I was giving the man page a very quick once over and I noticed quite
> a few occurrences of the string "%%NEXT%%". I'm fairly certain that
> version related text was intended in these places.
Yes, but it's intentionally left for the moment. I put that in as a
placeholder, to be replaced as one of the final steps in making a
release. That way if we change our mind about what the next release
is, or if we decide we have to go back and branch off for a 3.8.3 or
some other thing, we can do the sub at those times and have the right
info, instead of having to do a lot more digging and hunting (or, more
likely, forgetting about it and having slightly wrong info).
> I started ctwm with the default config. When I mouse over the menu
> buttons they go blank.
I'd guess that's probably the new version expecting the pixmaps in a
different place than the old version put 'em. Try setting
PixmapDirectory explicitly in the config file to wherever they are
(either installed versions from the old ctwm, or into the source tree
of the new one; the images in there haven't changed in a while).
> The menu items are also off on the y axis (which is the x and which
> is the y is implementation defined :) as is the cool 3D effect which
> does not have any text at all on it.
Not really sure what that would be, or maybe even mean. Stick a
screenshot up on a web server somewhere, we can take a look.
Now, peripherally to the above, I wouldn't argue with somebody
suggesting the default config could use some work. Partially I
think it has some oddities because it's simultaneously acting as
fallback/default, and example. Still probably dated and odd. But
it's way too far down my list to possibly make it into 4.0.0,
unless the release got pushed waaaay back, and it's already
probably overdue.
That certainly shouldn't discourage anybody else from messing with
it though!
> the window info function has lots of new lines and might scroll off
> the screen (It's eating the real estate currently).
Shouldn't, unless you've got a real tiny screen (or a really big
font). It'll reposition itself to not shift off the edge of the
screen. So unless it's bigger than your screen...
> Hmm. I think the only thing missing is to bind the mouse scroll
> wheel to the change work space behaviour (I forget if that would
> work or if there is a function for that ... grep ... grep ... grep,
> nope, can't find it).
Mouse wheel clicks turn up as button presses (4/5 for me), so binding
to e.g. f.{next,prev}workspace or the like should work OK. Though you
probably want to bind it with Ctrl or some other modifier, or you
won't be able to use it to scroll in regular apps (well, or not bind
it in the window context, but that may be worse from a usability
standpoint).
--
Matthew Fuller (MF4839) | [email protected]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
