Re: Notification: incoming/847
On 22 Jan 2002 21:25:38 +0100, Olivier Chapuis wrote: > > Any way I do not understand why xterm considers > iso-8859-15 string as multibyte string if the string > contains non ascii characters (with an iso-8859-15 locale). Someone said previously that this is not multibyte for one-byte non iso8859-1 charsets, but escape sequences containing charset as a hint. Maybe we should just write a filter that strips these escape sequences with --disable-multibyte, if we don't use this charset info anyway? > I do not know if we should close this bug report. I think > that we can put it in confirmed, do so that --enable-multibyte > can be the default and then close it. > > BTW, Mikhael, what about distributing i18n rpms? I would not double the number of rpms. Are --enable-multibyte problems easily solvable for it to be a default? If not, stripping escape sequences would be a good solution. Regards, MIkhael. -- Visit the official FVWM web page at 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: Notification: incoming/847
On Tue, Jan 22, 2002 at 04:46:24PM +0100, Olivier Chapuis wrote: > On Tue, Jan 22, 2002 at 03:55:48AM -0600, [EMAIL PROTECTED] wrote: > > FVWM Bug Tracking notification > > > > new message incoming/847 > > > > Message summary for PR#847 > > From: [EMAIL PROTECTED] > > Subject: Bug in window Title with iso8859-15 > > Date: Tue, 22 Jan 2002 03:55:43 -0600 > > 0 replies 0 followups > > > > > ORIGINAL MESSAGE FOLLOWS < > > > > Date: Tue, 22 Jan 2002 03:55:43 -0600 > > > > Full_Name: Nicolas CRoiset > > Version: 2.4.4 > > CVS_Date: > > OS: linux RH 7.2 > > X_Server: XFree86-4.1.0 > > Submission from: (NULL) (80.65.226.85) > > > > > > When you have a title with accents on characters, the Title is not display > > correctly. > > > > For example "Mise à jour de l'heure". > > > > we installed fvwm with fvwm-2.4.4-2.rh7.i386.rpm > > > > Hello, > > Do this happen with all applications? > > What happen with > > xterm -T "¤éèàç" > > and > > env LC_CTYPE=fr_FR xterm -T "¤éèàç" > > (the first characters is the EuroSign). If you have rxvt can > you try with it too. > > This seems strange but you may have to compile fvwm yourself > with --enable-multibyte as option to ./configure > (I need to do that so that xterm works properly with fvwm > and an "@euro" locale). > I've got some feedback from Nicolas Croiset. Compiling fvwm with --enable-multibyte fix the problems. Any way I do not understand why xterm considers iso-8859-15 string as multibyte string if the string contains non ascii characters (with an iso-8859-15 locale). I do not know if we should close this bug report. I think that we can put it in confirmed, do so that --enable-multibyte can be the default and then close it. BTW, Mikhael, what about distributing i18n rpms? Olivier -- Visit the official FVWM web page at 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: Remaining issues in Transparency
On Tue, Jan 22, 2002 at 04:14:14PM +0100, Olivier Chapuis wrote: > On Tue, Jan 22, 2002 at 10:44:42AM +0100, Dominik Vogt wrote: > > On Tue, Jan 22, 2002 at 09:03:16AM +0100, Olivier Chapuis wrote: > > > On Mon, Jan 21, 2002 at 04:14:17PM +0100, Dominik Vogt wrote: > > > > On Mon, Jan 21, 2002 at 03:07:55PM +0100, Olivier Chapuis wrote: > > > > > Hello, > > > > > > > [snip] > > > > > An other problem is transparent modules swallowed into > > > > > a transparent or not FvwmButtons, there are currently > > > > > some problems when the colorsets of the FvwmButtons change. > > > > > > A solution here, is again a new command similar to Colorset. > > > When a FvwmButton change the background of a swallowed window > > > with X-id ID (and if the swallowed app is an Fvwm module, see > > > the next paragraph) it can send the command "BackgroundChange". > > > > Whoa, don't overestimate the usefulness of that FvwmButtons hack. > > Setting the background of swallowed applications > > > > - is *evil* > > - rarely works > > - may screw up or even crash the application > > > > You can't even find out which window to set the background to. > > Personally, I'd not even consider making transparency of swallowed > > windows in a transparent button bar working :-) > > > > Yes agree. But It will be fine that if a FvwmButton button swallow > a _Fvwm Module_ with a transparent background (typically a FvwmPager > or an IconMan), the things work in the following sens: > 1 - Disabled the evil hack for Fvwm Module > 2 - If the background of the button change inform the swallowed modules > (by using module to fvwm2 to module communication). Yes, I agree. That's a good thing to do. > > > Then fvwm2 will send the string "ROOT_BG_CHANGE_STRING ID" > > > to modules and the module with X-id ID may be able to update > > > its background if it is transparent (fvwm2 already send > > > "ROOT_BG_CHANGE_STRING" when fvwm2 detects that the root > > > background change). BTW, it will be maybe better to send > > > a MX_ROOT_BG_CHANGE message as we have now some places? > > > > If the message makes sense I have no objections. To prevent that > > we run out of messages again too soon one might consider to write > > a generic message like 'MX_PROPERTY_CHANGE' with an argument like > > BG_CHANGE, FOO_CHANGE, BAR_CHANGE etc. > > Yes, good idea I will use it. > > > > Also it will be useful for FvwmButtons to know if the > > > swallowed window is a FVWM Module or a normal X application. > > > The only solution I see is to claim in the FvwmButtons > > > man page that if the swallow command begin with Fvwm or > > > Module then FvwmButtons will consider that it will > > > swallow a Fvwm module. > > > > I guess it would be acceptable if the user has to put this > > information in the Swallow command, e.g. > > > > *FvwmButtons(Swallow (fvwmmodule) foo "exec foo") > > > > > So if a complex function is used to launch a swallowed app the > > > name of this complex function have some importance. > > > > I don't understand what you mean. > > What I mean is that with a line of the form: > > *FvwmButtons(Swallow "foo" "Module foo [xyz]") > or > *FvwmButtons(Swallow "foo" "Fvwmfoo [xyz]") > > then FvwmButtons consider that it swallow a Fvwm Module > and with a line of the form > > *FvwmButtons(Swallow "foo" "Complexfunc") > or > *FvwmButtons(Swallow "Foo" "Exec exec foo") > > then FvwmButtons consider that it swallow classical > X app. > > But of course Complexfunc can run a module and Fvwmfoo > maybe a complex function which runs a classical X app. > > In the place of the "fvwmmodule" flags for Swallow I > will prefer that FvwmButtons consider that it swallows > a Fvwm Module if the swallow command begin with "Module" > (no space at the end, no case of course). No? Okay. In addition the option I proposed won't hurt for the cases in which the module has another name (some old setups may do this with aliases) or a normal application has such a name. > But we may imagine a more complex protocol: FvwmButtons > send a message to all modules when it swallows an > application with the x-id of the swallowed window and > with the x-id the FvwmButtons, if a module recognize > itself it sends back a message with the x-id of the > FvwmButtons. > > > > Is this acceptable? > > > > > Maybe, in the place of "BackgroundChange" we may use a command > > > as "SwallowedConfigure id [bg_ch ...other options in the future]", > > > which will force fvwm to send a MX_SWALLOWED_CONFIGURE message. > > > > Fvwm does not manage swallowed windows. The window structure is > > destroyed when the window is reparented to FvwmButtons. > > Yes I know. But, of course fvwm2 still sends messages to a sawllowed > modules. Ah, yes, right. > So, it is possible that a FvwmButtons says to a module > that it is swallowed and it can send a message to this module via > fvwm2 (E.g., a MX_PROPERTY_CHANGE with SWALLOWED as argument). Bye Dominik ^_^ ^_^ -- Dominik Vog
Re: Notification: incoming/847
On Tue, Jan 22, 2002 at 03:55:48AM -0600, [EMAIL PROTECTED] wrote: > FVWM Bug Tracking notification > > new message incoming/847 > > Message summary for PR#847 > From: [EMAIL PROTECTED] > Subject: Bug in window Title with iso8859-15 > Date: Tue, 22 Jan 2002 03:55:43 -0600 > 0 replies 0 followups > > > ORIGINAL MESSAGE FOLLOWS < > > Date: Tue, 22 Jan 2002 03:55:43 -0600 > > Full_Name: Nicolas CRoiset > Version: 2.4.4 > CVS_Date: > OS: linux RH 7.2 > X_Server: XFree86-4.1.0 > Submission from: (NULL) (80.65.226.85) > > > When you have a title with accents on characters, the Title is not display > correctly. > > For example "Mise à jour de l'heure". > > we installed fvwm with fvwm-2.4.4-2.rh7.i386.rpm > Hello, Do this happen with all applications? What happen with xterm -T "¤éèàç" and env LC_CTYPE=fr_FR xterm -T "¤éèàç" (the first characters is the EuroSign). If you have rxvt can you try with it too. This seems strange but you may have to compile fvwm yourself with --enable-multibyte as option to ./configure (I need to do that so that xterm works properly with fvwm and an "@euro" locale). Regards, Olivier -- Visit the official FVWM web page at 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: CVS domivogt: * New nice commands ResizeMaximize and ResizeMoveMaximize. These allow
On Tue, Jan 22, 2002 at 03:16:37PM +, Mikhael Goikhman wrote: > On 17 Jan 2002 16:24:00 -0600, FVWM CVS wrote: > > > > CVSROOT:/home/cvs/fvwm > > Module name:fvwm > > Changes by: domivogt02/01/17 16:24:00 > > > > Modified files: > > . : ChangeLog NEWS > > fvwm : commands.h decorations.c functions.c > > functions.h fvwm2.1 move_resize.c > > > > Log message: > > * New nice commands ResizeMaximize and ResizeMoveMaximize. These allow > > a) To resize a window interactively and maximize it in one operation so that > > you can switch back to the original geometry. > > b) To exactly control the geometry of a maximized window. > > Try to interactively ResizeMaximize a window not on page (0, 0). > The window disappears (gets incorrect position). > > I can reproduce this consistently, hope you can too. Yes, fixed. There may still be a problem if you interactively resize the window over a page boundary (with paging). 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 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 domivogt: * Fixed ResizeMaximize and ResizeMoveMaximize on pages other than 0 0.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/01/22 09:38:08 Modified files: . : ChangeLog fvwm : move_resize.c Log message: * Fixed ResizeMaximize and ResizeMoveMaximize on pages other than 0 0. -- Visit the official FVWM web page at 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 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))
>
Re: Remaining issues in Transparency
On Tue, Jan 22, 2002 at 10:44:42AM +0100, Dominik Vogt wrote: > On Tue, Jan 22, 2002 at 09:03:16AM +0100, Olivier Chapuis wrote: > > On Mon, Jan 21, 2002 at 04:14:17PM +0100, Dominik Vogt wrote: > > > On Mon, Jan 21, 2002 at 03:07:55PM +0100, Olivier Chapuis wrote: > > > > Hello, > > > > > [snip] > > > > An other problem is transparent modules swallowed into > > > > a transparent or not FvwmButtons, there are currently > > > > some problems when the colorsets of the FvwmButtons change. > > > > A solution here, is again a new command similar to Colorset. > > When a FvwmButton change the background of a swallowed window > > with X-id ID (and if the swallowed app is an Fvwm module, see > > the next paragraph) it can send the command "BackgroundChange". > > Whoa, don't overestimate the usefulness of that FvwmButtons hack. > Setting the background of swallowed applications > > - is *evil* > - rarely works > - may screw up or even crash the application > > You can't even find out which window to set the background to. > Personally, I'd not even consider making transparency of swallowed > windows in a transparent button bar working :-) > Yes agree. But It will be fine that if a FvwmButton button swallow a _Fvwm Module_ with a transparent background (typically a FvwmPager or an IconMan), the things work in the following sens: 1 - Disabled the evil hack for Fvwm Module 2 - If the background of the button change inform the swallowed modules (by using module to fvwm2 to module communication). > > Then fvwm2 will send the string "ROOT_BG_CHANGE_STRING ID" > > to modules and the module with X-id ID may be able to update > > its background if it is transparent (fvwm2 already send > > "ROOT_BG_CHANGE_STRING" when fvwm2 detects that the root > > background change). BTW, it will be maybe better to send > > a MX_ROOT_BG_CHANGE message as we have now some places? > > If the message makes sense I have no objections. To prevent that > we run out of messages again too soon one might consider to write > a generic message like 'MX_PROPERTY_CHANGE' with an argument like > BG_CHANGE, FOO_CHANGE, BAR_CHANGE etc. > Yes, good idea I will use it. > > Also it will be useful for FvwmButtons to know if the > > swallowed window is a FVWM Module or a normal X application. > > The only solution I see is to claim in the FvwmButtons > > man page that if the swallow command begin with Fvwm or > > Module then FvwmButtons will consider that it will > > swallow a Fvwm module. > > I guess it would be acceptable if the user has to put this > information in the Swallow command, e.g. > > *FvwmButtons(Swallow (fvwmmodule) foo "exec foo") > > > So if a complex function is used to launch a swallowed app the > > name of this complex function have some importance. > > I don't understand what you mean. > What I mean is that with a line of the form: *FvwmButtons(Swallow "foo" "Module foo [xyz]") or *FvwmButtons(Swallow "foo" "Fvwmfoo [xyz]") then FvwmButtons consider that it swallow a Fvwm Module and with a line of the form *FvwmButtons(Swallow "foo" "Complexfunc") or *FvwmButtons(Swallow "Foo" "Exec exec foo") then FvwmButtons consider that it swallow classical X app. But of course Complexfunc can run a module and Fvwmfoo maybe a complex function which runs a classical X app. In the place of the "fvwmmodule" flags for Swallow I will prefer that FvwmButtons consider that it swallows a Fvwm Module if the swallow command begin with "Module" (no space at the end, no case of course). No? But we may imagine a more complex protocol: FvwmButtons send a message to all modules when it swallows an application with the x-id of the swallowed window and with the x-id the FvwmButtons, if a module recognize itself it sends back a message with the x-id of the FvwmButtons. > > Is this acceptable? > > > Maybe, in the place of "BackgroundChange" we may use a command > > as "SwallowedConfigure id [bg_ch ...other options in the future]", > > which will force fvwm to send a MX_SWALLOWED_CONFIGURE message. > > Fvwm does not manage swallowed windows. The window structure is > destroyed when the window is reparented to FvwmButtons. > Yes I know. But, of course fvwm2 still sends messages to a sawllowed modules. So, it is possible that a FvwmButtons says to a module that it is swallowed and it can send a message to this module via fvwm2 (E.g., a MX_PROPERTY_CHANGE with SWALLOWED as argument). Olivier -- Visit the official FVWM web page at 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: CVS domivogt: * New nice commands ResizeMaximize and ResizeMoveMaximize. These allow
On 17 Jan 2002 16:24:00 -0600, FVWM CVS wrote: > > CVSROOT: /home/cvs/fvwm > Module name: fvwm > Changes by: domivogt02/01/17 16:24:00 > > Modified files: > . : ChangeLog NEWS > fvwm : commands.h decorations.c functions.c >functions.h fvwm2.1 move_resize.c > > Log message: > * New nice commands ResizeMaximize and ResizeMoveMaximize. These allow > a) To resize a window interactively and maximize it in one operation so that > you can switch back to the original geometry. > b) To exactly control the geometry of a maximized window. Try to interactively ResizeMaximize a window not on page (0, 0). The window disappears (gets incorrect position). I can reproduce this consistently, hope you can too. Regards, Mikhael. -- Visit the official FVWM web page at 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]
Notification: incoming/847
FVWM Bug Tracking notification new message incoming/847 Message summary for PR#847 From: [EMAIL PROTECTED] Subject: Bug in window Title with iso8859-15 Date: Tue, 22 Jan 2002 03:55:43 -0600 0 replies 0 followups > ORIGINAL MESSAGE FOLLOWS < >From [EMAIL PROTECTED] Tue Jan 22 03:55:48 2002 Received: from karazm.math.uh.edu ([129.7.128.1]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 16Sxed-0003gs-00 for [EMAIL PROTECTED]; Tue, 22 Jan 2002 03:55:47 -0600 Received: from malifon.math.uh.edu (IDENT:[EMAIL PROTECTED] [129.7.128.13]) by karazm.math.uh.edu (8.9.3/8.9.3) with ESMTP id DAA08011 for <[EMAIL PROTECTED]>; Tue, 22 Jan 2002 03:55:43 -0600 (CST) From: [EMAIL PROTECTED] Received: from localhost ([127.0.0.1] ident=65534) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 16SxeZ-0003go-00 for [EMAIL PROTECTED]; Tue, 22 Jan 2002 03:55:43 -0600 To: [EMAIL PROTECTED] Subject: Bug in window Title with iso8859-15 Message-Id: <[EMAIL PROTECTED]> Date: Tue, 22 Jan 2002 03:55:43 -0600 Full_Name: Nicolas CRoiset Version: 2.4.4 CVS_Date: OS: linux RH 7.2 X_Server: XFree86-4.1.0 Submission from: (NULL) (80.65.226.85) When you have a title with accents on characters, the Title is not display correctly. For example "Mise à jour de l'heure". we installed fvwm with fvwm-2.4.4-2.rh7.i386.rpm -- Visit the official FVWM web page at 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
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 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: Remaining issues in Transparency
On Tue, Jan 22, 2002 at 09:03:16AM +0100, Olivier Chapuis wrote: > On Mon, Jan 21, 2002 at 04:14:17PM +0100, Dominik Vogt wrote: > > On Mon, Jan 21, 2002 at 03:07:55PM +0100, Olivier Chapuis wrote: > > > Hello, > > > > > > I hope that the Transparent colorset for top level background > > > work fine now for all modules but for FvwmWharf (a lot of > > > changes is needed here and there is FvwmButtons if one want > > > transparency). > > > > > > Of course so that Transparency works the module must have the > > > ParentalRelativity Style. I think it will be good that if > > > a module has a Transparent colorset background then fvwm2 > > > sets automatically this style to the module and unset this > > > style if the colorset is no more transparent (the > > > WindowShadeShrinks style may be toggled too). This is more > > > in the spirit of FvwmThemes than using a Style command > > > after a colorset change. > > > One solution is to add an FVWM extension to the wm-spec: > > > we can add a new state FVWM_NET_WM_STATE_PARENT_RELATIVE. > > > Monitoring this state will allow to automatically sets > > > the good styles. Is there any objection for this method? > > > > Wouldn't it be better to keep that functionality inside fvwm for > > now and not export properties to the world? This could be done > > with a style: > > > > SendToModule FvwmTheme ... > > Style FvwmButtons ParentRelativeFrameBackground > > > > I am afraid to do not understand. what I would like to > implement is automatic configuration. An alternative to > atom is a new (undocumented) _command_, say, ParentRelative. > If a module has a transparent background then it send to > fvwm2 "ParentRelative On" to force the ParentalRelativity and > WindowShadeShrinks styles. If the colorset change and the > background become non transparent the modules then send > "ParentRelative Off". Okay, a (module) command then. I didn't give it too much though. I just don't like the idea of exporting such information to the world that anybody might use and then complain if we change it some day. > > > An other problem is transparent modules swallowed into > > > a transparent or not FvwmButtons, there are currently > > > some problems when the colorsets of the FvwmButtons change. > > A solution here, is again a new command similar to Colorset. > When a FvwmButton change the background of a swallowed window > with X-id ID (and if the swallowed app is an Fvwm module, see > the next paragraph) it can send the command "BackgroundChange". Whoa, don't overestimate the usefulness of that FvwmButtons hack. Setting the background of swallowed applications - is *evil* - rarely works - may screw up or even crash the application You can't even find out which window to set the background to. Personally, I'd not even consider making transparency of swallowed windows in a transparent button bar working :-) > Then fvwm2 will send the string "ROOT_BG_CHANGE_STRING ID" > to modules and the module with X-id ID may be able to update > its background if it is transparent (fvwm2 already send > "ROOT_BG_CHANGE_STRING" when fvwm2 detects that the root > background change). BTW, it will be maybe better to send > a MX_ROOT_BG_CHANGE message as we have now some places? If the message makes sense I have no objections. To prevent that we run out of messages again too soon one might consider to write a generic message like 'MX_PROPERTY_CHANGE' with an argument like BG_CHANGE, FOO_CHANGE, BAR_CHANGE etc. > Also it will be useful for FvwmButtons to know if the > swallowed window is a FVWM Module or a normal X application. > The only solution I see is to claim in the FvwmButtons > man page that if the swallow command begin with Fvwm or > Module then FvwmButtons will consider that it will > swallow a Fvwm module. I guess it would be acceptable if the user has to put this information in the Swallow command, e.g. *FvwmButtons(Swallow (fvwmmodule) foo "exec foo") > So if a complex function is used to launch a swallowed app the > name of this complex function have some importance. I don't understand what you mean. > Is this acceptable? > Maybe, in the place of "BackgroundChange" we may use a command > as "SwallowedConfigure id [bg_ch ...other options in the future]", > which will force fvwm to send a MX_SWALLOWED_CONFIGURE message. Fvwm does not manage swallowed windows. The window structure is destroyed when the window is reparented to FvwmButtons. 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 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: Remaining issues in Transparency
On Mon, Jan 21, 2002 at 04:14:17PM +0100, Dominik Vogt wrote: > On Mon, Jan 21, 2002 at 03:07:55PM +0100, Olivier Chapuis wrote: > > Hello, > > > > I hope that the Transparent colorset for top level background > > work fine now for all modules but for FvwmWharf (a lot of > > changes is needed here and there is FvwmButtons if one want > > transparency). > > > > Of course so that Transparency works the module must have the > > ParentalRelativity Style. I think it will be good that if > > a module has a Transparent colorset background then fvwm2 > > sets automatically this style to the module and unset this > > style if the colorset is no more transparent (the > > WindowShadeShrinks style may be toggled too). This is more > > in the spirit of FvwmThemes than using a Style command > > after a colorset change. > > One solution is to add an FVWM extension to the wm-spec: > > we can add a new state FVWM_NET_WM_STATE_PARENT_RELATIVE. > > Monitoring this state will allow to automatically sets > > the good styles. Is there any objection for this method? > > Wouldn't it be better to keep that functionality inside fvwm for > now and not export properties to the world? This could be done > with a style: > > SendToModule FvwmTheme ... > Style FvwmButtons ParentRelativeFrameBackground > I am afraid to do not understand. what I would like to implement is automatic configuration. An alternative to atom is a new (undocumented) _command_, say, ParentRelative. If a module has a transparent background then it send to fvwm2 "ParentRelative On" to force the ParentalRelativity and WindowShadeShrinks styles. If the colorset change and the background become non transparent the modules then send "ParentRelative Off". > > An other problem is transparent modules swallowed into > > a transparent or not FvwmButtons, there are currently > > some problems when the colorsets of the FvwmButtons change. A solution here, is again a new command similar to Colorset. When a FvwmButton change the background of a swallowed window with X-id ID (and if the swallowed app is an Fvwm module, see the next paragraph) it can send the command "BackgroundChange". Then fvwm2 will send the string "ROOT_BG_CHANGE_STRING ID" to modules and the module with X-id ID may be able to update its background if it is transparent (fvwm2 already send "ROOT_BG_CHANGE_STRING" when fvwm2 detects that the root background change). BTW, it will be maybe better to send a MX_ROOT_BG_CHANGE message as we have now some places? Also it will be useful for FvwmButtons to know if the swallowed window is a FVWM Module or a normal X application. The only solution I see is to claim in the FvwmButtons man page that if the swallow command begin with Fvwm or Module then FvwmButtons will consider that it will swallow a Fvwm module. So if a complex function is used to launch a swallowed app the name of this complex function have some importance. Is this acceptable? Maybe, in the place of "BackgroundChange" we may use a command as "SwallowedConfigure id [bg_ch ...other options in the future]", which will force fvwm to send a MX_SWALLOWED_CONFIGURE message. Olivier -- Visit the official FVWM web page at 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]
