On Tue, Jan 22, 2002 at 03:11:28PM +0100, Olivier Chapuis wrote:
> 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.
That would help a lot.
> With this ewmh_SetWmIconFromPixmap() will not modify the FvwmWindow
> structure by a call to GetIconPicture.
Not? Then why is it called at all? I'm puzzled.
> Moreover, GetIconPicture (and
> GetIconBitmap, GetIconWindow, ...etc) may be moved into the library
> and used by FvwmIconBox.
Also a good idea. There is way too much code duplication in
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.
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.
> 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.
Um, really? Doh. Forget my comments above.
> 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.
Um, how about shorter names like
EWMH_GetIconPicture
and
EWMH_DonateIconPicture
plus
SetIconPicture (icons.c)
?
> 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.
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 ^_^ ^_^
--
Dominik Vogt, email: [EMAIL PROTECTED]
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
