Re: zen and debconf
Glenn McGrath <bug1@optushome.com.au> writes:
> A couple of hours ago it hit me, we shouldnt be trying to invent the
> wheel, we can use a web browser as the defualt user interface and a web
> server as the backend (e.g. the kernel web server). Using html should
> have a number of advantages in the tools available to use such as web
> servers, proxies, remote backends, remote UI, debconf package scripts
> developed as html.
So far, Zen lacks something very important, namely support for forms,
but that's probably not that very difficult to put in. I just haven't
had much time over for Zen lately.
Else than that, I do like the idea. It would also mean Zen could get
some help to get further developed. Right now, I'm alone in hacking on
it.
> Zen looks like it could be exactly what we would need, however i do have
> a question on frambuffer support (ofbis).
>
> 1) I couldnt get the ofbis framebuffer interface workinging straight
> away. It didnt compile by default, then when i went into the ./ui/ofbis/
> dir and tried to make it there it couldnt find ofbis.h, is ofbis
> interface usable yet ?
Indeed it is. The ofbis interface was the first interface I made
(actually, the plain text dump was before, but that hardly counts),
and getting a web browser for the framebuffer was the reason why I
started on Zen to start with.
Did you get and install the oFBis library? The header file will be
placed in /usr/local/include/osis/ofbis.h by default. When installing
oFBis, it will also install a script, ofbis-config, similar to
gtk-config and programs like that, to find out where oFBis is
installed, and such. That script is used by Zen's configure script to
find out if it can compile the ofbis interface.
> 2) We will be using a 2.4 kernel, and we want to support old video
> cards, so we would like to be able to use 16 colour (4-bit) framebuffer
> modes. Could zen work down to 16 bit colour framebuffer, if not would it
> be difficult to do?
I haven't tried. oFBis have support for 4 bitplanes mode, such as the
Amiga and Atari uses, but I don't think it has support for 4-bit chunk
mode, if there is such? It's however easy to add support for it. The
oFBis library has a modular design internally, so it should be a
simple task.
If you decide on another framebuffer library than oFBis, it's also not
that extremely difficult to create a new interface for it in
Zen. You'd also have to create a slang interface. The only X interface
available so far uses GTK+, so that might be a bit overkill for
installation.
> (it seems like a good idea to me now, hope i havente overlooked
> something obvious).
Images in Zen are handled by libjpeg or libmagick, but it is possible
to compile Zen without these libraries, and no images will be
shown. Images might not be top priority for an installation program.
I haven't studied the memory footprint of Zen, so that might be
interesting to do. I think that most memory it takes, is for images,
and especially when using libmagick, which is kind of memory
expensive. I've tried to keep the program and shared library size of
Zen and its interfaces down pretty much, so it should be small in that
sense. An exception is the small animation used by the GTK+ interface,
which takes an extra 64K, which isn't really that very useful.
Currently, Zen requires libdl and libpthread, and it's not possible to
compile it statically linked, but as I understood, you wouldn't want
to do that anyway.
I think it's a good idea if you get the sources for both oFBis and Zen
from our CVS, since we don't make releases as often as we should. You
can read more about our CVS on http://www.nocrew.org/software-cvs.html
When compiling oFBis, a test program called fbtst will be compiled,
but not installed. Running that would show if you've compiled oFBis
correctly.
If you still can't get the ofbis interface to work, send me your
config.log, or something like that from Zen, and maybe I can see what
goes wrong.
Good luck,
Tomas
Reply to: