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 .''`. [EMAIL PROTECTED] : :Ⓐ : # apt-get install anarchism `. `'` `-
signature.asc
Description: Digital signature