selection should default to free space

[Jono Bacon]

When gparted opens, the menu option to create a new partition is disabled. This is because it is only active when free space is selected, and it is not selected by default. The free space should be selected by default.

[Colin Watson (cjwatson)]

I agree.

[Rodrigo Novo (rodarvus)]

This patch attempts to fix this bug by modifying the behavior of gparted on refreshes (including startup):

Before, selected partition was always "cleared" on refreshes - now we search the list of partitions, and check if there is any marked as "unallocated" - in this case, select it. If all partitions are allocated (or there is no free space on device), no partition is selected.

I'd be glad if someone could give a little more testing to this patch, as I only was able to test it locally.

[Christian Reis (kiko)]

nit: the code has inconsistent spacing around parenthesis; follow the style in the file, but I suggest not adding spaces after ( and before ) -- PEP-8 style :)

[Christian Reis (kiko)]

Hmm, from the diff context it appears that the standard in that file is to include spaces (yuck) so take /that/ with a grain of salt (or just ignore me!)

[Daniel Hahler (blueyed)]

The patch needs some work, it applies with -F3, but then causes build failure:
i486-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/gtkmm-2.4 -I/usr/lib/gtkmm-2.4/include -I/
Win_GParted.cc: In member function 'void GParted::Win_GParted::Refresh_Visual()':
Win_GParted.cc:708: error: 'vbox_visual_disk' was not declared in this scope

[amithji (coolamith23)]

use gparted and follow the steps properly dont miss any minute details........

[Bodsda (bodsda)]

Untested, but looking at the code and the patch file, if you change vbox_visual_disk to drawingarea_visualdisk, that should work. The only two objects in this file that use that method are treeview_detail and drawingarea_visualdisk.

If I get time tonight I'll test this out, but if someone else could test it, that would be great.

[Kyle Hall (pcfreak2-deactivatedaccount)]

It might confuse some users
Although I think this would not be a good idea because some people might accidentally format a partition/free space

[Kyle Hall (pcfreak2-deactivatedaccount)]

It would be good as long as users are careful and understand what is happening

[Phillip Susi (psusi)]

That's kind of the point: you want to be able to create a new partition, without the confusing need to click on the free space first. You can't "accidentally" create a partition.

Come to think of it, I'm not sure why you even need to have the free space selected to create a partition. It goes without saying that creating a new partition will use free space, so there shouldn't be a need to select it explicitly. Maybe the create menu option just needs to be enabled regardless of what you have selected.

[Curtis Gedak (gedakc)]

> Maybe the create menu option just needs to be enabled regardless
> of what you have selected.

This might be a good solution to this request.

The create "New" partition menu would always be available.

There would be three scenarios to handle:

A) If the user had pre-selected unallocated space.
     In this case the usual dialog for creating a new partition would be displayed.

B) If a user had pre-selected a formatted partition.
     In this case we have some options:
       i) the user could be warned by a dialog to select unallocated space only (I prefer this option)
       ii) the user could be prompted with a dialog to format the existing partition and lose the data

C) If the user had pre-selected neither unallocated space, nor a formatted partition.
     In this case the user could be prompted with dialog to select unallocated space.

Does the above sound reasonable, or is there perhaps a better way to address this?

[Phillip Susi (psusi)]

Why not just *always* show the usual new partition dialog? Why does creating a partition depend on the current selection at all? New partitions are always created out of free space, so why explicitly require that space to be selected first?

[Curtis Gedak (gedakc)]

The current selection is important because there can be more than one section of the disk with free unallocated space.

[Phillip Susi (psusi)]

Ahh, and the normal dialog has to be told which one to allocate from instead of letting you choose there? Then perhaps it would be sufficient to check if free space is already selected when you try to create a partition, and if it isn't, automatically select the largest free space?

[Curtis Gedak (gedakc)]

That would work -- selecting the largest free space if no free space is already selected.

Two situations could still arise that would need handling:

A) The user had pre-selected a file system with a partition.

      In this case the "New" menu and toolbar button could be disabled.
      OR
      A warning dialog could be presented.

B) The disk device had no free space remaining.

      In this case the "New" menu and toolbar button could be disabled.
      OR
      A warning dialog could be presented.

These options seem like a lot of work for not much gain.

I tend to prefer the way that PalmOS handled menus and buttons. These were not greyed out or disabled at any time. Instead if a user clicked on a button or selected a menu and the action was not valid, then the user was prompted with what to do so that the menu or button would work.

To apply this PalmOS way to the user pressing the "New" button we have four scenarios:

1) Free unallocated space selected but no partition table on device

     Show dialog indicating to create a new partition table.

2) No partition or area selected

     Show dialog indicating to select free unallocated space.

3) Existing partition selected

    Show dialog indicating to select free unallocated space.

4) Free unallocated space selected

    Proceed as currently to create new partition dialog.

This method would follow the PalmOS philosophy, but is not in alignment with the GNOME HIG regarding control or menu sensitivity.
http://developer.gnome.org/hig-book/3.2/controls-sensitivity.html.en
http://developer.gnome.org/hig-book/3.2/menus.html.en

In fact enabling any control when it is not yet valid is a violation of the GNOME HIG. When I think of this problem in this way, this request is for a violation of the GNOME Human Interface Guidelines, or at least my interpretation of these guidelines.

[Curtis Gedak (gedakc)]

The only thing that I can think of that does not violate the GNOME HIG is to perhaps default to selecting free space on the default selected drive.

[Phillip Susi (psusi)]

#1 and #4 sound good, but why bother telling them they need to select free space? Just select it for them if it isn't already.

[Curtis Gedak (gedakc)]

I think we are in agreement. The part that is required is to default select the free space.

#1 and #4 are already in the code. :-)

Bodsda, are you working to fix the patch in comment #2, or otherwise to implement a default selection of free unallocated space?