Re: Removing gnome support from FvwmGtk
seventh guardian a écrit : On 7/12/06, Thomas Adam [EMAIL PROTECTED] wrote: On Wed, Jul 12, 2006 at 11:24:57PM +0100, seventh guardian wrote: Hello. Having looked at FvwmGtk code, I realise there's no need for gnome support, as no gnome specific functions are used. So, there's no advantage of calling gnome_init vs gtk_init. And from what I see, the gnome support has been several times mis-used by precompiled distros (forcing the instalation of gnome libs when they are not required at all). So, I ask if we can remove the gnome support from FvwmGtk. I've been saying this for years -- yet no one would listen. I am in favour of it. Humm.. After a bit more dig up, it seems that gnome support is not just that.. It's also the gnome wm hints support.. it may be important, as this allows fvwm to integrate with gnome desktop (pagers and stuff). yes, but only for gnome 1, so ... But in what refers to FvwmGtk, it works exactly the same without gnome support. The final question is, is it worth remove gnome support from FvwmGtk if the rest of fvwm still needs it... Not exactly (bug report system, if I remember some discussions on this list). This known as, I am in favor of removing gnome support in FvwmGtk. Olivier
Re: Grabbing and complex functions
Scott Smedley a écrit : Hi Dominik et al, This post follows on from the previous ModuleListenOnly command which was getting a bit off-topic. As a hack/compromise, maybe we could modify AddToFunc to keep track of whether or not it uses a mouse modifier only then grab the X server, in execute_complex_function(). We discussed this a couple of years ago, and Olivier(?) suggested to allow functions without grabbing. The problem is that it is generally unpredictable which functions need to grab and which do not, and you can't do it on the fly because its too late then. I see. Well, there is at least 3 cases and not only 2 (grab / nograb). - Try to grab hard (for a long period of time) and give up if the grab fail. Current fvwm behavior, one problem (beside non execution) is that fvwm can be locked for a non negligible period of time. - Executing the function without trying to grab at all. You suggest to add such possibility. - Try to grab just 2 times (this is really fast). If the grab succeed everything is ok. If it fails execute the function any way. This is maybe a bit stronger/better than the previous case. My fvwm do that for any totally immediate function. This is not a perfect solution (but never cause me problems). But at the time we get our first discussion on this topic there was no consensus about how this should be expressed in term of fvwm configuration (or not at all). Of course you may want to have a 4th possibility: grab fast and do not execute if it fails. Olivier
Re: Removing EWMH support?
Etan Reisner a écrit : Before I comment specifically, I'll introduce myself. I am (at least one) of the other gaim folk Ethan referred to. I also understand the problems with the EWMH for window managers that don't exactly fit into the standard paradigm, I'm an ion3 user. I am also quite interested in getting this (and other similar issues) worked out appropriately. So with all that in mind, read on. Sorry to answer only now. On Fri, 24 Mar 2006, Olivier Chapuis wrote: Ethan Blanton a écrit : Olivier Chapuis spake unto us the following wisdom: Now a note on _NET_CURRENT_DESKTOP (and _NET_DESKTOP_VIEW PORT), the EWMH spec says that this property (as a client msg) is for a pager. Thus if gtk_window_present() uses this property (and one may understand that it uses it in the *view of the doc*), you may understand that you go beyond what an application is espected to do at startup: is gaim a Pager? After some discussion with the Gaim folk who grok Gtk+, we have some questions ... are you actually _seeing_ _NET_CURRENT_DESKTOP or _NET_DESKTOP_VIEWPORT? I do not know I do not use gaim (I use psi). But I read the discussion on the forum and Dominik conclude that such msg was send by gaim. Moreover, my gtk_window_present() doc says: Presents a window to the user. This may mean raising the window in the stacking order, deiconifying it, moving it to the current desktop, and/or giving it the keyboard focus, possibly dependent on the user's platform, window manager, and preferences. So the doc says that gtk_window_present() may send a _NET_CURRENT_DESKTOP client msg. Maybe this depends on the version of gtk ... Not exactly, the documentation says that calling that function might cause the window to move to the current desktop. It doesn't say that it might switch the current desktop to the one the window is on. And as _NET_CURRENT_DESKTOP is the property indicating the current desktop I wouldn't assume sending that is what gtk_window_present does at all. Furthermore, I have looked at the gtk code for gtk_window_present and, at least in the cvs checkout I am looking at, all it does is call gdk_window_show and gdk_window_focus. gdk_window_show does a bunch of things, but the only part of note (as fas as I can tell) is call XMapWindow. gdk_window_focus checks that the wm lists support for _NET_ACTIVE_WINDOW and then it sends a _NET_ACTIVE_WINDOW message using XSendEvent. So everything is ok :o) So if someone is seeing gtk do something else I would very much like to know what and which gtk version they are using. Maybe some old version of gtk do something stronger than a _NET_ACTIVE_WINDOW. It was my impression when I read some mails and forum. As best we can tell, gtk_window_present() calls gtk_window_show() when the window is not visible, and gtk_window_focus() when it is. We suspect that the gtk_window_focus is the problem, as it raises _NET_ACTIVE_WINDOW. Is it possible that fvwm is actually seeing _NET_ACTIVE_WINDOW, this causes it to switch desktops/pages? If so, is this an inappropriate client message (I don't believe it is.) It is clearly causing a behavior that at least some users are not pleased with. I think that Dominik ask the user with the gaim problem to disable _NET_ACTIVE_WINDOW msg for fvwm and the switching was still there. Dominik? I am also quite interested in the response to this. I do not think that _NET_ACTIVE_WINDOW is an inappropriate msg if the source indication is set to 2 (indicating a normal application msg). gtk does that with gtk_window_show() I think. I will add: a normal application can set the source indication to 1 (taskbar/pager) or send a _NET_CURRENT_DESKTOP msg if and only if this depends on a direct user action or if this is a (non default) option of the app (e.g., maybe some user like to have focus problems and want that an IM msg force the focus to the discussion window :o). The source indication for a pager is 2, for application is 1. Which gtk does correctly for gdk_window_focus (which as I explained is what gtk_window_present calls). gdk_window_focus doesn't set data.l[2] (since that would require more information than they have), nor do I really know how much help that would be here (or even in general). I do not think that an application that is not a pager should ever set source indication to 2, if any does I would claim that application is broken. I also think that (ab)using _NET_ACTIVE_WINDOW is a problem. Using it to present any existing (and even some new) windows is not the problem, the problem is when this is unavoidable and is used for no reason. I will say that this is out off topic ... any way I start the discussion on this. My logic is that the user may be able to decide what behavior he wants. Users are stronger than specification. So if a widely used wm (e.g., metacity) decides to never show a window after a _NET_ACTIVE_WINDOW send by an application (e.g
Re: Removing EWMH support?
Ethan Blanton a écrit : Olivier Chapuis spake unto us the following wisdom: Now a note on _NET_CURRENT_DESKTOP (and _NET_DESKTOP_VIEW PORT), the EWMH spec says that this property (as a client msg) is for a pager. Thus if gtk_window_present() uses this property (and one may understand that it uses it in the *view of the doc*), you may understand that you go beyond what an application is espected to do at startup: is gaim a Pager? After some discussion with the Gaim folk who grok Gtk+, we have some questions ... are you actually _seeing_ _NET_CURRENT_DESKTOP or _NET_DESKTOP_VIEWPORT? I do not know I do not use gaim (I use psi). But I read the discussion on the forum and Dominik conclude that such msg was send by gaim. Moreover, my gtk_window_present() doc says: Presents a window to the user. This may mean raising the window in the stacking order, deiconifying it, moving it to the current desktop, and/or giving it the keyboard focus, possibly dependent on the user's platform, window manager, and preferences. So the doc says that gtk_window_present() may send a _NET_CURRENT_DESKTOP client msg. Maybe this depends on the version of gtk ... As best we can tell, gtk_window_present() calls gtk_window_show() when the window is not visible, and gtk_window_focus() when it is. We suspect that the gtk_window_focus is the problem, as it raises _NET_ACTIVE_WINDOW. Is it possible that fvwm is actually seeing _NET_ACTIVE_WINDOW, this causes it to switch desktops/pages? If so, is this an inappropriate client message (I don't believe it is.) It is clearly causing a behavior that at least some users are not pleased with. I think that Dominik ask the user with the gaim problem to disable _NET_ACTIVE_WINDOW msg for fvwm and the switching was still there. Dominik? I do not think that _NET_ACTIVE_WINDOW is an inappropriate msg if the source indication is set to 2 (indicating a normal application msg). gtk does that with gtk_window_show() I think. I will add: a normal application can set the source indication to 1 (taskbar/pager) or send a _NET_CURRENT_DESKTOP msg if and only if this depends on a direct user action or if this is a (non default) option of the app (e.g., maybe some user like to have focus problems and want that an IM msg force the focus to the discussion window :o). Olivier
Re: Removing EWMH support?
Dominik Vogt a écrit : On Sun, Mar 12, 2006 at 11:41:54PM +0100, Dominik Vogt wrote: A current discussion with the gaim developers about some gaim mis-feature has made me think about abandoning EWMH support completely. In my eyes, the only usefull message it has is the FULLSCREEN stuff. Everything else is just causing trouble. Reasoning: * Most of the EWMH features are intended to mix applications written for the different desktop environments (DE), e.g. a KDE pager with a GNOME taskbar. * If fvwm is not running under a DE, these features are utterly useless. * If running under a DE, using the DE's pager, taskbar, etc. is not necessary as fvwm has a rich set of these modules. * An increasing number of applications mis-uses the EWMH hints to do funny things. * Most users have *no* chance to control such appications. For example, the problem with SkipMapping and gaim that led to the discussion on the gaim list. It took the user several days to figure out the problem and had to ask the fvwm developers for help. All this leads me to the conclusion that the EWMH spec (at least the client message part) offers very little benefits but causes a huge amount of trouble. It is simply not worth the effort. I vote for abandoning EWMH support (at least the client messages). Opinions? There have been so many interesting responses that I can't reply to them individually. To summarize what I understood: * Some people want EWMH support for third party pagers, taskbars, panels, etc. * Fullscreen is a useful feature. * Nobody(?) cares about *client messages* (other than fullscreen) that are not sent by pagers, etc. * EMWH *hints* are generally considered useful. So, I suggest the following defaults: * Hints are fully supported. * Fullscreen messages are honoured for all windows by default. * Client messages with source indication class 2 (pagers, ...) are honoured by default. * Client messages with source indication class 1 (other apps) are disabled by default. * Client messages with source indication class 0 (not set) are disabled by default. * Client messages without source indication are honoured by default. Unfortunately, if an application uses them, there is no way to disable them selectively. Yes, this seems reasonable. Regarding _NET_ACTIVATE_WINDOW we may have 3 functions: EWMHActivateWindowFunc # the one we have, for class 2 EWMHActivateClientWindowFunc # class 1 EWMHActivateLegacyWindowFunc # class 0 in addtion with some styles which enable/disbale the _NET_ACTIVATE_WINDOW client msg (I've these functions here but not the styles). Rational: what I've recently prototyped is an implementation of a demands attention state (which, in particular, implement the _NET_WM_STATE_DEMANDS_ATTENTION EWMH STATE). This state can be set by a fvwm command DemandsAttention and is set in the window flags structure. It is unset automatically when the window is activated. For now I've: AddToFunc EWMHActivateClientWindowFunc + I DemandsAttention On AddToFunc UrgencyFunc + I DemandsAttention On and I've added some colorsets/button state in FvwmIconMan for buttons which represent a window with the demands attention state (Moreover, such buttons are always shown in IconMan). This way if an application want to be activated (using _NET_ACTIVATE_WINDOW or the Urgency hint) the window is not activate but a red button appear in my IconMan. Also, the DemandsAttention state is set when a _NET_WM_STATE_DEMANDS_ATTENTION EWMH STATE client msg is received and when a window is mapped not visible (useful for my IM windows which are on page 1 1 with the SkipMapping style). All this is not very original (some wm and taskbars have already all this), but I think this is useful for preventing focus grabing which is really a big problem. Now the next step is to detect when an application use XSetInputFocus, and then reject the Focus and set the demands attention state (this is surley not so easy but I think we can do something in the most important cases). Olivier
Re: Removing EWMH support?
Dominik Vogt a écrit : A current discussion with the gaim developers about some gaim mis-feature has made me think about abandoning EWMH support completely. In my eyes, the only usefull message it has is the FULLSCREEN stuff. Everything else is just causing trouble. Reasoning: * Most of the EWMH features are intended to mix applications written for the different desktop environments (DE), e.g. a KDE pager with a GNOME taskbar. Some users use fvwm with kicker, gnome-panel, kdesktop or nautilus. * If fvwm is not running under a DE, these features are utterly useless. Not all: strut, icons and mini-icons, fullscreen, resizing by the bottom-right of the client, automatic stacking (yes some users like this). It will be good to implement the Killing Hung Processes process and maybe the _NET_WM_STATE_DEMANDS_ATTENTION _NET_WM_STATE. * If running under a DE, using the DE's pager, taskbar, etc. is not necessary as fvwm has a rich set of these modules. FvwmButtons is not GUI configurable, has poor systray support and in general distributions does not ship fvwm with their Distribution Menu. Kicker and gnome-panel have all these. Also, FVWM as no desktop application (some users like such app ... I do not know why :o) Also, I use it to monitor user window management activity (for my work). * An increasing number of applications mis-uses the EWMH hints to do funny things. Yes. But some application use it properly and if you remove EWMH support you will have some complaints. * Most users have *no* chance to control such appications. For example, the problem with SkipMapping and gaim that led to the discussion on the gaim list. It took the user several days to figure out the problem and had to ask the fvwm developers for help. All this leads me to the conclusion that the EWMH spec (at least the client message part) offers very little benefits but causes a huge amount of trouble. It is simply not worth the effort. I suggest to make the EWMH support more configurable (if needed). You can already almost totally disable EWMH support by fvwm config. One point is that there is now source indication for client msg. Maybe we can fix the gaim problem with this. Also, we do not implement the _NET_WM_STATE_DEMANDS_ATTENTION _NET_WM_STATE. Some gaim like problem may be fixed by a proper implementation of this state I think (gaim may ask for _NET_WM_STATE_DEMANDS_ATTENTION and we can add a colorset to FvwmIconMan for this state. Maybe if gtk++ see that _NET_WM_STATE_DEMANDS_ATTENTION is not implemented it does funny thing like switching to the current page and desktop) I may work on these. I vote for abandoning EWMH support (at least the client messages). Opinions? I vote against. Some applications miss-use the ICCCM spec, do you want to remove ICCCM support in fvwm? Olivier
Re: EWMH Window Types
On Thu, Nov 10, 2005 at 11:21:47PM +0100, Viktor Griph wrote: The way fvwm handles the _NET_WM_WINDOW_TYPE hint is very non-configurable currently. You can't even set other style options on the windows yourself. Yes. Moreover, in the case of the TOOLBAR type the interpretation follows the interpretation given by some old version of KDE (e.g., kpager had this type in version 3.0, it will be interesting to know if this is still the case with more recent versions). I did this because at the time I implemented the EWMH spec KDE was the only place where the TOOLBAR type was used. Now, others use this type and I think we should follow the spec and not the old(?) KDE interpretation. There are several ways to improve this. In short term a style EWMHIgnoreWindowType would allow for users to set their own style on windows having a specific windowtype without being foced to also have the default options of that window type. While this is an easy-to-make solution, I think there is room for more improvment. It would be good with configurable styles on a window type level, also for the window types currently ignored by fvwm. A command EWMHWindowTypeStyle could be added, and when the Style command is changed according to the 3.0 todo Type could be made a option to match on. I already got an implementation of the EWMHIgnoreWindowType which is ready for commit if agreed that such a style woud be useful (there might be other better solutions to the problem). I'd like to take a look at the implementation of an EWMHWindowTypeStyle command once I get a little more spare time. I've no objection. It will be also interesting to have the types as conditions for the conditionnal commands. Olivier
Re: MenuStyle
On Thu, Oct 20, 2005 at 11:06:36AM +0200, Dominik Vogt wrote: On Thu, Oct 20, 2005 at 07:42:36AM +0200, Viktor Griph wrote: Hi I am looking into the MenuStyle code trying to understand how some things are done. I plan to enable negation of all on/off menu styles by prefixing ! to them. However looking at the code raise some questions: First of all what exactly does FreeColors free up? In certain modes, X colours are managed in so called colour cells. There may be a limited number of available cells. They are reserved with XAllocColor and freed with XFreeColor. Because colours are used in many places inside fvwm (colour sets!), fvwm keeps a reference counter for the allocated colours. The corresponding code may be a bit difficult to understand (libs/PictureUtils.c). FreeColors eventually decreases the reference counters and frees the cells if the reference count drops to 0. Actually the process is more complicated. I think Olivier has written most of the code. Yes, the code is complex. It allows, in particular, to save in a fast way the allocated pixels for an image or a gradient with minimal memory usage. Before that, colours leak was systematic with gradients and images. Any way, colours management (sharing) at depth 8 is a mess in the X world, I discourage any one to try to understand the problems :o) Note that we do not receive complaint anymore on colours at depth 8 on fvwm-users. Maybe, no body have to use anymore these applications which need depth 8 to work properly. Olivier
IconAndSelect buttons in IconMan
Hello, If there is no objection I will add to IconMan an IconAndSelectButton option and an IconAndSelectColorset option. These options will respect backward compatibility: the buttons which represent an iconified and selected window will respect the SelectButton and SelectColorset options if the new options are not used. Regards, 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]
Re: FVWM: FvwmButtons and fullscreenmodes in recent fvwm broken?
On Fri, Jan 14, 2005 at 06:02:08PM +0100, Trilobit wrote: Hi, I recently updated my Debian Linux Box. And so I got version 2.5.12 of fvwm installed. After starting X11 with the new fvwm and my old working configuration for 2.5.x FvwmButtons hangs using 99percent of CPU time. And, after moving a window (in not opaque style), seems to freeze fvwm for some seconds. And so, giving after the freeze following error message (the only on in the whole .xsession-errors file): FVWM][FlushMessageQueue]: ERROR Failed to write descriptor to 'FvwmButtons': - select rc=0 - terminate signal=N --- So I installed, just for testing, version 2.5.8 from www.fvwm.org, the problem had gone. Here I switch to the workers list (fvwm-workers@fvwm.org). Can you post your FvwmButtons config (with the related functions/styles ...etc config). Regards, 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]
FlushMessageQueue
Hello,
It is easy to write some fvwm code to reproduce a
[FVWM][FlushMessageQueue]: ERROR Failed to write descriptor
error.
Just do so that:
- fvwm grab the server
- fvwm FlushMessageQueue
- a module is locked at some place (server is grabbed)
-- The error
So, fine, we should not FlushMessageQueue when we grab the server
(e.g., in a non opaque move).
Unfortunately, it seems that we can have a FlushMessageQueue errors
with a fastly reapeted sequence:
- fvwm grab the server
- fvwm do somting
- fvwm ungrab the server
- fvwm FlushMessageQueue
I will be interested by any comments on the following (non conservative)
solution:
In FlushMessageQueue (module_interface.c), do not select with
moduleTimeout but with a very short timeout, if select fail
do not kill the module, just return (the msg queue will be flushed later!).
Patch attached. Maybe this should be allowed only in certain
condition. Also, the module may be killed if FlushMessageQueue
*always* fail for a long time.
Regards, Olivier
--- module_interface.c.orig 2005-01-16 07:09:38.0 +0100
+++ module_interface.c 2005-01-16 07:10:34.0 +0100
@@ -1651,7 +1651,6 @@
void FlushMessageQueue(int module)
{
- extern int moduleTimeout;
mqueue_object_type *obj;
char *dptr;
int a;
@@ -1689,8 +1688,8 @@
{
/* Wait until the pipe accepts further
* input */
- timeout.tv_sec = moduleTimeout;
- timeout.tv_usec = 0;
+ timeout.tv_sec = 0;
+ timeout.tv_usec = 10;
FD_ZERO(writeSet);
FD_SET(channel, writeSet);
rc = fvwmSelect(
@@ -1707,6 +1706,7 @@
}
if (!FD_ISSET(channel, writeSet))
{
+#if 0
char *name;
name = get_pipe_name(module);
@@ -1721,6 +1721,7 @@
name, rc, isTerminated ?
'Y' : 'N');
KillModule(module);
+#endif
return;
}
Re: Notification: incoming/1550
On Fri, Jan 07, 2005 at 11:10:41AM -0600, [EMAIL PROTECTED] wrote: FVWM Bug Tracking notification new message incoming/1550 Message summary for PR#1550 From: [EMAIL PROTECTED] Subject: Working Area breaks with GNOME Xinerama Date: Fri, 7 Jan 2005 11:10:09 -0600 0 replies 0 followups ORIGINAL MESSAGE FOLLOWS From [EMAIL PROTECTED] Fri Jan 07 11:10:20 2005 SNIP I use FVWM as the GNOME window manager. Crazy, I know, but it works great. This is not so crazy, we have work a lot so that can be possible. When I switched to Xinerama (actually NVIDIA TwinView, but it looks like Xinerama to X clients) the GNOME panel started getting covered by new windows. I believe this is because the Working Area is not being adjusted properly according to the _NET_WM_STRUT hints. SNIP $ xprop | grep STRUT # top panel _KDE_NET_WM_FRAME_STRUT(CARDINAL) = 0, 0, 0, 0 _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 34, 0, 0, 0, 0, 0, 1280, 2559, 0, 0 _NET_WM_STRUT(CARDINAL) = 0, 0, 34, 0 SNIP Again, things worked fine with only one screen. If I use EwmhBaseStruts 0 0 34 34 behavior is as before but because the panels only span one screen, I lose 68 pixels of useful mapping space on the left screen. Yes, fvwm does not support _NET_WM_STRUT_PARTIAL. So your report is a valid bug (or a miss feature). I do not know when we will have the time to fix it. Thanks, 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]
Re: Patch: FvwmScript - add ReliefDepth parameter to H/VDipSticks
On Fri, Dec 24, 2004 at 07:42:18PM -0500, Lev Babiev wrote: Hello all, I recently started using FvwmScript as part of my setup. One of the functions performed by the script is displaying CPU load, memory usage and swap utilization. The output is displayed using small VDipSticks on my panel. Since these VDipSticks are rather small (11x56), having them sunk and raised by 2 pixels results in a rather cluttered look (8 of 11 pixels by width are taken up by relief). Can you post your Script? I created a patch to address this issue. The patch adds a new option for VDipSticks and HDipSticks called ReliefDepth. This option allows setting a number of pixels to raise/sink the dipstick by. The default value is 2, so omitting the option would result in normal behavior and existing scripts would not be affected. This option it interesting. I will just call it ReliefThickness (to be consistent with, for example, FvwmIconMan). What about extending this patch to all the widgets? And supporting the ReliefThickness option at the head of the script for setting the default? The patch is fairly large due to the changes in files generated by lex/yacc, the actual changes are fairly small. The patch file is located here: http://crion.no-ip.org/fvwmscript-nrdip2.patch If there is no objection I will apply the patch. If you do an other one you do not need to put the files generated by lex/yacc in it (I can generate it). Regards, 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]
Re: EWMH and Maximize growonwindowlayer patch
On Tue, Dec 14, 2004 at 01:19:27AM +0100, Arnaud Vrac wrote: In my config i have: EwmhBaseStruts 0 0 20 0 Style * EWMHUseStrutHints, EWMHPlacementUseWorkingArea Mouse 1 4 A Maximize growonwindowlayer grow grow However when i maximize a window the EWMH area is covered. That should only happen if ewmhiwa is set on Maximize. Correct me if this is not true, anyway i attached a patch that applies against cvs. Applied, Thanks 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]
Re: CVS olicha: * Added a set of functions for implementing tool tips
On Wed, Dec 08, 2004 at 10:26:27PM -0500, Dan Espen wrote: Olivier Chapuis [EMAIL PROTECTED] writes: On Sun, Dec 05, 2004 at 07:44:40PM -0500, Dan Espen wrote: FVWM CVS fvwm-workers@fvwm.org writes: For FvwmIconMan, I adjusted the first paragraph, but got stuck on the second: ManWidth is the width of the full FvwmIconMan. For example if the width of the FvwmIconMan manager is 1024, MaxButtonWidthByColumns 4 is equivalent to MaxButtonWidth 256. This is useful when you do not know, at config time, the width of the manager (e.g., for swallowed IconMan). In a certain sense you will never have less than 4 columns. So maybe, MinColumns is good. I used MaxButtonWidthByColumns to say that the MaxButtonWidth is expressed in terms of columns (or computed from a number of columns. I like the idea to use something like MaxButtonWidth_something_good to express the fact that this option is just an other way to set the MaxButtonWidth option. I think I have it now. Please check and see. Yep, Thanks. In another part of the same man page, I don't follow part of the TipsJustification description. The part between the lang_check markers (which I did modify a little): .IP *FvwmIconMan: [id] TipsJustification \fIvalue\fP where \fIvalue\fP can be leftup, rightdown or center. Specifies the justification (direction) of the tips window relative to its button after the tips window has been placed. \.#needs_lang_check Default is leftup which means that if a tip is placed above or below (respectively, on the left or on the right of) its button, then the left (respectively, the top) border of the tip and of the button are aligned. \.#end_needs_lang_check The alignment is adjusted by the TipsOffset option. See next option. The way you use respectively is very hard to read in english. Just describe leftup then start a new sentence and say rightdown and center work like leftup but in different directions. I tried to read it ignoring the repectively stuff and still couldn't follow it. If you just expand on it or give an example like you did above that would help. I Followed your suggestion. Can you check? Thanks, 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]
Re: CVS olicha: * Added a set of functions for implementing tool tips
On Sun, Dec 05, 2004 at 07:44:40PM -0500, Dan Espen wrote: FVWM CVS fvwm-workers@fvwm.org writes: CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: olicha 04/12/03 02:47:49 Modified files: . : ChangeLog NEWS libs : Makefile.am defaults.h modules: ChangeLog modules/FvwmIconMan: FvwmIconMan.1.in FvwmIconMan.c FvwmIconMan.h fvwm.c globals.c readconfig.c x.c xmanager.c xmanager.h Added files: libs : FTips.c FTips.h Log message: * Added a set of functions for implementing tool tips * Implemented tips in IconMan * New options IconMan MaxButtonWidth and MaxButtonWidthByColumns * Fixed bug #1480 by updating EWMHUseStackingOrderHints documentation * One needs_lang_check in fvwm.1.in and one in FvwmIconMan.1.in fvwm.1.in is not checked in. Did you really change it? Yes, but I probably forget to save the file before the commit I will commit again soon. For FvwmIconMan, I adjusted the first paragraph, but got stuck on the second: .IP *FvwmIconMan: [id] MaxButtonWidth \fIwidth\fP Defines a maximum for the width of a button (in pixels). By default there is no maximum. A value of 0 resets the default. The maximum is only used with a non growing manager (the ManagerGeometry option specifies non zero width and height). .IP *FvwmIconMan: [id] MaxButtonWidthByColumns \fIcol\fP This is equivalent to MaxButtonWidth ManWidth/col where ManWidth is the width of the Manager. What is ManWidth? Should this be MaxWidthInColumns, or just MaxColumns? ManWidth is the width of the full FvwmIconMan. For example if the width of the FvwmIconMan manager is 1024, MaxButtonWidthByColumns 4 is equivalent to MaxButtonWidth 256. This is useful when you do not know, at config time, the width of the manager (e.g., for swallowed IconMan). In a certain sense you will never have less than 4 columns. So maybe, MinColumns is good. I used MaxButtonWidthByColumns to say that the MaxButtonWidth is expressed in terms of columns (or computed from a number of columns. I like the idea to use something like MaxButtonWidth_something_good to express the fact that this option is just an other way to set the MaxButtonWidth option. I will follow any suggestion. Thanks Dan, 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]
Re: fvwm: Fullscreen should not require EWMHUseStackingOrderHints style
On Wed, Oct 27, 2004 at 11:06:27AM +0200, Per von Zweigbergk wrote: On Tue, 26 Oct 2004, Olivier Chapuis wrote: On Tue, Oct 26, 2004 at 01:26:38PM -0500, Manoj Srivastava wrote: If the EWMHUseStackingOrderHints style is off, fullscren works, but pager is not hidden. But, EWMH always-on-top modes such as the one found in tvtime still works. Maybe tvtime use the old GNOME hints? What happen if you use Style * IgnoreGnomeHints ? No. According to Billy Biggs (main developer of tvtime), he says that he's pretty sure that he uses EWMH hints only for this case. I haven't looked closely at the source code himself, though, but I could unless you know another way to check what tvtime uses. I've just tried tvtime version 0.9.12. I can confirm that it uses the EWMH fullscreen hint and no GNOME hints. However, If I've a stay on top window (EWMHUseStackingOrderHints not enabled) this window is *not* covered by tvtime. What version of tvtime do you use? I take fast look at the 0.9.13 source code. What *may* happen is that after tvtime is mapped it ask to be above with the _NET_WM_STATE_ABOVE hints (if a window want to be above it should set this state before mapping). So, FVWM interprets this has a user query (e.g., the user has used the kicker taskbar menu on the tvtime icon) and not as a program query and respect the user query (ignoring !EWMHUseStackingOrderHints). If tvtime do effectively this, in my opinion, it tries to override the wm stacking policy and this is not regular (and I will be not happy with such application). There is a plan to extend the EWMH spec so that the wm can know who send a _NET_WM_STATE_FOO query (so if the app developers do not cheat we will be able to handle the situation below). 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]
Re: fvwm: Fullscreen should not require EWMHUseStackingOrderHints style
On Tue, Oct 26, 2004 at 01:26:38PM -0500, Manoj Srivastava wrote: Hi, [Please retain the CC to [EMAIL PROTECTED] so that the Debian BTS has a record of your input] This was reported by a Debian user. Fvwm2 seems to have some trouble with the EWMH fullscreen mode. My configuration includes a stay-on-top FvwmPager. When putting EWMH compliant applications, such as tvtime, the pager is not obscured by the fullscreen window, so I get a TV window with a pager floating on top, which is less than desirable. The bug can also be reproduced with the fullscreen modes in Mozilla Firefox and OpenOffice.org, but I have not tested using this extensively as I have with tvtime. The bug can be worked around by setting: Style * EWMHUseStackingOrderHints in the .fvwm2rc file. So, everything is fine. No? You use a stay on top pager (i.e., you use stacking), so you should use this style. I've no time to explain why, but I do like stay on top windows at all. Maybe, this EWMHUseStackingOrderHints should be on by default. I do not know (and I do not care). After investigating the problem, my analysis of the problem is that it seems (according to the excellent fvwm manual page) that the EWMHUseStackingOrderHints was intended to disable/enable some KDE-specific extentions. For me the bug is in the man page. Unfortunately, the slightly misleading option name lead a programmer to misinterpret the meaning of the flag when programming the fullscreen code, and made that disable the stacking code in that when it was enabled. The fact that the option is not intended to disable *all* stacking hints is further supported by the fact that tvtime also has an (AFAIK) EWMH-compliant Always-on-top mode, which does manage to obscure the pager properly, even when EWMHUseStackingOrderHints unset. From http://www.freedesktop.org/standards/wm-spec/1.3/ar01s07.html#STACKINGORDER # Stacking order # # To obtain good interoperability between different Desktop Environments, # the following layered stacking order is recommended, from the bottom: # # * windows of type _NET_WM_TYPE_DESKTOP # * windows having state _NET_WM_STATE_BELOW # * windows not belonging in any other layer # * windows of type _NET_WM_TYPE_DOCK (unless they have state # _NET_WM_TYPE_BELOW) and windows having state _NET_WM_STATE_ABOVE # * focused windows having state _NET_WM_STATE_FULLSCREEN # # Windows that are transient for another window should be kept above this # window. # # The window manager may choose to put some windows in different stacking # positions, for example to allow the user to bring currently a active # window to the top and return it back when the window looses focus. FVWM try to follow the spec but surely do not follow this *recommendation* without an user intervention (or if EWMHUseStackingOrderHints was a default, without the possibility to break such a recommendation). For me, the only acceptable stacking rule is the one concerning _NET_WM_TYPE_DESKTOP. Let me summarize: If the EWMHUseStackingOrderHints style is on, fullscreen works. Pager is hidden as it should be. Fine. If the EWMHUseStackingOrderHints style is off, fullscren works, but pager is not hidden. But, EWMH always-on-top modes such as the one found in tvtime still works. Maybe tvtime use the old GNOME hints? What happen if you use Style * IgnoreGnomeHints ? According to the documentation, EWMHUseStackingOrderHints affects KDE-specific extentions. The extentions mentioned aren't KDE extentions, they are a part of the EWMH standard 1.3 from freedesktop.org. So either the documentation is wrong or the code is wrong. The documentation is wrong. The EWMHUseStackingOrderHints code and doc was written before _NET_WM_STATE_BELOW, _NET_WM_STATE_ABOVE and _NET_WM_STATE_FULLSCREEN was introduced in the ewmh spec. Even, I think that at some point in the spec elaboration it was decided that no stacking rules should appear in the spec (Dominik?), but one day someone decided that all wm should work like kwin and metacity ... The code follows the EWMHUseStackingOrderHints style but not the doc :o/ This happen even with FVWM! And still, you shouldn't have to activate a special option in order for FVWM to fully comply with the recommendation in the standard. Not agree (but I do not care if we can disable these stacking dictatorial rules via a style). So, I see two possibilities: - The option is intended to tell EWMH never to dictate stacking. Yes! In that case it's broken since tvtime's EWMH always-on-top stacking still works when that option is disabled, and the documentation is wrong. Maybe there is a bug somewhere. I've not tvtime here; but as I said maybe the old GNOME hints are used. Try to disable the GNOME hints and see if tvtime is still stay on top. - And what I think is more
Re: Some new FVWM features from metisse
On Fri, Sep 03, 2004 at 10:54:55AM +, Mikhael Goikhman wrote: On 03 Sep 2004 10:03:19 +0200, Dominik Vogt wrote: On Fri, Sep 03, 2004 at 07:20:59AM +0200, Olivier Chapuis wrote: * Support for _NET_SHOW_DESKTOP via a new command ShowDesktop bool: this command, if bool is on, iconify all window not in the window skip list. If bool is off the command uniconify all window iconified by a ShowDesktop On. This can be simulated by a fvwm function (by using State) modulo stacking order problems. FVWM GNOME/KDE users will be happy with the support of _NET_SHOW_DESKTOP. My vote: yes. _NET_SHOW_DESKTOP support: yes; implementation with icons: no. I am almost sure using icons for this purpose will make more trouble than it saves. Instead, all windows should just be unmapped like when they are on a different desk. The checks for the current desk are strewn all over the place, so this is no simple patch. I do not see which kind of problem we can have, but Animate like problem. Moreover, you can build a fvwm function which almost do the show desktop feature, so it seems to me that if we get problems by using icons for show desktop we will have to fix it any way. Yes, if FvwmAnimate is on, mass-iconify may be problematic. This is why I added pause, push and pop messages to FvwmAnimate some time ago. Indeed, I used these in the code. I can't say yet whether iconifying without iconified windows is good. No opinion too and I have not the time to implement the show desktop feature using an other method than simple iconification. * New option -transient-window to the FvwmPager which causes FvwmPager to be transient and to execute Silent Current MoveToPage x y or Silent Current MoveToDesk d or Silent Current MoveToDeskAndPage d x y in the place of the GotoPage, GotoDesk and GotoDeskAndPage usual cmd. Optionally the usual GotoPage, GotoDesk and GotoDeskAndPage are also executed. My vote: yes. What is that good for? I suggest to rename the option to -transient-move, or -transient -move, where -move is only relevant with -transient. FvwmPager -transient-move is supposed to be bound to a window operation menu, it nicely shows all pages and moves the window to the chosen page. Yes, very user friendly, contextual menu. Regards, 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]
Some new FVWM features from metisse
Hello, When working on metisse (http://insitu.lri.fr/~chapuis/metisse) and related projects I added a few new features to FVWM. Maybe some can go into the official 2.5.x tree as it does not seem that the tree is really feature freezed. Just vote! Here a full list of the difference between 2.5.x and the fvwm included in metisse 0.3.4 (not yet released). * New command SaveWindowPointerPosition: this command save the pointer position relatively to the current window. You can restore this position with a new option to the WarpToWindow cmd: UseSavedPosition. WarpToWindow UseSavedPosition 50 50 will either restore the pointer position if saved or put the pointer in the middle of the window. My vote: I do not care. * New command ShowCursor: draw a flashing circle around the cursor during a fraction of time. I use this with some new options to WarpToWindow: ShowCursor and ShowCursorOnSavedPosition. My vote: I do not care. Example of use of these two cmd and these options to WarpToWindow: DestroyFunc FuncFvwmSaveWindowPointerPosition AddToFunc FuncFvwmSaveWindowPointerPosition + I Silent All (HasPointer Focused) SaveWindowPointerPosition On + I TestRc (Match) Break 1 + I Silent All (HasPointer) SaveWindowPointerPosition On + I TestRc (Match) Break 1 + I Silent Current SaveWindowPointerPosition On DestroyFunc WindowListFunc AddToFunc WindowListFunc + I Iconify false + I FlipFocus + I Raise + I WarpToWindow UseSavedPosition ShowCursorOnSavedPosition 10p 10p DestroyFunc MyAltTabFunc AddToFunc MyAltTabFunc + I FuncFvwmSaveWindowPointerPosition + I WindowList Root c c NoDeskSort, SelectOnRelease Meta_L Key Tab A MMyAltTabFunc * Support for _NET_SHOW_DESKTOP via a new command ShowDesktop bool: this command, if bool is on, iconify all window not in the window skip list. If bool is off the command uniconify all window iconified by a ShowDesktop On. This can be simulated by a fvwm function (by using State) modulo stacking order problems. FVWM GNOME/KDE users will be happy with the support of _NET_SHOW_DESKTOP. My vote: yes. * A library FTips for implementing tips in modules. I used this library to add tips to IconMan with a lot of options (I've even write down the man page I can poste it). I used this library in the Pager and I plan to use it to implement (multiline) tips in FvwmButtons. My vote: yes (a step toward removing the FvwmTaskBar). * New option MaxButtonWidth to FvwmIconman. My vote: yes (an other step toward removing the FvwmTaskBar). * New option -transient-window to the FvwmPager which causes FvwmPager to be transient and to execute Silent Current MoveToPage x y or Silent Current MoveToDesk d or Silent Current MoveToDeskAndPage d x y in the place of the GotoPage, GotoDesk and GotoDeskAndPage usual cmd. Optionally the usual GotoPage, GotoDesk and GotoDeskAndPage are also executed. My vote: yes. * The execute totally immediate complex function even if we cannot grab the pointer patch. Should not be disputed here :o) * There are others stuffs which are not stable enough. Some new complex stacking/focus policy related to text selection and dnd (these use XRecord). TaskBar Launch buttons used all the rows. My vote: no. * Some metisse specific stuff. New module msg MX_STARTSTOP_OPERATION, MX_MODULE_INTERACTIVE_MOVE and MX_CLICK_MOTION mainly for non standard operation and interactive move in FvwmAmetista. New msg for syncing desk switching are incoming. A new BugOpts option MetisseWorkaround for small things. My vote: obviously no. 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]
Re: Some new FVWM features from metisse
On Fri, Sep 03, 2004 at 06:44:49AM +0100, Thomas Adam wrote: On Fri, Sep 03, 2004 at 07:20:59AM +0200, Olivier Chapuis wrote: * Support for _NET_SHOW_DESKTOP via a new command ShowDesktop bool: this command, if bool is on, iconify all window not in the window skip list. If bool is off the command uniconify all window iconified by a ShowDesktop On. This can be simulated by a fvwm function (by using State) modulo stacking order problems. FVWM GNOME/KDE users will be happy with the support of _NET_SHOW_DESKTOP. My vote: yes. Of course, this is easily scripted by a FvwmFunction, I can see nothing wrong in making it in-line Fvwm. An (odd) side-effect of this can also be achieved using the command 'vdesk', as well. I do not see how to make a ShowDesktop complex function which respects the stacking order. The All (condition) command loop over the windows following the normal list and not the stacking list. Maybe a stack option should be added to certain conditional commands. * A library FTips for implementing tips in modules. I used this library to add tips to IconMan with a lot of options (I've even write down the man page I can poste it). I used this library in the Pager and I plan to use it to implement (multiline) tips in FvwmButtons. My vote: yes (a step toward removing the FvwmTaskBar). * New option MaxButtonWidth to FvwmIconman. My vote: yes (an other step toward removing the FvwmTaskBar). I had no idea we were thinking of removing FvwmTaskBar -- indeed, I don't think it should be removed, it is used by quite a lot of people. FvwmtaskBar is not so easy to maintain and if one day we can exactly simulate the FvwmTaskBar with FvwmButtons + FvwmIconMan we may _discuss_ the removal of the FvwmTaskBar. Regards, 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]
A 3D X Desktop
Hello, Maybe some people can be interested by this experimental software: http://insitu.lri.fr/~chapuis/metisse It is a 3D X desktop based on Xvnc, XDarwin, FVWM and Ametista. There is a special version of FVWM included in it. Regards, 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]
Re: CVS write access for Scott?
On Thu, Jun 03, 2004 at 08:44:52AM -0400, Dan Espen wrote: Dominik Vogt [EMAIL PROTECTED] writes: I think we should give CVS write access to Scott. Anybody to second that opinion? Mikhael proposed this on 31-May so you've just seconded it. And I second it too ... now. 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]
Re: FvwmTaskBar FvwmButtons crash when managing remote display
On Sat, May 29, 2004 at 01:41:02AM +0200, BUCHMULLER Norbert wrote: Hi, I posted a bug report a week ago (incoming/1284). Since then I investigated the problem a bit more, and found it to be MIT-SHM related (and independent of any configuration file; does the same with a zero conffile, ie. fvwm -f /dev/null). I managed to hunt down the bug (at least I hope so:-), here's a patch. (I can't say that I fully understand the intent of that if statement in line 127. So there may be an other - cleaner - solution.) Without the if statement, if you compile without shm support you get a warnning. Note that there are no ifdef in the code, however the compilation is conditional. I've applied the patch, Thanks! Regards, 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]
Re: Pixmaps, icons, etc. don't work in remote fvwm
On Sat, May 01, 2004 at 12:15:15AM +0100, Piotr Zielinski wrote: Piotr When I use fvwm remotely, none of the image-based stuff (icons, Piotr pixmap, etc.) work. Olivier I've recently commited a fix to this problem. At present time Olivier I cannot test this fix. Can you try Olivier ftp://ftp.fvwm.org/pub/fvwm/devel/snapshots/fvwm-snap-20040430.tar.gz Thanks for a prompt reply. I've tried the cvs version of fvwm and everything works ok with the exception of a single image, which is still displayed as a random bitmap. This image (a small png file) is the first image mentioned in my .fvwm2rc; if I change the order then the new first image doesn't work. Moreover, if I type the same line TitleStyle AllActive TiledPixmap decor/title-active.png -- Flat again (in FvwmConsole), then everything works fine. Yes, I see. Fixed (I hope) in the current cvs. Regards, 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]
Re: Pixmaps, icons, etc. don't work in remote fvwm
Piotr Zielinski wrote: When I use fvwm remotely, none of the image-based stuff (icons, pixmap, etc.) work. I see a random image of the same size instead and fvwm reports the following error (many times) [FVWM][FvwmErrorHandler]: ERROR *** internal error *** [FVWM][FvwmErrorHandler]: ERROR Request 145, Error 168, EventType: 4 from time to time also [FVWM][FvwmErrorHandler]: ERROR Request 145, Error 168, EventType: 12 and [FVWM][FvwmErrorHandler]: ERROR Request 145, Error 10, EventType: 4 This problem appears even if fvwm is started without a configuration file fvwm -f /dev/null Finally, when fvwm works without any problems if used locally on either of the two machines. Hello, I've recently commited a fix to this problem. At present time I cannot test this fix. Can you try ftp://ftp.fvwm.org/pub/fvwm/devel/snapshots/fvwm-snap-20040430.tar.gz and report again by answering this mail? Thanks, 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]
Re: Fvwm shm and remote X sessions
On Tue, Apr 13, 2004 at 01:38:36AM +0530, Kingsly John wrote: When you try to run fvwm in a remote X session(ie., Xserver runs on one machine.. and fvwm on another.) it's trying to use shared memory and it causes a lots of issues with images.. 1) all my FvwmButtons which use images coredump(the ones which don't use images and just swallow other apps work fine) 2) My minimized app icons look like this .. http://kingsly.net/tmp/fvwm-shm-bug.png 3) There is also similiar corruption in the mini-icons used in windowlists etc. I rebuilt fvwm with the --disable-shm option... and everything works fine now. Would be nice if fvwm could detect if shared memory is usable before it tries to use it... mplayer seems to be able to do it. Hello Kingsly, I've committed a fix to the cvs. Can you try the next snapshot: ftp://ftp.fvwm.org/pub/fvwm/devel/snapshots/fvwm-snap-20040430.tar.gz which should pop up soon. Regards, 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]
Re: Fvwm shm and remote X sessions
On Tue, Apr 13, 2004 at 01:38:36AM +0530, Kingsly John wrote: When you try to run fvwm in a remote X session(ie., Xserver runs on one machine.. and fvwm on another.) it's trying to use shared memory and it causes a lots of issues with images.. Yes I known this problem, I will fix it soon. Thanks for the report, 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]
Re: EWMHIgnore... styles incomplete?
On Wed, Mar 31, 2004 at 10:55:18AM +0200, Dominik Vogt wrote: Olivier, it looks like the EWMHIgnore...Hints styles only handle the initial hints of a window. For example, with EWMHIgnoreStateHints, applications can not specify an initial layer, but can change their layer via a client message. Yes. The problem is that it is not possible to know if it is the application itself or an ewmh TaskBar/Pager which send the client msg. I.e., after the initial stage we cannot detemine if it is the application allone or the user (via an interaction with an ewmh TaskBar/Pager) which send the client msg. So, the EWMHIgnore...Hints styles only handle the initial hints of a window. Should this be included in these styles? So ... No. Alternatively we could add EWMHIgnore...Request to block client messages. Yes, we may. Regards, 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]
Re: Solaris 8 and Iconv
On Mon, Mar 08, 2004 at 08:29:27PM +0100, Marcus Lundblad wrote: On Mon, 8 Mar 2004, Dan Espen wrote: Marcus Lundblad [EMAIL PROTECTED] writes: Markus can you check that all the new (vs 2.5.7) text conversion stuff are not used too often? I removed some redundant calls. Actually for example when drawing underlines, the width (in pixels) of one character is computed. In this case, if the character consists of one byte (ISO-8859-x) I make the assumption that the width is equal to the raw character corresponding to that byte. This will work exept for ISO-8859-6 (8-bit Arabic) which we don't support anyway (this would need joining characters using UTF-8 internally). I also included a check in the drawing routine so that character positions is only computed when combining characters are actually present in the string (redundant otherwise). Could somebody try this out in Solaris 8? It's definitely faster. The menus come up blank and the text appears 1/4 second later. On larger menus, I can see the text appear in blocks. How about using UTF-8 locale on Solaris 8? Is that implementation smart enough to just return imediatly when converting UTF-8 to UTF-8 (like in glibc, the pointer is just return back, the code in Flocale.c checks this)? I do not think that the Solaris 8 libc supports an UTF-8 locale. I don't see much more to do (the combining code uses 16-bit charcters internally, so converting to UTF-8 and then to 16-bit is needed). One alternative as a last emergency could be to write special code as fallback for at least ISO-8859-x to/from UTF-8, but this seems close to reimplementing Iconv. Hum, for which charset we need to combine characters? Do we need to combine for iso8859 1 or 15 charset for example? If yes can you give a concrete example. With bidi conversion are performed only for UTF-8, ISIRI-3342, ISO8859-6, ISO8859-9, CP1255 or CP1256. I suggest we do something like that for combining. Actually I find it amazing that implementation can be so slow. On my system, PII 400 MHz, I don't notice any abnormal delay even using the version before my last fix (though I use UTF-8 locale, so maybe that's the reason). The problem is not the CPU. It seems that on Solaris 8 iconv is dramatically slow. Regards, 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]
Re: fvwm-2.4.18 and fvwm-2.5.10 have been released
On Fri, Mar 19, 2004 at 05:42:54PM +0100, Dominik Vogt wrote: Tarballs and announcements are in the usual place. It seems that the fvwm-2.4.18 release has not been announced (fvwm users list and freshmeat). Regards, 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]
Re: fvwm-2.4.18 and fvwm-2.5.10 have been released
On Tue, Mar 23, 2004 at 08:35:51AM -0600, Jason L Tibbitts III wrote: OC == Olivier Chapuis [EMAIL PROTECTED] writes: OC It seems that the fvwm-2.4.18 release has not been announced (fvwm OC users list and freshmeat). A message was sent to fvwm-announce on March 19 at 10:55AM CST. The message ID was [EMAIL PROTECTED]. The subject was fvwm 2.4.18. I received it back from the list. fvwm 2.5.10 was announced in the same manner at essentially the same time. Ooops Yes. An error in my mail filters. Sorry Jason, 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]
Solaris 8 and Iconv
Hello, So it seems that Solaris 8 + Iconv and 2.5.7 has no problem with text rendering performance (at least with an iso8859-1 locale). But 2.5.8 and better has some important problem (fixed by --disable-iconv). In a certain sense text rendering performance with Solaris 8 + Iconv is not surprising. Solaris 8 has a poor iconv implementation. E.g., sun ask to use gnu libiconv on Solaris 8 for GNOME2. About 2.5.7 vs 2.5.8 or better, I see two possibility, either there is a configure bug in 2.5.7 which disable iconv or some change in Flocale*.c force to use utf-8 conversion to often. The only thing I can remember is that when I wrote the locale support I take care to use utf-8 conversion only when this is really needed. Markus can you check that all the new (vs 2.5.7) text conversion stuff are not used too often? In any case even if we can found workarounds for an iso8859-1 locale + Solaris 8 we may still have some problem as any other software which uses iconv (e.g., any i18n soft which use the glib!). So it will be fine if we can detect during configuration that the libc implementation of iconv is ok and disable iconv if not (note that if gnu libiconv if found fvwm will use it and I do not think that we will have problem with it). Unfortunately, I do not see a simple generic way to test if a libc iconv implementation is ok. But, maybe we just have to check that the libc is the Solaris 8 libc (Is this possible?). Maybe other system either have a good libc iconv implementation or use gnu libiconv (This is the case of the BSD* I think). Regards, 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]
Re: fvwm-root failure
On Wed, Feb 25, 2004 at 02:16:15PM -0500, Chris Ross wrote: Olivier Chapuis wrote: On Fri, Feb 20, 2004 at 11:38:34AM -0500, Chris Ross wrote: [ limits on shm usage cause fvwm-root to fail ] I will fix this bug this week-end. Normaly, if shm fail fvwm-root use normal XImage, but it seems that there is miss-print somewhere (a cast problem I think). Thank you very much! Would much appriciate it. I've just commited a fix. Can you try it? Thanks, 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]
Re: fvwm-root failure
On Fri, Feb 20, 2004 at 11:38:34AM -0500, Chris Ross wrote: Hi. I'm running a solaris 8 system, with the installed openwin X server, and fvwm-root is failing with a shared memory error on my machine. I looked into it, and it's a error returned from shmget() somewhere in the X libraries. The X error being displayed is: X Error of failed request: BadAccess (attempt to access private resource denied) Major opcode of failed request: 131 (MIT-SHM) Minor opcode of failed request: 1 (X_ShmAttach) Serial number of failed request: 10 Current serial number in output stream: 11 Looking at the system calls, it appears that shmget() is returning EINVAL when it's being called to create a 5+ MB memory segment. In reading documentation, I see that the system default maximum size for shared memory is 1MB. I realize my fvwm-root is trying to ask for a little over 5MB, but, doing some math, even a 1024x768 screen at 16-bit pixmap-depth will produce an X Pixmap that is 1.5MB in size. Perhaps there should be another way to load this? Is this just a solaris bogosity? Can we interact with the MIT-SHM extension directly to check on things? I will fix this bug this week-end. Normaly, if shm fail fvwm-root use normal XImage, but it seems that there is miss-print somewhere (a cast problem I think). Regards, 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]
The Schedule cmd does not execute complex functions
Hello, Try this: AddToFunc foo I Echo OK Schedule 500 foo it seems that foo is not executed via the Schedule cmd. Regards, 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]
Re: Beep when opening menus
On Mon, Jan 19, 2004 at 10:00:16AM +0100, Dominik Vogt wrote: On Sat, Jan 17, 2004 at 12:36:43AM +0100, Olivier Chapuis wrote: On Fri, Jan 16, 2004 at 05:21:22PM +0100, Uwe Pross wrote: Hi there, On 16 Jan 2004 at 14:58:58 +0100, Olivier Chapuis wrote: Use fprintf(stderr,*** FVWM Bell: Abort function %s\n, action); I got: *** FVWM Bell: functions.c line 987 [MarkWindowAsActiveFunc] *** which comes from FvwmEvent. So I guess it is my fault :-\ I do not think that it is your fault :o) If you use my version of FVWM you never get these beeps (and the function will be executed). But, for some reasons dominik does not want that your setup work. Would you *please* stop spreading these rumours? I really don't understand why you have to provoke this argument again. I do not understand your position on the subject! Note that I am not alone. Simply re-read the last thread on the subject. And it's useless too, since if we keep haggling over features that won't be implemented in 2.6 anyway, we will never get it done, and new features will never be written. Instead of focusing on these discussions - which stop me from doing any fvwm work for one to two months every time - It seems the same happen to me ... how about doing some work towards the release together instead? How can I work on FVWM as I *cannot* use the current cvs? Your are the FVWM maintainer, one of the main developer (really I worked a lot on the 2.5.x series) strongly think that we should do something about a given subject. But you do not care and you reject any compromise. For me there is a problem here. Regards, 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]
Re: Beep when opening menus
On Fri, Jan 16, 2004 at 10:50:08AM +0100, Uwe Pross wrote:
Hi there,
A couple of weeks ago I reported an nerving beep when
opening FvwmWindowList or menus of some programs. In the
last days I used FrameMaker which shows this behaviour quite
often when a submenu is opened and closed. I added some
debug statement to 2.5.7 to see where the beep comes from.
It says that the beep comes from functions.c [987]:
/* we have to grab buttons before executing immediate actions because
* these actions can move the window away from the pointer so that a
* button release would go to the application below. */
if (!GrabEm(CRS_NONE, GRAB_NORMAL))
{
func-use_depth--;
fprintf(stderr,*** FVWM Bell: %s line %d ***\n, __FILE__,
__LINE__);
cf_cleanup(depth, arguments);
return;
}
Use
fprintf(stderr,*** FVWM Bell: Abort function %s\n, action);
in the place of
fprintf(stderr,*** FVWM Bell: %s line %d ***\n, __FILE__, __LINE__);
the you will know which function cause the beep (maybe a scheduled
function?).
Regards, 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]
Re: FVWM: Re: Mozilla/Firebird FullScreen issues
On Mon, Jan 05, 2004 at 12:24:38PM +0530, Kingsly John wrote: +++ Olivier Chapuis [2004-01-04 20:47:08]: Hello, First some clarifications. 2.5.8 support the ewmh way to go full screen (_NET_WM_STATE_FULLSCREEN) and 2.5.7 does not. I can reproduce the mozilla disappearing problem with 2.5.7, I cannot with 2.5.8. One point is that an application (here mozilla) can use different method to go full screen regardless the fact the wm support or not the _NET_WM_STATE_FULLSCREEN state. If you switch from 2.5.7 to 2.5.8 with a restart, mozilla can think that 2.5.8 does not support the _NET_WM_STATE_FULLSCREEN state. This is what I was doing until now... I now added fvwm2 to the last line of my .xinitrc and exited fvwm... and a new instance started up. Now Mozilla/Firebird disappear more frequently than before... and even when they do go full screen they still have the border and titlebar. Does someone else that is sure to run 2.5.8 and mozilla 1.4 or a recent Firebird can reproduce this? About layer. It will be good to have fullscreenLayer style, we have not. But you should try: Style * EWMHUseStackingOrderHints which puts (ewmh) full screen window at the default top layer. This helped fix the problems of gkrellm staying on top of other full screened applications. [ie., tvtime now runs on Layer 4 in windowed mode, and Layer 6 in full screen.] But is it really necessary to add that line because everything was working fine on 2.5.7 even without that extra line. Since this is expected behavior wouldn't it be better if it was turned on by default ?(ie., not having to turn it on in the config. It does not work fine with 2.5.7. For example, with gnome-terminal 2 and others gnome2 apps full screen does not work at all. Also, mozilla some time disappeared :o/ I do not know what is the expected behavior about layer of fullscreen window. I do not think that there is an expected behavior at all about layer of windows regarding theirs type. This depends on the apps and of your general setup. Here, everything is configured so that every windows has layer 4. For example, when I use mozilla in fullscreen mode I may want to take a look to my download manager or to gkrellm. As everything as layer 4 I just have to raise/lower. There is also an interesting complaint from a gimp developer and gimp fullscreen with some wm which use the expected behavior (moreover as it is the/a non configurable wm you cannot fix the problem). I am sure that you can configure fvwm to use layer and get a functional desktop. Typically, one want to have certain app as the TaskBar or gkrellm on top. This is fine for me. However, I do not use layers because I think that there is a more powerful method which is conditional auto-raise: DestroyModuleConfig FvwmEvent-AutoRaise: * *FvwmEvent-AutoRaise: PassId *FvwmEvent-AutoRaise: enter_window FuncFvwmEnterWindow *FvwmEvent-AutoRaise: leave_window FuncFvwmLeaveWindow DestroyFunc FuncFvwmEnterWindow AddToFunc FuncFvwmEnterWindow + I WindowId $0 (gkrellm) Raise + I WindowId $0 (FvwmTaskBar) Raise + I WindowId $0 (FvwmPager*) Raise # ...etc DestroyFunc FuncFvwmSpecialRaise AddToFunc FuncFvwmSpecialRaise + I All (gkrellm) Raise + I All (FvwmTaskBar) Raise + I All (FvwmPager*) Raise # ...etc # a key binding for FuncFvwmSpecialRaise DestroyFunc FuncFvwmLeaveWindow AddToFunc FuncFvwmLeaveWindow # one may want to auto lower certain app (or cancel scheduled # cmd) This is just the idea, one may use the schedule cmd to get a delay. When you have no layer you have your full desktop to work with normal applications. With conditional autoraise some special apps are easy to access/view. This is just the way *I* work with my computer. Again, one can prefer layers. The good point is that I hope fvwm can be configured to fit the needs of most users. Also, I think that using a non configurable wm has some advantage for some users. Regards, 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]
Re: Mozilla/Firebird FullScreen issues
Hello, First some clarifications. 2.5.8 support the ewmh way to go full screen (_NET_WM_STATE_FULLSCREEN) and 2.5.7 does not. I can reproduce the mozilla disappearing problem with 2.5.7, I cannot with 2.5.8. One point is that an application (here mozilla) can use different method to go full screen regardless the fact the wm support or not the _NET_WM_STATE_FULLSCREEN state. If you switch from 2.5.7 to 2.5.8 with a restart, mozilla can think that 2.5.8 does not support the _NET_WM_STATE_FULLSCREEN state. About layer. It will be good to have fullscreenLayer style, we have not. But you should try: Style * EWMHUseStackingOrderHints which puts (ewmh) full screen window at the default top layer. On Sun, Jan 04, 2004 at 09:05:42PM +0530, Kingsly John wrote: +++ Mikhael Goikhman [2004-01-04 13:34:36]: Try hitting F11 multiple times... I have been unable to go past 6-7 hits on Mozilla 1.4! Pressed F11 100 times in Mozilla 1.4, it does not disappear. Just a bad repositioning/jump to +0+0 on un-fullscreen. I notice that too (the titlebar gets placed outside the screen). Yes, when I test this my conclusion was that this is a mozilla bug (mozilla ask this, maybe there is a style workaround). This is what fullscreen looks like on my machine... http://kingsly.net/mozfull.png - 238KB For me this is 2.5.7? Then we use either different fvwm or mozilla versions. Do you see empty output or a line with _NET_WM_STATE_FULLSCREEN when you run the following in xterm: xprop | grep _NET_WM_STATE and select a full-screen mozilla? There is no output on both Mozilla and Firebird. Again, for me this is 2.5.7. (and I just noticed that gkrellm remains on top of Mozilla too! ref. other thread.) It seems that currently a window in FULLSCREEN state is simply raised, I think it may be placed into layer 10 too, or this may be configurable. This functionality has changed between 2.5.7 and 2.5.8 .. in 2.5.7 both mozilla and tvtime go fullscreen and on top... but in 2.5.8 gkrellm stays on top of both the apps. See the intro of this mail. Regards, 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]
Re: Colorset usability issues
On Sun, Oct 12, 2003 at 03:36:51PM +0300, Mikhael Goikhman wrote: I suggest these colorset usability things: 1) New colorset option Clear or NoEffects depending on what it does that removes all effects from a colorset, it may be aproximately equivalent to: Colorset N NoDither, \ # not sure about this one Tint, fgTint, bgTint, Alpha, fgAlpha, IconTint, IconAlpha, \ Plain, NoShape, fg, bg # not sure about these 4 This is intended to be used in dynamical configurations as in: Colorset N Clear, fg .., bg .., VGradient .. # set completely new colors I.e. it either resets all effects leaving only fg/bg/image/gradient or resets everything. Both are ok for me. Probably reseting everything is preferred. In this case Clear may work like CleanupColorsets just on a single colorset. 2) It seems to me that whenever I do Tint color percent I always want to do bgTint color percent too, otherwise the sh/hi colors look incorrectly. So I think, Tint should also set bgTint. If someone really wants the current behaviour (doubtly), he may always reset bgTint, i.e. Tint cyan 20, bgTint. For most of cases bgTint will be redundant with this proposal. What about using fvwm functions AddToFunc SetClearColorset + I Colorset $0 ... clearing ... + I Colorset $* AddToFunc SetColorsetTint + I Colorset $0 Tint $1, bgTint $1 The colorset code is delicate. As we are in feature freeze I am not very motivated to change some code which seems bug free (for some minor feature). 3) It seems to me that whenever I do Transparent or RootTransparent I always want to do bg average after that. I remember the last time we discussed this it was rejected, since it takes time to evaluate average. However most of users will need to do it anyway, just explicitely. I think bg average should be implicetely set after every background image/gradient/transparent change. I think this may be solved nicely in this way. Initially or after Clear or after bg average, bg is set to be average-ed on every background change, hovewer after explicit bg setting, the auto-averaging is off. I disagree. bg average can be very slow and can use a lot of (dynamical) memory. It can also reduce fvwm usability under certain situation, e.g., FvwmBacker big bgs = 2 secs or more for switching between desks (colorset FvwmBacker bg can solve this but you should have all your bg in memory ...). I think that it is better that the user set bg average itself (there is a warning in the man page, he takes his responsibility). By the way, I think we should fix this problem: when the bg is big the average bg colour can be computed on a random subset of points of the bg. Regards, 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]
Re: Status of logo voting?
On Mon, Sep 29, 2003 at 12:59:05PM +0200, Uwe Pross wrote: Hi there, On 29 Sep 2003 at 10:22:19 +0200, Dominik Vogt wrote: I think we need to start the voting process soon before the logo artits get angry :-) I got hardly feedback for the actual voting page. You reported one problem I could not reproduce. Using the actual voting page voting should be possible. Could you please check if you can vote with the actual page? I don't think we should state any voting results during the voting time. I tried it, it seems to work fine. Regards, 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]
Re: Notification: incoming/1076
On Wed, Sep 10, 2003 at 11:08:25AM -0500, [EMAIL PROTECTED] wrote: FVWM Bug Tracking notification new message incoming/1076 Message summary for PR#1076 From: [EMAIL PROTECTED] Subject: Mouse strokes Date: Wed, 10 Sep 2003 11:08:24 -0500 0 replies 0 followups ORIGINAL MESSAGE FOLLOWS Subject: Mouse strokes Full_Name: Kornel Szabo Version: 2.5.7 CVS_Date: OS: Gentoo Linux 2.4.22 X_Server: 4.3.1 Submission from: (NULL) (132.231.54.1) Ok, here's the problem: I typed FvwmCommand 'Module FvwmConsole' in a terminal. After that i tried to configure some mouse strokes to see, if it works and this is what i got: [FVWM][__execute_function]: ERROR No such command 'Stroke' When i try to configure it in the configfile, the strokes won't work. bye Maybe your fvwm is compiled without stroke support? Try: [EMAIL PROTECTED] fvwm]$ fvwm --version fvwm 2.5.8 (from cvs) compiled on Sep 2 2003 at 10:36:16 with support for: ReadLine, Stroke, XPM, PNG, Shape, XShm, SM, Bidi text, Xinerama, XRender, XFT, NLS Does Stroke appear? Regards, 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]
Re: Using Unicode's Private Use Are for additional presentation forms
On Sun, Sep 07, 2003 at 09:23:12PM +0200, Marcus Lundblad wrote: I was looking through some documentation on the web. The program Mutt has assigned some part of the private use area for contextual presentation forms and ligatures not present in normal Unicode. For example U+E600 to U+E6FF contains Arabic presentation forms not defined in the Unicode standard (as compatibility characters). This is mostly (as far as I can see) for charaters used in languages normally written in other scripts (Khazak,Uzbek etc.) and unusual forms. This range could easily be supported in FVWM by exending some lookup tables. I would also like to add support for Indic scripts (Mutt has defined some ligature ranges for those scripts also), but this will require some more research. So, what do you think, is it a good or bad idea to add the U+E600 range? This assumes the user has a font with the correct characters in this range (such as Mutt's clearlyu). Maybe this is an acceptable assumption (after all these Arabic characters is probably quite rare). I do not know. I will prefer that fvwm respects the standard and it seems strange to me to add support for one font (there is a lot of ttf fonts which cover various part of the unicode). Not also that we are in feature freeze. I will be very happy to see a test/purify/text_rendering.fvwmrc. Say a big menu which may look like (very informal): CopyMenuStyle * fooxyz MenuStyle fooxyz Font a_fooxyz_font ... AddToMenu TestTextRendering Test Text Rendering Title + Test Arabic font:foo, enc:xyz Popup ArabicTestfooxyz ... AddToMenu ArabicTestfooxyz ArabicTestfooxyz Title + some more or less random string + some more or less random string + ... CopyMenuStyle * fooxyz ChangeMenuStyle fooxyz ArabicTestfooxyz ... Of course some part of this big menu may works only with the good locale (and this may appear on the label of the menus). Finally, I've noted the following problem with hot key: My locale is fr_FR and I want to display a menu with UTF-8 labels: I used CopyMenuStyle * xdg MenuStyle xdg Font StringEncoding=UTF-8:xft:piselsize=10 MenuStyle xdg AutomaticHotkeys AddToMenu test Test Title + Ãconomiseur d'écran Exec xscreensaver-demo --crapplet ChangeMenuStyle xdg test So the label in iso-8859-15 is Économiseur d'écran. The Hot-key underline is too big: it is under Écon. Regards, 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]
Re: [PATCH] fix missing font charsets
On Sat, Aug 30, 2003 at 11:07:13PM -0600, S. Anderson wrote: Hello everyone, While using a utf-8 locale I get this message in my ~/.xsession-errors: [FVWM][FlocaleGetFontSet]: (-*-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-*-*,-*-fixed-medium-r-normal-*-14-*-*-*-*-*-*-*,-*-*-medium-r-normal-*-16-*-*-*-*-*-*-*-*) Missing font charsets: KSC5601.1987-0, GB2312.1980-0 This patch will fix it: diff -urN fvwm.0/libs/defaults.h fvwm/libs/defaults.h --- fvwm.0/libs/defaults.h 2003-08-30 22:55:58.0 -0600 +++ fvwm/libs/defaults.h2003-08-30 22:56:22.0 -0600 @@ -125,7 +125,7 @@ #define FLOCALE_MB_FALLBACK_FONT \ -*-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-*-*, \ -*-fixed-medium-r-normal-*-14-*-*-*-*-*-*-*, \ - -*-*-medium-r-normal-*-16-*-*-*-*-*-*-*-* + -*-*-medium-r-normal-*-16-*-*-*-*-*-*-* /* rationale: -*-fixed-medium-r-semicondensed-*-13-* should gives fixed in most non multibyte charset (?). -*-fixed-medium-r-normal-*-14-* is ok for jsx Hopefully someone can apply this patch. Applied, Thanks, 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]
Re: fvwm crash
On Mon, Aug 25, 2003 at 02:47:43AM +0200, Jochen Klenner wrote: Hello, noticed this with the recent CVS version. To reproduce, start fvwm with the attached config file, touch the taskbar with the mouse to shade it, iconify a window by clicking the only titlebar button. Fvwm freezes, using 100% CPU power (top shows 1/3 going to fvwm, 2/3 to the X server). The only way out is stopping X via ctrl-meta-backspace. This crash occurs since a few days (can't reconstruct the exact date). Fixed (I hope) in current cvs. Can you try it? This is not directly related but when animation occur when the TaskBar is shaded and an animation occur the TaskBar is unshaded and reshaded. This may break your config (Style FvwmTaskBar TitleAtBottom should fix it). However, I will change this TaskBar behavior soon (by animate on the shaded frame). Thanks, 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]
Re: CVS olicha: * Fixed _NET_WM_STATE_FULLSCREEN: set correctly _NET_WM_STATE
On Thu, Aug 14, 2003 at 02:25:43PM +0200, Dominik Vogt wrote: On Thu, Aug 14, 2003 at 01:17:29PM +0200, Olivier Chapuis wrote: On Thu, Aug 14, 2003 at 03:48:20AM -0500, FVWM CVS wrote: snip * Removed the decor for EWMH fullscreen windows, forbid shading Why? If you shade a window without decoration, then you have a 1 pixel line. This is problematic, but why not. Now in the case of a fullscreen window the 1 pixel line is on the top of the monitor and often the offscreen top part of the monitor is black, also there is (maybe) the panframe. So it is extremely difficult to unshade the window. This may happen with some non fullscreen window, but here I get a criterion (fullscreen). However, if you think that we should allow shading this is really not a problem for me. Regards, 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]
Re: Problems with the new detection of IOCCC/Traditional move method
On Sat, Aug 09, 2003 at 11:28:43PM +0300, Mikhael Goikhman wrote: Here I demonstrate some bad problems with the current move/placement methods. I use TiledCascadePlacement, but this should not matter here. I know that xv was always problematic, but I see this with some other programs too. (And there were good workarounds for xv previously.) 1) Run: xv -geo 1500x1500 pictures/fvwm-logo-steelblue.gif Part of the image is out of the screen, because the title is fully visible, previously the image was fully visible and the title was out of the screen. Additionally, click right mouse and double click the file name, the window walks to the right (can't go down here). Press n several times to see it walking right-down. Note first that I have not xv on my machine (xv has disappeared from some distributions as Redhat and Mandrake). You should try: Style match_xv MoveByProgramMethod IgnoreGravity or Style match_xv MoveByProgramMethod UseGravity However, maybe the ICCCM/Traditional move method can be improved: Do not make any conclusion for window which are larger than the screen. [snip] 4) Run display from ImageMagick: display Then press right mouse and choose Image Info, this window is placed partially out of the screen. It does not seems that this is related to the new ICCCM/Traditional move stuff. For me this depends on the position of the main display window (if it is at top left then the transient image info pop up on my screen). I think it is a Transient Windows placement problem (or miss-feature). Regards, 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]
Re: Gnome 2 and FVWM
On Mon, Jul 14, 2003 at 06:53:33PM -0400, Paul Smith wrote: snip If we could get this working it would be nice to have an entry for Gnome 2 in the FAQ, because the current info there for Gnome is all Gnome 1.x based (there is no Window Manager option under the control panel etc. anymore, that I can find...) Done: Q/A 2.8, maybe someone can proof read this new entries. Regards, 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]
Re: Session management and Swallowed apps
On Thu, Jul 31, 2003 at 10:05:47AM +0300, Mikhael Goikhman wrote: On 30 Jul 2003 15:11:27 +0200, Olivier Chapuis wrote: In fact there is a solution. From the XSMP spec: Some clients may wish to manage the programs they start. For example, a mail program could start a text editor for editing the text of a mail message. A client that does this is a session manager itself; it should supply the clients it starts with the appropriate connection information (i.e., the SESSION_MANAGER environment variable) that specifies a connection to itself instead of to the top level session manager. [end of section 3] So, the solution is to make FvwmButtons (and FvwmScript which may swallow some applications too) a simple session manager. I've writing down in libs/ a fsm library which allows FvwmButtons to be a simple _dummy_ session manager. When a XSMP award application is started by FvwmButtons it contact FvwmButtons and not the top level session manager and so this application is not restarted by the session manager (we may even improve window swallowing by using sm, but this is for the future). Unfortunately, there is two problems (with solutions I hope). Any advice/comments is welcome. - As a session manager FvwmButtons should start applications with its own SESSION_MANGER env variable (network address). As it is fvwm which execute the swallow action a workaround should be found. What I do: FvwmButtons defines a function: DestroyFunc xxxFvwmButtonsExecuteSwallowActionXYZ AddToFunc xxxFvwmButtonsExecuteSwallowActionXYZ + I SetEnv SESSION_MANAGER FvwmButtons_SESSION_MANAGER + I $. + I SetEnv SESSION_MANAGER SESSION_MANAGER_orig where SESSION_MANAGER_orig is the value of $SESSION_MANAGER for fvwm (FvwmButtons has it because it is the value of $SESSION_MANAGER at FvwmButtons startup before its become a session manager). Then, a swallow button action is executed by sending to fvwm: xxxFvwmButtonsExecuteFunctionxxx action Can this cause problem? Should we have only one such function in the default fvwm config (for Buttons, Script and any module which can swallow window)? I don't think the global function is the way to go. We have commands for this. So you mat add a command RunWithSM sm-value fvwm-command Yes why not, but I do not like to much to add (and write) an internal only cmd that can be easily simulated by a complex function (why we have complex function?). So, I think that first I will use a complex function in ConfigFvwmDefdault. I you want and there are no objection you may add a RunWithSM cmd. or a more generic: RunEnv [var=value ...] fvwm-command that works like /usr/bin/env; sets variables, runs the supplied command as is (without expansion) and restores modified variables. Outch, I do not want to write the necessary parsing ... Regards, 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]
Re: Notification: incoming/1000 (KDE Kicker system tray)
On Thu, Mar 20, 2003 at 07:15:51AM -0600, [EMAIL PROTECTED] wrote: FVWM Bug Tracking notification new message incoming/1000 Message summary for PR#1000 From: [EMAIL PROTECTED] Subject: KDE Kicker system tray Date: Thu, 20 Mar 2003 07:15:50 -0600 0 replies 0 followups Date: Thu, 20 Mar 2003 07:15:50 -0600 Full_Name: Robby Pählig Version: 2.5.6 CVS_Date: OS: Linux 2.4.19 X_Server: XFree86 4.3 Submission from: (NULL) (212.202.167.112) fvwm doesn't handle the KDE Kicker system tray properly. Often the icons are misplaced. The KAlarm system tray icon doesn't show up at all. If I kill fvwm and start the native KDE window manager, the Kicker tray works properly. Fixed in current cvs. You may try the next snapshot. Regards, 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]
Session management and Swallowed apps
Hello, Note first that this subject has been already discussed in the pass (Subject: session management problems, Date ~ 2001-03-15; fvwm running under a session manager): * There is an old known problem with swallowed windows, they multiply on every start (started by e.g., FvwmButtons and the session manager. The solution is not to use swallowing button bars, or, maybe, to use session aware programs (xload and xclock are not) and mark them Restart never if possible. Teoretically using Swallow(UseOld,NoClose) should help, but it does not (probably because FvwmButtons starts before old xload/xclock). It even produces walking windows before reswalowing on restart, see other entries. They appear for 5 seconds and then are swallowed. I thought about a new Swallow(AllowOnlyOne) option especially for SM, which kills all application instances except for one. No solution was found and this bug was postponned. In fact there is a solution. From the XSMP spec: Some clients may wish to manage the programs they start. For example, a mail program could start a text editor for editing the text of a mail message. A client that does this is a session manager itself; it should supply the clients it starts with the appropriate connection information (i.e., the SESSION_MANAGER environment variable) that specifies a connection to itself instead of to the top level session manager. [end of section 3] So, the solution is to make FvwmButtons (and FvwmScript which may swallow some applications too) a simple session manager. I've writing down in libs/ a fsm library which allows FvwmButtons to be a simple _dummy_ session manager. When a XSMP award application is started by FvwmButtons it contact FvwmButtons and not the top level session manager and so this application is not restarted by the session manager (we may even improve window swallowing by using sm, but this is for the future). Unfortunately, there is two problems (with solutions I hope). Any advice/comments is welcome. - As a session manager FvwmButtons should start applications with its own SESSION_MANGER env variable (network address). As it is fvwm which execute the swallow action a workaround should be found. What I do: FvwmButtons defines a function: DestroyFunc xxxFvwmButtonsExecuteSwallowActionXYZ AddToFunc xxxFvwmButtonsExecuteSwallowActionXYZ + I SetEnv SESSION_MANAGER FvwmButtons_SESSION_MANAGER + I $. + I SetEnv SESSION_MANAGER SESSION_MANAGER_orig where SESSION_MANAGER_orig is the value of $SESSION_MANAGER for fvwm (FvwmButtons has it because it is the value of $SESSION_MANAGER at FvwmButtons startup before its become a session manager). Then, a swallow button action is executed by sending to fvwm: xxxFvwmButtonsExecuteFunctionxxx action Can this cause problem? Should we have only one such function in the default fvwm config (for Buttons, Script and any module which can swallow window)? - smproxy and gnome-smproxy (a modified version of smproxy) break the XSMP protocol: they always contact the session manager which start it (most often the top level session manager). When a top level window is mapped the a proxies should compute the value of the SESSION_MANAGER ev on the application which maps the window and should either ignore this window if this value is not equal to the proxy SESSION_MANAGER ev (a one sm proxy only) or should contact the session manager identified by $SESSION_MANAGER. smproxy and gnome-smproxy do not do that and this is *not* impossible to do. So with the current version of smproxy and gnome-smproxy applications which use the old session management protocol (e.g., xload but not xclock) are started by the session manager and FvwmButtons. One obvious solution is to do not run a sm proxy ... however I will try to convince XFree and GNOME developers to fix their sm proxies (yes I know I am optimist ...): A session manager (master or not) can set on a leader window (which use the old session manager protocol) a property SESSION_MANAGER(STRING) to the value of its network address (i.e., the value of its SESSION_MANAGER environment variable). A sm proxy should use this property to contact the correct session manager or to ignore this window if it works for only one sm (e.g., the master one) and the value of this property is not the network address of its session manager. The proxy should monitor the SESSION_MANAGER property and update its connection(s) accordingly (typically a window will map without the SESSION_MANAGER property set, if SM_CLIENT_ID is not set a concerned sm can then set the SESSION_MANAGER property). [We can do a more safe stuff: add a SESSION_MANGER_CHECK_WINDOW(Window) property that should be also set by the sm on the top level window and gives the id of a window which belong to the sm and have the property SESSION_MANGER_CHECK(STRING) set to the value of the SESSION_MANAGER property. This can be used by a sm to answer the
Session and display
Hello, Current bug: Start a session manager on display 1 with fvwm and save your session. The restart commands will look like: fvwm -d :0.0 -s -clientId clien_id0 -restore restore_file0 (with two screens an other fvwm is restarted: fvwm -d :0.1 -s -clientId clien_id1 -restore restore_file1) Then later you start X on display 1 with the session manager, fvwm will not start at all (if there is no X running on display 0 or if a window manager run on display 0.*) or fvwm starts on the screen(s) 0.* (if there is an X connection on display 0 and no window manager running on screen 0.*). So, we get a session with no window manager on display 1. Solution: Add an argument to -s which gives the screen on which fvwm should run (the display will be found either with $DISPLAY or the arg of the -d option or with a dummy XOpenDisplay). The Restart command will look like: fvwm -s screen_number -clientId clien_id -restore restore_file and will restart fvwm on the display good_display.screen_number. Do I miss something? Any comments? Regards, 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]
Re: Gnome 2 and FVWM
On Sat, Jul 19, 2003 at 08:01:12AM -0400, Paul Smith wrote: %% Olivier Chapuis [EMAIL PROTECTED] writes: oc Ok, I've found the problem: the gnome-session editor wants oc the SmCloneCommand. I will commit a fix soon. Excellent; thanks Olivier. Current cvs contains the fix. Regards, 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]
Re: Gnome 2 and FVWM
On Thu, Jul 17, 2003 at 10:40:50PM +0200, Olivier Chapuis wrote: On Wed, Jul 16, 2003 at 04:29:26PM -0400, Paul Smith wrote: All the rest of my problems seem solved, except this one: anyone have any idea whether the Gnome 2.2 session manager is sufficiently different that it doesn't grok FVWM? I work hard on this today but do not found the trick :o/ I guess that the problem is a _simple_ thing that fvwm do not do or do. Ok, I've found the problem: the gnome-session editor wants the SmCloneCommand. I will commit a fix soon. Regards, 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]
Re: FVWM: GNOME2/fvwm integration
On Thu, Jul 17, 2003 at 12:47:28AM +0300, Mikhael Goikhman wrote: On 16 Jul 2003 21:53:37 +0200, Olivier Chapuis wrote: On Wed, Jul 16, 2003 at 09:21:06PM +0200, Olivier Chapuis wrote: On Wed, Jul 16, 2003 at 06:08:41PM +0200, Olivier Chapuis wrote: The problem is simple: all gnome panels have the same name, icon name, res name and class name! So when we restore the window state fvwm/session.c is unable to make the distinction between all the gnome panels. Any idea for a fix? The obvious idea after reading the SM spec (and the ICCCM2) is to use the SM_CLIENT_ID property (on a possible WM_CLIENT_LEADER window) But, at first view the gnome panels have no SM_CLIENT_ID set!! I did not notice these additional messages before writing my previous reply. I think this bug (gnome-panel does not support XSMP and does not set SM_CLIENT_ID) should be reported to gnome-panel developers. see below. I think that sawfish, metacity, icewm and kwin simply ignore window without the SM_CLIENT_ID property set (on the client leader) regarding session management. I think we should add the SM_CLIENT_ID as the main identifier in the session code and either: Ok sorry it is already the case. - do not reset session state for windows with an identifier (sm client id, name ...etc) with two matching identifiers in the session window list. or - simply do not save/restore state for window without SM_CLIENT_ID. Old application do not support XSMP (I think xterm already supports XSMP, but probably rxvt does not). my rxvt support XSMP. After name comparision there is a command line comparision. So if 2 windows have the same command lines (say xterm -ls -g 80x40) it is really not important if we replace them, since they are just indentical. Agree. I can't explain how 2 gnome-panel use the same command lines and open different panels (one at top and one at bottom). I guess one gnome-panel process opens 2 windows, at top and at bottom. I would really fix this in gnome-panel, because the current fix makes old applications (like 2 rxvt with the same parameters) to lose all fvwm properties/flags on the next session. This is only my understanding. I do not think there is a gnome-panel bug here: SM_CLIENT_ID and WM_COMMAND are not set on the managed gnome-panel windows (no leader too). I think that gnome-panel developer does not want that the gnome-panel state be restored by the window manager. By the way there is an unmanaged gnome-panel window with SM_CLIENT_ID set. I think that the correct fix is that session.c totally ignore windows which do not set SM_CLIENT_ID neither WM_COMMAND. There is no way for a session manager to start such application at session startup. Other problems I see with the session code: - Some session manager now only consider window with XSMP support. So an app which use WM_COMMAND will not be started by the session manager. So maybe the user will start the app after session startup and can be troubled by the fact that fvwm restore the windows app state. Solution? Detect the session manager and support only XSMP app if this session manager support only XSMP app. - Some app with XSMP support may use the RestartNever style hint. The session manager will not start such app at session startup. If the user start this app later, again fvwm will restore the state. Solution? Can we query the restart style hint or only the session manager can do that? The only general solution I see is a way for the session manager to say to the wm which apps it will restart at session init. Regards, 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]
Re: Gnome 2 and FVWM
On Wed, Jul 16, 2003 at 04:29:26PM -0400, Paul Smith wrote: All the rest of my problems seem solved, except this one: anyone have any idea whether the Gnome 2.2 session manager is sufficiently different that it doesn't grok FVWM? I work hard on this today but do not found the trick :o/ I guess that the problem is a _simple_ thing that fvwm do not do or do. Regards, 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]
Re: Gnome 2 and FVWM
On Tue, Jul 15, 2003 at 10:33:42AM -0400, Paul Smith wrote: Another thing is that the fonts don't look so hot anymore: I'm using Microsoft's Arial TrueType font for window titles, menus, etc. and they used to look excellent, but now they look blocky and uneven. They still look great in some parts of the desktop (stuff that's rebuilt specifically for Gnome 2?), but not others. Anyone have any ideas? I think it's because I'm using a different font server/rendering engine (freetype2?) but I don't know the details. What are your exact fvwm configuration lines for loading font? Do you use Xft or core fonts rendering? About FreeType2 lib, a compile time option (off by default for licence reseon) can lead to a better font rendering. Using a font server (as xfs) or not can also change fonts rendering (for core fonts rendering). Regards, 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]
Re: FVWM: GNOME2/fvwm integration
On Wed, Jul 16, 2003 at 06:08:41PM +0200, Olivier Chapuis wrote: On Sat, Jul 05, 2003 at 10:06:34AM -0400, Tessa Lau wrote: I'm installing Debian unstable and the latest GNOME2 desktop on a friend's system, and I'm trying to convince him to see the light and switch from sawfish to fvwm2. However I'm running into a few bugs with the GNOME2 integration. I'm using a freshly built fvwm 2.5.7. I switch to fvwm by killing sawfish and running fvwm2, then saving my session. The first time after I log out and log back in with fvwm, the GNOME menu panel, which is always at the top of the screen, has been relocated to the bottom of the screen. The bottom edge panel has been relocated to the top of the screen. The menu panel cannot be moved. If I move the bottom edge panel down to the bottom of the screen where it belongs, it gets hidden behind the menu panel, and is lost forever. It is a fvwm bug. I hope that we will be able to fix it soon. I switch to the fvwm-workers list. The problem is simple: all gnome panels have the same name, icon name, res name and class name! So when we restore the window state fvwm/session.c is unable to make the distinction between all the gnome panels. Any idea for a fix? The obvious idea after reading the SM spec (and the ICCCM2) is to use the SM_CLIENT_ID property (on a possible WM_CLIENT_LEADER window) But, at first view the gnome panels have no SM_CLIENT_ID set!! I think that sawfish, metacity, icewm and kwin simply ignore window without the SM_CLIENT_ID property set (on the client leader) regarding session management. I think we should add the SM_CLIENT_ID as the main identifier in the session code and either: - do not reset session state for windows with an identifier (sm client id, name ...etc) with two matching identifiers in the session window list. or - simply do not save/restore state for window without SM_CLIENT_ID. Regards, 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]
Re: FVWM: GNOME2/fvwm integration
On Wed, Jul 16, 2003 at 09:21:06PM +0200, Olivier Chapuis wrote: On Wed, Jul 16, 2003 at 06:08:41PM +0200, Olivier Chapuis wrote: On Sat, Jul 05, 2003 at 10:06:34AM -0400, Tessa Lau wrote: I'm installing Debian unstable and the latest GNOME2 desktop on a friend's system, and I'm trying to convince him to see the light and switch from sawfish to fvwm2. However I'm running into a few bugs with the GNOME2 integration. I'm using a freshly built fvwm 2.5.7. I switch to fvwm by killing sawfish and running fvwm2, then saving my session. The first time after I log out and log back in with fvwm, the GNOME menu panel, which is always at the top of the screen, has been relocated to the bottom of the screen. The bottom edge panel has been relocated to the top of the screen. The menu panel cannot be moved. If I move the bottom edge panel down to the bottom of the screen where it belongs, it gets hidden behind the menu panel, and is lost forever. It is a fvwm bug. I hope that we will be able to fix it soon. I switch to the fvwm-workers list. The problem is simple: all gnome panels have the same name, icon name, res name and class name! So when we restore the window state fvwm/session.c is unable to make the distinction between all the gnome panels. Any idea for a fix? The obvious idea after reading the SM spec (and the ICCCM2) is to use the SM_CLIENT_ID property (on a possible WM_CLIENT_LEADER window) But, at first view the gnome panels have no SM_CLIENT_ID set!! I think that sawfish, metacity, icewm and kwin simply ignore window without the SM_CLIENT_ID property set (on the client leader) regarding session management. I think we should add the SM_CLIENT_ID as the main identifier in the session code and either: Ok sorry it is already the case. - do not reset session state for windows with an identifier (sm client id, name ...etc) with two matching identifiers in the session window list. or - simply do not save/restore state for window without SM_CLIENT_ID. Regards, 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]
Re: FVWM: GNOME2/fvwm integration
On Sat, Jul 05, 2003 at 10:06:34AM -0400, Tessa Lau wrote: I'm installing Debian unstable and the latest GNOME2 desktop on a friend's system, and I'm trying to convince him to see the light and switch from sawfish to fvwm2. However I'm running into a few bugs with the GNOME2 integration. I'm using a freshly built fvwm 2.5.7. I switch to fvwm by killing sawfish and running fvwm2, then saving my session. The first time after I log out and log back in with fvwm, the GNOME menu panel, which is always at the top of the screen, has been relocated to the bottom of the screen. The bottom edge panel has been relocated to the top of the screen. The menu panel cannot be moved. If I move the bottom edge panel down to the bottom of the screen where it belongs, it gets hidden behind the menu panel, and is lost forever. It is a fvwm bug. I hope that we will be able to fix it soon. I switch to the fvwm-workers list. The problem is simple: all gnome panels have the same name, icon name, res name and class name! So when we restore the window state fvwm/session.c is unable to make the distinction between all the gnome panels. Any idea for a fix? Regards, 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]
Re: Move/Resize ConfigureRequest
On Tue, Jul 08, 2003 at 08:55:37AM +0200, Dominik Vogt wrote:
On Tue, Jul 08, 2003 at 08:12:18AM +0200, Olivier Chapuis wrote:
On Mon, Jul 07, 2003 at 09:37:54AM +0200, Dominik Vogt wrote:
On Mon, Jul 07, 2003 at 09:09:42AM +0200, Olivier Chapuis wrote:
On Sun, Jul 06, 2003 at 02:12:54PM +0200, [EMAIL PROTECTED] wrote:
On Sun, Jul 06, 2003 at 07:24:33AM +0200, Olivier Chapuis wrote:
On Sat, Jul 05, 2003 at 10:15:25PM +0200, [EMAIL PROTECTED] wrote:
It seems to work as mozilla set it and the good algo is choosen.
(All KDE = 2 and GNOME2 apps set this prop).
By the way, should we implement _NET_WM_STATE_FULLSCREEN?
Yes. I'd like to do it myself to gather some experience with the
ewmh code.
It seems that this start to work. But what about a FullScreen command
which removes the decoration, MoveResize the window to the size
of the screen and possibly put the window in a given layer:
FullScreen [bool] [StayOnTop|layer x y] [size_hint_override]
then we define defaults fvwm func:
AddToFunc EWMHFullScreenOn I FullScreen On
AddToFunc EWMHFullScreenOff I FullScreen Off
which are called when needed by the ewmh code.
I'd prefer doing this via a function. We have way too many move/
resize/maximize functions already. The new ewmh code calls the
ResizeMoveMaximize command.
Yes. But I do not see how to restore the initial window state
without a designed command (or an new Maximize flags) for fullscreen:
AddToFunc EWMHFullScreenOn
+ I WindowStyle !Borders, !Title
+ I WindowStyle StaysOnTop
+ I Maximize ewmhiwa 100 100
AddToFunc EWMHFullScreenOff
+ I WindowStyle Borders, Title
+ I WindowStyle StaysPut
+ I Maximize off
works well only on decorated stays put window.
A more detailed reply. I should have read more carefully.
1) I think fiddling with the window's decorations and layer is a
bad idea. If the application wants the window on a specific
layer it can use the layer protocol.
From the ewmh spec:
_NET_WM_STATE_FULLSCREEN indicate that the window should fill the entire
screen and have no window decoration.
Also there are stacking order recommendation in the ewmh spec. At present
time fvwm respect this recommendation only if the EWMHUseStackingOrderHints
style is used (off by default). The recommendation is:
- window with _NET_WM_STATE_BELOW
- normal window
- panel/dock apps (_NET_WM_TYPE_DOCK) without _NET_WM_STATE_BELOW
- FULLSCREEN window with the _focus_
Regarding this there is two types of user. Those who want its
panel (or main Buttons or TaskBar) on top and those who want
its panel put (like me and you dominik I think). The first type
of users will want fullscreen window on top, the others will want
fullscreen window put.
I do not want to consider the _focus_ condition (but this can be
implemented with WindowStyle + FvwmEvent and a FullScreen condition).
So a reasonable alternative is to use the same layer than the panel
for fullscreen window.
So my suggestion is to add a new fvwm command
--
FullScreen [flags] [bool]
Without its optional arguments (or if the bool bit has the value
toggle) FullScreen causes the window to alternately switch from
a full-screen size without decoration to its normal size with its
normal decoration. To force a window into full-screen (normal) state
you can use a True or False value for the bool argument.
The optional flags argument is a space separated list containing the
following key words: ewmh, layer x, ontop, decoration,
size_override. These options are useful only when the window switch to
full-screen and the possible effect caused by these options are
discarded when the window switch back to its normal size. layer x put
the fullscreen window into layer x, ontop put the fullscreen window
into the StaysOnTop layer, ewmh put the fullscreen window into the
StaysOnTop layer only if the window has the EWMHUseStackingOrderHints
style, decoration forces to do not remove the window decoration. A
full-screen window may not be resized to the full size of the screen,
because a window may require some specific sizes. The size_override
key word forces screen full size.
--
Of course as we are in feature freeze it is may be not reasonable
to add this command??
Then, we add default functions
EWMHFullScreenOn I FullScreen ewmh True
EWMHFullScreenOff I FullScreen False
that the user can redefine.
If we do not add such a command I think we should leave the code
at is now (decoration off screen!?) or we need to add new variables
as explained in 3) to be able to define EWMHFullScreen{On,Off}.
By the way, Dominik if I well understand your last mail in
the StyleById patch voting thread thread, the addition of the
WindowStyle command will not have grave consequence?
3) And finally, I noticed that certain information about the
window is not accessible from functions. To allow
Re: Move/Resize ConfigureRequest
On Mon, Jul 07, 2003 at 09:37:54AM +0200, Dominik Vogt wrote: On Mon, Jul 07, 2003 at 09:09:42AM +0200, Olivier Chapuis wrote: On Sun, Jul 06, 2003 at 02:12:54PM +0200, [EMAIL PROTECTED] wrote: On Sun, Jul 06, 2003 at 07:24:33AM +0200, Olivier Chapuis wrote: On Sat, Jul 05, 2003 at 10:15:25PM +0200, [EMAIL PROTECTED] wrote: It seems to work as mozilla set it and the good algo is choosen. (All KDE = 2 and GNOME2 apps set this prop). By the way, should we implement _NET_WM_STATE_FULLSCREEN? Yes. I'd like to do it myself to gather some experience with the ewmh code. It seems that this start to work. But what about a FullScreen command which removes the decoration, MoveResize the window to the size of the screen and possibly put the window in a given layer: FullScreen [bool] [StayOnTop|layer x y] [size_hint_override] then we define defaults fvwm func: AddToFunc EWMHFullScreenOn I FullScreen On AddToFunc EWMHFullScreenOff I FullScreen Off which are called when needed by the ewmh code. I'd prefer doing this via a function. We have way too many move/ resize/maximize functions already. The new ewmh code calls the ResizeMoveMaximize command. Yes. But I do not see how to restore the initial window state without a designed command (or an new Maximize flags) for fullscreen: AddToFunc EWMHFullScreenOn + I WindowStyle !Borders, !Title + I WindowStyle StaysOnTop + I Maximize ewmhiwa 100 100 AddToFunc EWMHFullScreenOff + I WindowStyle Borders, Title + I WindowStyle StaysPut + I Maximize off works well only on decorated stays put window. Regards, 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]
Re: Move/Resize ConfigureRequest
On Sun, Jul 06, 2003 at 02:12:54PM +0200, [EMAIL PROTECTED] wrote: On Sun, Jul 06, 2003 at 07:24:33AM +0200, Olivier Chapuis wrote: On Sat, Jul 05, 2003 at 10:15:25PM +0200, [EMAIL PROTECTED] wrote: I have mostly completed and applied the patch. Still missing: * The window styles (although the members of the window_style structure are already defined). * Handling changes in update.c. * Write man page. I can do that if you want ... as I have also write down a patch (partial) too! I'm already on the job - I'm getting nervous with a half finished patch in cvs :-) * Check for _NET_WM_PID. Seems you do that. Actually, I have difficulties to understand the design of the ewmh_...c files. I understand there are properties that are * set once on the root window at fvwm startup * set on the root window but updated regularly * set by fvwm on application windows (?) * set by once applications on their windows when mapped * set by apps on their window and updated later (?) * client messages from apps to fvwm * client messages from fvwm to client windows. Where is this all located in the code and how does it correspond to the nine atom lists in ewmh.c? The logic in the lists splitting is a bit different. There are comments which explain this logic where there are defined. Basically, atoms in a given list are handled in the same way by the code. The code is maybe a bit difficult to understand at first reading but it is easy to add new EWMH stuff as a lot of things are done automatically: _basically_ add an atom in a list with a function handler and you have done. Note that the signification of an atom can depends on how it is used. For, example the atoms in the EWMH_ATOM_LIST_WM_STATE can be received by fvwm as a client message (send by any application) to ask a state change. Secondly, the wm must set the _NET_WM_STATE on an application window with the atoms of the EWMH_ATOM_LIST_WM_STATE accordingly with the state of the window. Finally, a window can map with a _NET_WM_STATE set on it to indicate a desired mapping state. It is useful to have such a list for automatic handling of these 3 situations via the functions handler of the list. These functions should handle 3 different situations: - Client msg (ev != NULL style == NULL) - Initial Mapping with the state set (ev == NULL style != NULL). Note the additional arg any (== has_hint) for recapture and restarting. - Query of the state (ev == NULL style == NULL) What is the idea behind these lists and how are they handled. E.g., are the atoms in the lists detected automatically? Yes. For example to add a _NET_WM_STATE add it to the EWMH_ATOM_LIST_WM_STATE list (in alphabetic order) and write down the function handler (all the other stuff is done automatically: client msg detection, initial mapping checking, state query for _NET_WM_STATE, addition in the list of supported _NET stuff). I will add more comment in ewmh code, but the list name and the functions handler name can be used to know where a given EWMH property is handled. * Test the patch. I have only tried Mozilla yet. Make some test with Tk it is ok. I have written a small testing app and found a lot of bugs that are all fixed now. Can you check with Tk, please? If anything strange happens give instructions to reproduce and post the console output. Ok. The seven detection methods are: - _NET_WM_PID (dould not find an application that sets it) - full screen detection (icccm) - full screen detection (traditional) - moving window adjacent to a border (icccm) - moving window adjacent to a border (traditional) - moving window by the border width/height (icccm) while it would stay in the same placew with the traditional method. - same for traditional I did not test the _NET_WM_PID detection yet. It seems to work as mozilla set it and the good algo is choosen. (All KDE = 2 and GNOME2 apps set this prop). By the way, should we implement _NET_WM_STATE_FULLSCREEN? Yes. I'd like to do it myself to gather some experience with the ewmh code. It seems that this start to work. But what about a FullScreen command which removes the decoration, MoveResize the window to the size of the screen and possibly put the window in a given layer: FullScreen [bool] [StayOnTop|layer x y] [size_hint_override] then we define defaults fvwm func: AddToFunc EWMHFullScreenOn I FullScreen On AddToFunc EWMHFullScreenOff I FullScreen Off which are called when needed by the ewmh code. Also you just wrote all the code for _NET_MOVERESIZE_WINDOW but the trivial stuff in fvwm/ewmh* Yes, I think so. The logic in the __cr_get_grav_position() function should return the requested frame position. It needs some work on the interface, though. What about building a ConfigureRequest event and send it to the events code with an override_gravity arg (which forces icccm motion algo
Re: Move/Resize ConfigureRequest
On Sat, Jul 05, 2003 at 10:15:25PM +0200, [EMAIL PROTECTED] wrote: On Fri, Jul 04, 2003 at 07:21:58AM +0200, Olivier Chapuis wrote: On Thu, Jul 03, 2003 at 10:14:31AM +0200, Dominik Vogt wrote: On Thu, Jul 03, 2003 at 08:12:29AM +0200, Olivier Chapuis wrote: However, I think we need a new style (as there is no standard way to detect that an application respect the EWMH spec). Having a style is not wrong anyway. Any opinions/comments/objections? For a detection algorithm: 1) If the windows CR algorithm was set by a style or detected before, use it. 2) If a window resizes itself to the *exact* size of the display and the requested position of the client window is either +0+0 or +border_width+border_height, put it at +0+0 and make a decision about the algorithm it uses based on the requested position. I am not sure to understand this one, can you be more precise? 3) If a window resizes/positions itself so that interpreting its position would shift it by exactly the width/height of the left or top border, set the algorithm that would prevent this shift (if possible). 4) If a window places itself in a way that would place it exaclty on the border of the display, choose the algorithm that keeps the border on screen. I will add: if the window has _NET_WM_PID set use the ICCCM algo. So we should have three styles (I don't like the term legacy because it displays a certain arrogance of the wm-spec people against tradition): MoveByProgramAlgorithm [SmartTraditional|SmartICCCM|ICCCM|Traditional] with SmartTraditional being the default (i.e. use above algorithm and use Traditional by default). However, the names of the styles are all bad (hard too understand). I think that we cannot found good names here. I have mostly completed and applied the patch. Still missing: * The window styles (although the members of the window_style structure are already defined). * Handling changes in update.c. * Write man page. I can do that if you want ... as I have also write down a patch (partial) too! * Check for _NET_WM_PID. Seems you do that. * Test the patch. I have only tried Mozilla yet. Make some test with Tk it is ok. With mozilla-1.1 when I press F11 to go to fullscreen and go back to normal stat (F11) my mozilla window totally disappear (probably a mozilla bug). With mozilla-1.4 (no fullscreen) when I use the resize grip mozilla do not go up and up anymore, however resizing is a bit erratic (probably bad interaction with the inc hints ...). By the way, should we implement _NET_WM_STATE_FULLSCREEN? Also you just wrote all the code for _NET_MOVERESIZE_WINDOW but the trivial stuff in fvwm/ewmh* Regards, 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]
Re: Move/Resize ConfigureRequest
On Thu, Jul 03, 2003 at 10:14:31AM +0200, Dominik Vogt wrote: On Thu, Jul 03, 2003 at 08:12:29AM +0200, Olivier Chapuis wrote: However, I think we need a new style (as there is no standard way to detect that an application respect the EWMH spec). Having a style is not wrong anyway. Any opinions/comments/objections? For a detection algorithm: 1) If the windows CR algorithm was set by a style or detected before, use it. 2) If a window resizes itself to the *exact* size of the display and the requested position of the client window is either +0+0 or +border_width+border_height, put it at +0+0 and make a decision about the algorithm it uses based on the requested position. I am not sure to understand this one, can you be more precise? 3) If a window resizes/positions itself so that interpreting its position would shift it by exactly the width/height of the left or top border, set the algorithm that would prevent this shift (if possible). 4) If a window places itself in a way that would place it exaclty on the border of the display, choose the algorithm that keeps the border on screen. I will add: if the window has _NET_WM_PID set use the ICCCM algo. So we should have three styles (I don't like the term legacy because it displays a certain arrogance of the wm-spec people against tradition): MoveByProgramAlgorithm [SmartTraditional|SmartICCCM|ICCCM|Traditional] with SmartTraditional being the default (i.e. use above algorithm and use Traditional by default). However, the names of the styles are all bad (hard too understand). I think that we cannot found good names here. Regards, 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]
Move/Resize ConfigureRequest
Hello, Ok, this subject is delicate ... Examples of pb: - Start Mozilla, say that its position is +x+y. Set fullscreen (F11), if you have a not too recent version of Mozilla this works (with Mozilla-1.4 and maybe other this does not work as Mozilla use NET_WM_FULLSCREEN which is not implemented in fvwm (this not the point of this email). Reset to normal state (F11). Then, either Mozilla crash or the Mozilla window totally disappear (strange) or the new window position is +(x-left_frame_width)+(y-top_frame_height) - Other Mozilla pbs: resizing the window with the internal Mozilla resize grip. - Tk experience: [EMAIL PROTECTED] olivier]$ wish % wm geometry . +0+0 The top-left part of the frame is out of screen - This problem will happen with any QT, GTK, JAVA and Tk application which move-resize itself (after mapping). All this applications are not buggy! They all respect the ICCCM2 (or at least a really reasonable interpretation of the ICCCM2). Note that most of the actively developed window manager respect this (e.g., icewm, kwin and metacity). Also this is documented in the EWMH spec. Of course fvwm no that, however it use a legacy way to move-resize a window because some old apps use this legacy logic (sorry I've no example, but Dominik has surely some). I suggest that we add a new style: LegacyConfigureRequest / ICCCMConfigureRequest or ICCCMConfigureRequest / LegacyConfigureRequest to handle this problem. About default we can do something a bit more complex: detect if the app respect the EWMH spec, if yes use ICCCMConfigureRequest if not use LegacyConfigureRequest. However, I think we need a new style (as there is no standard way to detect that an application respect the EWMH spec). Any opinions/comments/objections? Regards, 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]
Re: comments on the recent ter-off menu patches
On Tue, Jul 01, 2003 at 12:53:34AM +0200, [EMAIL PROTECTED] wrote:
There are some parts of the patch I do not understand or that are
bugs.
1) In menu_tear_off():
ms = menustyle_find(buffer);
if (!ms)
{
/* this must never happen */
fvwm_msg(
ERR, menu_tear_off,
impossible to create %s menu style, buffer);
free(buffer);
DestroyMenu(mr, False, False);
return;
}
Is there a specific reason why you use menustyle_find() instead of
MR_STYLE(mr_to_copy) which is much simpler and can not fail?
Even if there is a reason, I don't think you can return from the
function.
ms is not MR_STYLE(mr_to_copy) it is the menu style just created
by menustyle_parse_style(F_PASS_ARGS) where action is the address
of mr. Maybe, it will be good that menustyle_parse_style return
the menu style that it creates or modifies ... done.
2) In clone_menu_root_static():
What is the logic of changing
MR_COPIES(dest_mr) = 0;
to
MR_COPIES(dest_mr) = 1;
? Was it a bug?
When, you create a menu (with AddToMenu) MR_COPIES(mr) = 1. The menu
code logic implies that MR_COPIES is never 0 but in DestroyMenu just
before it is totally destroyed (and maybe re-created and in this case
MR_COPIES is re-incremented).
Yes, I think it was a bug. What happen if you enter DestroyMenu
with MR_COPIES(dest_mr) = 0?
...
MR_COPIES(dest_mr)--; -- MR_COPIES is -1
...
if (MR_COPIES(dest_mr) == 0) -- leaks
{
free some stuff
}
Any way if you change the test
MR_COPIES(dest_mr) == 0
by
MR_COPIES(dest_mr) = 0
it is not a big problem to set MR_COPIES to 0 for a tear off
menu. However, it seems that the logic is to set MR_COPIES
to 1 when you create a tear off menu.
3) This is a bug:
do_menu_close_tear_off_menu(pmp-menu, *pmp);
pmret-rc = MENU_ABORTED;
discard_window_events(
MR_WINDOW(pmp-menu), EnterWindowMask);
do_menu_close_tear_off_menu() destroys the MR_WINDOW(pmp-menu)
and thus discard_window_events() operates on a random Xid.
Yes. Fixed.
4) Please name all functions exported in menustyle.c
menustyle_something(). (I renamed copy_menu_style() to
menustyle_copy()).
Yep, such naming scheme is good. Ha 2 questions.
Under which condition you start the function with __?
(a private version of an exported function?).
What is the goal of the TearMenuOff command, how can
we use it?
Regards, 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]
Re: StyleById patch voting thread
On Fri, Jun 27, 2003 at 10:07:37PM -0400, Dan Espen wrote: Olivier Chapuis [EMAIL PROTECTED] writes: On Tue, Jun 24, 2003 at 09:39:47AM +0200, Dominik Vogt wrote: On Tue, Jun 24, 2003 at 06:40:50AM +0200, Olivier Chapuis wrote: On Thu, Jun 19, 2003 at 03:51:50PM +0200, [EMAIL PROTECTED] wrote: On Sat, Jun 07, 2003 at 07:20:12PM +0200, Olivier Chapuis wrote: On Mon, May 19, 2003 at 01:44:27PM +0200, Dominik Vogt wrote: Should the StyleById patch be applied before 2.6? Please cast your votes here. Seems that there is no conclusion here. It seems that there is two votes for it (me and Mikhael) one vote against (Dominik) and one unclear vote (Dan). So I ask for more votes and clarification (Dan?). For that I send an other version of the patch (attached). I've followed all the advice (I can follow) that I get in this thread. In particular, I've followed all the remarks (as I can) of Dominik regarding the code. So, Dominik I even hope you revert your vote (very little hope ...). I don't know about your hope, but the chance that I do is zero. It is not the right time. The reason of my hope is that the new version of the patch take in account the reasons why you reject it. Nothing on earth can make me agree to adding huge features in feature freeze. It is not a huge feature, it is one of the few features that fvwm miss to become a perfect window manager. So let us have it!! Looking at the patch, I agree, its not huge. Its not minor either. You give 7 arguments. The new patch handle arguments 3, 4 and 6. Moreover, I've worked on argument 5 and style list simplification has been improved. As I said before, I reject making facts now that can never be changed again. The way the style list works has always been a mistake. No matter how much time you spend on optimising the style list code, it will always be a memory leak. This logic is due for replacement, not for expansion. I will say that this has almost nothing to do with the WindowStyle cmd. This is a general problem regarding styles. Any way, I will be interested to see a natural situation where the style list go to infinity (with a fixed number of names). I don't agree that the Style code is fundamentally broken. But I know from past experience that Dominik's standards are higher than mine. To me, the style code does the job so I don't see a problem with it. The way matches work may seem odd, but I don't think there's a better way. I don't understand the comment about the memory leaks. I remember Dominik doing some work to combine styles as they were issued. There shouldn't be any leaking going on. About 1 and 2 I can just say that I do not _think_ that the patch can cause instability. It has already consumed much time in pointless arguments that could have been spent stabilising the code. There is a direct relationship between my motivation to work on the remaining problems and the amount of distractions on this list that have nothing to do with it. Finally, I do not understand argument 7. It's an ad-hoc syntax that *will* be thrown away right when we start thinking. I have many enhancements in mind that have no chance of being implemented with this kind of just-throw-in-a-new- command-whenever-it-seems-to-work-for-the-moment approach. I do not see the problem. If I follow your logic the Style command will drastically change. Moreover, I cannot imagine that we rework the style stuff and that at the end it will be not possible to set window attributes on a given window. But, maybe the most important is that there is 4 votes for the patch (Dan, Mikhael, Olivier and Tim) and one vote against (Dominik). Of course Dan can speak for himself, but according to the mail archive he did neither vote for nor against the patch. Not that I think it matters. In general Dan does not vote. He gives arguments. At the end there is no arguments against. But yes it is possible that Dan use abstention. I agree with Dominik, my vote hardly matters. As I said before, I think votes should be in proportion to contribution. In this case, I've been agreeing with both sides. Dominik has some very good points. I don't agree about the Style code being a problem and therefore shouldn't be extended, but I do agree that we need to freeze features to create a stable release. I am not agree with this. I think the code is safe. I do not understand Dominik arguments against the patch (second version). We have always added feature during feature freeze. Note also that you can add bugs when you fix a bug... Currently, the existence of the patch allowed to fix a few bugs! I think Oliviers point about this nicely rounding out the feature set, and not being a big change is very
Re: Fw: Re: fvwm-menu-desktop
On Mon, Jun 30, 2003 at 12:55:47PM +, Mikhael Goikhman wrote: I forward this message. Initially Matt asked me privatelly about supporting parsing of the vfolders XML Categories description. Yes, fvwm-menu-desktop should be rewritten to support vfolders and the new spec (http://www.freedesktop.org/standards/desktop-entry-spec/). I've not the time to do this. Sorry. Regards, Olivier X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Mikhael Goikhman [EMAIL PROTECTED] Subject: Re: fvwm-menu-desktop Date: Mon, 30 Jun 2003 10:27:18 +0100 From: Matt Davey [EMAIL PROTECTED] What is vfolders XML Category description? On the current redhat distribution (and I've no idea which others, but I guess anything keeping with the everchanging gnome2 landscape), the .desktop files include an extra piece of meta-information. For example, my gnu-emacs.desktop contains the line: Categories=TextEditor;Development;X-Red-Hat-Base;Application; Then, .menu files a menu structure is defined, with each submenu defined by a set of categories which can be ANDed and NOTted together, in the style of Apache XML configuration. My rh9 distribution has all the .desktop files in /usr/share/applications.. . So you should use: fvwm-menu-desktop --dir /usr/share/applications /usr/share/applications has no subdirectories, so I end up with a flat menu list that is about twice the height of my desktop, and doesn't split into multiple columns. All the best, Matt -- 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: Fw: Re: fvwm-menu-desktop
On Mon, Jun 30, 2003 at 04:56:25PM +0200, Olivier Chapuis wrote: On Mon, Jun 30, 2003 at 12:55:47PM +, Mikhael Goikhman wrote: I forward this message. Initially Matt asked me privatelly about supporting parsing of the vfolders XML Categories description. Yes, fvwm-menu-desktop should be rewritten to support vfolders and the new spec (http://www.freedesktop.org/standards/desktop-entry-spec/). Sorry it is: http://www.freedesktop.org/standards/desktop-entry-spec/desktop-entry-spec.html Also http://www.freedesktop.org/standards/menu/draft/menu-spec/menu-spec.html http://www.freedesktop.org/standards/basedir/draft/basedir-spec/basedir-spec.html should be taken in account Regards, 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]
Re: FlocaleDrawUnderline and BIDI
On Sun, Jun 29, 2003 at 07:22:16PM +0200, Marcus Lundblad wrote: I'm almost done now with the implementation of superimposing combining characters. I wonder why the function FlocaleDrawUnderline doesn't call FlocaleEncodeWinString (to perform BIDI and so on). Probably a bug ... I never test underline with non standard strings. Regards, 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]
Re: CVS olicha: * Fixed animation when the TaskBar is shaded
On Fri, Jun 27, 2003 at 08:29:34AM -0500, FVWM CVS wrote:
CVSROOT: /home/cvs/fvwm
Module name: fvwm
Changes by: olicha 03/06/27 08:29:34
Modified files:
modules: ChangeLog
modules/FvwmTaskBar: FvwmTaskBar.c
Log message:
* Fixed animation when the TaskBar is shaded
Here what was the problem:
NoIcon and animation enabled in the TaskBar. If the TaskBar is shaded
when you (de)Iconify a window the animation proceed as if the TaskBar
was not shaded. Various solutions:
1. Unshade, animate and shade (the solution I've just committed).
2. Animate but take in account the shaded geometry of the TaskBar.
3. Do not animate at all (I do not like this solution).
I've used 1 as it is the simplest solution and it is fun (if the
user want animation he get a triple animation). 2 seems to be a
reasonable alternative. Note that IconMan, IconBox and WinList have
this problem and that the case of a swallowed Icon{Man,Box} into a
FvwmButtons should be handle too.
Any advice before I continue to fix this problem?
Regards, 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]
Re: StyleById patch voting thread
On Tue, Jun 24, 2003 at 09:39:47AM +0200, Dominik Vogt wrote: On Tue, Jun 24, 2003 at 06:40:50AM +0200, Olivier Chapuis wrote: On Thu, Jun 19, 2003 at 03:51:50PM +0200, [EMAIL PROTECTED] wrote: On Sat, Jun 07, 2003 at 07:20:12PM +0200, Olivier Chapuis wrote: On Mon, May 19, 2003 at 01:44:27PM +0200, Dominik Vogt wrote: Should the StyleById patch be applied before 2.6? Please cast your votes here. Seems that there is no conclusion here. It seems that there is two votes for it (me and Mikhael) one vote against (Dominik) and one unclear vote (Dan). So I ask for more votes and clarification (Dan?). For that I send an other version of the patch (attached). I've followed all the advice (I can follow) that I get in this thread. In particular, I've followed all the remarks (as I can) of Dominik regarding the code. So, Dominik I even hope you revert your vote (very little hope ...). I don't know about your hope, but the chance that I do is zero. It is not the right time. The reason of my hope is that the new version of the patch take in account the reasons why you reject it. Nothing on earth can make me agree to adding huge features in feature freeze. It is not a huge feature, it is one of the few features that fvwm miss to become a perfect window manager. So let us have it!! You give 7 arguments. The new patch handle arguments 3, 4 and 6. Moreover, I've worked on argument 5 and style list simplification has been improved. As I said before, I reject making facts now that can never be changed again. The way the style list works has always been a mistake. No matter how much time you spend on optimising the style list code, it will always be a memory leak. This logic is due for replacement, not for expansion. I will say that this has almost nothing to do with the WindowStyle cmd. This is a general problem regarding styles. Any way, I will be interested to see a natural situation where the style list go to infinity (with a fixed number of names). About 1 and 2 I can just say that I do not _think_ that the patch can cause instability. It has already consumed much time in pointless arguments that could have been spent stabilising the code. There is a direct relationship between my motivation to work on the remaining problems and the amount of distractions on this list that have nothing to do with it. Finally, I do not understand argument 7. It's an ad-hoc syntax that *will* be thrown away right when we start thinking. I have many enhancements in mind that have no chance of being implemented with this kind of just-throw-in-a-new- command-whenever-it-seems-to-work-for-the-moment approach. I do not see the problem. If I follow your logic the Style command will drastically change. Moreover, I cannot imagine that we rework the style stuff and that at the end it will be not possible to set window attributes on a given window. But, maybe the most important is that there is 4 votes for the patch (Dan, Mikhael, Olivier and Tim) and one vote against (Dominik). Of course Dan can speak for himself, but according to the mail archive he did neither vote for nor against the patch. Not that I think it matters. In general Dan does not vote. He gives arguments. At the end there is no arguments against. But yes it is possible that Dan use abstention. So, I think we should apply the patch. Then take the consequences and abandon the idea of a stable 2.6 release. Why? Regards, 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]
Re: StyleById patch voting thread
On Thu, Jun 19, 2003 at 03:51:50PM +0200, [EMAIL PROTECTED] wrote: On Sat, Jun 07, 2003 at 07:20:12PM +0200, Olivier Chapuis wrote: On Mon, May 19, 2003 at 01:44:27PM +0200, Dominik Vogt wrote: Should the StyleById patch be applied before 2.6? Please cast your votes here. Seems that there is no conclusion here. It seems that there is two votes for it (me and Mikhael) one vote against (Dominik) and one unclear vote (Dan). So I ask for more votes and clarification (Dan?). For that I send an other version of the patch (attached). I've followed all the advice (I can follow) that I get in this thread. In particular, I've followed all the remarks (as I can) of Dominik regarding the code. So, Dominik I even hope you revert your vote (very little hope ...). I don't know about your hope, but the chance that I do is zero. It is not the right time. The reason of my hope is that the new version of the patch take in account the reasons why you reject it. You give 7 arguments. The new patch handle arguments 3, 4 and 6. Moreover, I've worked on argument 5 and style list simplification has been improved. About 1 and 2 I can just say that I do not _think_ that the patch can cause instability. Finally, I do not understand argument 7. But, maybe the most important is that there is 4 votes for the patch (Dan, Mikhael, Olivier and Tim) and one vote against (Dominik). So, I think we should apply the patch. Regards, 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]
Re: Bugs with transparency when used with various modules
On Mon, Jun 16, 2003 at 09:30:37AM -0700, Jason Gabler wrote: transparency + FvwmWinList: I'm trying to use as much transparency as possible (similar to the Crystal theme), this includes using transparency with the FvwmWinList module. I find that it often uses the wrong window names/titles in the list. Sometimes an fvwm restart can fix this (most often not). Fully login out of X and then back in sometimes fixes it (more often than an fvwm restart). Basically the behavior is FvwmWinList will use window names of windows that have WindowListSkip in their Style to replace window names that sjould be in the list. For the record, I've never seen this happen when not using transparency. I've only seen this when Fvwm starts. I will take a look at this pb but you start your module as Module FvwmBacker Module FvwmTheme Module FvwmWinList Module FvwmButtons This is not a good idea (as the man pager says). This should be AddToFunc StartFunction + I Module FvwmBacker + I Module FvwmTheme + I Module FvwmWinList + I Module FvwmButtons transparency with title bars: Transparent title bars can often get locked into a particular portion of the background. No matter where you place the windows they maintain them same portion of the background. This can happen when Fvwm starts or after some use of the WM. Transperent title bars sometimes show the given background color and do not do transparency.This can happen when Fvwm starts or after some use of the WM. transparency with FvwmButtons: The same sticking image problem can happen as with title bars. I think that these stick images problem come from your FvwmBaker config: *FvwmTheme: Colorset 12 Pixmap initialD_FDnFC.xpm *FvwmBacker: Command (Desk *, Page * *) Exec fvwm-root /home/jason/Icons/Desktop/initialD_FDnFC.xpm *FvwmBacker: Command (Desk 0) Colorset 12 *FvwmBacker: RetainPixmap You should use the --retain-pixmap option of fvwm-root transparency with FvwmPager: Not sure if this is transparency related, but sometimes FvwmPager just doesn't start or it wont swallow into Buttons. I've never seen this w/o transparency. Do you have any error msg (X stderr) or a core dump file when this happen? My .fvwm2rc is attached as fvwm2rc.jyg Some others remarks on you config. First you do not always define the bg color in the Colorsets. This causes fvwm to compute the average color of your root pixmap. If you do not want this for a colorset define the bg color (this speedup colorset loading). ModulePath /usr/libexec/fvwm/2.5.7 This line is not useful and cause pb when you upgrade Please replace any line of the form: *FvwmThemes: Colorset by Colorset and be sure you do not start the FvwmTheme module. Regards, 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]
Re: simplify styles list
On Sat, Jun 14, 2003 at 06:37:34PM +, Mikhael Goikhman wrote: On 14 Jun 2003 19:04:51 +0200, Olivier Chapuis wrote: My WindowStyle patch leads me to study the __simplify_style_list function. Here some possible amelioration: 1 - style name compatibility: Example: Style abc* options1 Style hop* options2 Style abc* options3 with options2 flags-inter options3 not empty. This is not simplified, but as no window can match both abc* and hop*, in fact this can be simplified to Style hop* options1 Style abc* merge(options1, option2) The point is to write down a efficent algo for: given two pattern p1 and p2, decides whether there exists a string which matchs both p1 and p2. I've done this. The problem here is that it is easy to create a window that matches both abc* and hop*. xterm -class abc -title hop Ooops, yes this simplification was stupid. Regards, 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]
Re: simplify styles list
On Sun, Jun 15, 2003 at 08:01:26AM +0200, Olivier Chapuis wrote: On Sat, Jun 14, 2003 at 06:37:34PM +, Mikhael Goikhman wrote: On 14 Jun 2003 19:04:51 +0200, Olivier Chapuis wrote: My WindowStyle patch leads me to study the __simplify_style_list function. Here some possible amelioration: 1 - style name compatibility: Example: Style abc* options1 Style hop* options2 Style abc* options3 with options2 flags-inter options3 not empty. This is not simplified, but as no window can match both abc* and hop*, in fact this can be simplified to Style hop* options1 Style abc* merge(options1, option2) The point is to write down a efficent algo for: given two pattern p1 and p2, decides whether there exists a string which matchs both p1 and p2. I've done this. The problem here is that it is easy to create a window that matches both abc* and hop*. xterm -class abc -title hop Ooops, yes this simplification was stupid. Note however that this logic can be applied in between WindowStyle style ... Regards, 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]
simplify styles list
Hello, My WindowStyle patch leads me to study the __simplify_style_list function. Here some possible amelioration: 1 - style name compatibility: Example: Style abc* options1 Style hop* options2 Style abc* options3 with options2 flags-inter options3 not empty. This is not simplified, but as no window can match both abc* and hop*, in fact this can be simplified to Style hop* options1 Style abc* merge(options1, option2) The point is to write down a efficent algo for: given two pattern p1 and p2, decides whether there exists a string which matchs both p1 and p2. I've done this. 2 - string matching sets inclusion Style hop options1 Style hop* option2 where options1 is a flags-subset of options2. This is not simplified but as every string which match hop match hop*, this can be simplified to Style hop* option2 Again the point is to write down an efficient algo for: given two patterns p1 and p2, decides whether all string which match p1 match also p2. I should write this ... 3 - Upward simplification Example: Style * SloppyFocus Style toc ClickToFocus Style * NoIcon is not simplified into: Style * SloppyFocus, NoIcon Style toc ClickToFocus This type of case are easy to handle. Any comments? Olivier, Regards -- 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: StyleById patch voting thread
On Sun, Jun 08, 2003 at 01:54:14AM +, Mikhael Goikhman wrote:
On 07 Jun 2003 14:17:41 -0400, Dan Espen wrote:
Olivier Chapuis [EMAIL PROTECTED] writes:
On Mon, May 19, 2003 at 01:44:27PM +0200, Dominik Vogt wrote:
Should the StyleById patch be applied before 2.6? Please cast
your votes here.
Seems that there is no conclusion here. It seems that there is two
votes for it (me and Mikhael) one vote against (Dominik) and one
unclear vote (Dan). So I ask for more votes and clarification
(Dan?). For that I send an other version of the patch (attached).
I've followed all the advice (I can follow) that I get in this
thread. In particular, I've followed all the remarks (as I can) of
Dominik regarding the code. So, Dominik I even hope you revert your
vote (very little hope ...). Also: the cmds are named WindowStyle and
DestroyWindowStyle and act on the selected window and there is the
doc and some tests in purify.fvwm2rc.
Can you please clarify one thing. You previously said that after applying
many WindowStyle commands and switching themes the style list didn't grow.
Do I understand you correctly? Because it is the Dominik's reason against
the patch (you seem to cover several other reasons with your new patch).
Yes, with fvwm-themes I've tried to switch and add some window style,
switch and add some window style ..etc and the style list does not
grow (in a not reasonable way). However, one can succeed to found a
way for making the style list to explode (with a limited number of
name) with or without the WindowStyle command. I think you have to do
very strange things for this (with or without the WindowStyle
command).
By the way, I think we may improve a bit __simplify_style_list, by
remplacing:
if (!styles_have_same_id(*cur, *cmp))
{
blockor((char *)interflags,
(char *)interflags,
(char *)cmp-flag_mask,
sizeof(style_flags));
blockor((char *)interflags,
(char *)interflags,
(char *)cmp-flag_default,
sizeof(style_flags));
cmp = SGET_PREV_STYLE(*cmp);
continue;
}
by something like:
Bool one_fw_can_match_both_ids(window_style s, window_style t)
{
if (SGET_ID_HAS_WINDOW_ID(s) SGET_ID_HAS_WINDOW_ID(t)
SGET_WINDOW_ID(s) != SGET_WINDOW_ID(t))
{
return False;
}
if (SGET_ID_HAS_NAME(s) SGET_ID_HAS_NAME(t))
{
if !(there exists a string which match
SGET_NAME(s) and SGET_NAME(t))
{
return False;
}
}
return True;
}
if (!styles_have_same_id(*cur, *cmp))
{
if (one_fw_can_match_both_ids(*cur,*cmp))
{
blockor((char *)interflags,
(char *)interflags,
(char *)cmp-flag_mask,
sizeof(style_flags));
blockor((char *)interflags,
(char *)interflags,
(char *)cmp-flag_default,
sizeof(style_flags));
}
cmp = SGET_PREV_STYLE(*cmp);
continue;
}
but I've to think more and we have to found a cleaver algo for:
there exists a string which match SGET_NAME(s) and SGET_NAME(t))
Regards, 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]
Re: StyleById patch voting thread
On Mon, May 19, 2003 at 01:44:27PM +0200, Dominik Vogt wrote:
Should the StyleById patch be applied before 2.6? Please cast
your votes here.
Seems that there is no conclusion here. It seems that there is two
votes for it (me and Mikhael) one vote against (Dominik) and one
unclear vote (Dan). So I ask for more votes and clarification
(Dan?). For that I send an other version of the patch (attached).
I've followed all the advice (I can follow) that I get in this
thread. In particular, I've followed all the remarks (as I can) of
Dominik regarding the code. So, Dominik I even hope you revert your
vote (very little hope ...). Also: the cmds are named WindowStyle and
DestroyWindowStyle and act on the selected window and there is the
doc and some tests in purify.fvwm2rc.
Regards, Olivier
PS: What are the rules for the votes?
Index: fvwm/add_window.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.c,v
retrieving revision 1.348
diff -u -r1.348 add_window.c
--- fvwm/add_window.c 27 May 2003 00:37:00 - 1.348
+++ fvwm/add_window.c 7 Jun 2003 17:13:26 -
@@ -3014,6 +3014,18 @@
return;
}
+ /* remove window style */
+ if (!IS_SCHEDULED_FOR_DESTROY(fw) !DO_REUSE_DESTROYED(fw))
+ {
+ style_id_t s_id;
+
+ memset(s_id, 0, sizeof(style_id_t));
+ SID_SET_WINDOW_ID(s_id, (XID)FW_W(fw));
+ SID_SET_HAS_WINDOW_ID(s_id, True);
+
+ style_destroy_style(s_id);
+ }
+
/** remove from window list **/
/* if the window is sheduled fro destroy the window has been already
* removed from list */
Index: fvwm/commands.h
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/commands.h,v
retrieving revision 1.36
diff -u -r1.36 commands.h
--- fvwm/commands.h 3 Jan 2003 06:57:35 - 1.36
+++ fvwm/commands.h 7 Jun 2003 17:13:27 -
@@ -167,6 +167,7 @@
F_DESTROY,
F_DESTROY_DECOR,
F_DESTROY_MOD,
+ F_DESTROY_WINDOW_STYLE,
F_ECHO,
F_FLIP_FOCUS,
F_FOCUS,
@@ -194,6 +195,7 @@
F_WARP,
F_WINDOWID,
F_WINDOW_SHADE,
+ F_WINDOW_STYLE,
F_END_OF_LIST = 999,
@@ -260,6 +262,7 @@
void CMD_DestroyMenuStyle(F_CMD_ARGS);
void CMD_DestroyModuleConfig(F_CMD_ARGS);
void CMD_DestroyStyle(F_CMD_ARGS);
+void CMD_DestroyWindowStyle(F_CMD_ARGS);
void CMD_Direction(F_CMD_ARGS);
void CMD_Echo(F_CMD_ARGS);
void CMD_EdgeCommand(F_CMD_ARGS);
@@ -383,6 +386,7 @@
void CMD_WindowList(F_CMD_ARGS);
void CMD_WindowShade(F_CMD_ARGS);
void CMD_WindowShadeAnimate(F_CMD_ARGS);
+void CMD_WindowStyle(F_CMD_ARGS);
void CMD_Xinerama(F_CMD_ARGS);
void CMD_XineramaPrimaryScreen(F_CMD_ARGS);
void CMD_XineramaSls(F_CMD_ARGS);
Index: fvwm/functable.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/functable.c,v
retrieving revision 1.23
diff -u -r1.23 functable.c
--- fvwm/functable.c11 Mar 2003 08:54:44 - 1.23
+++ fvwm/functable.c7 Jun 2003 17:13:29 -
@@ -220,6 +220,10 @@
CMD_ENT(destroystyle, CMD_DestroyStyle, F_DESTROY_STYLE, 0, 0),
/* - Delete style defined using Style */
+ CMD_ENT(destroywindowstyle, CMD_DestroyWindowStyle,
+ F_DESTROY_WINDOW_STYLE, FUNC_NEEDS_WINDOW, CRS_SELECT),
+ /* - Delete style defined using WindowStyle */
+
CMD_ENT(direction, CMD_Direction, F_DIRECTION, 0, 0),
/* - Operate on the next window in the specified direction */
@@ -619,6 +623,10 @@
CMD_ENT(windowshadeanimate, CMD_WindowShadeAnimate, F_SHADE_ANIMATE,
0, 0),
/* - (obsolete, use Style * WindowShadeSteps) */
+
+ CMD_ENT(windowstyle, CMD_WindowStyle, F_WINDOW_STYLE,
+ FUNC_NEEDS_WINDOW, CRS_SELECT),
+ /* - Set styles on the selected window */
CMD_ENT(xinerama, CMD_Xinerama, F_XINERAMA, 0, 0),
/* - Control Xinerama support */
Index: fvwm/fvwm.1.in
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/fvwm.1.in,v
retrieving revision 1.92
diff -u -r1.92 fvwm.1.in
--- fvwm/fvwm.1.in 3 Jun 2003 19:22:31 - 1.92
+++ fvwm/fvwm.1.in 7 Jun 2003 17:14:07 -
@@ -5769,10 +5769,16 @@
all styles starting with Application.
.TP
+.B DestroyWindowStyle
+deletes the styles set by the
+.B WindowStyle
+command on the selected window. The changes take effect immediately.
+
+.TP
.BI UpdateStyles
All pending updates of all windows' styles and looks are applied
immediately. E.g. if
-.BR Style or TitleStyle
+.BR Style , WindowStyle or TitleStyle
commands were issued inside a fvwm function.
.TP
@@ -7540,6 +7546,14 @@
Style * NoIcon
Style FvwmPager Icon
.EE
+
+.TP
+.BI WindowStyle options
+sets attributes (styles) on the selected
Re: FvwmBanner: PNG or Colorset support and more
On Thu, Jun 05, 2003 at 03:39:45PM +, Mikhael Goikhman wrote: We don't seem to have the png or colorset support in FvwmBanner. There is png support in FvwmBanner. There is just a bug ... fixed soon (I hope). However, the support is limited: no alpha blending! if a point has an alpha of = 130 then the point is removed and if the alpha 130 the point is fully displayed ... Now, we can add alpha blending but on what? X has no translucent support ... So, we can either (if the image has some alpha): 1 - blend vs the Root window (need ParentalRelativity Style) 2 - or over a colorset background 3 - or over a colorset background without the shape from the image. 1 and 2 may look ugly under certains situations. For example, with 1 and FvwmBanner over an other window than the root window. So, 3 can be a default (with colorset 0). This leads to new options: *FvwmBanner: Colorset cs Specifies a colorset for the bg of FvwmBanner (default 0). This is only useful if the image has a transparent part and the Shaped option is used or if the image has an alpha channel. *FvwmBanner: Shaped bool Shape or not the FvwmBanner window with the transparent part of the image. Default is false if the image has an alpha channel, true otherwise. With these two options we can do 1, 2 and 3. Regards, 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]
Re: Reproduceable Failed to write descriptor to module bug
On Fri, Jun 06, 2003 at 07:35:21PM +, Mikhael Goikhman wrote: Previously I got Failed to write descriptor to 'FvwmConsole' often, but now I can narrow the problem, this time with FvwmBanner, not FvwmConsole. Fixed, I think. Regards, 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]
Re: Support for combining characters
On Sat, May 31, 2003 at 07:05:19PM +0200, Marcus Lundblad wrote: I implemented a first basic version of combining characters. What it does is compress sequences of characters to the canonical pre-composed form. Additionally a fix for superimposing needs to be added. Ie. combining characters that could not be composed into a pre-composed form should be drawn superimposed. Olivier, could you assist me a bit on this? Yes, but I know nothing on combining, bidi and joint ... If I extend my function that does composing to fill in an array mapping character position in the in-string to their visual position. For example, let's say there is o + some obscure composing char + a, where there is no pre-composed form for an o with some obscure composing char, it would give an array: [0,0,1] That is the first 2 characters should get drawn in first square, the last in the second square. What could perhaps be tricky is to handle BIDI. The mapping array must be rearranged as characters are reorganised by the BIDI algorithm. I do not understand the problem, sorry. But two remarks/questions: What about merging FCombineChars, FBidi and FBidiJoin? Which charset (in the sense of the FlocaleCharsetTable from FLocaleCharset.c) needs Char Combining and which charset needs Joining (I know for Bidi)? I hope my code is not crashing on anyone. Please test it. I have tested it, and it seems to work. But maybe I missed something critical. Can you send some relevant strings (in UTF-8 or/and others encoding) for adding test in purify.fvwm2rc? Also Nadim, could you test this with Arabic combining characters? Marcus, you should always cc to Nadim. Regards, 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]
Re: Birthday announcement draft
On Fri, May 30, 2003 at 10:07:14AM +0200, Dominik Vogt wrote: On Fri, May 30, 2003 at 10:04:37AM +0200, fvwm-workers wrote: * Learn more about fvwm's history link to history page and its authors and users link to page with photographs. Read: * Learn more about fvwm's history link to history page and its authors and users link to page with photographs and their pets ^_^ link to cats page. :-) About fvwm history I've just write down something in french (for linuxfr). I may translate it if no one want to write something and someone want to correct it (english + whatever). Regards, 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]
Re: Birthday announcement draft
On Fri, May 30, 2003 at 02:13:27PM +0200, Olivier Chapuis wrote: On Fri, May 30, 2003 at 10:07:14AM +0200, Dominik Vogt wrote: On Fri, May 30, 2003 at 10:04:37AM +0200, fvwm-workers wrote: * Learn more about fvwm's history link to history page and its authors and users link to page with photographs. Read: * Learn more about fvwm's history link to history page and its authors and users link to page with photographs and their pets ^_^ link to cats page. :-) About fvwm history I've just write down something in french (for linuxfr). I may translate it if no one want to write something and someone want to correct it (english + whatever). In fact I will be unable to translate this text in a good way. Here the text I wrote in french (still one spelling needed). Un peu d'histoire. Comme dit précédemment la première version (probablement la version 0.5) de FVWM est sortie avec une version de rxvt le 1er juin 1993. La version 1.0 est sortie à la fin de cette même année comme un logiciel indépendant. La première motivation de Robert Nation était d'avoir un gestionnaire de fenêtres plus léger que twm pour son portable avec un CPU à 33 MHZ et 4 MB de RAM. De nos jours, FVWM signifie F? Virtual Window Manager, libre à chacun de remplacer le ? (Feline est particulièrement à la mode à l'heure actuelle). En fait, à l'origine le F signifiait Feeble (faible). Mais rapidement, ce prénom est devenu inapproprié et un mystère autour du F a été volontairement instauré (voir la question 1.1 de la FAQ de FVWM). En août 1995 Rob a abandonné FVWM et Charles Hines a repris la flamme jusqu'au mois de mai 1998. Puis Brady Montz a repris FVWM pour quelques mois. Durant cette période le rôle du mainteneur était principalement d'appliquer les patches envoyés par les utilisateurs et développeurs et de réaliser de nouvelles versions. Il était le seul à avoir accès au code et durant certaines périodes il n'avait pas toujours le temps nécessaire. On peut dire que mi 1998 le developpement de FVWM était presque mort. Mais en octobre 1998 sous l'impulsion de quelques personnes (en particulier Dominik Vogt qui est toujours le mainteneur actuel) FVWM a changé de mode de devellopement en passant à la méthode du bazar. Plusieurs développeurs ont eux accès au code via un arbre CVS (administré par Jason Tibbitts). Le développement n'a jamais été aussi actif depuis ce changement même si cela a parfois posé quelques problèmes d'organisation. Ceci à conduit à la version 2.2.0 en février 1999. En plus de Dominik Vogt, on peut cité Johan Bengtsson, Matthias Clasen, Dan Espen, Michael Han, Tomas Ogren, Tim Phipps, Chris Rankin, Steve Robbins, Paul Smith, Andrew Veliath et Bob Woodside. Par la suite, certains développeurs sont devenus moins actifs ou ont abandonnés et d'autres sont apparus. Olivier Chapuis (moi-même), Brad Giaccio et Mikhael Goikhman durant le developpemnt de la version 2.4.0 sortie le 3 juillet 2001. Suzanne Britton, Marcus Lundblad, Uwe Pross et Jason Weber durant le développemnt de la future version 2.6.0 prévu pour septembre. Ceci pour citer seulement ceux ayant un accès directe au code, mais FVWM ne serait pas ce qu'il est sans les centaines de personnes ayant envoyées des patches (plus de 130 personnes dans le fichier AUTHORS) et les milliers de personnes qui ont participé ou participe aux listes de discussions de FVWM. La dernière version stable est la 2.4.16. La version de développment est la 2.5.7. Elles sont soties le 31 mai 2003 a l'ocasion du 10ème annivairsaire de FVWM. -- 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: CVS olicha: * Added a list for the windows which are scheduled for destroy
On Tue, May 27, 2003 at 02:34:55AM +0200, [EMAIL PROTECTED] wrote: On Mon, May 26, 2003 at 12:25:34PM +0200, Olivier Chapuis wrote: [snip] * So, I restored the previous logic (2003-05-20) and add a simple list of the windows which are scheduled for destroy. This list is used in update.c to really destroy/free the fvwm window. I do not know what is the problem ... maybe under certain situation the window which are scheduled for destroy are put back in the fvwm window list in a strange way, that I do no understand. Here the core dump I get when I run purify.fvwm2rc. It is not 100% reproducible (but always happen at the same place during the Iconify test). I reproduce it more easily if I proceed as follows (need to cvs update first for my last purify.fvwm2rc commit): - install purify - run fvwm without config - Open a FvwmConsole and type: Read path_to_fvwm_cvs_tree/tests/purify/purify.fvwm2rc PurifyInit - pop-up the purify menu and select Some Setup - Bloc on Pick after each test - Then, run all test. You should click and click again to progress in the tests When I've no core dump I've a window7 which has lost its client. The same core dump occur with fvwm version prior to the 2003-05-18. I never saw this core dump, but there were a number of bugs that were triggered by the Style2-Func in the script. It boiled down to something like AddToFunc Style2-Func + I Exec xterm -geometry 10x5 -T window1 -n window1 -e sleep 1000 + I Wait window1 + I All (window*) Close + I Exec xterm -geometry 10x5 -T window2 -n window2 -e sleep 1000 + I Wait window2 + I All (window*) Close + I Exec xterm -geometry 10x5 -T window3 -n window3 -e sleep 1000 + I Wait window3 + I All (window*) Close + I Exec xterm -geometry 10x5 -T window4 -n window4 -e sleep 1000 + I Wait window4 + I All (window*) Close + I Exec xterm -geometry 10x5 -T window5 -n window5 -e sleep 1000 + I Wait window5 + I All (window*) Close 1) The next and prev members of the window still pointed to the window list (fixed by you in 2.5.7 and by me in 2.4.x). 2) The code in focus.c ignored the fact that the prev member of the window may not have contained anything useful (fixed in 2.4.x and 2.5.7). 3) If destroy_window() was called multiple times for a single window, it did some of the work twice, e.g. unmapping the icon and broadcasting a message (fixed in 2.4.x and 2.5.7). 4) Once a window was destroyed, X sometimes reuses the same window id. If the timing was right, the code in add_window.c called XDeleteContext on that window id and deleted the context of the new window assuming it was still swallowed in the old frame. Later, the window got destroyed but fvwm ignored the event because it did not find an associated frame. (fixed in 2.4.x and 2.5.7). These patches may or may not have fixed the core dump you got. I cannot reproduce the core dump anymore. I do not have window7 windows without clients at the end of the Test too. Great, 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]
Re: CVS olicha: * Added a list for the windows which are scheduled for destroy
On Sun, May 25, 2003 at 01:20:55AM +0200, [EMAIL PROTECTED] wrote: On Thu, May 22, 2003 at 07:10:51PM +0200, Olivier Chapuis wrote: On Tue, May 20, 2003 at 04:39:22AM -0500, FVWM CVS wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: olicha 03/05/20 04:39:22 Modified files: . : ChangeLog fvwm : add_window.c focus.c screen.h update.c libs : FGettext.c Flocale.c Makefile.am Added files: libs : flist.c flist.h Log message: * Added a list for the windows which are scheduled for destroy * Always remove a fw from the fw list when destroy_window There is something broken in this commit. Please, Mikhael do not release 2.5.7 before I (or Dominik) fix it. What exactly is the problem? I would like to have an answer. I get a core dump (stacking ring corruption?) or fvwm windows which have lost its client window when I run purify.fvwm2rc. Here the story. * Before the 2003-05-18, one logic in destroy_window was to - remove the window from the fvwm window list - test if the window should be scheduled for destroy if yes, return after some job if no, really destroy/free the fvwm window The problem was: when it is the time to really destroy/free the fvwm windows which are scheduled for destroy (in update.c) as the window has been removed from the fvwm window list fvwm do not found these fvwm windows! * On the 2003-05-18 I commit a fix by inverting the logic above: - test if the window should be scheduled for destroy if yes, return after some job - if no remove the window from the fvwm window list - really destroy/free the fvwm window I thought that was not so bad as the scheduled_for_destroy flags is maybe here to forbid certain operations on the fvwm windows in the fvwm window list which are scheduled for destroy. Indeed, I've _no_ problems with this logic (no core dump no fvwm windows which have lost is client). But, you suggest that this logic is bad (and yes some operations are performed on some fvwm windows which are scheduled for destroy). * So, I restored the previous logic (2003-05-20) and add a simple list of the windows which are scheduled for destroy. This list is used in update.c to really destroy/free the fvwm window. I do not know what is the problem ... maybe under certain situation the window which are scheduled for destroy are put back in the fvwm window list in a strange way, that I do no understand. Here the core dump I get when I run purify.fvwm2rc. It is not 100% reproducible (but always happen at the same place during the Iconify test). I reproduce it more easily if I proceed as follows (need to cvs update first for my last purify.fvwm2rc commit): - install purify - run fvwm without config - Open a FvwmConsole and type: Read path_to_fvwm_cvs_tree/tests/purify/purify.fvwm2rc PurifyInit - pop-up the purify menu and select Some Setup - Bloc on Pick after each test - Then, run all test. You should click and click again to progress in the tests When I've no core dump I've a window7 which has lost its client. The same core dump occur with fvwm version prior to the 2003-05-18. #0 0x0808d968 in __raise_or_lower_window (t=0x0, mode=8389217, allow_recursion=1, is_new_window=135186360) at stack.c:823 823 XRaiseWindow (dpy, FW_W_FRAME(t2)); (gdb) where #0 0x0808d968 in __raise_or_lower_window (t=0x0, mode=8389217, allow_recursion=1, is_new_window=135186360) at stack.c:823 #1 0x0808e1eb in RaiseWindow (t=0x81ae9e0) at stack.c:1417 #2 0x080813b6 in DeIconify (fw=0x81ae9e0) at icons.c:2405 #3 0x08081b19 in CMD_Iconify (cond_rc=0xbfffeb04, exc=0x1, action=0x81dba30 0 \True\ üpikü) at icons.c:2671 #4 0x08099b22 in __execute_function (cond_rc=0xbfffeb04, exc=0x81ebe08, action=0x81d0598 E, exec_flags=0 '\0', args=0x81dba30) at functions.c:636 #5 0x0809a7ef in execute_function (cond_rc=0xbfffeb04, exc=0x81ebe08, action=0x81de636 Iconify 0 \True\ üpikü, exec_flags=0 '\0') at functions.c:1228 #6 0x0809d1e3 in circulate_cmd (cond_rc=0xbfffeb04, exc=0x81ebe08, action=0x81de62d (window2) Iconify 0 \True\ üpikü, new_context=1, circ_dir=1, do_use_found=1, do_exec_on_match=1) at conditional.c:198 #7 0x0809e1ef in CMD_Next (cond_rc=0xbfffeb04, exc=0x81b4bf8, action=0x81de62d (window2) Iconify 0 \True\ üpikü) at conditional.c:876 #8 0x08099b22 in __execute_function (cond_rc=0xbfffeb04, exc=0x81ef898, action=0x81b4bf8 E, exec_flags=128 '\200', args=0x81de62d) at functions.c:636 #9 0x0809a037 in __run_complex_function_items (cond_func_rc=0xbfffeb04, cond=105 'i', func=0x1, exc=0x81ef898, args=0xbfffeb90) at functions.c:822 #10 0x0809a28f in execute_complex_function (cond_rc=0xbfffed24, exc=0x81eb248, action=0x81ef898 E, desperate=0x5) at functions.c:992 #11 0x08099bcf in __execute_function (cond_rc
Re: CVS olicha: * Added a list for the windows which are scheduled for destroy
On Tue, May 20, 2003 at 04:39:22AM -0500, FVWM CVS wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: olicha 03/05/20 04:39:22 Modified files: . : ChangeLog fvwm : add_window.c focus.c screen.h update.c libs : FGettext.c Flocale.c Makefile.am Added files: libs : flist.c flist.h Log message: * Added a list for the windows which are scheduled for destroy * Always remove a fw from the fw list when destroy_window There is something broken in this commit. Please, Mikhael do not release 2.5.7 before I (or Dominik) fix it. Regards, 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]
Re: CVS olicha: * Fixed one tone of bugs (leak/core dump) in fvwm:
On Wed, May 21, 2003 at 01:37:21AM +, Mikhael Goikhman wrote: On 19 May 2003 09:34:19 +, Mikhael Goikhman wrote: On 19 May 2003 08:30:00 +0200, Dominik Vogt wrote: On Sun, May 18, 2003 at 08:27:12PM +0200, Olivier Chapuis wrote: [snip] * Added x,r,w,f,i file conditions to the On command BTW, this means I don't think -i is a good name, ReadableImagePath is. After actually reading the sources, I see it is more ReadableImage. So, I think I prefer these names instead: -x, -r, -f - the same as the equal file flags in test/shell/perl -X, -I, -M - search for the given executable/image/module in its PATH Dot no see why we need a -. Moreover, if you want a -x (without path search) give a full path to -X (with your terminolgy). So I think that x,r,w,f,i,m are ok. Regards, 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]
Re: StyleById patch voting thread
On Tue, May 20, 2003 at 08:32:03AM +0200, Dominik Vogt wrote:
Some further explanations below.
3. It does not introduce a data type identifying a style, just
passes lists of arguments to the style functions.
Not sure to understand. There is a new element in the window_style
structure xid (!=0 if and only if the window_style was generated
by the StyleById command).
When style identifiers become more complex than a simple string,
they need to have their own data type, e.g.
typedef struct
{
char *name;
XID window_id;
struct
{
has_name;
has_window_id;
} flags;
} style_id_t;
4. It unnecessarily exports knowledge of style related design
choices to sub functions that do not need to know about them.
Not sure to understand. As FocusStyle vs Style? Not a big issue
IMHO.
See above. Passing all the possible style identifiers through the
function interface to functions parsing some of the styles is not
a good idea.
5. Because id-specific styles are kept in the same list as the
normal styles, it will cause memory consumption by the style
list to explode under certain situations. Clean rules for a
new style preference order are needed first.
Adding _a_ style by id is the same thing as adding a style with a name
which do not already appear in the list. There is style list
simplification/merging in between style by id. Only UseStyle is not
supported by the patch (not a big issue, this can be documented).
You need to understand the problem the style list already has. If
you issue style commands in the wrong order, the list grows ad
infinitum because styles can not be merged or deleted. Configs
with many style changes (theme switching!) or styles tied to a
window id increase this probability a lot because they add
incompatible style identifiers to the list that prevent merging.
I've wrote a Styles subject to the PrintInfo cmd which count the
styles in the style list and print the style names (I can commit this
if you want). With fvwm-themes theme switching does not increase the
number of styles! This is probably because fvwm-themes is well written
... and __simplify_style do a very good job!
In fact, it seems to me that you should have to be careful (and do
strange things) for making the style list growing and growing (say
with two style name).
Anyway, maybe style by id should be prioritary vs style by name:
apply style by name and then apply style by id?
As I said It is just a tmp command.
Then I agree with Dan: I see no reason to introduce temporary
commands into stable releases.
If we add this command and in the future re-design the styles cmds,
it will be surely possible to warp style by id to one of the new
command?
Regards, 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]
Re: StyleById patch voting thread
On Tue, May 20, 2003 at 02:01:55AM +, Mikhael Goikhman wrote: On 19 May 2003 20:47:13 +0200, Olivier Chapuis wrote: I recall my intention: style by id is a great feature, with a simple _hack_ we can get it, so it is difficult to me to do not wrote such code. Yes it is a hack it is not the new great WindowStyle command we want (which needs more discussion and an enormous code reworte). Yes it is just a simple piece of code with some theoretical problems, but ok I think in practice. How exactly StyleById id is different from WindowStyle? Yes the id param is not useful. But, I am just afraid that the future WindowStyle has a syntax which is not compatible. So, as WindowStyle is reserved I will prefer an other name as StylePerWindow. Regards, 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]
Re: StyleById
On Mon, May 19, 2003 at 08:52:23AM +0200, Dominik Vogt wrote: On Mon, May 19, 2003 at 03:01:38AM +0200, Olivier Chapuis wrote: Hello, Attached to this msg 2 new cmds StyleById and DestroyStyleById. StyleById applies styles to specific windows: Pick Style $[w.id] NoTitle, !Borders DestroyStyleById can destroy such a style. The implementation solve the pbs with the patch send by Craig Milo Rogers a few weeks ago: - When a window is destroyed the associated StyleById is destroyed too (if not a new window can have the same id and the old style by id is applied). - No more ambiguity with the Style cmd as we have a new cmd. I see no strong reason against this patch, but (as we are under feature freeze) a vote against it. Any one? Adding the patch to 2.5.x is out of the question (feature freeze). During 2.3.x we added new features during feature freeze. Of course adding a new feature should lead to discussion and voting. But I do not think that we _must_ not add some. During development period we may, for various reasons, postpone/forget/miss certain stuff. Then, during feature freeze we can fix these stuff. Apart from that, this topic requires much more thought. We don't want to make an ad-hoc syntax now, find out later that it does not work with all the other Style related enhancements and the redesign exevrything from scratch. Oh yes. For me, these commands are just _workaround_ commands: This feature is important and it is easy to get it so why we should live without it? Because, we have an ambitious project the WindowStyle command which leads to Conditional Style? Well, with the current FVWM development logic we will have to wait 3 years to get something that can do what StyleById can do now (and I am optimist ... I do not think that we should start a discussion on FVWM future now). Regards, 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]
Re: StyleById
On Mon, May 19, 2003 at 01:22:58PM +0200, Dominik Vogt wrote: On Mon, May 19, 2003 at 12:52:47PM +0200, Olivier Chapuis wrote: On Mon, May 19, 2003 at 08:52:23AM +0200, Dominik Vogt wrote: On Mon, May 19, 2003 at 03:01:38AM +0200, Olivier Chapuis wrote: Hello, Attached to this msg 2 new cmds StyleById and DestroyStyleById. StyleById applies styles to specific windows: Pick Style $[w.id] NoTitle, !Borders DestroyStyleById can destroy such a style. The implementation solve the pbs with the patch send by Craig Milo Rogers a few weeks ago: - When a window is destroyed the associated StyleById is destroyed too (if not a new window can have the same id and the old style by id is applied). - No more ambiguity with the Style cmd as we have a new cmd. I see no strong reason against this patch, but (as we are under feature freeze) a vote against it. Any one? Adding the patch to 2.5.x is out of the question (feature freeze). During 2.3.x we added new features during feature freeze. Of course adding a new feature should lead to discussion and voting. But I do not think that we _must_ not add some. During development period we may, for various reasons, postpone/forget/miss certain stuff. Then, during feature freeze we can fix these stuff. I am trying to stabilise fvwm We (all) are trying to stabilise fvwm ... and patches of this dimension have the potential to throw us back for months. I do not think so. It may cause problems but does not lead to such a delay. Apart from that, this topic requires much more thought. We don't want to make an ad-hoc syntax now, find out later that it does not work with all the other Style related enhancements and the redesign exevrything from scratch. Oh yes. For me, these commands are just _workaround_ commands: This feature is important and it is easy to get it so why we should live without it? Because, we have an ambitious project the WindowStyle command which leads to Conditional Style? See my reply to Mikhael's post. If you prefer a neverending beta status, we can not work on the same project. Why do you use such argument? Well, with the current FVWM development logic we will have to wait 3 years to get something that can do what StyleById can do now Everybody is welcome to help solving the problems that stand between 2.5.6 and 2.6.0. And of course I do nothing for that :o) Regards, 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]
Re: StyleById patch voting thread
On Mon, May 19, 2003 at 01:44:27PM +0200, Dominik Vogt wrote: Should the StyleById patch be applied before 2.6? Please cast your votes here. I vote yes. But maybe the patch should be applied later. I recall my intention: style by id is a great feature, with a simple _hack_ we can get it, so it is difficult to me to do not wrote such code. Yes it is a hack it is not the new great WindowStyle command we want (which needs more discussion and an enormous code reworte). Yes it is just a simple piece of code with some theoretical problems, but ok I think in practice. About the code: a style in the style list is identified by its name. With the StyleById patch a style in the style list is identified with either by the XID used (generated by the StyleById command) or the name (generated by the Style command) not both. The only change in the earth of the style code is the test these two styles have the same identifier. The rest of the code is basically obvious (decoration): parse and use already written function. I vote for no because 1. It will even further delay delay the 2.6 release. 2. It will destabilise the code because of the delicate nature of the style to window propagation. About this two it is difficult to be sure of something. I think that the patch will cause only very few problems. If we want to do a perfect WindowStyle command, then this surely delay a lot 2.6 and destabilize the code. But StyleById is not perfect by nature. 3. It does not introduce a data type identifying a style, just passes lists of arguments to the style functions. Not sure to understand. There is a new element in the window_style structure xid (!=0 if and only if the window_style was generated by the StyleById command). 4. It unnecessarily exports knowledge of style related design choices to sub functions that do not need to know about them. Not sure to understand. As FocusStyle vs Style? Not a big issue IMHO. 5. Because id-specific styles are kept in the same list as the normal styles, it will cause memory consumption by the style list to explode under certain situations. Clean rules for a new style preference order are needed first. Adding _a_ style by id is the same thing as adding a style with a name which do not already appear in the list. There is style list simplification/merging in between style by id. Only UseStyle is not supported by the patch (not a big issue, this can be documented). 6. It introduces inacceptably complicated if-conditions and code duplication. The complicate if-condition is just a visual complication. We can add a macro STYLES_HAS_THE_SAME_IDENTIFIERS(*style1, *style2) and maybe a macro which test if a fw window match a style identifier. I do not see code duplication, but the way to safely do a strtoul (we can put this in one function somewhere). 7. We will regret the ad-hoc syntax very soon: - It is not flexible (mixing different kinds of style patterns is difficult). - The syntax does not help with state-specific styles. - The syntax does not help with regexp style name matching. - It may further complicate abstracting the style parsing code to allow all style names in other contexts (e.g. conditions). As I said It is just a tmp command. Regards, 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]
Re: CVS olicha: * Fixed one tone of bugs (leak/core dump) in fvwm:
On Sun, May 18, 2003 at 01:12:15PM -0500, FVWM CVS wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: olicha 03/05/18 13:12:15 Modified files: . : ChangeLog fvwm : add_window.c borders.c builtins.c conditional.c functions.c fvwm.c menustyle.c menustyle.h windowlist.c libs : FGettext.c Flocale.c defaults.h tests : ChangeLog tests/purify : purify.fvwm2rc Log message: * Fixed one tone of bugs (leak/core dump) in fvwm: * Some purify.fvwm2rc update Again Valgrind help as well as fvwm-themes and purify.fvwm2rc * Fixed a memory leak (a FvwmWindow !) when a window is not destroyed but scheduled for destroy. Not sure that this is the good fix. When an FvwmWindow is destroyed and should be SCHEDULED_FOR_DESTROY, with the old code, it seems that the associated FvwmWindow structure is never freed. The reason is that the window is removed from the list of the fvwm windows before the window is set SCHEDULED_FOR_DESTROY and the struct is not freed. What I do: Keep the window in the fvwm windows list until it is really destroyed. This seems logic for me (regarding the existence of the SCHEDULED_FOR_DESTROY bit), but I am just afraid to add bugs to complex functions. An other possibility is remove from list and to add a list for the windows which are scheduled for destroy. Any comments? * Fixed the default buttons memory leak and * Removed inconsistent #if 0 code and comments about leak and MiniIcon decor style I _hope_ that I've fixed all the memory leaks in the decoration parsing code. However, I am maybe a bit naive here as I've just added one line and removed some comments and unused code. Dominik any comments? * Limited the depth of function to MAX_FUNCTION_DEPTH (=512). This fixes cores dumps with recursive functions [snip] * Added x,r,w,f,i file conditions to the On command Ooops, a new feature that appear under my hands during this debugging session (do not know really why ...). If someone want I can remove it at once. If not I will document it (usual file access tests X_OK, R_OK, ... but for x (X_OK) the file is also searched in $PATH. i is R_OK access in the ImagePath.) Regards, 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]
StyleById
Hello,
Attached to this msg 2 new cmds StyleById and DestroyStyleById.
StyleById applies styles to specific windows:
Pick Style $[w.id] NoTitle, !Borders
DestroyStyleById can destroy such a style.
The implementation solve the pbs with the patch send by Craig Milo Rogers
a few weeks ago:
- When a window is destroyed the associated StyleById is destroyed
too (if not a new window can have the same id and the old style by
id is applied).
- No more ambiguity with the Style cmd as we have a new cmd.
I see no strong reason against this patch, but (as we are under
feature freeze) a vote against it. Any one?
By the way I've noted a problem with the DestroyStyle cmd:
- Start an xterm
- Style * SloppyFocus
- Style XTerm ClickToFocus
- DestroyStyle XTerm
Then, the xterm has ClickToFocus (need a recapture to get SloppyFocus).
Regards, Olivier
Index: add_window.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/add_window.c,v
retrieving revision 1.346
diff -u -r1.346 add_window.c
--- add_window.c18 May 2003 18:12:14 - 1.346
+++ add_window.c19 May 2003 00:54:40 -
@@ -2997,6 +2997,13 @@
return;
}
+ {
+ char xid[20];
+
+ sprintf(xid, 0x%x, (unsigned int)FW_W(fw));
+ CMD_DestroyStyleById(NULL, NULL, xid);
+ }
+
/** check if we have to delay window destruction **/
if ((Scr.flags.is_executing_complex_function ||
Index: commands.h
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/commands.h,v
retrieving revision 1.36
diff -u -r1.36 commands.h
--- commands.h 3 Jan 2003 06:57:35 - 1.36
+++ commands.h 19 May 2003 00:54:40 -
@@ -60,6 +60,7 @@
F_DESTROY_MENU,
F_DESTROY_MENUSTYLE,
F_DESTROY_STYLE,
+ F_DESTROY_STYLE_BY_ID,
F_DFLT_COLORS,
F_DFLT_COLORSET,
F_DFLT_FONT,
@@ -137,6 +138,7 @@
STROKE_ARG(F_STROKE)
STROKE_ARG(F_STROKE_FUNC)
F_STYLE,
+ F_STYLE_BY_ID,
F_TEARMENUOFF,
F_THISWINDOW,
F_TITLE,
@@ -252,6 +254,7 @@
void CMD_DesktopName(F_CMD_ARGS);
void CMD_DesktopSize(F_CMD_ARGS);
void CMD_Destroy(F_CMD_ARGS);
+void CMD_DestroyStyleById(F_CMD_ARGS);
#ifdef USEDECOR
void CMD_DestroyDecor(F_CMD_ARGS);
#endif /* USEDECOR */
@@ -368,6 +371,7 @@
void CMD_StrokeFunc(F_CMD_ARGS);
#endif /* HAVE_STROKE */
void CMD_Style(F_CMD_ARGS);
+void CMD_StyleById(F_CMD_ARGS);
void CMD_TearMenuOff(F_CMD_ARGS);
void CMD_ThisWindow(F_CMD_ARGS);
void CMD_Title(F_CMD_ARGS);
Index: functable.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/functable.c,v
retrieving revision 1.23
diff -u -r1.23 functable.c
--- functable.c 11 Mar 2003 08:54:44 - 1.23
+++ functable.c 19 May 2003 00:54:42 -
@@ -220,6 +220,10 @@
CMD_ENT(destroystyle, CMD_DestroyStyle, F_DESTROY_STYLE, 0, 0),
/* - Delete style defined using Style */
+ CMD_ENT(destroystylebyid, CMD_DestroyStyleById,
+ F_DESTROY_STYLE_BY_ID, 0, 0),
+ /* - Delete style defined using StyleById */
+
CMD_ENT(direction, CMD_Direction, F_DIRECTION, 0, 0),
/* - Operate on the next window in the specified direction */
@@ -573,6 +577,9 @@
#endif /* HAVE_STROKE */
CMD_ENT(style, CMD_Style, F_STYLE, 0, 0),
/* - Set attributes of windows that match a pattern */
+
+ CMD_ENT(stylebyid, CMD_StyleById, F_STYLE, 0, 0),
+ /* - Set attributes of a window using its X id */
CMD_ENT(tearmenuoff, CMD_TearMenuOff, F_TEARMENUOFF, 0, 0),
/* - Convert a menu to a window, for use as a menu command */
Index: fvwm.h
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/fvwm.h,v
retrieving revision 1.220
diff -u -r1.220 fvwm.h
--- fvwm.h 2 Jan 2003 12:01:18 - 1.220
+++ fvwm.h 19 May 2003 00:54:45 -
@@ -547,6 +547,7 @@
struct window_style *next;
struct window_style *prev;
char *name;
+ XID xid;
#if 0
WindowConditionMask *condition_mask;
#endif
Index: style.c
===
RCS file: /home/cvs/fvwm/fvwm/fvwm/style.c,v
retrieving revision 1.208
diff -u -r1.208 style.c
--- style.c 11 Mar 2003 23:14:07 - 1.208
+++ style.c 19 May 2003 00:54:52 -
@@ -724,7 +724,7 @@
}
}
-static Bool remove_all_of_style_from_list(char *style_ref)
+static Bool remove_all_of_style_from_list(char *style_ref, XID xid)
{
window_style *nptr = all_styles;
window_style *next;
@@ -735,7 +735,15 @@
{
next = SGET_NEXT_STYLE(*nptr);
/* Check if it's to be wiped */
- if (!strcmp(SGET_NAME(*nptr), style_ref))
+ if (xid)
+ {
+
A Silent core dump
Hello, A get a core dump with the following function: AddToFunc CoreDump I Silent Move Then executing CoreDump in a FvwmConsole gives a core dump with the follwing gdb output: #0 __move_window (cond_rc=0xbfffef84, exc=0x81e93a8, action=0x81e939c , do_animate=0, mode=0) at move_resize.c:1321 1321w = FW_W_FRAME(fw); (gdb) where #0 __move_window (cond_rc=0xbfffef84, exc=0x81e93a8, action=0x81e939c , do_animate=0, mode=0) at move_resize.c:1321 #1 0x0806682b in CMD_Move (cond_rc=0xbfffef84, exc=0x81e93a8, action=0x81e939c ) at move_resize.c:1461 #2 0x080998b5 in __execute_function (cond_rc=0xbfffef84, exc=0x81e9308, action=0x81e93a8 M, exec_flags=128 '\200', args=0x81e939c) at functions.c:602 #3 0x08099d87 in __run_complex_function_items (cond_func_rc=0xbfffef84, cond=105 'i', func=0x1, exc=0x81e9308, args=0xb010) at functions.c:787 #4 0x08099fdf in execute_complex_function (cond_rc=0xb0ac, exc=0x81e5d98, action=0x81e9308 M, desperate=0x5) at functions.c:957 #5 0x0809993a in __execute_function (cond_rc=0xb0ac, exc=0x81e9240, action=0x81e5d98 M, exec_flags=0 '\0', args=0x81e92f8) at functions.c:621 #6 0x0809a53f in execute_function (cond_rc=0x0, exc=0x81e9240, action=0x81db168 CoreDump, exec_flags=0 '\0') at functions.c:1193 #7 0x08086171 in ExecuteModuleCommand (w=0, module=1, text=0x81db168 SF) at module_interface.c:693 #8 0x0808760e in ExecuteCommandQueue () at module_interface.c:1924 #9 0x08063cf7 in My_XNextEvent (dpy=0x80eb418, event=0xb360) at events.c:3500 #10 0x08063a52 in HandleEvents () at events.c:3297 #11 0x0808458c in main (argc=3, argv=0xb8a4) at fvwm.c:2433 #12 0x401fc082 in __libc_start_main () from /lib/i686/libc.so.6 CMD_Move is executed with no FvwmWindow as DeferExecution is stopped by silent but with (exec_flags FUNC_DONT_DEFER) true. I see various possible fix. However, Dominik, maybe you will prefer to fix this yourself? Regards, 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]
Core dump from __move_loop
I get the following core dump: #0 FCheckWindowEvent (display=0x80eb418, w=8389041, event_mask=32, event_return=0x0) at FEvent.c:330 330 *event_return = fev_event; (gdb) where #0 FCheckWindowEvent (display=0x80eb418, w=8389041, event_mask=32, event_return=0x0) at FEvent.c:330 #1 0x0808a9ae in HandlePaging (pev=0x0, HorWarpSize=1024, VertWarpSize=768, xl=0xbfffea0c, yt=0xbfffea10, delta_x=0xbfffea04, delta_y=0xbfffea08, Grab=0, fLoop=0, do_continue_previous=1) at virtual.c:533 #2 0x08067608 in __move_loop (exc=0x1, XOffset=-6, YOffset=-161, Width=522, Height=322, FinalX=0xbfffeeb8, FinalY=0xbfffeebc, do_move_opaque=1) at move_resize.c:2001 #3 0x08065b94 in InteractiveMove (win=0x1, exc=0x82113c8, FinalX=0xbfffeeb8, FinalY=0xbfffeebc, do_start_at_pointer=-6) at move_resize.c:1010 #4 0x080664d7 in __move_window (cond_rc=0xb0b4, exc=0x82113c8, action=0x822f304 , do_animate=0, mode=-161) at move_resize.c:1408 #5 0x0806682b in CMD_Move (cond_rc=0xb0b4, exc=0x82113c8, action=0x822f304 ) at move_resize.c:1461 #6 0x080998a5 in __execute_function (cond_rc=0xb0b4, exc=0x8211348, action=0x82113c8 E, exec_flags=128 '\200', args=0x822f304) at functions.c:602 #7 0x08099d77 in __run_complex_function_items (cond_func_rc=0xb0b4, cond=109 'm', func=0x1, exc=0x8211348, args=0xb140) at functions.c:787 #8 0x0809a158 in execute_complex_function (cond_rc=0xb1dc, exc=0x81e2bd8, action=0x8211348 E, desperate=0x6d) at functions.c:1080 #9 0x0809992a in __execute_function (cond_rc=0xb1dc, exc=0x81267f8, action=0x81e2bd8 E, exec_flags=0 '\0', args=0x81e7798) at functions.c:621 #10 0x0809a52f in execute_function (cond_rc=0x0, exc=0x81267f8, action=0x811dc70 FuncFvwmMoveOrRaiseOrShade, exec_flags=0 '\0') at functions.c:1193 #11 0x0806045c in __handle_bpress_action (exc=0x81267f8, action=0x811dc70 FuncFvwmMoveOrRaiseOrShade) at events.c:568 #12 0x080606ac in __handle_bpress_on_managed (exc=0x811dc70) at events.c:673 #13 0x08060745 in HandleButtonPress (ea=0xb314) at events.c:717 #14 0x080639b8 in dispatch_event (e=0xb360) at events.c:3261 #15 0x08063a70 in HandleEvents () at events.c:3299 #16 0x0808457c in main (argc=3, argv=0xb8a4) at fvwm.c:2433 #17 0x401fc082 in __libc_start_main () from /lib/i686/libc.so.6 I think I can fix it, but Dominik I think it is better that you fix it. Regards, 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]
Re: FwmIdent errors
On Wed, Apr 30, 2003 at 12:48:24AM -0400, Bob Woodside wrote: On Tue, 29 Apr 2003 17:48:54 -0400 Dan Espen [EMAIL PROTECTED] wrote: I run FvwmIdent with: *FvwmIdent: Back Black *FvwmIdent: Fore white *FvwmIdent: Font 9x15bold no problem here, but I missed the version you had the problem with. I don't get any errors running with current CVS. Aha! Do you by any chance also have a *FvwmIdent: Colorset n command...following the Back/Fore commands? That works. UpdateBackgroundTransparency is getting called from ProcessXEvent with a colorset of -1 if there is no colorset specified, or if Back/Fore are specified after the colorset. It just goes downhill from there. Yes, that's the bug. Is the intent that order matters (i.e., that Back or Fore should override a previously specified colorset), or that the colorset should override Back/Fore regardless of the order? (My current working copy implements the former precedence, but I'll change it to do the latter if that's the consensus.) I think that Back or Fore should override a previously specified colorset. Regards, 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]
