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