Differences between revisions 12 and 13
Revision 12 as of 2006-06-22 07:42:22
Size: 13930
Editor: ALagny-109-1-10-249
Comment: formatting
Revision 13 as of 2006-06-22 10:38:34
Size: 14030
Editor: ALagny-109-1-10-249
Comment: Partition Magic
Deletions are marked like this. Additions are marked like this.
Line 53: Line 53:
 * [ Partition Magic]


Rewrite Ubiquity's advanced partitioner, concentrating on usability and commonality of code.


The use of gparted/qtparted in Dapper's live CD installer (Ubiquity) was expedient in terms of developer time, but it wasn't the long-term right answer. Using an external partition editor has many inherent problems, such as complex communication requirements with the rest of the installer, UI inconsistency between frontends, and behavioural inconsistency with the text-based installer and with autopartitioning. Furthermore, both gparted and qtparted are complex independently-designed C++ programs which require complicated patches to work in both standalone and installer mode; updating them has become a risky and time-consuming business, and fixing bugs can require investigating the design of both programs from the ground up.

To replace this, we will write a simple Python frontend to partman using ubiquity's standard debconffilter framework, with relatively small PyGTK/PyQt shims. The UI will be designed from scratch with an eye to usability, and will be sufficiently similar between the GTK and KDE frontends to offer familiarity.

Use cases

  • Judith has been using Unix for some time, and wants to install Ubuntu using a custom partition layout with separate /, /usr, and /var filesystems. She wants reasonably fine control over the sizes of these partitions, and wants to choose which filesystems to use for each.
  • Eugene has a number of different operating systems installed for experimentation, and wants to add Kubuntu to the list. To make room, he will resize one of his existing partitions and delete another.
  • Chris has been trying out both Ubuntu and Kubuntu, and is confused by the way the advanced partitioners are so different in each. He would like to be able to transfer his experience from one to the other.
  • James has a system with two hard drives that mirror each other using RAID1, to reduce the risk of data loss from drive failures; the hard drives are both much larger than he needs right now, so he uses LVM on these so that he can extend filesystems easily without having to set up the partition table perfectly first time. He would like to use Ubiquity to install Ubuntu on this system.


A successful implementation will provide a working and reliable advanced partitioner for both Ubiquity's GTK and KDE frontends that behaves similarly to that of the text-based installer but has a more attractive and better-designed UI, properly integrated into Ubiquity. LVM and RAID functionality is not required in a first iteration, but may be added later if time permits.


