On Sat, May 03, 2003 at 01:27:01PM +0100, Sonny Dawn-Hiscox wrote:
> Hi,
>
> I am a final year CS student at the uni of Manch. and I've got to know
> fvwm for my final project, I was not acquainted with it previously. I
> have created a new module that I called FvwmGamePort designed to handle
> I/O from a gamepad and attach some fvwm functionality to it.
>
> I was just wondering if anyone had any comments on a problem that I'm
> sure you're all aware of?
>
> I was controling the cursor by calling "CursorMove" but when I call a
> menu, the single-threaded design of fvwm will not allow me to continue
> manipulating the cursor...
Well, I think this functionalaty should not be application or
window manager dependent but in the X server itself. But I guess
this does not help you much :-)
> Does anyone have any thoughts on this matter?
> The project is finished, time-wise but I was just thinking that if there
> is a way of configuring fvwm to create a new instance of the GamePort
> module when a menu is called then maybe my project can be left open for
> development using some kind of notion of recursion??? What do you think?
We have talked about these issues several times. The menu code is
too interweaved with the rest of the code to be moved to a
separate process easily. The single threaded design causes big
problems with tear off menus, for example.
Fvwm is already partially recursive ("Wait" command), but all this
does not work well. The X server has no notion of recursive key
and button grabs, and the individual key and button events can get
lost between the layers of the recursion.
The problem could theoretically be solved if fvwm accepted module
input during manu operation. But it is already a maintenance
nightmare to keep track of the consistency of the various objects
in memory. For example, what happens if a module deletes the
window from which the menu was invoked? It's hard to prevent core
dumps here, even without module input. And if the invoked
function freezes the pointer, fvwm may hang completely. And the
module interface lacks the functionality to filter out module
input of various types and allow only input that is harmless at
the time.
> This problem also lead me to abandon dynamic reconfiguration for this
> module...
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]
