Re: EWMH icons
Some apps (for example GVim) appear to have their own icons built in I'm wondering if there's a way to access them somehow? (through the perllib interface of course) Using the WindowList tracker, M_MINI_ICON events have the value ewmh_mini_icon for the name/mini_icon_name field. Not useful to FvwmTabs as I can't load the image. I suppose you mean field named icon_id in M_MINI_ICON in perllib. Ah, I can do a XGetImage($icon_id). Are you sure you can't just embed the mini icon window by its id? Don't think so. There appears to be only one copy of each mini icon (pixmap) in the X server - the same icon_id can be used by multiple windows. You will need to do this anyway, since I think Tk does not support png. Tk supports PNG images just fine - I am currently using them in FvwmTabs. If you are at it, feel free to update FvwmWindowMenu to use WindowList tracker Sure. I'm currently implementing a whole bunch of new features for FvwmTabs - I'll look at FvwmWindowMenu after I release the next version. and to support ewmh mini icons (I guess, you need to patch fvwm menus a bit to support mini-icons by window id, in addition to by name). Ok. SCoTT. :) -- 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]
Re: EWMH icons
On 22 May 2004 05:24:42 +1000, Scott Smedley wrote: Some apps (for example GVim) appear to have their own icons built in I'm wondering if there's a way to access them somehow? (through the perllib interface of course) Using the WindowList tracker, M_MINI_ICON events have the value ewmh_mini_icon for the name/mini_icon_name field. Not useful to FvwmTabs as I can't load the image. I suppose you mean field named icon_id in M_MINI_ICON in perllib. Are you sure you can't just embed the mini icon window by its id? You will need to do this anyway, since I think Tk does not support png. If you are at it, feel free to update FvwmWindowMenu to use WindowList tracker and to support ewmh mini icons (I guess, you need to patch fvwm menus a bit to support mini-icons by window id, in addition to by name). :-) Regards, Mikhael. -- 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]
EWMH icons
Hi Mikhael, A question for you: Some apps (for example GVim) appear to have their own icons built in I'm wondering if there's a way to access them somehow? (through the perllib interface of course) Using the WindowList tracker, M_MINI_ICON events have the value ewmh_mini_icon for the name/mini_icon_name field. Not useful to FvwmTabs as I can't load the image. I'm trying to associate mini icons with each tab in FvwmTabs. See: http://users.tpg.com.au/users/scottie7/tmp/fvwmtabs.icons.png Any ideas? SCoTT. :) -- 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]
CVS olicha: * Fixed the shape mask of ewmh icons and icons with some alpha
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: olicha 02/08/30 03:40:57 Modified files: . : ChangeLog fvwm : ewmh_icons.c icons.c Log message: * Fixed the shape mask of ewmh icons and icons with some alpha -- 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]
CVS olicha: * Speed up color limitation for png image and ewmh icons
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: olicha 02/04/05 08:19:36 Modified files: . : ChangeLog libs : FImageLoader.c Log message: * Speed up color limitation for png image and ewmh icons * Respect color limit even with DirectColor and TrueColor -- 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]
icons, ewmh icons and information hiding
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 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]
Re: icons, ewmh icons and information hiding
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
Re: icons, ewmh icons and information hiding
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
