Re: zen and debconf
Ben Collins wrote:
>
> On Wed, Sep 20, 2000 at 02:53:28PM +1100, Glenn McGrath wrote:
> > Ben Collins wrote:
> > >
> > > > If we are going to do anything fancy in our UI we could allow packages
> > > > to use there own html code to present there questions rather than
> > > > building a web page for them, this would add a large degree of
> > > > flexibility which i think is needed.
> > >
> > > The whole idea of debconf is to disconnect packages from the configuration
> > > frontend details. If we start asking them to produce HTML, we might as
> > > well ditch debconf and let them handle everything internally.
> > >
> >
> > We shouldnt force them to use html, we could do the same thing the
> > current debconf does when it target a web browser (i have to confess i
> > havent tried it though)
>
> Check it out, it does have flexibility. You can group several questions
> together in a block, which can all be presented to the user on a single
> webpage. The block is set by the package, and is transparent to the UI
> being used (I think the GTK frontend also used to use it).
>
> I think joey says it needs work, but needing "work" is better then needing
> "development". An interface is there, it just needs to be used and
> tweaked.
>
Maybe im confused, i thought all of debconf was dependent on perl, and
the whole motivation of rewritting debconf in c is to reduce
dependencies on perl. So a c-debconf would have to develop every user
interface it uses, we cant just fix up the web frontend in the existing
debconf and use that without perl can we?
> BTW, I like your idea, but I'm just afraid if we aren't careful, it will
> lead to a ggi type conundrum, where we have layers and layers of frontends
> all implementing each other. I want to avoid that by design.
>
Fair enough, zen is modular, it has a gtk interface a framebuffer
interface and a text interface. Unfortunately im finding that it would
take a bit of development to get it working correctly, right now i cant
get it working on a 16 color framebuffer which is what we need, and the
text interface just dumps the address to screen, its not interactive.
Currently the only ui that doesnt have a layer on it it the text-ui.
slang-ui and dialog-ui have the slang library on top of text, gtk-ui on
x, web-ui under a browser.
The browser is under other layers, either slang, ncurses, framebuffer or
X, so i do see your point about adding layers.
If zen didnt work out we could use w3m for a text-ui and viewML for a
framebuffers-ui, which would bloat it out.
Using a browser as a ui will cost us more space on the floppies,
probably too much if zen doesnt work out, i will investigate zen
further.....
Glenn
Reply to: