Re: GDK framebuffer needed for the GTK debian installer



On Sun, 2005-05-08 at 12:36 +0000, attilio wrote:
> Hi everyone
> 
> i'm involved in debian development and i'm actually working on the gtk 
> frontend for the debian-installer (the plans for post-sarge relase are 
> to implement a graphic installation system based on gtk).
> Actually the gtk frontend module seems to work on a "X bench-test" (go 
> to http://lists.debian.org/debian-boot/2005/05/msg00242.html to see the 
> last news).
> Experimenting with the gtk i've come to the conclusion that
> -X gdk is solid rock but, for many reasons, is too big to fit on a 
> instalation cd
> -the directframebuffer gdk layer, though longly unmanteined, compiles 
> and works but is still too buggy (gives serious memory corruption problems).
> -the framebuffer gdk doesn't even compile
> I'm posting to this mailing list to ask you if some future development 
> of the fb/dfb gdk are planned, since this would be the most appropriate 
> gdk layer for a gtk-based debian-installer.

If you want something that works, really, X based GTK+ :-). There is
really no reason why an X server should take more than 700-800k of
disk space total. (Xfbdev, say) The X libraries are a bit bigger,
but getting everything into 2 megs should be possible.

Compared to the rest of GTK+ and its dependencies, compared to the set
of fonts you need for an internationalized install, it's only a 
moderate space usage.

And you get the big advantage that you don't have to build a separate
copy of GTK+ for your installer.

I don't think the work needed to get the "linux-fb" backend to GTK+
back into a working state is that large. On a rough guess, it's 
roughly a week of work for someone not that familiar with the GDK
code.

None of the existing GTK+ team members are planning to do that, but if
someone wanted to pick up maintenance, that would be great.

A suggestion I'd make would be to consider modularization of the
input/output away from the core code. That would allow creating a
"nested" device just took input and output from X ... and thus
make testing a whole lot easier. 

Regards,
					Owen

Attachment: signature.asc
Description: This is a digitally signed message part



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