Subject: Style merging

From: Dan Espen <[email-masked]>
Date: Fri, 01 Oct 1999 13:29:18 -0400

Something went wrong with that last change.  I have:

Style "*" IconBox -80 240 -1 -1, IconGrid 80 67, \
          IconBox 1040x20+0-40,  IconGrid 80 80, IconFill r t

and its using only the second iconbox.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 2 Oct 1999 15:49:16 +0200

> and its using only the second iconbox.

Ah, yes.  I misunderstood how icon boxes work and let the latest
icon box override existing ones.  I corrected this.  However,
I don't understand how you can reset your icon boxes.  It seems
that the only way to clear out already defined icon boxes is to
destroy the complete style and build it from scratch.  Is this
right?  If it is 'IconBox' is the only style that cannot be
changed after it has been set.

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Sat, 02 Oct 1999 19:50:12 -0400

> changed after it has been set.

I'm not sure I understand.  If you issue a new

Style * Iconbox <newlocation>

then all new windows will go into the new iconbox.
If you issue "Recapture" then existing windows move to the new iconbox.

I think thats the same as how other styles work.

The only "odd" thing is that multiple iconboxes have to be defined in
one command, and they are all overridden by the next "style iconbox".

I think thats a necessary part of the "multiple iconboxes" feature.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 4 Oct 1999 11:24:39 +0200

> I think thats a necessary part of the "multiple iconboxes" feature.

But how do you turn all icon boxes off?  I can't see how this
can be done.  Dan, can you clarify the description in the man
page?  It doesn't explicitly state that a new IconBox style
overrides existing ones.  And I am not sure that this still
applies with the new merging code.  I believe that IconBoxes
are added until a style with a different name is used between
two IconBox definitions.

Bye

Dominik ^_^

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Tue, 05 Oct 1999 15:14:57 -0400

> are added until a style with a different name is used between

Hmm, turn iconboxes off?

I don't think you would ever want to do that.  I recently added logic,
to create a  default iconbox behind all   the others, that  covers the
screen.  If all the  others get filled, it uses  that one.  So you can
override them, make them so small, nothing will go  into them, but not
remove them.

Of course if you don't want your icons in an iconbox, you just use
"Style * NoIcon".  Otherwise, they have to go somewhere.

I remember   working thru  the    merging issues  when I   wrote   the
"iconboxes" enhancement.   This wording describes  style matching  for
all style related matching:

  windowname can be a window's name, class, or resource string.
  It can contain the wildcards * and/or ?, which are matched in the
  usual Unix filename manner.  They are searched in the reverse order
  stated, so that Style commands based on the name override or augment
  those based on the class, which override or augment those based on the
  resource string.

I think iconboxes are no different than any other style parameter as
far as the matching goes.

But, somehow, I think I'm missing your point.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 7 Oct 1999 11:48:52 +0200

> But, somehow, I think I'm missing your point.

The point is that you can reset any style except 'IconBox' and
perhaps 'UseDecor' to its default setting.  Once you have defined
an icon box you can't remove it completely from the style without
destroying the style.  I guess it wouldn't be difficult to make
'IconBox' without arguments delete all style specific icon boxes.

Bye

Dominik ^_^

---

From: Dan Espen <[email-masked]>
Date: Thu, 07 Oct 1999 15:50:37 -0400

> 'IconBox' without arguments delete all style specific icon boxes.

I think I understand now, but first, how do you remove:

Style * Forecolor red

you replace it with another color.  You can't reset it to the default.

But thats neither here nor there.  (Das machts nicht. ?)

I think the only important issue is no one ever asked to be able
to do that.  (Except you.)  I don't think:

Style * Iconbox -, Icongrid -, Iconfill -

would do us much good.

But, if you feel the urge, go for it.

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 8 Oct 1999 02:40:14 +0200

> changed after it has been set.

I has a feeling that the problem is in a bad syntax for icon box style.
This is the only style, which treats things differently when they are on
the same line or not. Example:

Style * IconBox 100x100+100+100, IconGrid 16, IconBox 200x200+200+200

is not equivalent to:

Style * IconBox 100x100+100+100, IconGrid 64 64
Style * IconBox 200x200+200+200

neither to:

Style * IconBox 100x100+100+100
Style * IconBox 200x200+200+200
Style * IconGrid 64 64

It is also not clear what needs to be done in all 3 cases; ambiguity.
I suggest a new syntax for a new Style IconBoxes instead of IconBox,
IconGrid and IconFill, which must solve all problems:

Style * IconBoxes ((Geometry +100+100, Grid 64 64), (Geometry +200+200))

and any icon box in parentheses inherits all non-specified attributes
from the previous icon box or a default.
Written this way it is clear that the next IconBoxes will overwrite
previously defined icon boxes. To delete previously defined icon boxes:

Style * IconBoxes ()

Comments?

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Fri, 08 Oct 1999 12:20:03 -0400

> Style * IconBox 200x200+200+200

To be consistent with the other style commands, this should do exactly
what it would do,  The second should override the first.

> Style * IconBox 200x200+200+200

If I  had allowed for   this syntax, it should  set  the grid for  the
previously defined iconbox, the one at 200+200,  or any other iconbox.
Looking back, I'm not sure why I didn't go this way.  The only problem
would  be  that  during  style  definition a  "iconbox"   structure is
created.  The  same structure is carried into  the window that matches
as it is created.

Where were you when this patch was first written?  :)

> previously defined icon boxes. To delete previously defined icon boxes:

I think you have an improved design that reproduces what the current
syntax accomplishes.

We'd have to keep the current syntax, and add a new one.  (I would not
generate a warning when the old one was used. :) )

Rather than fooling with the syntax, I have a list of things I wish I
had time to create for iconboxes:

1,  A GUI tool that would let you draw a box on the root to outline the 
iconbox area, and give you the command to define the box.
At the same time, I'd like to see and define the grid.  Doing this as
a module would be neat, you could draw it, and then the icons could
move right into it.

2,  Better positioning of the icon in the grid.  To my eyes, the icons
aren't centered in the grid very well.  (At least when you don't have
icons with uniform size.)

3. Scaling or clipping of the icon to fit the grid.

4. Fvwm generated active icons.  That is, the icon is a shrunk image of
the window.  (Someone offered to pay money for this feature a few years
back.)

---

From: Brad Giaccio <[email-masked]>
Date: Fri, 8 Oct 1999 14:07:42 -0400

> a module would be neat, you could draw it, and then the icons could

That would be pretty slic, I might even start using icons a regular basis 

> the window.  (Someone offered to pay money for this feature a few years

Well you can already do this with xterms 
 xterm +ai
 
-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Fri, 08 Oct 1999 14:23:16 -0400

> Well you can already do this with xterms 

I do this with x3270 and XEmacs (live-icon.el).

The person that wanted to  pay us was interested in  "xv" windows as I
recall.  (I know they could get a similar result by just shrinking the
xv window.)

But if fvwm or an fvwm module did this...

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 9 Oct 1999 01:53:20 +0200

> Where were you when this patch was first written?  :)

Definitely not here. :) This was in 2.0.47...

> a module would be neat, you could draw it, and then the icons could

Interesting.
 
> icons with uniform size.)

I would prefer not to center the icon in the grid, just to be able to get
the first icon exactly in the specified geometry. But it is not very
important (I mean which default is, centered, right- or left-justified),
because icons must have an uniform size anyway. :-)

> the window.  (Someone offered to pay money for this feature a few years

I would add:

5. An option saying that Move for icons respects icon box grid, so the
icon can only jump to the next grid cell. Probably MoveStep attribute in
IconBoxes, defaulting to 1, can do this.

Finally, to be honest, Dan, I don't like too much that the icon, which was
moved, is treated specially (has the fixed position). I think it is a
number 53 in fvwm-2.4 todo, moved to done by your suggestion.
Fortunately, 'All (CurrentPage Iconic) RecaptureWindow' fixes the problem.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Sat, 09 Oct 1999 07:48:50 -0400

> because icons must have an uniform size anyway. :-)

This  being fvwm, if  someone wrote "centering",  I'm sure it would be
accompanied by all the possible positioning directions.

For my  own use, I find that  even if I had all  my icons with uniform
size, I want some to have icon titles, and some  don't need them, so I
suppress them.  Program generated icons come in various sizes also.

So, I still don't get my icons positioned that well.

> IconBoxes, defaulting to 1, can do this.

Snap to icon grid.  I can remember some discussion, but not the outcome.

> number 53 in fvwm-2.4 todo, moved to done by your suggestion.

I'm  sorry, I don't know  what you mean by  "fvwm-2.4  todo", but then
I've only been awake a half hour or so.

The way moved icons  hold their place  has been an fvwm "feature" from
before I was involved.  I don't have any use for the feature at all.

---

From: [email-masked] (Paul D. Smith)
Date: 09 Oct 1999 13:49:14 -0400

%% Dan Espen <[email-masked]> writes:

  >> Finally, to be honest, Dan, I don't like too much that the icon,
  >> which was moved, is treated specially (has the fixed position).

  de> The way moved icons hold their place has been an fvwm "feature"
  de> from before I was involved.  I don't have any use for the feature
  de> at all.

I agree; this stickiness I find annoying and useless.  Of course, I
don't move icons much, either.

Does _anyone_ like it?  When is it handy?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 10 Oct 1999 00:29:27 +0200

> Snap to icon grid.  I can remember some discussion, but not the outcome.

I think that the idea of icon boxes must be redesigned to provide answers
for this and the one below questions. Would I only have a time... Anyway,
I will read archives on this topic.

Some time later...

  http://www.hpc.uh.edu/fvwm/archive/9512/msg00171.html

No comments for now.

> I've only been awake a half hour or so.

I mean these weekly status posts by our brave Dominik.

> before I was involved.  I don't have any use for the feature at all.

Ah, I didn't know this.

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 10 Oct 1999 01:56:25 +0200

On 10 Oct 1999 00:29:27 +0200, Mikhael Goikhman wrote:
> I think that the idea of icon boxes must be redesigned

Just to clarify myself, here is what I mean by redesigning icon boxes.
First of all I suggest to rename existing icon boxes to icon areas, which
is less confusing (and avoids name collision with FvwmIconBox module).

Currently, icon boxes (areas) are only used for initial placement, and
nothing else, so one can not do these operation on per icon area basis:
  * swap icons
  * move an icon to an empty cell
  * rearrange icons
  * resort icons
  * move the entire icon area to another place
  * dynamically change grid and fill of icons (current IconGrid, IconFill)
  * change aligning of an icon inside an icon cell (grid)
  * use colorset background instead of root for shaped icons
  * show/hide icon area borders (using a menu item bound to icons)
  * more...

A new FvwmIconArea module can do such things. Unlike other NoIcon modules
it could draw on the root. On the other hand, if icon boxes (areas) will
be moved to a module, what will remain in the core fvwm? And then NoIcon
term is becoming confusing (not what it is not confusing now).

A material for thinking.

Regards,
Mikhael.

---

From: Bob Woodside <[email-masked]>
Date: Sat, 09 Oct 1999 21:21:29 -0400

> Does _anyone_ like it?  When is it handy?

	I do, I do. If I go to the trouble to move an icon to a particular
place, it's because I wanted it there and not somewhere else. I don't
want the window manager deciding I'd really like it somewhere else: I
wouldn't.

	I arrange several pages of my desktops this way, with (non-uniform)
icons placed conveniently for the current layout of that page. On
others, I just let the icons fall into an icon box; and in these cases,
I really don't care how the icon box gets arranged or rearranged. That
is, I don't care as long as FVWM doesn't appear to be getting too fussy
about it. I like things to move smoothly when I drag them around, and I
wouldn't want icons jerking from one grid position to the next because I
happened to be within an icon box; but an option for this would be fine.

	This is why I wrote the old RecaptureRemembersIconPositions GlobalOpts
hack a few years ago (haven't yet gotten around to converting it to a
style, so it's still a hack for 2.0.46 on my aged Unofficial Patches
page).

Cheers,
Bob

---

From: Dan Espen <[email-masked]>
Date: Sat, 09 Oct 1999 22:10:35 -0400

> want the window manager deciding I'd really like it somewhere else: I

Thanks Bob.  What you  say makes perfect sense.  I  don't have any use
for the feature, but I  imagine if I did  move an icon, it wouldn't be
to adjust its position in the box but to give it a new home.

> style, so it's still a hack for 2.0.46 on my aged Unofficial Patches

Seems like a logical patch.

While we are throwing around design ideas instead of coding,
couldn't recapture be improved by making it more atomic?

I don't  know the  code,  but we  seem  to need recapture  in order to
change the appearance  of things, move  icons, change titles, buttons,
borders.

If I just wanted to change the color of a titlebar, I get this flashing
all over the screen.  I wonder if there couldn't be a bunch of types
of recapture like:

Recapture <style> Icons
Recapture <style> Frames 

This might make it easier to create a configuration module where
you could change frame appearance without the whole display going nuts.

---

From: [email-masked] (Paul D. Smith)
Date: 09 Oct 1999 23:52:14 -0400

The only time I move an icon is if it's obscuring another one.  Then,
after I move it, it's invariably a pain in the rear because it never
moves again and is _always_ covering something up and generally making a
nuisance of itself.  Typically I end up deleting the window out of
frustration :(.

I'd prefer a way to toggle this behavior.

---

From: Bob Woodside <[email-masked]>
Date: Sun, 10 Oct 1999 00:01:50 -0400

> you could change frame appearance without the whole display going nuts.

	Hmmm. Interesting idea. Maybe we want to think about a new command,
something like Redecorate or Reconfigure - which, of course, could be
applied to a single window or all of them (or maybe even an ad hoc
grouping of windows...maybe rubber band selectable...ah, go get some
sleep, Bob). And maybe, like you suggest, it should be selectively
applicable to only certain Style features.

	I think the nasty flashing part comes from destroying all the windows
(and their decorations) to reparent them to root, then capturing them
and recreating all their decorations - oh, yes, and remapping all the
windows on desktops other than the current one and then unmapping them
again (wonder if we could eliminate that part of the operation?). I
think the actual redrawing part isn't that big a deal.

	I'm not sure how feasible this is...because what I'm thinking of is
just redrawing decorations rather than destroying and recreating the
window. Certainly some decorations could be treated this way - color
changes, etc. Other things could get pretty convoluted, involving window
resizing, etc.

	Smoother appearance changing would certainly be nice....

Cheers,
Bob

---

From: Bob Woodside <[email-masked]>
Date: Sun, 10 Oct 1999 00:19:55 -0400

> I'd prefer a way to toggle this behavior.

	Well, I was thinking that maybe a new style to control this would be in
order. Of course, then you'd need to do a Recapture to toggle it, and we
have all that flashing...unless we can come up with a smoother way of
realizing style changes than the current Recapture.

	It sounds like you'd generally prefer the behavior to be off, though.
Would controlling it via a style suit you? Or would this be better as a
global option (no Recapture needed in that case, by the way)?

Cheers,
Bob

---

From: [email-masked] (Paul D. Smith)
Date: 10 Oct 1999 00:31:58 -0400

I don't care about recaptures or flashing or anything; I'm never going
to toggle it myself.  What would be the purpose?  Basically I guess I
just don't want to arrange my desktop like that.  So maybe I'm not the
best "customer" to be asking :).

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 11 Oct 1999 00:01:10 +0200

