Re: Framebuffer version of Abi ?


Subject: Re: Framebuffer version of Abi ?
From: Paul Rohr (paul@abisource.com)
Date: Thu Mar 09 2000 - 11:59:59 CST


At 03:40 AM 3/9/00 PST, ArcadePreserv Center wrote:
>Would it at all be possible to port AbiWord to Linux, using only the
>frambuffer for output? (Which would make it possible to have a full
>wordprocessor with very few MB HD space).

In theory, yes, but it might be a *lot* of work.

AbiWord was designed to take advantage of the types of desktop services
typically offered by any modern GUI operating system, such as:

  - 2d graphics and font-handling,
  - image blitting and stretching,
  - overlapping windows,
  - dialogs,
  - toolbars,
  - pop-up menus,
  - multi-button mice,
  - keyboard input methods,
  - etc.

The preceding list is not comprehensive, but helps suggest the kinds of
assumptions made by our XP (cross-platform) code. As you probably know, we
already have ports underway for the following platforms:

  - Win32
  - Unix/GTK
  - GNOME
  - BeOS
  - QNX/Photon
  - MacOS

Most of these ports are of similar levels of complexity, since the
underlying GUI primitives provided are roughly comparable.

Obviously, starting a new port all the way down at the framebuffer level
would be a *lot* more work, since you'd have to build implementations for
all those GUI services yourself. You'd probably be better off starting with
a higher-level toolkit, as Tamas suggests. Even here, you may still find
yourself implementing widgets (such as toolbars) which aren't provided by
the underlying toolkit.

One final suggestion -- instead of porting AbiWord to another toolkit, you
might consider porting one of the *toolkits* already supported by AbiWord.
For example, are there any projects to get the GTK APIs running on a
*lightweight* non-X core? (I already know about the GTK on Win32 and BeOS
projects, neither of which is relevant here.)

bottom line
-----------
You have a lot of choices here. The AbiWord codebase is heavily XP-centric,
and we'd love to have ports to more platforms, including ones we've never
thought of.

While it's not clear that the AbiWord UI will ever be useful on handheld
devices with ultra-limited displays, this *is* the age of non-PC devices,
and there are lots of interesting possibilities where having AbiWord as an
option could make a lot of sense.

Have fun!

Paul



This archive was generated by hypermail 2b25 : Thu Mar 09 2000 - 11:54:29 CST