[olpc-software] AbiWord, HIG

Jim Gettys jg at laptop.org
Thu Mar 16 02:57:48 UTC 2006 

On Wed, 2006-03-15 at 10:12 -0800, Alan Kay wrote:
> Hi Kim --
> 
> At 09:56 AM 3/15/2006, Jim Gettys wrote:
> >Firefox and Opera (and probably Safari, but I have no first hand data),
> >are much more capable of dynamic behavior than you probably realize.
> >                                 - Jim
> 
> Makes sense. However, too bad the minimal needed things (e.g symmetric 
> authoring as in all other personal computer software) were not done in the 
> early browsers. That was a complete lapse.
> 
> So perhaps the question is how to get around IE?
> 

Well, installing Firefox or Opera is one strategy: nicely cross
platform.

Google just bought Writely: this is an AJAX based WYSIWYG editor, and
similar (maybe less ambitious) editors are also being built for several
Wiki's even using the pretty lame IE subset technology.  Thankfully,
Firefox's success is forcing Microsoft to finally update IE as well.
Competition is good ;-).

Another interesting proof of what can be done is Zimbra; if you really
get your head around this stuff, one can build some really interesting
apps now.  It isn't quite ready to replace conventional toolkits, but
their days are numbered.
			- Jim

> > >
> > > I said a little more about what I think the larger problem is in a recent
> > > email to Rob.
> > >
> > > Cheers,
> > >
> > > Alan.
> > >
> > > At 08:25 AM 3/15/2006, Jim Gettys wrote:
> > > >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.
> > > >                                 - Jim
> > > >
> > > >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 at 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
> > > > everything
> > > > > > > being visible, but as the user learns can move to more subtle and
> > > > smaller
> > > > > > > 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
> > > > > >"usability".
> > > > >
> > > > > And this could be (should be) different as the end-user learns. It's
> > > > always
> > > > > pained me that so little learning curve is built into most of 
> > today's UI
> > > > > designs.
> > > > >
> > > > > >  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
> > > > instead
> > > > > 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.
> > > > >
> > > > > Cheers,
> > > > >
> > > > > Alan
> > > > >
> > > > >
> > > > > >Best,
> > > > > >Rob
> > > > >
> > > > >
> > > > > --
> > > > > olpc-software mailing list
> > > > > olpc-software at redhat.com
> > > > > https://www.redhat.com/mailman/listinfo/olpc-software
> > > >--
> > > >Jim Gettys
> > > >One Laptop Per Child
> > >
> > >
> >--
> >Jim Gettys
> >One Laptop Per Child
> 
> 
> --
> olpc-software mailing list
> olpc-software at redhat.com
> https://www.redhat.com/mailman/listinfo/olpc-software
-- 
Jim Gettys
One Laptop Per Child

More information about the olpc-software mailing list