Re: gtk frontend to the new debian-installer
On Fri, Feb 06, 2004 at 06:33:50PM -0200, Gustavo Noronha Silva wrote:
[...]
> Hi,
>
> I am interested in that and got cdebconf to install on a chroot to hack on it.
> Unfortunatelly I had no success trying to use d-i on bochs yet -- at least
> I could not get past some stage, but loading the gtk frontend is still
> something I have to investigate how to do. I have worked on porting
> the gnome frontend for debconf to debian from progeny and then to
> gnome2, so I now some of the basics already.
Cdebconf comes with some test cases under src/test/, so you can first
test your frontend outside of d-i.
[...]
> Should I request the account now so that I can use the CVS directly
> or should I set up my own CVS?
This frontend is currently not built in binary packages, so you can
commit whatever you want under src/modules/frontend/gtk. Changes
in src/ should be discussed on debian-boot first.
> Also, while googling I found this email which brings up some problems
> which seem to not yet be fixed and I may not be able to tackle them
> myself, so I still need help:
>
> http://lists.debian.org/debian-boot/2003/debian-boot-200306/msg00139.html
I do not understand all questions, but consider
To display the log output in a gtk window, I came to the conclusion
that I needed threads. If control goes to some udeb postinst which
produces an error, the frontend code must be in control to actually
display it (gtkmain).
Cdebconf launches a server (which controls the interface) and a client
(maintainer scripts) and they communicate through a pipe. So the
frontend always has the control. Current frontends only wait for input
on their pipe, but a graphical installer will naturally respond to
keyboard and mouse events, how this is done is unrelated to cdebconf.
Denis
Reply to: