ui:initial brainstorming (window manager)

[Luka (Peter) <luka@mit.edu>]

Here's a few things to start discussion about the SEUL UI.
Some discussion on the UI actually started on the seul-dev-install list, so
I'll repost some quips from that here; check the archives if you need more
context on them.
Note that we'll be keeping the runtime and installer UI separate for now,
since basing the installer UI on the discussions of this group would get
nowhere fast.  To be precise, the installer group will be (for now) implemting
a UI independent of the one discussed here.  Discussing a UI here which is
applicable to the installer /as well/ as the runtime system would certainly
be relevant, but I will discourage it unless someone has a really impressive
idea, since I think that would be too large of a consideration to take as a
requirement at this time.
Keep in mind that generality is always a good thing, though, if nothing else
is at stake.  So, if possible, choosing a UI design that can be applied to the
installer as well as the runtime would be a good thing to aim for in the
end.  My own impression on this at the moment is that it /will/ be possible
if done by using a scalable abstract UI specification (e.g icons that can be
reused at different resolutions, non-dependence specifically on X/wm, etc),
since it can then just be scaled down to whatever level the installer is able
to support and still meet its own requirements on space and hardware issues.

================================

I'm going to start the theme of this discussion around that of the
_ Window Manager _.  There are many other issues relevent to UI that will
probably come up soon (such as the old topic of GUI toolkits), but I feel
like starting with some ideas that other ppl and I have had about window
managers under SEUL.  This should provide plenty of initial discussion space.


here's what jmunoz wrote:
>I was looking at window managers.  AfterStep, Enlightenment, and K all
>caught my eye.  Olvwm was not the coolest, but not bad looking.  I used
>to use it. Enlightment seemed way cool, but too narrow in it's cult
>appeal, non standard shape libs, etc.  It will not seem businesslike. 
>It looks like an extremely cool time waster.  The other ones, although
>slick as spit, still seemed work oriented, nicer that windows, etc. 
>These are impressions.  What we really need to do is list our 
>requirements.  Here are mine, in descending order of importance.  Use
>the best, standard, freely available libraries available (If there is a
>market leader, bugs will be fixed sooner).  Very few bugs. Good
>security. Interoperability/supported by many packages, Cool features,
>including most of: (wallpaper, 3d widgets, drag -n- drop, CDE style
>virtual desktop, color gradients), decent performance, support for many
>colors 8/16/24/32 bit would be nice, both focus policies, good
>xterm/color xterm, etc.     

response from kai wetzel:
>> I was looking at window managers.  AfterStep, Enlightenment, and K [...]
>
>While I still use FVWM2 ;) I think WindowMaker is the nicest
>(if we consider e somewhat 'special') and the one with the
>fastest development cycle currently.  WindowMaker isn't stable
>enouhg for a "default" WM but I have the impression that it'll
>be there when SEUL ships.
>
>> Olvwm was not the coolest, but not bad looking.
>
>This waas my first impression of X and it was a very
>nice impression.  I think some anti-aliasing of the
>round menu and button edges as well as a nice raytraced
>pin would have been a significant improvement, though.
>
>[...]
>> What we really need to do is list our requirements.
>
>E.g. looking at one of them and ask "What's lacking ?"
>
>I think it would be cool to provide a default WM (candidates
>would IMO be: WindowMaker, AfterStep, and FVWM95) as well
>as offer quite a lot of auto-configured alternatives as we
>proceed.  I think switching WMs on the fly is one of the
>cool features of X which people who like to try new stuff
>will like.  think of the success of the '95 themes :)
>
>As another idea, it would be nice to have a meta-window-
>mamager.  This would be an app which pops up a little
>selection dialog when you hold down "shift" when X comes up.
>Otherwise, the default WM would be started (the default could
>be configurable).  So if you don't care about the WM, it doesn't annoy
>you :-)

my responses:

I'm not sure if I've mentioned this before (or maybe someone else did), but
what I think we want as a general policy for SEUL's wm is to have one primary
"SEUL window manager", which may be an existing wm or a hacked one that we
officially fully support and use as our default, but in addition we should
still allow the the user to switch to whatever wm he likes best, understanding
that he may not get all of the cutting-edge SEUL improvements.
I'll use SEULwm from here on to refer to that primary wm, though what wm it
is has yet to be determined.  We may also support 1 or 2 "seconday" wm's,
basically to keep up with trends.  e.g. fvwm95 is pretty dreadful from the UI
design perspective, but it's also pretty popular, so I would be inclined to
NOT use fvwm95 as SEULwm, but since a lot of people will want to run it, we
should probably list it as a secondary, which means we'll make sure SEUL runs
reasonably well with it (almost, if not completely as well as with the primary
SEULwm)

