Subject: FVWM: FvwmIconMan: MiniIcons and Minimization

From: Brian Sayatovic <[email-masked]>
Date: Wed, 16 Jul 1997 13:03:32 -0400

I've noticed that the MiniIcons used with FvwmIconMan are only drawn on
buttons for minimized windows,  Is there a way to disable this so that
they are drawn on a window regardless of its state?  I'd prefer to use
this for my one particular manager where I use ONLY the icons ina 
'tray-like' area, and no distinguishing text.  They just sort of
disappear when I click them to restore the window.

Brian.
-- 
 ___________________________________________________________
|                                                           |
|  Brian Sayatovic                 (mailto:[email-masked])  |
| --------------------------------------------------------- |
|  International TechneGroup, Inc. (http://www.iti-oh.com)  |
|___________________________________________________________|
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Brady Montz <[email-masked]>
Date: 16 Jul 1997 12:37:38 -0700

> disappear when I click them to restore the window.

Well, the original intent was that the miniicons are used to denote which
windows are iconified. I've been toying with the idea of adding code that
allows you to specify other ways of showing this, but haven't really figured
out a nice way. 

Basically, I'd like to completely generalize the format string. Like add a
specifier for the miniicon (like %m) and a way to conditionalize when certain
fields of the format string are shown. Like maybe an icon which is displayed
for sticky windows. Or a way to say: show the resource name for all windows
except when it equals "Netscape" since Netscape titles look like "Netscape:
blah blah blah" anyway. I'd also like to be able to show the window geometry
in the button, so that I could determine which of my "emacs: *scratch*"
windows I want to uniconify. And, I need to be able to right justify the whole
string. What would be really cool is if I could specify a maximum size for a
particular field, and control the justification of that field in it's little
region. I could just use printf syntax for that.

This ties in with wanting to make it so that you could use the state of the
windows to determine which manager manages them, since I'd have to grab some
code from fvwm to do the parsing of strings like "!iconic" and whatnot. I've
had a request to make an option so that a manager window would only list
iconified windows. But I can imagine wanting to only show uniconified windows,
or (un)sticky windows. So you could have one manager for iconfied windows, and
one for the uniconified windows.

Basically, I guess I'm coming perilously close to just dropping a python
interpreter into FvwmIconMan, since all of this is starting to become
unwieldy. It bas bad enough when I made one extension language for the
actions. Adding another extension language to control what gets drawn in the
buttons (and printf like format strings are a simple language; adding
conditionals makes it unsimple), is starting to get out of control.

FvwmIconMan is starting to truly act like an icon manager, just as fvwm is a
window manager.

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. 

Man, and I've got a thesis to work on too. Good thing my advisor doesn't read
this list :-)

-- 
 Brady Montz
 [email-masked]

---

From: Richard Lister <[email-masked]>
Date: Thu, 17 Jul 1997 12:32:03 -0400

On 16 Jul 1997 12:37:38 -0700
Brady Montz <[email-masked]> 
> allows you to specify other ways of showing this, but haven't really figured

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. 

> FvwmIconMan is starting to truly act like an icon manager, just as fvwm is a

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. 

> titled "al01 *" en masse to another desktop. 

Whoosh! Now you're getting carried away :-) 

Ric

Richard J Lister, Georgetown Institute for Cognitive and Computational Sciences
Georgetown University Medical Center, Washington, DC.
Phone: 202-687 2878
Email: [email-masked] 
Web: http://www.giccs.georgetown.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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Brady Montz <[email-masked]>
Date: 17 Jul 1997 11:47:39 -0700

> 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.

> 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.
> 

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.

---

From: LAURENT DEGEILH <[email-masked]>
Date: Tue, 22 Jul 1997 11:39:22 +0200 (METDST)

I' ve seen the question in the archive mailing list but 
without answer ...

SO:

Is there a way to make a window 'sticky' on just some desktops ?

| PMS Laurent DEGEILH       METEOFRANCE/SCEM/PREVIMAR |
| 42,Av G. Coriolis        Tel = (33/0) 5 61 07 82 63 |
| 31057 TOULOUSE           Fax = (33/0) 5 61 07 82 09 |
| FRANCE            e-mail = [email-masked] |

---

From: Kai Grossjohann <[email-masked]>
Date: 22 Jul 1997 20:02:13 +0200

>>>>> LAURENT DEGEILH writes:

  Laurent> Is there a way to make a window 'sticky' on just some
  Laurent> desktops ?

AFAIK, fvwm can't do this.  Ctwm can and that's one of the reasons I
had that one running once.  Nowadays, I like fvwm better.

kai
-- 
A large number of young women don't trust men with beards.
(BFBS Radio)