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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
