On Sat, 4 Mar 2017 10:56:01 -0600
"Matthew D. Fuller" <[email protected]> wrote:
<snip>
> Let's not forget to bear in mind that whatever gets come up with, it
> ain't gonna make everybody particularly happy. And that it's not
> really for any of us anyway; we're all gonna keep using the baroque
> monstrosities of custom config we've come up with for ourselves over
> the years.
>
> We want something that provides a useful environment for somebody just
> trying it out, and hopefully simultaneously serves as a good example
> config for some of what's possible. Of course, those goals are a
> little contradictory...
Isn't that a little self explanatory?
Is there some particular thing that I've not noticed that caused you to
write this?
> So that said, some thoughts I have from poking at it. A lot are
> probably matters of taste, so take 'em from that perspective. This is
> discussion and suggestion, not veiled [or un-] commands!
>
> - Some defaults should be the other way around I think. OTOH, I'm
> gonna mostly ignore that in this mail, because I'm nearly certain
> I'm gonna do that down in the code anyway; expect another mail about
> that sometime soon...
>
> - If'n you ask me, ShowIconManager and IconifyByUnmapping are
> Fundamental(tm). Having actual icons around for iconified stuff as
> the way to access them seems clunky as heck once you get more than a
> few windows, never mind the fun when they wind up below the windows
> you actually have up. Of course, I hear tell there are some weirdos
> on the list who DO use icons and DON'T use the icon manager at all.
> But, they're weird. Proof: they're on this list.
Good idea.
> - Also I'd lean toward RandomPlacement; having to manually choose the
> position of new windows, and having everything blocked until you do,
> would be pretty peculiar to people used to other environments.
I strongly disagree. The reason I like ctwm/fvwm is because they can
place windows where *I* want them instead of directly over top of the
window I'm working on.
That being said, if there was a way (think future), that ctwm could only
select random placement if a window would not overlap another then I'd go
for that (except for full screen ones, of course).
> - It may be helpful to add some of the standardish key bindings (e.g.,
> everybody's favorite Alt-F4[0]) for window ops. Looking over what
> Windows, Mac, or KDE/Gnome do might hint at some things new users
> might expect. I mean, maybe "sort of uwm-ish" is a reasonably
> default for good newbie-familiarity in 1987, but...
I could, but there are sooo many apps that use lots of bindings. I worry
about annoying clashes (blender, the 3D suite, is a big one).
> - Similarly, some of the standard-like titlebar buttons for things
> like maximize, and maybe a window menu. Y'know you can do that?
> See [1]. Of course, what you'd want in a window menu in practice
> would differ from what you'd want in a root menu, so you probably
> would want to make a special menu for it too.
I planned to do that.
> - If you start messing with titlebar buttons, you probably want to
> consider NoDefaults instead. Actually, I'm of more than half a mind
> that that should be there anyway; that way somebody looking at it
> doesn't get all head-scratchy wondering where some magic is coming
> from that they can't find in the config.
Thanks
> - I wouldn't include f.adoptwindow. The whole captive ctwm thing is
> weird and wonky, and I remain not untempted to deprecate and quietly
> murderize it. I don't think we should tempt an inexperienced user
> with it. f.pin is also useful demonstration; how useful it is
> use-wise on any given menu is probably a bit harder to call...
f.adoptwindow is an interesting feature. I was originally intended for
testing but think is has a useful function, it would, with a little
work, solve Adam's problem documented in my attachment in as much as
ctwm could embed itself inside of a terminal inside of itself thus
enabling per-screen desktops/pages.
> - Definitely want more menu work. Some additional depth and
> categorization. Maybe showing off the various special menus[2].
> I've been happier since I nested f.quit down in an extra layer of
> menu, so it's harder to hit accidentally.
Defiantly.
> And including more of the sort of programs people are likely to want
> to run now that it's not the 80's. Of the 4 things you can exec
> from that menu, even as a grumpy old man I don't even have xman or
> xmag installed, and I don't recall ever even using either one other
> than recreationally back in the 90's. xcalc is around, but I
> certainly never use it either. Web browsers, OTOH, I spawn off all
> the time.
>
> - Similarly some of the special color overrides, title/occupy, etc.
> If it's a program no random new user is gonna have around or even
> know about (WTF is "Axe", anyway?), it won't do anything, and will
> only confuse them when the try and read the config. Also, perhaps
> swap the 'xterm' entries over to 'XTerm' so they still match the
> standard class even if the window name is changed (as from previous
> mails a while back, this may just be an extra vagary of my setup).
Ok.
I was wondering what Axe was also...
Xmag is still useful, though I wish It were real instead of virtual, for
reading legal agreements (:
> - For the second purpose (documentation of the possible), more
> interspersed comments on some things would be good.
Actually, I was thinking that lots of comments would make going through
the config painful and duplicate a lot of the man page.
> Key/button
> bindings for instance. The header comment describing the syntax is
> good, but details on the individual lines about what the
> modifiers/context mean in human terms would probably help new
> readers.
++
> What each of the coloring vars are for might be nice too.
> Grump. The manual could use a little work on that topic too...
I'm thinking that it would be better placed in the man page.
> - I like tabs for indenting blocks (though not for aligning columns
> after text). But Thank The Maker for getting rid of the godawful
> mixing of both!
>
>
>
> > A change log is in the file.
>
> I'd discourage this. They tend to end up very inconsistently updated,
> so that Murphy pretty much guarantees that any time you actually look
> at it to find out something, the thing you're looking for isn't there.
> And if they _were_ updated well (and usually, even if they aren't),
> they wind up enormous, and every time you open the file you have to
> scrollscrollscrollscroll to get to where you wanted to be.
>
> That's what we have a VCS for! :)
That idea of mine was two fold.
One, because it's not in the vcs yet it would be helpful to mention what
changed instead of just sending you an attachment of the config. I could
do this in the email itself, but for book keeping purposes, it's more
reliable to do it in the file then by memory. When I submit it into the
vcs in it's finished (for now, anyway), form then I'll truncate my in
file changelog and place the changelog into the vcs.
Two, if I place a header into the config file then when a distro, or
luser, adopts it they can mention their customizations in a specific
place and when the luser submits us a problem with the config then we can
see what happened and why more swiftly.
If you disagree then feel free to mention it.
> > The only problem is that I tested my changes and I can not, with or
> > without my mods, discover what f.movetitlebar does. Anyone know?
>
> It's for moving a squeezed titlebar around on top of a window. If you
> don't have SqueezeTitle set, it won't do anything.
Interesting. Just a thought, but there are some WM's one of whose main
features is to have an option to place the title bar on the side of the
window, maybe it could eventually be adopted to serve that purpose also?
> > Comments on what aught to be added to a default ctwmrc as well as a
> > colour scheme (the default seems to be high contrast), aught to be
> > are welcome.
>
> Might be helpful surveying what people here are using. Mine's heavy
> on maroon and grays, probably because that's how twm was setup on an
> AIX RS/6000 box I used back in the 90's that the remote ancestry of
> much of my config comes from.
Wasn't that King Tut's system? :)
> You might try playing around with some color scheme generators. I
> used one I found in a little googling when I redid the web site; can't
> tell offhand which it was, but http://www.colorschemer.com/online.html
> is a nice simple one, and http://paletton.com/ has more bistles and
> whells. https://coolors.co/ seems to be a little of both; more random
> in operation. Or you just mess around trying stuff until something
> looks good, assuming you have a better eye for colors than I do[3].
I'm ok with colors, I just did not know if there was something
particular that was considered best, the last time I had to color
something I was told four bright colors was optimal (think widowz logo),
I'll mess around and submit for you and others to criticize.
> [0] Of course, anybody trying that on my machine will be real
> disappointed when they find themselves staring at my 4th
> workspace...
You know, that actually makes sense to me.
Thanks,
David
--- Begin Message ---
Hello,
One of the most requested features from FVWM is the ability to have per-screen
pages/desks. Unfortunately, this is a really large change, and given that
FVWM has pages as well as desks, compounds the problem.
The EWMH specification doesn't say anything about per-screen desks which is
annoying as it's not possible to have a separate root window per-output. Were
it possible, then the XAtom hints would make this easier to achieve. As
there's currently only one root window, only one XAtom can be set to indicate
the actual desktop in use, and this breaks down with more than one screen.
But you can emulate this behaviour by using States. This is a FVWM feature
whereby a window can be placed in a state and can then be manipulated by FVWM
commands. What I've done is to assign ten states per monitor, and to have
those states attached to the output(s) which are present.
So for example: screen 0 has states 0 -> 9, screen 1 has states 10 -> 19,
etc. There is a limit on the number of states (currently 31) so this will run
out quite quickly with more than four monitors. But I'm assuming that's quite
rare.
When FVWM starts, each output is assigned a current state. This state is the
one which is the state being shown. Windows, if they don't have a style
indicating a state to place them in, are put in the active state. These
variables are tracked via the InfoStoreAdd command. The same operation
applies when windows are moved between screens.
Windows started without being told which state the window applies to are
started on the screen with the mouse pointer, and the state which is on
display at the time. Hence:
Style * InitialMapCommand AssignTag $[infostore.screen-$[w.screen]-ActiveTag]
Windows can be told to appear on another tag as in:
Style SomeApplication InitialMapCommand AssignTag 13
If the tag in question happens to be on another monitor, then the window is
moved there. If the state in question isn't the active one, the window is
hidden.
Hiding windows makes use of iconifying with the following condition:
Style * !Icon
FvwmButtons is set up with one instance per monitor, showing each state, and
which ones are for which monitors. If a state has a window on it, the title
of the buttons is updated to include a little asterisk at the end. Switching
to that state shows the windows on it. Additionally, the buttons are
colour-coded to show which state is the active one. If a state contains a
window which has the urgency flag set on it, the colour of that state (if it's
not the active one) will turn red.
A sample screenshot illustrating this can be seen here:
http://picpaste.com/pics/state-342X4FRT.1464099362.png
The configuration for all of this currently resides in a Gist, found here:
https://gist.githubusercontent.com/ThomasAdam/7c19827686481383a6ff8a24bbb3bc2c/raw/937529b7384041b053b0ca56d6f3bccbcda7b012/gistfile1.txt
Because I'm using Infostore to track the Window IDs and which state they're
assigned to, this does all go a little pear-shaped when FVWM is restarted.
I'm working on making Infostore persistent across reboots, the code for which
is here:
https://github.com/fvwmorg/fvwm/commit/df160edfcd59ffb83e899abbed0d777cd33ffdd9.patch
But I consider that a rare thing, so not so much a problem for now.
Note that this is still rather rough around the edges, and I do plan on
cleaning it up. But for now, it's rather functional.
Comments and feedback are welcome.
-- Thomas Adam
--- End Message ---
