Subject: Extending Fvwm

From: Sonny Dawn-Hiscox <[email-masked]>
Date: Sat, 03 May 2003 13:27:01 +0100

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...

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?

This problem also lead me to abandon dynamic reconfiguration for this
module...

Thanks all,

Sonny
--
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-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 3 May 2003 14:05:34 +0000

> development using some kind of notion of recursion??? What do you think?

Yes, you can't control cursor when internal menu is open unless you
change the core code. Moreover, the module messages are not processed
until a menu is closed.

So, if you still want to use menus, you should use external menus. For
example create GTK menus using FvwmGtk (I think GTK does not lock cursor
when a menu is open, but you should check this). Or use FvwmButtons to
create something similar to a menu:

  *FvwmButtons-GamePortMenu: (Title "line 1", Action "command 1")
  *FvwmButtons-GamePortMenu: (Title "line 2", Action "command 2")

Of course, I guess the whole idea is to support gamepad controls in the
internal menus... I don't think there is a way currently.

> This problem also lead me to abandon dynamic reconfiguration for this

I think this may be solved, but you may need an adequate GUI for this.
Probably you may solve this using dynamical FvwmButtons configuration,
but I can't say anything concrete since I didn't see the requirements.

BTW, any way to read the FvwmGamePort man page?

Regards,
Mikhael.

---

From: [email-masked]
Date: Sun, 4 May 2003 19:08:27 +0200

> 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 :-)

> 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

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]