[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [olpc-software] AbiWord, HIG



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?

Cheers,

Alan



>
> 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 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 redhat com
> > > https://www.redhat.com/mailman/listinfo/olpc-software
> >--
> >Jim Gettys
> >One Laptop Per Child
>
>
--
Jim Gettys
One Laptop Per Child



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]