On Tue, Jan 22, 2002 at 11:04:24AM +0100, Dominik Vogt wrote:
> 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.  

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

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.

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

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

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

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
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]

Reply via email to