Subject: icons, ewmh icons and information hiding

From: Dominik Vogt <[email-masked]>
Date: Tue, 22 Jan 2002 11:04:24 +0100

I'm trying to clean up that unholy mess with icons in fvwm.  In
other words:  I'm trying to give all (okay: most) icon related
information a clear interface in icons.h and use that everywhere.

I started with the functions in icons.c that find out the window
or pixmap to use at the icons.  These are currently modifying the
window structure directly.  Unfortunately, GetIconPicture() is
called from ewmh_icons.c recursively which makes this a whole lot
more difficult.  Also, ewmh_SetWmIconFromPixmap() is called from
several places in fvwm.  This should only be done from
GetIconPicture().  For example, when fvwm wants to donate its icon
to the ewmh hints, EWMH_DoUpdateWmIcon() (shouldn't this be called
EWMH_DonateWmIcon?) which in turn calls ewmh_SetWmIconFromPixmap()
again which modifies the window structure and then even calls
GetIconPicture().

Olivier, can this be rewritten so that:

 1) There is a function that just donates the icon without
    modifying the FvwmWindow (BTW, what happens if fvwm deletes
    the pixmap used in the hint?)
 2) ewmh_SetWmIconFromPixmap() does not modify the window
    structure but instead just returns what it found through
    pointers.
 3) Make all icon setup run through icons.c.  I think update.c
    should not call EWMH_SetIconFromWMIcon() but some more generic
    function in icons.c that knows what to do and that makes the
    call to ewmh_icons.c if necessary.  The knowledge about ewmh
    icons should be limited to as few files as possible.

And then there are setup_icon() and change_icon() in add_window.c.
In theory, when the icon changes for some reason it should be
possible to simply call change_icon() and that takes care of
anything else. (?)

Bye

Dominik ^_^  ^_^

-- 
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
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: Olivier Chapuis <[email-masked]>
Date: Tue, 22 Jan 2002 15:11:28 +0100

On Tue, Jan 22, 2002 at 11:04:24AM +0100, Dominik Vogt wrote:
> more difficult.  

Yes, this is done because if the window is not iconified (or the
style is NoIcon), then the FvwmWindow structure does not contain
information on the icon which will be displayed by fvwm2 (also
there is some problems to create the ewmh icon from the info
given by the FvwmWindow structure if the icon info are set in
the structure). So, ewmh_SetWmIconFromPixmap() save the info
concerning the icon of the FvwmWindow structure, create it (possibly
again if the window is iconified), create the ewmh icon and set it on
the application, destroy the created data and restore the original
info in the  FvwmWindow structure.
What about, having a FvwmIconPicture structure:

typedef struct FvwmIconPicture
{
  int iconDepth;              /* Drawable depth for the icon */
  Window icon_pixmap_w        /* icon picture window */
  Pixmap iconPixmap;          /* pixmap for the icon */
  Pixmap icon_maskPixmap;     /* pixmap for the icon mask */
  rectangle g                 /* geometry of the icon picture window */	
} FvwmIconPicture;

Then, GetIconPicture can be split into two pieces: 

(1) GetIconPicture(order_rules, *icon_file, window, ...)
   which only return an FvwmIconPicture structure (passed
   to GetIconBitmap, GetIconWindow, ...EWMH_SetIconFromWMIcon etc)
(2) SetIconPicture(FvwmWindow)
   which set the FvwmIconPicture structure of the FvwmWindow structure
   via GetIconPicture.

With this ewmh_SetWmIconFromPixmap() will not modify the FvwmWindow
structure by a call to GetIconPicture. Moreover, GetIconPicture (and
GetIconBitmap, GetIconWindow, ...etc) may be moved into the library
and used by FvwmIconBox.

> Unfortunately, GetIconPicture() is
> more difficult.  
> Also, ewmh_SetWmIconFromPixmap() is called from

I do not think that ewmh_SetWmIconFromPixmap() is called recursively.
ewmh_SetWmIconFromPixmap() is called when:
1) the window map (iconified or not) 
2) a style changes modify the icons which should be donated to
the application as an ewmh icon.
3) the app change its icon via the hints and styles tell fvwm2
to use the window icon.

ewmh_SetWmIconFromPixmap() is never called from GetIconPicture()
it is EWMH_SetIconFromWMIcon() which is called from GetIconPicture()
which is the reversed operation. Of course one may be afraid that
something like this happen: the window map with an ewmh icons (a true
one set by the app), fvwm2 EWMH_SetIconFromWMIcon() and then
fvwm2 ewmh_SetWmIconFromPixmap() !! But this never happen as
there is a flag in the FvwmWindow structure which forbid such
operation.

>     structure but instead just returns what it found through

This is not a problem. Indeed ewmh_SetWmIconFromPixmap should work
like this. ((But a few elements in the FvwmWindow structure must
be set by ewmh_SetWmIconFromPixmap (as ewmh_icon_height and
ewmh_icon_width) but these elements concerns only
ewmh_SetWmIconFromPixmap))

>     icons should be limited to as few files as possible.

EWMH_SetIconFromWMIcon() is not called in update.c for icon (it is
called in update.c for mini-icons only). On the other hands
ewmh_SetWmIconFromPixmap() is called in update.c, but in a certain
sense this does not concern the fvwm2 icon code.
I am not sure but some times it seems that you inverse

  * EWMH_SetIconFromWMIcon
      make fvwm2 using the ewmh icon as icon, this function should
      work as GetIconBitmap, GetIconWindow, ...etc

and

  * ewmh_SetWmIconFromPixmap
      set an ewmh icon hint on the application from the icon that
      fvwm2 will/may/actually use (this never happen if the app has
      an ewmh icon). It use GetIconPixmap as a library function:
      it is true that this is not good!

May be the names are not good. EWMH_GetEWMHIcon and
ewmh_SetEwmhWmIconFromFvwmIcon are maybe better.

Maybe I said one or two stupid things. Anyway, if you make change
in the icons code I will double check the EWMH part (you may
disabled some troubling part with some #ifdef) and test the
new codes.

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 22 Jan 2002 16:26:55 +0100

>    which set the FvwmIconPicture structure of the FvwmWindow structure

That would help a lot.

> structure by a call to GetIconPicture.

Not?  Then why is it called at all?  I'm puzzled.

> Moreover, GetIconPicture (and

Also a good idea.  There is way too much code duplication in
FvwmIconBox.

> I do not think that ewmh_SetWmIconFromPixmap() is called recursively.

With 'recursively' I mean that GetIconPicture() calls
ewmh_SetWmIconFromPixmap() which again calls GetIconPicture().  It
won't call ewmh_SetWmIconFromPixmap() again.  That link makes it
difficult to separate icons.c and ewmh_icons.c in the proposed
way (i.e. make icons.c become a se4rvice "library" for all icon
functionality).  Of course it would have been much easier if fvwm
had been designed in a modular way from the start.

> which is the reversed operation.

Um, really?  Doh.  Forget my comments above.

> Of course one may be afraid that

Um, how about shorter names like

  EWMH_GetIconPicture

and

  EWMH_DonateIconPicture

plus

  SetIconPicture (icons.c)

?

> disabled some troubling part with some #ifdef) and test the

I tried but I can't.  I don't understand enough of the code in
ewmh_icons.c to do this right.  I have a version on my disk that
lets all the Get... functions in icons.c write into return
parameters instead of directly into the window structure, but I
was unable to make the changes in ewmh_icons.c.  Is still don't
understand how this code works clearly.

Bye

Dominik ^_^  ^_^