Re: Framebuffer port of GTK/GDK !!



Havoc Pennington <hp@redhat.com> writes:
> "Shawn T . Amundson" <amundson@eventloop.com> writes:
> > On Wed, Mar 22, 2000 at 09:16:53AM -0800, ArcadePreserv Center wrote:
> > > Am I right, when I assume that this will make it possible to run GTK 
> > > programs, like Gimp without X ?
> > 
> > GIMP can already run without X on at least 2 platforms, so the answer
> > to that is yes.
> 
> However BeOS and Windows both have windowing systems to use I would
> think, for straight framebuffer you have to write a simple windowing
> system. A windowing system suitable for a kiosk-style app is probably
> pretty trivial, possibly much easier than one suitable for desktop
> apps.

There is DinX, which is supposed to fit this application space.

  http://dinx.sourceforge.net/

It was discussed on linux-kernel a few months ago, and appeared well
recieved.  Some excerpts from the webpage:

  [...] DinX, an experimental windowing system. DinX is designed to
  be simple, lightweight, and fast. It should be suitable for running
  multiple windowed programs on a small system, like a Linux handheld. 
[snip]
  DinX is licensed under the Mozilla Public License, with an option to
  convert to the GPL if you wish to do so. This is so that the kernel
  modules might eventually make it into the Linux distribution, and so
  that the DinX libraries can be linked with other GPL programs.
[snip]
  DinX uses the Linux kernel's framebuffer video driver. It adds two
  new interfaces, /dev/dinxsvr and /dev/dinxwin. A server program
  connects to /dev/dinxsvr and arbitrates requests from windows to
  occupy various parts of the display. It also sends them events like
  mouse movements. The window client programs connect to /dev/dinxwin,
  and write commands that either communicate messages to the server,
  or cause drawing to occur in the window.

  Drawing in DinX is done without context switches. The kernel module
  contains just enough logic to clip a drawing operation to any
  windows that might be obscuring it, and to draw what's left to the
  framebuffer. It also sends redraw events to windows that need to
  clean up after some part of the window that was obscured becomes
  visible again. Everything else, like events, window management,
  palette configuration etc, is handled by the server process. The
  kernel module passes through messages between the client windows and
  the server.

There would be, however, the GPL contamination of the GDK LGPL, or if
the MPL is compatible with LGPL, it may be OK.

- Hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash



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