Having a "standard" window manager(s) of our choice like this gains us two
things:
1. We can place a bound on required testing of SEUL.  If we just say "use
 whatever wm you want", there's no way we'll get SEUL out the door and have
 it thoroughly tested (it would even be debatable whether testing with
 something like nawm (not-a-window-manager; the one i use), or no wm at all
 would be a legitimate concern).
2. We can have full conctrol over the wm-provided part of the interface at
 least under SEULwm, and having this kind of control is important if we want
 to end up with a good, robust, total UI solution for the end-user.  We can
 also (hypothetically) take the liberty of hacking SEUL extensions directly
 into that wm, though we should think carefully when doing so about its
 implications.  (There's not much to analyze in the general case, though if
 a specific extension idea comes up, expect some serious discussion of its
 exact impacts.)

Note one ambiguity that will need to be nailed down is exactly how far we'll
take the statement, "We support SEULwm.  You can use something else, but you
might lose."  How much are we willing to make the system dependent on the
presence of SEULwm, and are there actually exteme opposite cases where we might
even be willing to say the system is allowed to /fail/?  I think we want to
avoid /failure/ in the case of any common non-SEULwm, or lack or any wm (since
the system may need to fall back to this state, and failing if it happens
would be blatantly fragile behavior), but the issue of whether failure is ok
if the user runs some bizarre, non-standard wm is open for debate.

*** So, any views so far on whether this is a good approach (SEULwm fully
supported; other wm's "allowed")?  Philospohical thoughts on how far we're
willing to go with SEULwm-specific extensions?  Specific reasons we would
want to limit extensions dependent on SEULwm?  And how badly are we willing
to let SEUL break in the absence of SEULwm (and why)?

Assuming we take the above approach (or anything close to it), we'll need
to decide what wm to take and possibly hack to get SEULwm.

A comment on ol[v]wm: That wm was actually originally designed with the goals
we have in mind: generating a uniform, user-friendly interface with minimal
user-oriented design effort from app developers.  Of course, the fact that
Sun abandoned the project I think signals something of what our attitude
toward it should be also...  I personally don't think the final look of olwm
turned out nearly as well as it "should" have.  Lots of little things should
be done more nicely.  It seems to me that the task of enforcing ideal layout
constraints, etc purely through writing an entirely new window mgr was too
large of an undertaking.  I'm of the opinion that this sort of control should
happen at the level of an gui toolkit/library (or RAD tool, if you take it
that far and like the buzzword), and I expect we'll hear more about that
concept soon.  Given that, ol[v]wm loses quite a bit of the luster that was
originally intended to go into it, and I don't think it's actual appearance
is that hot...
*** dissenting opinions?

My own choice for SEULwm would be fvwm(2), potentially hacked a bit, but I
don't have a whole lot reasons for that to be the case.  Among the wm's I've
tried, fvwm tends to be stable, not too heavy computationally, reasonably
configurable, and generally not-too-shabby-looking.  But note that I have not
dug into it's (or any wm's) code/config too deeply, so someone else can
probably offer a more expert opinion on this matter, and I haven't tried many
window managers overall (less than 10 I think).  In particular, I don't know
a thing about WindowMaker.  Since Kai gave this a thumbs up, I'd like to know
a lot more about it.  Could we have some pointers to info/sources?  And if
you've tried it, impressions would be good to hear.
*** Input on this?

Last thing (which I kind of implied in various places above) is that we will
have some general requirements specs for our choice of wm, which we need to
meet.  jmunoz mentioned a few potential ones, all of which I think are good
ideas.  Rather than spewing my own list of req's now, I think I'll just stop
(this is getting too long anyway), and let other ppl throw out some ideas on
this first.  What are features that we want our window manager to have?  Note
that this includes obvious graphical features (such as level of color support,
virtual screen support (and the interface to the virtual screens), support
for icons on desktop?, etc), as well as performance requirements (it really
/should/ be able to run on a 486/16M at more than one refresh/minute.... and
our requirement should prob be a lot tighter than that), and anything else
you think of....
*** So, if you have any thoughts on what should/shouldn't be on the
 requirements list (and WHY), let us know....
 This can also extend to a separate thread on general UI requirements,
 if you have some thoughts in that area...

-luka, wearing my UI hat.

=====-----------------------------------------=====
 Peter Luka            ...            luka@mit.edu
 SEUL Project development leader/systems architect
               http://www.seul.org
-----=========================================-----