Subject: Style Icon issues

From: Matthias Clasen <[email-masked]>
Date: Wed, 14 Apr 1999 09:53:10 +0200

I have just tried to find out the difference between the
following commands

Style * Icon bla
Style ** Icon bla

which everybody would expect to be completely equivalent.
It turns out they're not. fvwm contains an ugly undocumented
hack to special-case  Style * Icon bla  to just set the "default
icon" to be used if no other icon could be found instead of
forcing all windows to use the same icon like  Style ** Icon bla
does.

I'd propose to remove this hack and add a proper DefaultIcon
command instead. Any objections ? We should probably adding
a warning for  Style * Icon  explaining the change.

Another thing which I would like to change is that there is
currently no way to get back at the client-provided icon
once there was an  Style foo Icon bar  command, ie after

Style foo Icon bar
Style foo Icon

you still get icon bar, not the icon provided by foo. Even

Style foo Icon bar
Style foo NoIcon
Style foo Icon

doesn't help. I propose to change  the NoIcon and  
Icon (without argument)  style options to reset 
Tmp_win->icon_bitmap_file. This change shouldn't affect
many users, but it increases the expressiveness of the
Style command. You can than, eg set a default icon for 
all windows of  foo, but use the client-provided icon 
for foo_main easily by

Style foo* Icon foo-default
Style foo_main Icon 

Any objections to this change ?

Matthias

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
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: Wed, 14 Apr 1999 12:04:01 +0200

On Wed, Apr 14, 1999 at 09:53:10AM +0200, Matthias Claasen wrote:
> It turns out they're not.

No, I wouldn't have expected that for a second.

> fvwm contains an ugly undocumented
> command instead. Any objections ?

Yes. A new command makes no sense. The icon is a style, so
why make a new command? If checking for "*" is a problem,
why don't we check for an arbitrary number of asterisks?

> We should probably adding

No objections. What I always do with new commands is to
reset to default when no parameter or 'default' is given.

BTW, your fix for xterm's active icon didn't fix anything
for me. The 'Style xterm Icon foo.xpm' still overrides
the ai. No chance to get one.

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: Matthias Clasen <[email-masked]>
Date: Wed, 14 Apr 1999 20:48:06 +0200

> No, I wouldn't have expected that for a second.

Why not ?

> why don't we check for an arbitrary number of asterisks?

No, the default icon is not a style, it is a part of the Scr
struct. It is used only if there is no WM_HINTS or Style-supplied
icon. This is different from normal Style foo Icon bar which 
does override WM_HINTS supplied icons. Thus I think a new command
would make a lot of sense. 

> reset to default when no parameter or 'default' is given.

Ok, I'll do this then.

> the ai. No chance to get one.

I thought I had made it clear that I didn't change this.
It has always been like this (well, at least it is also the case  
in 2.0.46) that icons supplied via Style Icon override WM_HINTS.
The code responsible for this is in add_window.c:

  /* find a suitable icon pixmap */
  if(SHAS_ICON(sflags))
    {
      /* an icon was specified */
      tmp_win->icon_bitmap_file = SGET_ICON_NAME(style);
    }
  else if((tmp_win->wmhints)
          &&(tmp_win->wmhints->flags & (IconWindowHint|IconPixmapHint)))
    {
      /* window has its own icon */
      tmp_win->icon_bitmap_file = NULL;
    }
  else
    {
      /* use default icon */
      tmp_win->icon_bitmap_file = Scr.DefaultIcon;
    }

Matthias

---

From: Dan Espen <[email-masked]>
Date: Wed, 14 Apr 1999 15:46:49 -0400

> would make a lot of sense. 

If DefaultIcon needs to be a new command, where do MiniIcons fit in?

How about the DefaultIconBox?

I didn't see anything wrong with "Style *" setting the default.

I certainly wasn't worried about "Style **".

--
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: Matthias Clasen <[email-masked]>
Date: Wed, 14 Apr 1999 21:57:22 +0200

> How about the DefaultIconBox?

I didn't think about these... 

> I didn't see anything wrong with "Style *" setting the default.

First of all, I couldn't find any hint in the docs that "Style *"
is special and second its just counterintuitive. The Icon style
option overrides WM_HINTS, except for that special case where it
behaves differently. I don't know who said it, but "different
concepts need a different syntax", otherwise its just confusing.

If there are more defaulted things, a better different syntax
might be Style default ... (with the slight disadvantage that
you can't match for the name default anymore) or
DefaultStyle ...

> I certainly wasn't worried about "Style **".

Neither am I - it was just a short way of demonstrating
the behaviour in question.

MAtthias

---

From: Dan Espen <[email-masked]>
Date: Wed, 14 Apr 1999 16:06:15 -0400

> you can't match for the name default anymore) or

OK, but watch out for menu style, from the man page:

The name "*" is reserved for the default menu style.

---

From: Matthias Clasen <[email-masked]>
Date: Wed, 14 Apr 1999 23:26:35 +0200

> > you can't match for the name default anymore) or

I looked again and found that Icon is the only option which 
is treated specially for Style *.

> The name "*" is reserved for the default menu style.

Yes, I consider this  a  unfortunate choice for a default.
MenuStyle default or DefaultMenuStyle would be better.

Matthias

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 14 Apr 1999 23:10:31 +0200

> you can't match for the name default anymore) or

I don't understand what you want, now that the change seems
to be in. On one hand you are complaining that Style * Icon
behaves differently than all other styles that override WM_HINTS
and make a new command to be consistent. On the other hand
you don't remove the "*" hack. So now we have two ways of
doing exactly the same. What is the gain?

Apart from this I really see no reason to make a change here.
*Nobody* wouuld be happy if 'Style * Icon foo.xpm' enforces
the same icon on all applications, even if they provide their
own. Defining a default icon is exactly what you would expect
here. Having the same icon for all applications makes no sense
at all. If you're so crazy about having a 'DefaultIcon' command,
okay, but changing "*" behaviour will make many people unhappy.

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: Dominik Vogt <[email-masked]>
Date: Wed, 14 Apr 1999 23:16:24 +0200

> > No, I wouldn't have expected that for a second.

Because I'm used to names in fvwm being symbolic names and not
really wildcard patterns. I don't care much about this, but if
this will be cleaned up some day I won't object.

> struct.

I don't care if it is implemented in the style structure. From the
user's point of view it is assigned to windows (potentially on
a one by one basis). That is the quality expected of styles. The
difference to the othe 'Default...' commands is that those are used
in other contexts too. The would be no 'DefaultFont' command if the
only place to use this font would be in window titles.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 15 Apr 1999 01:49:44 +0200

> MenuStyle default or DefaultMenuStyle would be better.

I wouldn't consider it unfortunate at all if the menu style
would behave like normal styles, i.e. if the asterisk indicated
a wildcard. This is recorded as an enhancement request and
will be coded when I find the time.

Bye

Dominik ^_^

---

From: Matthias Clasen <[email-masked]>
Date: Thu, 15 Apr 1999 13:32:18 +0200

> only place to use this font would be in window titles.

I may be annoying, but the default icon cannot be assigned to windows
on a one by one basis. It is just a global thing. What you say is true
for all other uses of the Icon style option. The "Default" in DefaultIcon
means that it will not override WM_HINTS, unlike other Icon style options.

Matthias

---

From: Matthias Clasen <[email-masked]>
Date: Thu, 15 Apr 1999 13:38:57 +0200

> doing exactly the same. What is the gain?

? I was fairly sure to have removed it ?

> here. Having the same icon for all applications makes no sense

Well the same argument can be applied to other uses of the Icon
option. Why should they ever override WM_HINTS ? Remember your complaint
about "active icon toggling" not working ? 

> okay, but changing "*" behaviour will make many people unhappy.

Ok back it out then, I certainly don't want to appear crazy about 
this... I just thought a little consistency would be nice... perhaps
we should at least document the overriding behaviour of Icon then.

Matthias

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 15 Apr 1999 13:49:18 +0200

> > > > Yes. A new command makes no sense. The icon is a style, so
                                               ^^^^
> means that it will not override WM_HINTS, unlike other Icon style options.

I didn't claim the 'default icon' is assigned on a one by one basis but
the 'icon'. Well, you can try to convince me. Please explain: why do you
consider breaking existing config files and making lots of users unhappy
a good thing? I can't believe consistency of syntax can justify this.

Let's consider this situation: a new user sets up his config file.
He works with fvwm and notices that some applications have no icon.
He looks into his config file and notices icons being set via the
'Style' command for some programs. He knows about the '*' style, so
he sets up 'Style * Icon foo.xpm'. He restarts fvwm and hates what he
gets since even his xv and xemacs which both provide icons use the
supposed 'default' icon. He's back at reading the FAQ/manpage, asks
at the mailing list or simply lives without icons. So, where is the
gain in usability? Give me an example where the user would wish that
'Style * Icon foo.xpm' enforces foo.xpm on every application. I simply
can't imagine one. If you have one, open my eyes.

In general it is easy to make an application 'consistent', but the user
is not interested in consistency but in usability. Did you ever hear
a user say "why does every command have a different syntax" when the
commands simply do what he expects when he simply copies existing
examples and modifies them a bit? The user thinks about consistency only
if things don't work as he expects. The secret of a comfortable user
interface is to guess what the user can do wrong and help him to prevent
his error. In this case it is very easy. There is no reason why the user
could want the consistent behaviour. So why should we let him bang his
head when there is such a simple solution?

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 15 Apr 1999 13:57:51 +0200

> ? I was fairly sure to have removed it ?

Nope, it's still in there.

> about "active icon toggling" not working ? 

Yes, I remember it quite well. There is a difference: aactivatin an active
icon is a conscious decision. If you dont start xterm with '+ai' you won't
get one. I bet the chance that the user really wants to override the active
icon is close to zero. Someone who wants to switch the ai off already knows
how to do it. Why should he want to override it from the config file?

> we should at least document the overriding behaviour of Icon then.

But I'm crazy about it ;-) (See my other mail for more flaming :)
I'm not against a little redundancy in the config files if it helps
users to customize fvwm (i.e. we can keep the DefaultIcon command).
I would just write some code to handle the "*****..." style name case.
Not that I think that is a serious matter, but a little consistency
can never hurt ;-)

Bye

Dominik ^_^

---

From: [email-masked] (Paul D. Smith)
Date: 15 Apr 1999 09:39:34 -0400

%% Matthias Clasen <[email-masked]> writes:

  mc> The "Default" in DefaultIcon means that it will not override
  mc> WM_HINTS, unlike other Icon style options.

Ah!  Here's the (to me) missing piece.  So, what we have now as far as
an algorithm for finding an icon is this:

 1) Use the icon in a Style (including "Style "*" Icon ..." if there is one)
 2) If not, use the icon built into the app (WM_HINTS)

Right?  And what you're proposing is this:

 1) Use the icon in a Style (including "Style "*" Icon ..." if there is one)
 2) If not, use the icon built into the app (WM_HINTS)
 3) If there's no built-in icon, use the DefaultIcon

Is that it?

That seems useful to me.  Maybe I have this wrong, though, since I don't
see how this breaks compatibility with existing config files...

-- 
-------------------------------------------------------------------------------
 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: Dominik Vogt <[email-masked]>
Date: Thu, 15 Apr 1999 15:53:14 +0200

>  2) If not, use the icon built into the app (WM_HINTS)

No, that's not what we have now. It's like this:

  1) Use the icon in a Style but don't look at the "*" style.
  2) If not, use the icon built into the app (WM_HINTS) if there is one
  3) If there's no built-in icon, use the DefaultIcon

The default icon can be defined with the DefaultIcon command as well
as with 'Style * Icon default.xpm'

>  3) If there's no built-in icon, use the DefaultIcon

Yes, that's right. The objection I have against this one is this:
Old config files often define a default icon with 'Style * Icon default.xpm'.
Look at step 1. The new logic will force the default.xpm upon any
application. No application supplied icons are possible anymore.
That does break existing config files because at present 'Style *'
just defines the default icon that is used in step 3.

I'm perfectly happy with the current solution. The only (small)
problem I see is that 'Style * Icon foo.xpm' and 'Style ** foo.xpm'
don't do the same thing (the first command defines a default icon,
the second one stores it in the style as any other style name would).

Bye

Dominik ^_^

---

From: Matthias Clasen <[email-masked]>
Date: Thu, 15 Apr 1999 16:17:19 +0200

> can't imagine one. If you have one, open my eyes.

There is not a single line in the man page telling him that 
Style * Icon foo.xpm sets the default icon rather than forcing foo.xpm
on all windows. 

> head when there is such a simple solution?

Well, especially for cut-n-paste configuration by modifying examples,
consistency is important.  Otherwise modifying examples doesn't work
too well.  I agree that the point of Style ** Icon is probably moot
and if you prefer it, I'll revert the changes I have done (ie
remove DefaultIcon and add the "hack" back), and just put a note
in the man page about the whole issue.

Matthias

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 15 Apr 1999 17:11:04 +0200

> Style * Icon foo.xpm sets the default icon rather than forcing foo.xpm

That's right. Although it is what the user probably expects it is not
documented. We have to fix the documentation.

> in the man page about the whole issue.

Hmm, I still don't see this supposed change in the code. Are we
referring to the same code? The last few lines of style.c:

  /* capture default icons */
  if(StrEquals(tmpstyle.name, "*"))
  {
    if(tmpstyle.flags.has_icon == 1)
      Scr.DefaultIcon = tmpstyle.icon_name;
    tmpstyle.flags.has_icon = 0;
    tmpstyle.flag_mask.has_icon = 0;
    tmpstyle.icon_name = NULL;
  }

It's still there. What we have to do is remove multiple asterisks
from style names (Style netscape** and Style netscape* would cause
unnecessary memory consumtion too).

Bye

Dominik ^_^

P.S.: I hope there are no hard feelings because of the hot discussion.
      I didn't want to get personally, I simply care a lot about this
      change.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 15 Apr 1999 17:13:08 +0200

On Thu, Apr 15, 1999 at 04:30:37PM +0200, Matthias Claasen wrote:
> OK, then we perhaps agree on leaving DefaultIcon plus the hack 
> (which I forgot to remove) in CVS, plus adding a little explanation
> to the man page. 

OK, no problem.

> I don't think that * vs ** is important enough to warrant any change
> to the code, I'd we should just add an example to the man page illuminating
> the difference. 

Well, you're right. Perhaps we should just tell people not to use
more than one asterisk in a row in the man page.

Bye

Dominik ^_^

---

From: Matthias Clasen <[email-masked]>
Date: Thu, 15 Apr 1999 17:36:28 +0200

> referring to the same code? The last few lines of style.c:

Yes we are. Sorry, I was confused, since I removed the hack from my
working directory, but forgot to commit it. No need to put the hack 
back, since it is still there! And no need to remove DefaultIcon
either, unless someone *really* dislikes it.

> unnecessary memory consumtion too).

Yes, thats another argument for collapsing *'s (not that I expect 
star sequences to be a common phenomenon in users rc files). 

Matthias

---

From: [email-masked]
Date: 17 Apr 1999 00:22:28 +0200

Dominik Vogt <[email-masked]> writes:

  > supposed 'default' icon.

How about attacking the whole thing from the other side?  How about
specifying that `Style foo Icon bar' *never* overrides an icon
specified by a program, unless OverrideProgramIcon or something is
also specified?

This would enable me to say `Style * Icon unknown.xpm' to specify
icons for `unknown' programs, and `Style XTerm Icon unknown_xterm.xpm'
for unknown xterms.  And xterms started like `xterm -name rlogin' can
use special icons.

This is probably a stupid suggestion, but maybe someone can actually
come up with a useful suggestion.

Most of the time, I turn off icons.  I find I almost never use them.
But now that I've found out about the +ai option for xterm, I think
I'll use more icons...

kai
-- 
Abort this operation?   [Abort]  [Cancel]

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 18 Apr 1999 03:30:15 +0200

> come up with a useful suggestion.

I don't think it's stupid. On the contrary, considering what you want
to do most of the time when specifying an icon it's a very good
suggestions. Why do people specify their own icons?

  a) Because the application doesn't provide an icon.
  b) Bacause the application supplied icon looks crappy.
  c) Because they use some fancy theme (that may be simply personal
     taste).

At present we can only make people with reasons b and c happy. 
Personally it bothers me that many of my icons are identical
although they're not from the same application, but the reson here
is that e.g. xterm and rxvt both don't provide an icon. This
idea would warrant a code change only if there *are* types of
applications that share the same resource/class where one application
defines an icon and another one doesn't.

Bye

Dominik ^_^