Re: Menu invoked by FvwmButtons causes a restart
On Sat, Jul 06, 2002 at 05:00:21PM +0930, Alex Wallis wrote: With current cvs if I issue the following command in an FvwmConsole... Style * Font shadow=2 3 SE:xft:Luxi Mono:Bold:pixelsize=14 ...then click on an FvwmButtons to invoke any menu it causes fvwm to restart. The above command also resets all window styles such as TitleAtLeft etc... Don't use current cvs. There is a core dump in Flocale.c for me. If you downgrade that file to the version from two days ago it works fine. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * FvwmAuto handles M_ENTER/LEAVE_WINDOW too (see man page).
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/07/06 10:40:22 Modified files: . : NEWS fvwm : events.c modules: ChangeLog modules/FvwmAuto: FvwmAuto.1 FvwmAuto.c Log message: * FvwmAuto handles M_ENTER/LEAVE_WINDOW too (see man page). -- 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]
reson module pipe deadlock, need some help
Okay, this is why busy modules using synchronized messages can run into a deadlock with fvwm: take for example FvwmEvent with the sync'ed M_DESTROY_WINDOW message. 1) When a lot of things are going on on the desktop (many X events are coming in), fvwm handles all of them and puts the module messages into the module queues (PositiveWrite()). 2) Now that we have a long message queue for our module, an event arrives that triggers a synchronized module message. In the case of FvwmEvent, a dying window triggers a M_DESTROY_WINDOW message. 3) The new message is added to the queue via PositiveWrite(). Afterwards, fvwm looks at the packet type and sees that the module requested synchronized transmission and goes into the part dealing with synchronization. 4) Next, FlushMessageQueue(module) is called. This function spits the data into the module pipe at full speed - and because the queue is so large, it pipe gets finally full and the next write() call returns EWOULDBLOCK or EAGAIN. 5) FlushMessageQueue stops writing data and simply returns. Result: fvwm entered the sync'ed code branch and waits for the unlock message from the module. But because the pipe is full, the M_DESTROY_WINDOW message that needed synchronization in the first place is never sent. The module simply waits for further input that never comes since fvwm waits for the unlock message. What do we do about this? Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS olicha: * Removed some randomly commit code in Flocale
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: olicha 02/07/06 14:27:35 Modified files: . : ChangeLog libs : Flocale.c Log message: * Removed some randomly commit code in Flocale -- 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: core in Flocale.c
On Fri, Jul 05, 2002 at 03:25:29PM +0200, Dominik Vogt wrote: It happens every time w/ the last Flocale.c commit. All data structures look sane. Probably the flf-fontset structure is broken. Yes, I've committed some unwanted test code. Is it ok now? Sorry, 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]
CVS domivogt: * Tried to fix module deadlock by adding a retry logic to FlushMessageQueue.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/07/06 15:17:17 Modified files: . : ChangeLog fvwm : module_interface.c libs : Strings.c modules/FvwmEvent: FvwmEvent.c Log message: * Tried to fix module deadlock by adding a retry logic to FlushMessageQueue. * Cleaned up FvwmEvent synchronization code. * Re-indented Strins.c. -- 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: reson module pipe deadlock, need some help
On Sat, Jul 06, 2002 at 09:12:50PM +0200, Dominik Vogt wrote: Okay, this is why busy modules using synchronized messages can run into a deadlock with fvwm: take for example FvwmEvent with the sync'ed M_DESTROY_WINDOW message. 1) When a lot of things are going on on the desktop (many X events are coming in), fvwm handles all of them and puts the module messages into the module queues (PositiveWrite()). 2) Now that we have a long message queue for our module, an event arrives that triggers a synchronized module message. In the case of FvwmEvent, a dying window triggers a M_DESTROY_WINDOW message. 3) The new message is added to the queue via PositiveWrite(). Afterwards, fvwm looks at the packet type and sees that the module requested synchronized transmission and goes into the part dealing with synchronization. 4) Next, FlushMessageQueue(module) is called. This function spits the data into the module pipe at full speed - and because the queue is so large, it pipe gets finally full and the next write() call returns EWOULDBLOCK or EAGAIN. 5) FlushMessageQueue stops writing data and simply returns. Result: fvwm entered the sync'ed code branch and waits for the unlock message from the module. But because the pipe is full, the M_DESTROY_WINDOW message that needed synchronization in the first place is never sent. The module simply waits for further input that never comes since fvwm waits for the unlock message. What do we do about this? I tried to fix it by adding another fvwmSelect call in FlushMessageQueues() that waits for the write pipe to accept further input. I'm not sure if I've done this right. Could someone with a better knowledge of pipe communication please take a look at the patch? I'm quite sure the select call is correct, but I'm not sure that how the code reats to errors is right and that it's ok to always retry writing. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- 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/902
On Fri, Jul 05, 2002 at 12:54:59PM -0500, fvwm-bug wrote: FVWM Bug Tracking notification new message incoming/902 Full_Name: Wesley Tanaka Version: 2.2.5 CVS_Date: OS: RedHat 7.2 X_Server: XFree86 version: 4.1.0 Submission from: (NULL) (209.246.29.222) I am using comicscartoon from the sharefonts package ftp://rpmfind.net/linux/contrib/noarch/noarch/sharefonts-0.10-9.noarch.rpm as my titlebar font by including the following line: WindowFont -*-comicscartoon-*-*-*-*-14-*-*-*-*-*-*-* in my .fvwm2rc file. In fvwm2 version 2.2.4, the font was displayed correctly. However, when I upgraded to version 2.2.5, the font was instead silently replaced with a different font. The comicscartoon font was still loaded on my system -- when I tried to do an xfontsel -pattern -*-comicscartoon-*-*-*-*-14-*-*-*-*-*-*-* the correct font displayed in the window. Please upgrade to the latest stable fvwm release (2.4.8). We have done a lot of work related to the parsing of fonts. You should not encounter this problem anymore. If the problem persits, please report back. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Workaround for tkdiff menu positioning problem.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/07/06 16:07:32 Modified files: . : ChangeLog fvwm : add_window.c events.c Log message: * Workaround for tkdiff menu positioning problem. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Workaround for tkdiff menu positioning problem.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/07/06 16:07:57 Modified files: . : Tag: branch-2_4 ChangeLog NEWS fvwm : Tag: branch-2_4 add_window.c Log message: * Workaround for tkdiff menu positioning problem. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Patch for wish/iconify/deiconify problems.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/07/06 16:37:14 Modified files: . : ChangeLog fvwm : events.c Log message: * Patch for wish/iconify/deiconify problems. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
CVS domivogt: * Missing NEWS.
CVSROOT:/home/cvs/fvwm Module name:fvwm Changes by: domivogt02/07/06 16:38:07 Modified files: . : Tag: branch-2_4 NEWS Log message: * Missing NEWS. -- 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: problem with TkDiff menues
Hi Dominik, I've committed a workaround in both, the stable and the development branch (simply send a ConfigureNotify event with the correct window position to the application). yes, it works fine again now. Thanks a lot ! This should be fixed in TK and/or tkdiff. Could you please file a bug report there? sure ! Cheers, Giuseppe. -- 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]
FVWM: Some problems
Hi, I am experiencing some problems with both FVWM 2.5.2 and the snapshot of 20020704. However, i'm not sure if these problems are due to fvwm or to other apps. First of all, when i add the line FontPath unix/:7101 to my XFree config file (to be able to use my truetype fonts), and i try starting fvwm, i only get an hourglass, and nothing happens. Removing the line, starting fvwm, and then using xset fp+ unix/:7101 to use xfstt seems to work fine. Another problem i am coping with, even with older versions of fvwm, can be seen on http://spike.ulyssis.org/tmp/snap.png When i move my mouse pointer quickly over the menu items, there seems to be a 'refresh' problem, leaving some blue spots of my highlight rectangle near the right arrows. The problem doesn't occur with XFree 3.3.6. Does anyone know what might cause these problems ? thanks, Remko PS: I run Debian (unstable) with XFree 4.1.0 and xfstt 1.2.1. -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FVWM: Problem with xmms - shaped window
Hi there, I realized a strange behaviour using xmms which uses a shaped window in version 2.5.1. xmms provides an option double size which shows the window zoomed in double size. If I start xmms in normal size mode and provide this option afterwards the contents of the window are zoomed but the window size remains the same which looks very weired and is quite use less. If I start the window in double size I can switch form double size to normal size and from normal size to double size without this strange behaviour. I put a screenshot on the web: http://www.tu-chemnitz.de/~uwp/download/xmms_problem.jpg to make it clearer. The problem does not occur with version 2.4.6 but it occurs as well which version 2.5.1 even if shaped support is disabled (configure option --disable-shape). Any hints. Uwe -- +-- | Uwe Pross | mail : mailto:[EMAIL PROTECTED] | www : http://www.tu-chemnitz.de/~uwp +-- Have a nice day ;-). --- -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Some problems
I am experiencing some problems with both FVWM 2.5.2 and the snapshot of 20020704. However, i'm not sure if these problems are due to fvwm or to other apps. Sorry about my last post, the errors i described don't occur in the snapshot any more. I just loaded the wrong version. Also, i should have used the bug tracking system instead of mailing it here. Sorry about that. cheers, Remko -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Automatically raise certain windows on mouse enter, flickering of windows and widgets
Hi there... Comments below, again: On Sat, Jul 06, 2002 at 03:28:09AM +0200, Dominik Vogt wrote: On Sat, Jul 06, 2002 at 01:46:42AM +0300, Tom Alsberg wrote: snip / The problem is not only with gv. The whole problem of flickering is still there, including the problems with buttons in GTK+ applications, Netscape toolbar, borders of some windows being automatically raised like XClock and FvwmIconMan, FvwmPager balloon titles, etc. I only gave gv as an example which always shows the problem. Unfortunately, the gv problem I saw had little to do with flickering. If other apps have this problem, I need more examples. Well, there are other examples, like I noted, with GTK+ buttons, Netscape toolbars, balloon titles in FvwmPager... And sometimes windows being automatically raised (e.g. FvwmButtons) start flickering - getting raised and lowered over and over again frequently in a short time... I do not have exact tests for those examples, though, as they do not always happen - only once in a while... But if you use this setup for a while, with some activity with automatically raised and lowered windows, then you'll probably see it a few times. I do not see why gv trying to grabbing the pointer should be a problem, especially that other window managers (e.g. CTWM) have such a feature (automatically raise and lower) which doesn't cause those problems. I don't see exactly why FVWM should grab the pointer for that. Because fvwm is executing a complex function. I would ask now - why does this have to be a complex function? Couldn't it be, instead of a complex function, just some AutoRaise/AutoLower style? The pointer is always grabbed during function execution (and has to be to prevent funny and hard to debug problems). Don't forget we're not using well tested, documented features here. After all, using enter and leave events is a real hack (and *slow*). By enter and leave events, do you mean events of FVWM (FvwmEvent), or events in the level of X? After all, FVWM does a lot of things on enter and leave, including focus, changing window styles, etc etc. If we are talking about X events here... Then, well, I find it hard to believe that it is not well tested and documented... As it is used a lot and seems to have not principle problems... Also, why a real hack (and *slow*)? Moving the pointer across the desktop can trigger dozens of enter and leave events. snip / This really sounds like a sub-optimal specific workaround for me. Couldn't this problem be fixed? No. Complex function = pointer grabbed. Again, why do automatically raising and lowering have to be implemented using a complex function? Any application that is stupid enough to not retry grabbing the pointer when it's needed and unlucky enough to try it at the wrong time has a problem. Correct fix = fix gv. Well, might be... But, well... I still find this a bit weird, considering that some other window managers handle that quite well, also with gv... And, as I said, the problem is not only with gv... gv is just a test that always shows the problem. I am not enough of an expert in X11 to tell exactly... But since other window managers, like CTWM (I keep giving it as an example because that's one I used lot beside and before FVWM) have this function (auto-raise and auto-lower) working fine, without flickering, and not causing problems with pointer grabbing with gv, I suppose that could be done with FVWM too... Sure. Use FvwmAuto. Of course you'd have to switch to SloppyFocus or MouseFocus and lose ability to enable the feature only for selected windows. I tried FvwmAuto for that, and those were exactly my problems... I do have my focus following the pointer, except windows which have the ClickToFocus style enabled... And mostly, those are the windows I want to automatically raise and lower... That was what my first post on this subject (back near the end of 2001) was to say... That I need a bit more than FvwmAuto can do, at that time... Couldn't there just be added two styles - AutoRaise and AutoLower, which would do that, and just that, and do it simple without flickering and problems, needing scheduling and the like? That would just move the problem into the fvwm core. Why would it? If the problem is that FVWM grabs the pointer in a complex function, than be it a simple style, and some of it is solved already... CTWM might also have an auto-raise feature, but I bet it's based on *focus* changes too and not on the pointer entering or leaving the window. No, actually it is based on the pointer entering and leaving the window... As I said, that was one thing that CTWM did just well, fine without problems as I expect it... It's much easier to code, but it doesn't work with ClickToFocus. By the way, what is actually the big difference for that matter between the mouse entering the window and the window getting focus? Originally you said that it is a
Re: FVWM: Problem with xmms - shaped window
On Sat, Jul 06, 2002 at 12:07:08PM +0200, Uwe Pross wrote: Hi there, I realized a strange behaviour using xmms which uses a shaped window in version 2.5.1. xmms provides an option double size which shows the window zoomed in double size. If I start xmms in normal size mode and provide this option afterwards the contents of the window are zoomed but the window size remains the same which looks very weired and is quite use less. If I start the window in double size I can switch form double size to normal size and from normal size to double size without this strange behaviour. I put a screenshot on the web: http://www.tu-chemnitz.de/~uwp/download/xmms_problem.jpg to make it clearer. The problem does not occur with version 2.4.6 but it occurs as well which version 2.5.1 even if shaped support is disabled (configure option --disable-shape). Upgrade to the latest xmms release. Versions prior to 1.2.4 are *very* buggy in their window handling. The latest release works fine. Bye Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: FVWM: Automatically raise certain windows on mouse enter, flickering of windows and widgets
On Sat, Jul 06, 2002 at 03:02:01PM +0300, Tom Alsberg wrote: On Sat, Jul 06, 2002 at 03:28:09AM +0200, Dominik Vogt wrote: On Sat, Jul 06, 2002 at 01:46:42AM +0300, Tom Alsberg wrote: snip / The problem is not only with gv. The whole problem of flickering is still there, including the problems with buttons in GTK+ applications, Netscape toolbar, borders of some windows being automatically raised like XClock and FvwmIconMan, FvwmPager balloon titles, etc. I only gave gv as an example which always shows the problem. Unfortunately, the gv problem I saw had little to do with flickering. If other apps have this problem, I need more examples. Well, there are other examples, like I noted, with GTK+ buttons, Netscape toolbars, balloon titles in FvwmPager... But what *are* the problems? I'm not a psychic. And sometimes windows being automatically raised (e.g. FvwmButtons) start flickering - getting raised and lowered over and over again frequently in a short time... I do not have exact tests for those examples, though, as they do not always happen - only once in a while... Then please try to pin it down. I have no such problems with the functions. But if you use this setup for a while, with some activity with automatically raised and lowered windows, then you'll probably see it a few times. Uh, but I won't. I hate auto raising. I can't use my desktop with it. :-) I do not see why gv trying to grabbing the pointer should be a problem, especially that other window managers (e.g. CTWM) have such a feature (automatically raise and lower) which doesn't cause those problems. I don't see exactly why FVWM should grab the pointer for that. Because fvwm is executing a complex function. I would ask now - why does this have to be a complex function? Couldn't it be, instead of a complex function, just some AutoRaise/AutoLower style? Well, what would you win with that? You'd still need a complex function to select the windows to use. No. Either you give up most of the flexibility or you have to use complex functions. The pointer is always grabbed during function execution (and has to be to prevent funny and hard to debug problems). Don't forget we're not using well tested, documented features here. After all, using enter and leave events is a real hack (and *slow*). By enter and leave events, do you mean events of FVWM (FvwmEvent), or events in the level of X? It's roughly the same. After all, FVWM does a lot of things on enter and leave, including focus, changing window styles, etc etc. Yes, but it *does not* restack windows triggered by these events. That's the one thing that does not work If we are talking about X events here... Then, well, I find it hard to believe that it is not well tested and documented... As it is used a lot and seems to have not principle problems... Let me explain. You probably think that one EnterNotify event is sent when a window is entered and one LeaveNotify event when the window is left. But that's not true. Let's assume we have two overlapping windows A and B. The most simple case would be windows without any children. In fvwm, the visible window still consists of a lot of sub windows: The top level window (frame), the Wparent window which contains the client window, and more than a dozen decorative windows. Let's assume the pointer is in the client window of A and is moved across the title bar into window B: - pointer moves into the titlebar of A Events: leave client A leave parent A enter title window A - Pointer moves into the border of A Events: leave title window A enter border A - Pointer moves directly into the client window of B. Events: leave border A leave frame A enter frame B enter parent B enter clent B And it get's much worse if pointer grabs are considered: when an application grabs the pointer, it can specify a grab context window. For example, if you open a menu (by a key stroke), the client, parent and frame of B are left and the menu window is entered, *even* if the pointer is not over the menu. The reverse events occur when the grab is released (leave menu, enter frame/ parent/client). The old window even gets enter events if the pointer is no longer over it - immediately followed by the usual leave events and the enter events on the new window hierarchy. (BTW, this grabbing issue is what makes the gv zoom window vanish: the pointer is grabbed by fvwm == zoom window receives a leave event and closes. It should ignore events triggered by grabs). Also, why a real hack Because the typical fvwm user won't be able to use this feature in a sensible way. You have to have a lot of experience in X programming to use it. Just look at me: I've been hacking fvwm for four years and know X event handling very well and I still can't easily come up with a good solution. (and *slow*)? Because
Re: FVWM: OpaqueMove... not enough! ;)
OpaqueResize style (that I know of)? OpaqueMove is nice, but I really I'm sure they can work on it. In the mean time, try out Style ResizeOpaque ;-). Andy -- Visit the official FVWM web page at URL: http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