> 	Smoother appearance changing would certainly be nice....

I'd rather not start adding even more 'Recapture' commands because
the 'Style' command sucks.  The right way to fix it is to make all
styles take effect immediately.  In fact I have been pondering this
for quite a while.  It would probably not be too hard to change, but
there is one major question I don't know how to answer:

  Should a changed style apply to all currently matching windows
  or only to those that already matched that style when they were
  created?

I tend to favour the second method since I believe it would more
what the user expects, but on the other hand it's much more difficult
to code.

Bye

Dominik ^_^

---

From: Dan Espen <[email-masked]>
Date: Sun, 10 Oct 1999 18:27:28 -0400

> there is one major question I don't know how to answer:

If style commands took affect immediately, rather than at add window
time, wouldn't there be a lot more window flashing taking place?

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 11 Oct 1999 00:38:37 +0200

> time, wouldn't there be a lot more window flashing taking place?

Not necessarily.  There should be some mechanism that records that
window styles have changed and that redraws only after fvwm has
finished the current top level command it is executing.  This way
you could even read in a complete file with 'Read' and experience
no flashing at all until after the file has been completely read.
And of course only the changed parts or the changed style(s) should
be applied.

Bye

Domiinik ^_^

---

From: Dan Espen <[email-masked]>
Date: Sun, 10 Oct 1999 18:45:35 -0400

> And of course only the changed parts or the changed style(s) should

If you could do that, you could make the recapture command obsolete.

I have some Fvwm Functions that call other Fvwm Functions to change
some styles.  The the last thing the functions do is Recapture.

Suppose those same commands were coming from a Module?

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 11 Oct 1999 01:16:50 +0200

> Suppose those same commands were coming from a Module?

Hm.  Is this a real issue or hypothetical?  I can imagine two
situations where this might happen: with FvwmCommand if used
to configure complex styles from the command line and with
FvwmConsole with cut-and-paste.  Before worrying too much about
this I would just write the new style code and see if it really
is an issue or if the additional flashing is hardly noticeable.

If the code can be easily written in a way that allows to update
only the parts of a style that have actually changed this is
no issue at all (well, perhaps performance).

Bye

Dominik ^_^

---

From: Dan Espen <[email-masked]>
Date: Sun, 10 Oct 1999 19:34:25 -0400

Dominik Vogt <[email-masked]> writes:
> 
> Hm.  Is this a real issue or hypothetical?

Its a hypothetical module that generates window styles.

The functions are real.

---

From: Tim Phipps <[email-masked]>
Date: Tue, 12 Oct 1999 11:30:50 +0100

Dominik Vogt wrote:
> for quite a while.

I think we should leave this until after 2.4 and then split Style into
several
different commands and get rid of Recapture altogether.  It seem like
Style has grown to be an enormous command that has no clear definition.
The name is vague which doesn't help.

It feels like it wants to be split into two new window-name matching
commands and several standalone commands. What I'm thinking of is:

1) InitialState <pattern> options
where options controls the state of a window when created, things like
StartIconic, SkipMapping. These would just be a way of overriding the
default state of a window at startup or the behaviour of fvwm when a
window is mapped.

2) Appearance <pattern> options
This would affect the look of windows: things like BorderWidth,
Title/NoTitle

n) lots of new commands for setting state in run time: things like
WindowListSkip, CirculateSkip, Sticky (already exists). This could be
lots of new commands or one with lots of options (ChangeState
CirculateSkip). Applying to windows based on name/class could be done
with the All command.

Any thoughts?

Cheers,
Tim.

PS the thing that really hacks me off about Recapture is that it sets
the sticky flag according to the style and ignores its current setting.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 15 Oct 1999 11:16:49 +0200

> CirculateSkip). Applying to windows based on name/class could be done

I don't know. Wouldn't this be too disruptive to existing config files?
I find the definition of 'Style' clear enough: Everything that can
be different for each window is a style.

Bye

Dominik ^_^