Richard Lister <ric_at_giccs.georgetown.edu> writes:
>
> I thought about this for a while and what I would like to see is the addition
> of an 'iconifiedbutton' identifier to correspond to selectbutton,
> focusbutton, etc. This way I could have flat buttons becoming raised
> when iconified, and so on. I would find this a stronger visual cue than
> the presence of a mini-icon.
>
> To be really flexible we could add a state 'none' to flat, up, down, etc,
> to have no button appear.
>
> I hacked around with the code a bit a couple of months ago in an attempt
> to implement the former, but I had quite a lot of difficulty. I can't
> remember the exact problem. Maybe I should try and dig out those hacks.
Well, this starts getting ugly with the current scheme. What about iconfied
selected buttons? Or uniconified focused selected vs. uniconified focused
unselected vs uniconified unfocused selected etc. Having two dimensions is
more than enough weight on the current scheme. I'd probably have to
orthogonalize it. You have the following things you can change: edge style,
foregound color, and background color. Logical things to add are format
string, and font. Then you have the following dimensions of window state:
focus, select, iconified. Then you specify, for each dimension, what get
varied, and how. So:
*FvwmIconMan*iconstate: edgestyle (none, raisededge)
*FvwmIconMan*focusstate: color ((white,black), (red,black))
so uniconified windows would have no edge, iconified would have raisededge
unfocused windows get white on black, focused get red on black
etc.
Clearly I'd haev to think about the syntax of all of this. Fortunately my
setup is orthoginal. Selected buttons are always down. Focused buttons are
always white on brown. I don't know if everybody else uses orthogonal
settings. They probably should though.
>
>
> > FvwmIconMan is starting to truly act like an icon manager, just as fvwm is a
> > window manager.
>
> I've always felt that icon handling shouldn't be a job for the window
> manager. We should strip all icon code out of fvwm, and just have a bunch
> of different icon managers running as modules to implement different
> icon handling strategies.
Probably true. Look at all the messages about people complaining about how
fvwm lays out icons on the root window. There is clearly a need for more
flexibility there. It would be nice if somebody wrote a module to handle the
"default" case where the icons get stuck on the root window. Many people would
like it.
>
> > Another potential cool thing is if (maybe by drag and drop - yow!) you
> > could use FvwmIconMan to group windows. Make a little key command to
> > create a new window manager, and drag buttons from one manager to the
> > next. Then make some fvwm commands to act on entire groups of windows, and
> > use FvwmIconMan to be a graphical interface for managing all of that. That
> > would be cool. He he. I'd love to iconify all of my netscape windows at
> > once, or move all of my xterms titled "al01 *" en masse to another
> > desktop.
>
> Whoosh! Now you're getting carried away :-)
>
> Ric
>
Actually, I don't think it would be that hard. There are three general issues:
1. I need to add group commands to FvwmIconMan. That's easy. Just send the
same fvwm command to all windows a specific manager. Perhaps I'd have to
have the ability to control the order in which they command is sent (python
definitely).
2. I need to be able to dynamically add managers and move windows between
them. Both are pretty close to there. Already windows can move between
managers if their titles change. And the code to handle the manager data
structures is pretty generalized now.
3. I need to have an interface so the user could dynamically specify which
windows are in which groups. This is the hard part, but it could be
delayed. I would still find it useful if I had to statically specify all my
window groups. I only use five classes of windows myself: xterms, xemacs
windows, netscape, fvwm windows, and miscellaneous. Being able to operate
on each class as a group is a start.
--
Brady Montz
bradym_at_cs.arizona.edu
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Thu Jul 17 1997 - 13:48:16 BST