partman, the partitioner used in the text-based installer, is a debconf application whose main control flow features a basic UI revolving around a select widget with one line per partition ([ screenshot]). On selecting each partition, a submenu of information and operations that can be applied to that partition is presented, including method (use a filesystem, don't use, swap, other specialised uses), flags (e.g. boot), create (when selecting free space), resize, delete, and others. Some of these operations cause further prompts to be presented, while others present the submenu anew with updated information and perhaps different operations.

partman's backend has been polished by use in one Debian and three Ubuntu releases, and while it certainly still has bugs they are generally relatively minor. partman's UI, on the other hand, while reasonably effective as far as it goes, is basic and can be confusing. Much of the confusion arises from the fact that it is not possible to cram all the available useful information into a single screen of text, and from limitations in cdebconf and its newt user interface that require partman to present select lists where in some cases buttons or other widgets would be more appropriate. Fortunately, these limitations do not apply to a graphical interface, and we already have the technology required to transform debconf protocol requests into a pretty good graphical user interface.

Driving partman

Any graphical user interface to partman is likely to require presenting information from the partition submenus up-front. As such, the Ubiquity partman component will on occasion (certainly on startup) need to navigate internally through all the available partition submenus and cache information about all of them; this can easily be done with the aid of a state machine. When the user performs an action in the user interface, the partman component will navigate to the proper partition submenu and select the requested action. When partman's update.d scripts are called for a particular partition, as happens following certain operations, the cache of information for that partition will be invalidated, and the partman component will need to reload it as soon as possible; some operations (such as deleting a partition) will update all partitions and so the cache will need to be reloaded from scratch.

While cache updates will take a little time to complete, the author expects that this can be optimised at need, and that the benefits of caching will render update times not generally a problem.

User interface

A quick screenshot survey of some other major distributions' advanced partitioners (please don't get offended if I've left one out!):

The coloured graphical view of the disk presented by Gentoo and Mandriva (and by RHEL without colours) is a useful visual cue. I don't think it's wise to rely on it entirely as Gentoo appears to; that has obvious accessibility problems and doesn't present much in the way of detailed information up-front. The RHEL display is visually plainer and in particular makes no use of colour, but it strikes a reasonable balance between visual cues and presentation of information up-front. SuSE's detailed view crams in lots of information without looking too cluttered, which I like. We should be able to borrow ideas from all of these.

I suggest that the UI should start at the top with a horizontal bar-chart representation of each disk on the system, and immediately below that a list of all partitions (and chunks of free space between or around partitions) with the following information for each: name (for some partition table types), partitioning method (filesystem, don't use, swap, etc.), mountpoint, label, bootable flag (and others?), and size. (Start and end positions could be added but are probably unnecessary with the bar chart and with inclusion of sizes for free space chunks.)

Across the bottom of the page there should be at least the following buttons, some of which may be greyed out depending on the selected partition list item: Create, Edit, Delete, Undo. The Create and Edit buttons will present a dialog that allows changing all of the items of information displayed for the partition, with the possible exception of size depending on external constraints. The Delete button will schedule a partition for deletion immediately without asking for confirmation; this sounds scary, but Undo is available and text on the UI will indicate that changes will not be committed until the user selects Next.

Due to some technical constraints in partman, resizing a partition must be committed immediately and cannot be undone. (It may be possible to lift this restriction some day.) Resizing a partition will present a message box that indicates this clearly. Given this unusual behaviour, it may make sense to add a Resize button in addition to Edit.

UI design from BoF (will refactor later)

We draw the distinction between an automatic partitioner and an advanced partitioner. An automatic partitioner consists of simple recipes for certain very common cases, and offers little or no configurability beyond perhaps single simple variables. An advanced partitioner offers direct control of all or most important items in the partition table, although it may use whatever presentation seems most effective. Observation of bug mail and other user requests indicates that a very wide range of both existing and desired partitioning setups are required by users of Ubiquity's advanced partitioner, with multiple disks, many (well over 10) partitions per disk, the full range of supported partition types, etc.; it is necessary to support these to at least the approximate level of functionality provided by the current external partition editors. LVM and RAID are in use by some users, and it is necessary at least to have a visual design which will be able to accommodate this in the future, although it is probably not necessary to make it possible to create such setups for Edgy.

There is a tension between, on the one hand, attractive and clean visual design and easy manipulation, and on the other, accurate presentation of information and fine control. It seems likely that the partitioning screen will need to comprise two major elements in order to achieve this. We recommend a split between a visually attractive list of disks with graphically-oriented controls, and a primarily textual presentation of detailed information about partitions in the disk selected in that disk view with controls that pop up detailed dialog boxes.

The disk view occupies the top part of the page, and looks as follows:

  • There is a vertically-arranged sequence of disks, which scrolls vertically if necessary.
  • Each disk is represented by a horizontal bar, which is divided into partitions.
  • Each partition is coloured according to its type (although of course it must not be necessary to be able to distinguish the colours used in order to use this) and includes a small amount of information about the partition table (type and mount point).
  • Free space on a disk appears similarly to real partitions. It should have some suitably inactive-looking colour, such as grey.
  • The disk view is initially displayed with the first disk and the first partition (or free space) on that disk selected.
  • Selecting a disk causes an appropriately-coloured background to be drawn around it, and the nearest partition to the click to be selected.
  • Selecting a partition or free space has the following effects:
    • The horizontal bar segment representing the partition or free space is drawn pushed down like a button, and all other segments are drawn pushed up.
    • Contextual buttons appear below (or next to?) the disk within the surrounding coloured background. (The buttons are placed here rather than below the entire disk view to avoid them jumping around as different disks with different available options are selected, and to reduce the amount of mousing around required to operate on a disk.)
    • If the segment does not represent free space, then a resize grip appears at its right-hand side. Dragging this asks for confirmation and if given resizes the partition immediately (this is due to partman limitations and may be changed in future).
  • For free space segments, a "Create a new partition" contextual button is displayed. Pressing this button asks for details in a yet-to-be-specified way (TODO).
  • For partition segments, "Edit partition" and "Delete partition" contextual buttons are displayed. Pressing the Edit button pops up a dialog with detailed information on the partition and the facility to modify it (TODO); pressing the Delete button asks for confirmation and if given deletes the partition.
  • Other contextual buttons may be present; for example LVM and RAID will require further contextual operations.
  • A global "Revert" button is displayed below the sequence of disks, which asks for confirmation and if given undoes all changes that have been made to partitions (possibly only since the last resize operation, depending on partman limitations).

Data preservation and migration

Partitioners involve an inherent risk to data, which must be mitigated as far as possible. Errors raised by partman will generally be presented to the user and may include an option to continue or go back. Steps will be taken to ensure that partman cannot proceed past its confirmation question to commit changes to disk unless the user has positively confirmed the changes.

BoF agenda and discussion

  • Settle on UI design; concrete sketches; make sure to gather input from both GNOME and KDE people.


Ubiquity/AdvancedPartitionerRewrite (last edited 2008-08-06 16:16:19 by localhost)