Re: cdebconf-entropy plugin: usage, templates and strings
Hey Jérémy,
On Thu, Mar 06, 2008 at 01:44:45PM +0100, Jérémy Bobbio wrote:
> The first plugin to be written, obviously, is the graphical sibling to
> the plugin gathering entropy, used in partman-crypto. The code for this
> plugin was actually written while working on the rest of the GTK+
> frontend [1] but as yet to be integrated properly.
>
> [1] http://people.debian.org/~lunar/fe_gtk-plugin-entropy.c
Thanks for your work on this!
The implementation looks fine from a quick glance. Please
feel free to add integrate it into cdebconf-entropy when
you are happy with it.
> I think it would make more sense to make a single question type, for
> both frontend, named "entropy", and to have a single question template
> in partman-crypto and a single code path handling both frontends.
Agreed.
> I thought about using the newly introduced debconf directives, but I
> might just wanna play with a new toy here. So I really want to know
> other advices before hacking… Here is the proposed implementation,
> though:
>
> Using directives would make the previous template look like:
>
> _Description: ${!ENTROPY_SHORT_TITLE}
> The encryption key for ${DEVICE} is now being created.
> .
> ${!ENTROPY_GENERATE_MORE}
>
> A new text template would be introduced in each plugin built by
> cdebconf-entropy. Its short description would be used for
> ENTROPY_SHORT_TITLE and ENTROPY_GENERATE_MORE would be its extended
> description.
The approach sounds fine.
I'm not familiar with the new debconf directive mechanism.
Is there any documentation I could look at? Any pointers
would be appreciated. :-)
If directives weren't available, I would probably have
gone for a similar but slightly diffent solution - we could
have partman-crypto provide a description fragment
_Description: The encryption key for ${DEVICE} is now being created.
The different 'entropy' type frontend plugins would take
the fragment and integrate it with the appropriate frontend-
specific text to form a complete dialog.
IOW, if directives are a good fit for this use, I see no
reason to not go ahead with the proposal you outlined.
Max
Reply to: