On Thu, Jul 26, 2007 at 01:35:19AM +0300, Anton Zinoviev wrote:
> 1. Partman and graphical installer
> ----------------------------------
As you've spotted, I started background thinking and small experiments
(thanks Haskell, GTK+ and Cairo) on what could be a good graphical user
interface for Partman.
Partman is so much more powerful than any other partitioner that I don't
see gparted or similar tools as an option. With LVM+dm-crypt setups
getting more common, users more frequently have to deal with the
"stacking" (if you have a better term, please correct me) capabilities
of partman. I really would like to see a graphical partitioner
reflecting this features and making them easier to use...
I have nothing to present yet. It's floating in my head, and we'll see
if I can come up with something.
> In the main screen of partman, it uses spaces in order to align
> columns. Obviously this doesn't work in g-i since there the font is
> proportional.
This also is an issue for language selection, currently.
> I have no idea how debconf works, but here is what parman can do
> easily in order to improve the situation.
>
> (1) db_capb align
>
> If debconf answers that it supports 'align' capability, then partman
> is going to use the Select template in a different way.
>
> (2) The first "choice" in 'align' mode is not a real choice, but a
> line of titles of the columns that follow. The names are
> separated by a special delimiter (such as '$$')
>
> (3) The next choices are the real choices. They also use this
> delimiter between fields.
I don't see any real issue in implementing such solution from my
experience in the GTK+ frontend code.
But I wonder if the right way is to hack on select semantics instead
of maybe adding a new specific question type. The plugin infrastructure
of cdebconf enable us to do so quite easily, actually.
> I suppose the users should be allowed to resize the width of the
> columns by moving the boundaries between the titles of the columns
> with the mouse.
>
> (4) However not all lines will use these delimiters. Such lines
> should not be affected by resizing the columns.
That is going to be a lot trickier to implement in GTK+, AFAIK.
Although, really easy in the web frontend. :)
> (5) I suppose currently g-i tryes to detect the branches of the
> choices tree (Options, Disks, Partitions). However I'd prefer
> if g-i does no guessing about such matters. It will be better
> if partman uses special character combinations in order to tell
> what is what (if cdebconf has 'align' capability).
I agree.
> I found this image: http://people.debian.org/~lunar/disk-widget.png.
> If you want to display such graphical representations of the disks and
> partitions (this would be great) I'd suggest the following format of
> the choices for partitions:
>
> level$1$$size$48903$$firs field$$second field$$third field$$...
>
> Here the special 'field' size$48903 tells the frontend that the
> relative size of the partition is 48903. (And level$1 says that this
> is a partition, not a disk. The choices for disks can start with
> level$0.)
My initial thoughts about implementing a graphical partitioner was
to use a custom debconf question type. As, IMHO, string manipulation in C
should be avoided whenever its possible, I would prefer partman to feed
the plugin values in the easiest format for the later.
Please note that using a custom plugin for the partitioning stage in the
GTK+ frontend does not invalidate the need for such an "align"
capabilities and would probably benefit other frontends as well.
One real question though: getting "align" to work in partman might be
done quickier than what I can imagine right now; should we switch to it
first before trying to get even better?
Cheers,
--
Jérémy Bobbio .''`.
lunar@debian.org : :Ⓐ : # apt-get install anarchism
`. `'`
`-
Attachment:
signature.asc
Description: Digital signature