Re: I just finished my ctwm docs

On Thu, 12 Oct 2017 08:13:00 -0500
"Matthew D. Fuller" <[email protected]> wrote:

> On Sat, Oct 07, 2017 at 10:13:35PM -0400 I heard the voice of
> Steve Litt, and lo! it spake thus:
> > 
> > I mentioned I was writing documentation about ctwm for
> > Troubleshooters.Com. I finished the docs, and they're at
> > http://troubleshooters.com/linux/ctwm  
> 
> Some notes in going through:
> 

Thanks for this thorough feedback, Matthew. This email contains
responses to the easy low-hanging fruit.


>     The nested/window-mode ctwm with -w is still high up on my mental
>     chopping block; it's a really weird thing that doesn't actually
>     work all that well in a lot of ways, has fingers mucking up a lot
>     of different parts of the code, and has been involved in some
>     weird bugs in the past even when you're not using it. 

Yes, -w is definitely twitchy. I once tried to import a base window
into the ctwm -w window, and that made a mess that finally resulted in
my killing X. 

>     I would
>     definitely recommend not even mentioning its existence; xnest is
>     better in every practical and most impractical ways.

I could recommend xnest, but not until I solve some of its problems.
First, it's horribly underdocumented --- I spoze I could fix that. But
also, ctwm acts funny within it. First is the deficiency also shown by
ctwm -w: hotkeys are intercepted by the base server (display :0) before
going to xnest (display :1), so hotkeys are out. Unless I include a
menu path to execute dmenu, this is a severely retarding influence (no
different than ctwm -w, though).

So I can't really change this until I solve some problems with running
ctwm in Xnest.




>   - "About Icons".  I'd probably move this into a place talking about
>     the icon manager.  In ctwm (and twm before it, for that matter)
>     I've always just used the icon manager and IconifyByUnmapping, so
>     icons never show up at all.  Other people do differ.

About a day after releasing this document,  I realized ctwm is at a big
disadvantage without full icon support. Also, Aaron Sloman pointed this
out to me. And now you.

I'll remove this very negative "About icons" sections, and probably add
a full document on icons and the icon manager.

> 
> 
> - install.htm
> 
>   - "Download either ctwm-4.0.1.tar.xz or ctwm-4.0.1.tar.xz."  You
>     probably wanted one of those to be .gz.  

Fixed!


>     I'd consider skipping
>     talking about .gz depending on your audience, since it's just
>     there for what are now pretty old systems that lack xz.

I left in the .gz. A lot of people still use that, especially for
archival purposes.

> 
>   - "Testing ctwm" (and the cp'ing of system.ctwmrc earlier); trust
>     me, nobody running ctwm uses or thinks too highly of the
>     system.ctwmrc   :).  Note that it's also baked into the binary, so
>     if you don't have a .ctwmrc (or .twmrc, as a fallback), it'll get
>     used anyway, so you may not have to bother cp'ing it around.

I'm glad to know I'm not alone in thinking the default messy. I left
the blurb about copying to ~/.ctwmrc in there on the theory that we all
like a known state.


> 
> 
> - modernize.htm
> 
>   - (various comments handled in talking about config)
> 
>   - f.fullscreenzoom mentions using F11 to "come back", but that isn't
>     something ctwm would do unless you added a key binding for it
>     (which I don't see in your config).  Some _programs_ (like
>     Firefox) use F11 

Ouch! I hate giving bad advice: Thanks for pointing this out to me. 

I just fixed it, telling them to move the window down and to the left,
then shrink it.



>   - "Accommodating Workspaces"
> 
>     - "There are two ways to navigate workspaces: Brute force menus,
>       and the super-magic workspace thingy, which looks like 8
>       chicklets in 2 rows of 4 columns each. This section uses a
>       little of each."
> 
>       Actually, there's at least one more; keybindings, which you then
>       talk about and have in your sample config, and are probably
>       widely used anyway.

I know that, and you know that, but the person not knowing it will
probably encounter it as a 2x4. I thought about more explanation, and
decided against it.

> 
>       Also, the size and layout of the WSM is pretty depending on how
>       you config it; e.g., mine (when it's shown, which is extremely
>       rarely) is currently a 3x3 grid, and in your sample config,
>       you've got it 8-wide in 1 row.

Again, not wanting to overload the reader, I left this for her/him to
discover.


> 
> - menu_behavior.htm
> 
>   - The "Slide left" behavior for the mouse is wrong.  Sliding left by
>     itself never does anything, no matter what entry you're on.

Fixed.
 
> 
> - patch.htm
> 
>   - vim-style menu navigation is an interesting idea.  I'll bet there
>     are ways that could be cleanly(*) made an option.

You bet there are. I had Vim-key menu navigation running for awhile
(with my patch) but took it out because I don't like changing other
peoples' code because I don't know their design priorities. My j,k,h
and l hotkeys overrode ctwm's excellent first letter recognition, so
probably in real life they should have a modifer like alt or ctrl.

> 
>       (*) Well, not significantly less clean than anything else around
>           that part of the codebase, anyway...
> 
>   - Re: the patch, I'd generally suggest something more like
> 
> -                                       if(!strcmp(keynam, "Return"))
> {
> +                                       if(0 && !strcmp(keynam,
> "Return")) {
> 
>     instead of messing with the string being compared; it's more
>     explicit about the intention to the reader, as well as making it
>     completely removable by the compiler.  Or using the preprocessor
>     to remove it, but that takes TWO lines instead of one, so it's
>     obviously only half as good.

You're right, of course, but I left the patch alone because as of your
next version release this becomes a moot point and I remove all
references to the patch.

> 
> - stevelitt_ctwmrc.htm (and -1.0.ctwmrc)
> 
>   - I've academic interest in how MaxWindowSize is helping you.  I had
>     it in my config for years, but I eventually took it out, because I
>     pretty much never saw it helping anything, and even once in a
>     great while (~yearly, if perhaps less) it got in my way.

I'm not sure, but I think it makes sure my maximized windows are the
correct size. Don't shoot me if I'm wrong.

> 
>   - BorderWidth and ThreeDBorderWidth.  If you're
>     UseThreeDBorders'ing, BorderWidth is meaningless.

I just set them to the same thing in case I switch between 3D and flat.


> 
>   - The various bits you have "Help kbd instantiated windows get
>     focus" commented probably need a little more precise explanation.
>     UsePPosition especially doesn't have anything to do with focus,
>     but with positioning, and ditto RandomPlacement.  Possibly you
>     mean how that just plop the window somewhere rather than waiting
>     for the user to position?  Of course, if you have RandomPlacement
>     on, UsePPosition wouldn't be needed for that anyway, and
>     RandomPlacement "on" is the default in 4.0.0+ as well.

That .ctwmrc code was some of the first I wrote, before I was even sure
I was going to spend any time with ctwm. It was a result of rapid fire
trial and error to get the behavior I wanted.

You're right about waiting for the user to position. In a workflow
where 90%+ of all windows result from a hotkey, requiring the user to
position the window would bring productivity to a halt.

> 
>     Now, I don't see any obvious reason it would be difficult or
>     ambiguous to add an AutoFocusToNewWindows or the like...  there
>     are certainly the various (IMO unpleasant) side effects, but
>     that's not the WM's fault.

I might examine that later. So far, my stevelitt.ctwmrc is working very
well for me, so further experimentation is a lower priority.

> 
>   - You may want to rethink whether to set NoDefaults; as long as
>     you're making some adjustments to the icons on the titlebar
>     anyway, you may want to just take over from scratch.  That's pure
>     personal style though.

Turns out I regularly use the default provided iconize and resize
buttons, and simply add to those. Given that the NoDefaults also
removes some default behavior, according to the man page, I took the
safe rout and left the defaults intact.

>   - On the menus:
> 
>     - There's probably no reason you need xcalc/xman/xmag on there  :)

xcalc and xman, you're right. Xmag, I did this:

 "Xmag"		!"xmag -mag 3 -source 600x300 &"

Yeah! Perfect!


> 
>     - menu "workspace-special" looks like a fossil from
>       experimentation; probably not needed in a dist'd config.

Yeah, that'll be gone in 1.1

> 
>     - I'd definitely lose the f.adoptwindow binding, along with the
>       other nested stuff above.  

Good catch. f.adoptwindow is just plain dangerous. That'll be gone in
1.1.

Thanks so much for this detailed report!
 
SteveT

Steve Litt 
October 2017 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21