Re: [wmii] Re: Fwd: wmiibar2 ready

On Fri, Feb 10, 2006 at 08:39:43AM +0100, Stefan Tibus wrote:
> On Thu, Feb 09, 2006 at 06:20:01PM +0100, Anselm R. Garbe wrote:
> > sorry I have to regret my decision. I agree with Uriel that
> > wmiimenu does not need an fs interface at all. This is because we
> > separate font/color configuration into three env vars (only
> > exception will be wmiibar which will allow post-configuration of
> > those colors to other colors):
> I don't agree that this is such a good idea. It may not happen that
> often that somebody wants to change the colors of the running wm.
> But if I do so, I would like not to have to restart it and thus
> have to rearrange all my windows then.
> And actually in my opinion it is very inconsistent to have this
> runtime configuration option only in some part of the wmii-tools.
> Minimalism should not break a good and consistent design.

I agree and due to the merge with bar into the wm, we have the
color and font files again (because it is out of question that
the bar needs runtime-color configuration for notifications and
monitoring stuff for example). But for wmiimenu this is not
necessary, it'll use the env vars you set in wmiirc, because it
will be executed for each request.

> Hmm...what about wmiimenu and wmiibar then? Since I'm not coding
> on wmii, I don't know how much keyboard handling wmiiwm actually
> does, but everything I press on my keyboard goes either to wmiikeys
> or the running application. I believe you can always save on the code
> when putting everything together, but I thought wmii was meant to
> be modular. If you'd put everything together you could even skip a
> lot of the wmiifs stuff, but I believe this is not the way you want
> to go.

Modularization isn't dropped. We still have wmiir, wmiimenu and
wmiiwm. Also we have the new event mechanism which allows to
externalize various decisions which would be hardcoded in
classic WMs. The bar has its own namespace in wmiiwm fileserver,
same with the keys, thus from an interface POV they are still
modular and can be easily plugged off if it would make sense.

The question is, in which cases modularization is senseful. And
due the 9P integration I came to the conclusion, if the
functionality isn't spectacular enough to be driven by its own
9P service, it should not be modularized. If the functionality
is small enough to live without a 9P service and don't relates
in some kind to the tasks of an existing service, then separate
it. For bar and keys it wasn't worth the trouble to implement an
own 9P service for them, which additionally made wmiifs
necessary which is obsolete.

The hg tip contains a working environment already (floating only
and maybe pretty unstable), but you can try it and see youself
that I think my decision has been correct, see wmiirc for
example, we don't need to drop the config in one place concept,
wmiirc contains the event loop now).

I also look forward for wmiislot and feared the complexity for
synchronization issues if one supports dockapps. This slot would
also hardly work in a separate process, because only one
connection per screen can grab for SubstructureNotify events on
the root window, thus only one WM can run per screen - this is
an useful X limitation to protect the environment from nesting
into deep if you could run two WMs concurrently (then one WM
would win and reparent the frames of the other WM).

To summarize, the modular concept would consist of following
structure (compare that with the current model I favorize):

<controller> <wmiifs> <component>
                                                 wmii (xinit child)

keys --\ /--> wmiikeys
          | |
bar ---\ /----> wmiibar
           \ /
            --------> wmiifs -------
           / \
menu ---/ \----> wmiimenu
          | \
wm --/ \--> wmiiwm
        /
status /

Each controller would consist of two processes, the script
process itself and the wmiir process reading the associated
/event file, all in all 1+2*5+1+4=16 processes.
The amount of sockets was 5. The amount of connections in
average 5 (controller) + 5 (wmiifs) = 10.

The model which is implemented in hg tip looks as follows:

<controller> <wmii>
                                         wmii (xinit child)

wmiirc
     \
      ---------------------------------> wmiiwm
     /
status
                                         wmiimenu (temporary)

This is much simplier, and we only have two controllers which
means 1+2*2+1(+1)=6(+1) processes.
The amount of sockets is 1. The amount of connections in average
is 2.

Regards,

-- 
 Anselm R. Garbe  ><><  www.ebrag.de  ><><  GPG key: 0D73F361