Ah, Alan, sounds like you can join the long line of X Window manager
writers. All the titlebars and decorations for manipulating windows are
generated by the WM, and not the application. Anything you can imagine
should be possible with some work; it isn't buried in the base system
where it is difficult to change. Fundamentally, this is one of the real
innovations that we did with X, very different than other window systems
of the '80s (including yours ;-)); window management is left to external
applications and not hard-wired.
While window manager wars have been unproductive, the ability to swap
out window management policy also enabled X to survive and for desktops
such as Gnome and KDE to be built many years after X11 was released.
In fact, the early X Window managers had no stink'n title bars at
all ;-), and were mostly driven by "control-shift-meta-cokebottle"
keybindings; until X11, we couldn't even do titlebars and controls in
the window managers.
P.S. for those young turks here, it turns out that some keyboards at MIT
really did have cokebottle keys in that era, though we never actually
used them in window management. :-).
On Wed, 2006-03-15 at 07:09 -0800, Alan Kay wrote:
> At 06:32 AM 3/15/2006, Robert Staudinger wrote:
> >On 3/15/06, Alan Kay <alan kay squeakland org> wrote:
> > > Just curious ... why is a lot of real estate still being taken for
> > > non-content items?
> >Please explain, what do you mean by "non-content items"? That the
> >toolbar is too big?
> I like to give the end-users the largest possible space for their own
> content. So the UI question is how can we then make it easy to understand
> and use the controls and tools without killing off the content space? E.g.
> is there a more compact way to show the title of the doc without
> permanently taking away vertical real estate (we don't need to know very
> often, but would like to know without having to invoke a command)? Perhaps
> alpha blending would work for this part of the UI?
> There are many other ways to provide access to controls -- e.g. William
> Newman at PARC used a kind of overlay scheme that worked quite well.
> I'm mainly suggesting that more ideas be tried here.
> > > There are very likely more compact solutions that start out with
> > > being visible, but as the user learns can move to more subtle and
> > > cues and access. Also, the chip set can do alpha blending, and we've
> > > experimented with using that to overlay some of the UI, etc.
> >Sure, this stuff is just quickly thrown together. Of course a balance
> >has to be found between optimal utilisation of available space and
> And this could be (should be) different as the end-user learns. It's
> pained me that so little learning curve is built into most of today's UI
> > Also I've been told in #olpc that colour and b/w screen
> >resolutions are different, prolly that should be taken into account as
> >well (maybe also a fullscreen/viewer mode for reading). All these
> >factors multiply to a considerable number of "modes" which i'm not
> >very happy about (in terms of development effort and UI complexity).
> I certainly don't like modes ...It's possible to avoid modes *and* still
> have full screen viewing. This should be a goal in general, and especially
> on a small screen
> >I'd be very interested learning more about the graphics capabilities
> >of the machine.
> Right now it has a HW bitbltter with alpha, so quite a bit can be done.
> >Maybe some UI parts could be implemented in a scalable
> >way using librsvg (if that will be available, it drags in cairo which
> >was avoided for the n770).
> I haven't heard the recent thoughts about Cairo, but it certainly was (and
> probably is) part of the proposed system.
> >I've also written the first few lines of a gtk engine with the goal of
> >implementing something like
> >http://ramnet.se/~nisse/diverse/temp/kidsthememock2.png - might be
> >appealing for kids too. Unfortunately cairo based engines are quite
> >slow ATM.
> I don't want to foment strife here, but I've always thought that
> applications are bad ideas -- they tend to stovepipe useful objects
> of providing a playground to mix, match and make them. This is especially
> true for a children's environment.
> > Good start ... I encourage you to continue with more and different
> > > experiments ...
> > >
> > > P.S. Can AbiWord take plugins (like a LOGO) that could manipulate its
> > media?
> >AbiWord's plugin system exports pretty much the whole internal API.
> >Missing stuff can be hooked up without much effort.
> This could be one route for the integration of media and scripting that
> children need.
> olpc-software mailing list
> olpc-software redhat com
One Laptop Per Child