Subject: future of fvwm development

From: [email-masked]
Date: Wed, 27 Nov 2002 20:40:12 +0100

I am writing this to sour out my thoughts.  Should you feel the
urge to reply, *please* reply to the mailing list, not to me in
private.

--

This is my view of the current state of affairs:

 Fact 1: Fvwm maintenance and looking after the mailing lists eats
         up the majority of my time available for fvwm work.  My
         inbox is notoriously overflowing (> 400 mails right now)
         and I long begun avoiding to read email at home because
         of the sheer amount of open bug reports that have to be
         resolved before moving on to developing.

 Fect 2: I feel like I am doing all the maintenance alone.

 Fact 3: I am becoming very frustrated by fvwm's design - or
         better: the absence of a design.

 Fact 4: I am very frustrated by our inability to write something
         usable and ituitive, not just powerful.  

 Fact 5: I begin to hate the time spent with fvwm development.

Please do not argue with me about these facts - that is what I
think.

--

Apart from other obvious conclusions I could draw from above
facts, I am toying with the thought of starting a new project that
combines the virtues of fvwm (lean, fast, flexible, modular) with
a solid design that somewhat resembles the idea of a policy free
microkernel as in Hurd.

The bare kernel would tackle only the most basic tasks like
sending and receiving events, providing a generic event interface
to the various extensions, relaying messages between the
extensions.  It might not even be aware of the windows.

Anything else would go into the extensions.  Some examples are:

 - Managing Xlib calls.
 - Managing the window structure.
 - Layout of window reparenting structure.
 - Layout of window decorations.
 - Handling of icons.
 - Font handling.
 - Handling X events.
 - Handling various hints (GNOME, EWMH, OpenView, XWM...Hints)
 - Command language shell.
 - Modules (pager, window lists etc.).
 - Moving windows.
 - Resizing windows.
 - Handling the input focus.
 - Menus.
 - Managing permissions.
 ...

The idea is that everything that happens in the wm is translated
to a kind of internal event and sent to the core.  The core
relays the events to the appropriate extensions so that they can
do whatever is appropriate.

None of the extensions are mandatory.  For example, if you do not
want window decorations and menus, you just do not load the
corresponding extensions.  The bare core does little more than
relaying events, defining the event types and informing X that a
window manager is running.  By the design of the iterfaces
(extensions do not know about each other) any extension can be
omitted or exchanged by a different one implementing a different
policy.  For example, there can be a number of extensions handling
window placement policies.  This allows to run the window manager
as a minimal program that just distributes the input focus among
the windows, or in mega-bloat-mode, loading every possible
extension.  Unused extensions do not even need to be compiled.

Other core ideas:

 - There is no module interface.  Modules are just normal
   extensions.
 - There is no built-in configuration language.  A command shell
   can be implemented to translate syntax into events.
 - There is no more distinction between window styles and states.

Some consequences of the design:

 - The source of the events is transparent to the extensions.
   Thus, the flow of events could be recorded and replayed later
   without the window manager even noticing.  A simple /bin/sh
   script could move and resize windows as the user would with the
   mouse, or provide EWMH icon hints, or cause windows to redraw
   by faking X events etc.
 - The client generating input can be chosen freely.  In this
   respect, there is no difference between keyboard shortcuts,
   menus, "modules", a shell or perl script, the X server, and so
   on.
 - Any event source can be controlled in detail.  It is easy to
   distinguish between requests from the program, a user action,
   a default "style" provided by the user etc.  It is equally easy
   to control which action is allowed and which isn't.

Some problems to solve:

 - Efficient core-extension and extension-extension communication.
 - Dynamic loading of extension hierarchies.
 - Dynamic management of window, desk, menu and other structures.
 - Dynamic extension of the command shell/command language.
 - Hiding the X server from the extensions.
 ...

--

Any comments are welcome, as long you do not try to talk me into
anything.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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]