To increase the size of a partition, the free space must be adjacent to the partition.

To increase logical partitions, the free space must be within the extended partition.

To increase primary partitions, the free space must not be within the extended partition.

See the tips in the Resizing a partition section of the GParted manual:
http://gparted.sourceforge.net/docs/help-manual/C/gparted.html#gparted-advanced-partition-actions

In your situation, you will need to unmount the swap partition, select the extended partition and move the left edge to butt up against the swap partition.  After doing this you should be able to add the free space to /dev/sda2.

Does that answer your question?

(In reply to comment #1)
> To increase the size of a partition, the free space must be adjacent to the partition.

This description fits to the current situation. I would find it more convenient if I could tell the tool just to move free space from the end to the beginning while the software will determine corresponding adjustments almost automatically.


> To increase logical partitions, the free space must be within the extended partition.
> 
> To increase primary partitions, the free space must not be within the extended partition.

I could manually specify to move the unused storage from the back to the front. Operations were queued as desired by QParted 5.2. Unfortunately, the changes were not applied as expected.


> In your situation, you will need to unmount the swap partition, select the
> extended partition and move the left edge to butt up against the swap partition.

No areas were mounted from my disks while I was using the GParted Live CD or Knoppix DVD.


> Does that answer your question?

Not really.

(In reply to comment #2)
> > In your situation, you will need to unmount the swap partition, select the
> > extended partition and move the left edge to butt up against the swap partition.
> 
> No areas were mounted from my disks while I was using the GParted Live CD or
> Knoppix DVD.

In the screen shot attached to comment #1, there is a key icon beside partitions /dev/sda5 (logical) and /dev/sda3 (extended).  The beginning of the extended partition /dev/sda3 could not be moved because the partition contains active mounted logical partitions.  All logical partitions must be unmounted before the extended partition can be edited.


If this does not answer the question you asked, perhaps you could restate your question in different words?

(In reply to comment #3)

I'm sorry that I did not interpret the key symbol as an indication for a partition that was already mounted (by Knoppix). The mentioned swap space can be switched off to unlock further adjustment operations.

Is this icon described in the documentation?
Would a corresponding tooltip help to clarify this detail in the user interface?

Created attachment 163939 [details]
excerpt from a screenshot from GParted Live 0.5.2-9

I guess that a part of my problem is indicated by the following message in the file "gparted_details.htm".

"...
Unable to satisfy all constraints on the partition.
Can't have the end before the start! ..."

I have tried to adjust my partitions without gaps between them so that the storage space should be completely assigned. Unfortunately, the user interface does not support to specify the partition limits by sector numbers yet. The corresponding text fields do also not allow to enter fractional values which might result in position mismatches.

It seems that there is an open issue with the handling of cylinder parts which results in left overs of storage units like "7.00 / 7.84 MiB" in my use case.

Created attachment 163941 [details]
Screen shot of GParted with mounted partition indicated by a padlock icon

In response to comment #4:

If the meaning of the key symbol was not clear to you, then it is probably confusing for others.

In the GNU/Linux distribution I am using, this symbol is shown as a picture of a padlock (see attachment).  From your screen shot I can see that KNOPPIX 6.3 uses a picture of two keys attached to a keyring.

The name of this icon is "Gtk::Stock::DIALOG_AUTHENTICATION".

A list of stock Gtk icons can be found at:
     gtkmm: Gtk::Stock Namespace Reference
     http://library.gnome.org/devel/gtkmm/2.19/namespaceGtk_1_1Stock.html

In the help manual documentation, the first note under Basic Partition Actions mentions that several actions require the partition to be unmounted.  See:
http://gparted.sourceforge.net/docs/help-manual/C/gparted.html#gparted-basic-partition-actions

The help manual documentation does not specify that a key icon or padlock icon indicates that the partition is mounted.  Your suggestion to add this to the documentation would probably help.  A sentence indicating the meaning of the icon could be added in this section.

A tool tip is also a good idea.


In response to comment #5:

There is indeed an issue with using cylinder alignment and working with partition sizes less than a full cylinder (~7.84 MiB on a device with 512 byte sectors).  This issue should be lessened by the next release of GParted which includes "Align to MiB" as the default partition alignment.

GParted 0.6.0 is planned for release on Friday, June 18th.  If you would like to help with testing, GParted 0.6.0-beta2 is currently available and can be found at the following link:
http://gparted-forum.surf4.info/viewtopic.php?id=14135

(In reply to comment #6)

Would an alternative symbol express the meaning "mounted partition" better?
The reuse of the icon "Gtk::Stock::DIALOG_AUTHENTICATION" seems to be convenient. But is it really appropriate?

Would you like to support the sorting or grouping of the entries in the table control by mount status?

> There is indeed an issue with using cylinder alignment and working with
> partition sizes less than a full cylinder (~7.84 MiB on a device with 512 byte
> sectors).  This issue should be lessened by the next release of GParted which
> includes "Align to MiB" as the default partition alignment.

I guess that this issue can only be completely solved if the storage unit can be selected.
Sector numbers or specific cylinders can only be integers. If MiB or GiB will be specified, the handling of floating-point values will be needed without rounding errors.

> (In reply to comment #6)
> 
> Would an alternative symbol express the meaning "mounted partition" better?
> The reuse of the icon "Gtk::Stock::DIALOG_AUTHENTICATION" seems to be
> convenient. But is it really appropriate?

Which alternative symbol or icon would you suggest?

One of the challenges is that it is hard to design a universally understood icon.  Personally I think the padlock icon conveys the meaning that the partition is somehow locked and perhaps cannot be changed.

The choice of the icon displayed appears to be related to the GNU/Linux distribution as can be seen in the following request in Ubuntu:

   gparted should show a padlock rather than a key next to locked partitions
   https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/577983

GParted Live is based on Debian GNU/Linux and our latest GParted Live image will display a padlock.

 
> Would you like to support the sorting or grouping of the entries in the table
> control by mount status?

I do not think that sorting or grouping partition entries by mount status will address the underlying problem.

If I understand correctly, the problem is that a user does not understand why certain actions are disabled for a partition.

In an attempt to address this issue we have:

1)  Added point FAQ point #5:
     5. Why are some menu items disabled? 
     http://gparted.sourceforge.net/faq.php

2)  Added to the help manual a note that some actions require the partition to be unmounted:
http://gparted.sourceforge.net/docs/help-manual/C/gparted.html#gparted-basic-partition-actions

3)  Added the option to View -> File System Support to see which actions are available for which file systems.
     This table of actions can also be viewed on the GParted web site at:
     http://gparted.sourceforge.net/features.php

4)  Ensured that our Official Live CD does not mount any partitions or enable any swap space.
     This should avoid the problem of possible confusion about a partition being mounted because no partitions are mounted or swap space enabled.


To further address this issue, at your suggestion we can look into:

5)  Adding a sentence to the documentation to explain that the padlock or key icons indicate that a partition is mounted and that some actions might not be available as a result.

6)  Adding a tooltip that is displayed when a user passes the mouse cursor over the padlock or key icon.  The tool tip would indicate that the partition is mounted and that some actions might not be available as a result.

(In reply to comment #9)
> One of the challenges is that it is hard to design a universally understood icon.

I agree. I guess that visual artists are more competent for this presentation issue.


> Personally I think the padlock icon conveys the meaning that the
> partition is somehow locked and perhaps cannot be changed.

I assume this is also an issue for localisation/internationalisation.


> The choice of the icon displayed appears to be related to the GNU/Linux
> distribution as can be seen in the following request

Are there any chances to extend the collection and enumeration "Gtk::Stock"?


> To further address this issue, at your suggestion we can look into:

7) Reconsideration of floating-point value processing

(In reply to comment #9)
> To further address this issue, at your suggestion we can look into:

How do you think about the companion feature request "Support for data entry and display of logical blocks (sectors)" (bug #622150)?

Thank you for creating a separate bug report (bug #622150).

I was getting a little confused because our discussion seemed to jump from one problem to another.  For example, I was having difficulty understanding how the following suggestion would help address the problem of mounted partitions having some actions disabled, or the title problem of "The beginning of an extended partition could not be moved":

> 7)  Reconsideration of floating-point value processing

The reason for this is that even if a user was able to provide exact sector values, the "Round to cylinder" feature would have insisted on aligning to a full disk cylinder anyway.

One goal I try to attain with GParted is to reduce the amount of knowledge needed for a user to partition a disk.  Many users do understand that space needs to be reserved for boot records.  For example, space must be reserved for partition information, such as the following:

MSDOS -- Space is required at the start of the disk device to store the Master Boot Record containing the partition table.

MSDOS -- Space is required in front of each logical partition to store an Extended Boot Record which contains a link to a higher numbered logical partition.

GPT -- Space is required at the end of the disk device to store the backup partition table.

I believe that GParted does diminish the need for a user to understand these space requirements when Cylinder or the new MiB alignment is used.

(In reply to comment #12)
> I was getting a little confused because our discussion seemed to jump from one
> problem to another.

I stumbled on two obstacles during my storage space movement.
- Ambiguous symbol interpretation in different Linux desktops.
- The GUI allowed to enter integers that did not fit to the expected layout. The partition editor library rejected new positions that were passed because of mismatches from floating-point value conversions.


> One goal I try to attain with GParted is to reduce the amount of knowledge
> needed for a user to partition a disk.

The tool can help the user to take informed decisions a bit easier as the issue "Improve knowledge presentation about partitions" (bug #539185) can also be discussed.

Created attachment 165016 [details]
 excerpt from a screenshot for GParted 0.6.0 in openSUSE 11.2

I would like to show another icon variation. Are there chances to disambiguate the user interface a bit more for the mount status?

(In reply to comment #9)
> I do not think that sorting or grouping partition entries by mount status will
> address the underlying problem.

I hope that an appropriate solution will be found for the unambiguous display of such a boolean flag by the graphical user interface.

How do you think about the application of symbols for the labels of narrow columns (or rows) if you would like to avoid any difficulties from grouping features in table widgets?

It is good to hear from you Markus.

(In reply to comment #15)
> How do you think about the application of symbols for the labels of narrow
> columns (or rows) if you would like to avoid any difficulties from grouping
> features in table widgets?

Using a symbol for the column name would certainly keep the width of the column much shorter than if text were used.

The two confusing symbols that are used by GParted are:

A) Padlock or Key icon which is used to indicate that a partition is
   active or mounted

B) Triangle with an Exclamation mark inside icon which is used to indicate
   that some problem was encountered when trying to read or interpret the
   contents of the icon.

These two icons could perhaps be placed in a "Status" column, instead of being appended to the "Partition" column.  The status column might use a scripted letter "i" to help indicate that status information is contained in the column.

It would also be useful if tooltips were used so that a text description would pop up when a person placed the mouse over the column name or icon.

Do you think this would help address the problem with interpreting the icons?

Is this something you would like to work on?

(In reply to comment #16)
> Do you think this would help address the problem with interpreting the icons?

Partly, yes. (Within the limitations of the current design approach ...)


> Is this something you would like to work on?

Not yet. - I would prefer a clarification of useful and accepted design alternatives before a specific implementation.

How do you think about a separation of the needed information display into two table widgets (for the adjustable and mounted partitions) with an optionally movable separator control element between them?

Created attachment 197084 [details]
Sample 1 - GParted with new separate status column

Attached is an image with a mock up of the new "information status" column which is indicated by a the "i" icon.

The key icons in the column are the "Gtk::Stock::DIALOG_AUTHENTICATION" icons used to indicate that a partition is active (i.e., mounted, swap-on, or an extended partition containing at least one active logical partition).

> How do you think about a separation of the needed information display into two
> table widgets (for the adjustable and mounted partitions) with an optionally
> movable separator control element between them?

Does the attached picture represent what you are describing?

(In reply to comment #18)
> Attached is an image with a mock up of the new "information status" column
> which is indicated by the "i" icon.

I agree that this picture looks a bit better.

Unfortunately, I imagine that this design approach will still result in open issues and further challenges for internationalisation/localisation.


> The key icons in the column are the "Gtk::Stock::DIALOG_AUTHENTICATION" icons
> used to indicate that a partition is active (i.e., mounted, swap-on, or an
> extended partition containing at least one active logical partition).

I find the use of this symbol inappropriate for your tool because it is not connected with the meaning you really need.
http://developer.gnome.org/gtkmm/3.0/namespaceGtk_1_1Stock.html#a774f24ac5ce37b55d836ee53327cdb88


> Does the attached picture represent what you are describing?

Yes. - It shows one of the proposed GUI adjustments.

I would prefer an alternative solution after all the shown icon variations.
How do you think about an application of panes?
http://developer.gnome.org/gtk3/stable/GtkPaned.html

Created attachment 197092 [details]
Sample 2 - GParted with lock icon in mount column

>> The key icons in the column are the "Gtk::Stock::DIALOG_AUTHENTICATION" icons
>> used to indicate that a partition is active (i.e., mounted, swap-on, or an
>> extended partition containing at least one active logical partition).
>
> I find the use of this symbol inappropriate for your tool because it is not
> connected with the meaning you really need.
> http://developer.gnome.org/gtkmm/3.0/namespaceGtk_1_1Stock.html#a774f24ac5ce37b55d836ee53327cdb88

Yes, this is a problem.  The meaning I desire is that the partition is locked because it is mounted.

Another way to try to relay this meaning would be to place the lock icon in the "Mount point" column.

Attached is another picture that demonstrates this possibility.  I think that this implementation is better than the solution depicted in "Sample 1 - GParted with new separate status column".


> I would prefer an alternative solution after all the shown icon variations.
> How do you think about an application of panes?
> http://developer.gnome.org/gtk3/stable/GtkPaned.html

Unfortunately I am not sure what you mean by this statement.

Would you be able to describe how the "application of panes" would be used?

(In reply to comment #20)
> Yes, this is a problem.  The meaning I desire is that the partition is locked
> because it is mounted.

If you would like to insist on this design direction, I imagine that it will be needed to convince the GTK developers about extensions for their "stock" enumeration. How are the chances for this approach?
http://developer.gnome.org/gtk3/stable/gtk3-Stock-Items.html#GTK-STOCK-DIALOG-AUTHENTICATION:CAPS


> Another way to try to relay this meaning would be to place the lock icon
> in the "Mount point" column.

Would you like to consider another little improvement for this variant?
How do you think about the applicability of column/row grouping?

Examples:
http://eclipse.org/nebula/widgets/grid/grid.php
http://java2s.com/Code/Java/GWT/GroupedtablecolumnExtGWT.htm
http://code.google.com/p/google-web-toolkit-incubator/wiki/ScrollTable


> Would you be able to describe how the "application of panes" would be used?

I try once more to clarify my suggestion.

I would prefer a cooperation with the class hierarchy around "GtkPaned". Each pane would contain a table widget if information should be displayed which falls into the following categories.
- resizeable/movable partitions
- mounted partitions

Rows could be moved between them to enable or disable a settings change.

(In reply to comment #21)
> (In reply to comment #20)
> > Yes, this is a problem.  The meaning I desire is that the partition is
> > locked because it is mounted.
> 
> If you would like to insist on this design direction, I imagine that it will
> be needed to convince the GTK developers about extensions for their "stock"
> enumeration. How are the chances for this approach?
> http://developer.gnome.org/gtk3/stable/gtk3-Stock-Items.html#GTK-STOCK-DIALOG-AUTHENTICATION:CAPS

If you have an interest in following up with the GNOME team to add a new stock icon, then please feel free to do so.  I do not intend to do this because I am content with the icon currently used for GTK-STOCK-DIALOG-AUTHENTICATION.

 
> > Another way to try to relay this meaning would be to place the lock icon
> > in the "Mount point" column.
> 
> Would you like to consider another little improvement for this variant?
> How do you think about the applicability of column/row grouping?
> 
> Examples:
> http://eclipse.org/nebula/widgets/grid/grid.php
> http://java2s.com/Code/Java/GWT/GroupedtablecolumnExtGWT.htm
> http://code.google.com/p/google-web-toolkit-incubator/wiki/ScrollTable

Thanks for the links.  The pictures helped to clarify the column/row grouping concept.

If I understand your suggestion, I think you mean a column/row grouping such as the following:

...  +------------------------------+ ...
     |      Mount Point             |
     |  Status   |  Directory Name  |
     +-----------+------------------+
     | Mounted   | /data/pictures   |
     | Unmounted |                  |
...

If this is correct then I do not think that the information displayed warrants adding a column row grouping.  My preference is to keep the GUI as simple as possible, and not loose an extra line of screen space for titles.


> > Would you be able to describe how the "application of panes" would be used?
> 
> I try once more to clarify my suggestion.
> 
> I would prefer a cooperation with the class hierarchy around "GtkPaned". Each
> pane would contain a table widget if information should be displayed which
> falls into the following categories.
> - resizeable/movable partitions
> - mounted partitions
> 
> Rows could be moved between them to enable or disable a settings change.

Thank you for another description of your suggestion.  If I understand correctly, the action of moving a row up or down would mount or unmount a partition respectively.  If this is the correct interpretation, then this seems to me to be an unusual and non-intuitive behaviour.  Also this would use up much more screen space, and I like to keep GParted functional on small screens too.

If I have misinterpreted your suggestion, then perhaps you could create a screen mock up, or draw a picture to illustrate your suggestion.

(In reply to comment #22)
> I do not intend to do this because I am content with the icon
> currently used for GTK-STOCK-DIALOG-AUTHENTICATION.

You like one variant which is not portable for your use case.

How do you think about the inclusion of an extra picture as a program resource for your desired symbol?
http://developer.gnome.org/gtkmm/3.0/namespaceGtk_1_1Stock.html#af5a3d62d679e3dd162bd77ac76205105


> If this is correct then I do not think that the information displayed
> warrants adding a column row grouping.

I suggest this arrangement so that sorting would be supported for each attribute "status" and "mount point".

An other live example for this GUI style:
http://www.sencha.com/examples/pages/grid/columngrouping.html


> My preference is to keep the GUI as simple as possible,
> and not loose an extra line of screen space for titles.

Does your "Sample 2" use a separate column?


> If this is the correct interpretation, then this seems
> to me to be an unusual and non-intuitive behaviour.

It would make the distinction for adjustable partitions more explicit, wouldn't it?

http://developer.gnome.org/gtkmm/3.0/classGtk_1_1Paned.html#_details
http://developer.gnome.org/gtk-tutorial/2.90/x1330.html#SEC-PANEDWINDOWWIDGETS

Let me suggest that we step back from this issue for a moment and look at it from a different perspective.

I think we have fallen into a common developer trap of throwing programming concepts at an issue in an attempt to solve a problem which is not clearly defined.

My recommendation is that we first define the problem from a users perspective.  Then when we have agreement on that we can think about how to try to fix the problem.


So in this line of thinking I will try to define the problem:

PROBLEM (FROM A USER PERSPECTIVE)
---------------------------------
The user is unable to perform an operation on a partition.
She is not aware of why she cannot perform the operation on the partition.
Further, she does not know what to do next to enable her to perform the operation on the partition.

EXAMPLE SCENARIO
----------------
The user wishes to resize her root "/" partition.
She selects the partition.
When she tries to choose the "Resize/Move" operation, this option is greyed out and is not available to her.  She does not know how to proceed from this point.

TECHNICAL REASON WHY RESIZE/MOVE OPERATION IS GREYED OUT
--------------------------------------------------------
The root "/" partition is currently mounted and in-use.
It is currently not possible to resize partitions that are in-use.


Do you agree that this is the problem encountered from the users perspective?

(In reply to comment #24)
> Let me suggest that we step back from this issue for a moment and look at it
> from a different perspective.

I am surprised about this suggestion for another wording approach.


> I think we have fallen into a common developer trap of throwing
> programming concepts at an issue in an attempt to solve a problem
> which is not clearly defined.

I thought that the mentioned open issues were described in a way that was clear enough.


> Then when we have agreement on that we can think about how to try
> to fix the problem.

Agreements are the usual communication challenges, aren't they?   ;-)


> Do you agree that this is the problem encountered from the users perspective?

Yes, of course. (My "special case" was that an activated swap partition blocked storage adjustments temporarily.)

I hope that the presentation of corresponding actions can be improved for your tool. A few options need further clarifications.

(In reply to comment #25)
> (In reply to comment #24)
> > Do you agree that this is the problem encountered from the users perspective?
> 
> Yes, of course. (My "special case" was that an activated swap partition blocked
> storage adjustments temporarily.)

Now that we are in agreement, let us forget about how GParted currently tries to communicate the in-use problem by using a lock icon.

Recognizing the series of steps the user goes through to perform an operation on a partition, is there somewhere in those steps that we could provide the needed information?

(In reply to comment #26)
> Now that we are in agreement, let us forget about how GParted currently tries
> to communicate the in-use problem by using a lock icon.

We do not need to forget it because this is a valid approach in principle.


> Recognizing the series of steps the user goes through to perform an operation
> on a partition, is there somewhere in those steps that we could provide the
> needed information?

Yes, of course. - It depends also on your willingness to present the involved data in alternative user interface styles with eventually increasing levels of verbosity and detail.

I strive to ensure that GParted is usable on small screens.  With that in mind, I am open to considering new layouts that would improve upon GParted's presentation of information.

Throughout this thread you have come up with many suggestions.  Would you be able to create a screen mock up that includes your ideas?

This would make it much easier for me to understand what you have envisioned in your mind.

(In reply to comment #28)
> Would you be able to create a screen mock up that includes your ideas?

I guess that a few of my ideas will result in bigger GUI alternatives to which you are reluctant at the moment. They can be discussed later ...

Now I would prefer to continue our design clarification with a fine-tuning of the layouts that are shown in your two samples (attachment #197084 [details] and attachment #197092 [details]) so that we can concentrate on easier incremental improvements. I recommend to get rid of the dependency on the symbol "Gtk::Stock::DIALOG_AUTHENTICATION". The display of (tri-state) check boxes would also be sufficient for its purpose, wouldn't it?

My preference would be to continue with the design shown in attachment #197092 [details].  This is the one in which we display a lock icon directly in front of the mount point.

In the case of an extended partition, the lock would be displayed all by itself due to a logical partition having a file system partition mounted, or a swap partition active.

A swap partition would have the lock icon also without a mount point.

In the case of both the extended partition and a swap partition we could add text like "active" or "in use" beside the icon to help clarify that the partition is in use.

I also agree with getting rid of the dependency on the symbol
"Gtk::Stock::DIALOG_AUTHENTICATION".

Regarding the tri-state check box, I assume that an extended partition would have an indeterminate state in the tri-state checkbox until all logical partition had been deactivated.

Also did you intend that if a person de-activated a checkbox that the partition would be unmounted, or swapped-off?

Or did you intend the lock icon to be replaced by the tri-state checkbox?

(In reply to comment #30)
> This is the one in which we display a lock icon directly in front
> of the mount point.

Does the notification symbol "Gtk::Stock::DIALOG_WARNING" (triangle with an exclamation mark) also need a separate column for sort support?


> In the case of both the extended partition and a swap partition
> we could add text like "active" or "in use" beside the icon
> to help clarify that the partition is in use.

This would be helpful textual feedback, too.


> I also agree with getting rid of the dependency on the
> symbol "Gtk::Stock::DIALOG_AUTHENTICATION".

I'm glad that we have achieved consensus on this implementation detail.


> Also did you intend that if a person de-activated a checkbox
> that the partition would be unmounted, or swapped-off?

Yes. - A confirmation dialogue can be optionally displayed if an entry will be (un)ticked.
How do you think about such a handling?


(In reply to comment #31)
> Or did you intend the lock icon to be replaced by the tri-state checkbox?

Yes. - I find such a change useful.

(In reply to comment #32)
> (In reply to comment #30)
> > This is the one in which we display a lock icon directly in front
> > of the mount point.
> 
> Does the notification symbol "Gtk::Stock::DIALOG_WARNING" (triangle with an
> exclamation mark) also need a separate column for sort support?

My thoughts are not to have a separate column for the "Gtk::Stock::DIALOG_WARNING" (triangle with an exclamation mark).

In my opinion this item is not useful as a sort criteria.

On the topic of sorting, what are your thoughts regarding logical partitions within an extended partition?

Currently the information in GParted is displayed according to the logical layout on the disk.  Would sorting cause more confusion than the value it adds?


> > Also did you intend that if a person de-activated a checkbox
> > that the partition would be unmounted, or swapped-off?
> 
> Yes. - A confirmation dialogue can be optionally displayed if an entry will be
> (un)ticked.
> How do you think about such a handling?

I think an confirmation dialog is a good idea.


> (In reply to comment #31)
> > Or did you intend the lock icon to be replaced by the tri-state checkbox?
> 
> Yes. - I find such a change useful.

I agree with changing the lock icon to the tri-state checkbox.


Did you have more ideas in this area?
Do you think a screen mock up useful so that we can confirm we are on the same line of thinking?

(In reply to comment #33)
> In my opinion this item is not useful as a sort criteria.

I would be interested in the feature to order or filter by special notifications.


> On the topic of sorting, what are your thoughts regarding logical partitions
> within an extended partition?

Would you like to distinguish a bit more between these partition types in the GUI?


> Do you think a screen mock up useful so that we can confirm
> we are on the same line of thinking?

I do not think that another picture is needed to show a mount status column which will contain check boxes.

(In reply to comment #34)
> (In reply to comment #33)
> > In my opinion this item is not useful as a sort criteria.
> 
> I would be interested in the feature to order or filter by special
> notifications.

If you see value to this, then I am open to having a separate thin column for these notifications.  This column might be displayed only when there is at least one special notification.

A textual tool tip for this column might be a useful addition too.


> > On the topic of sorting, what are your thoughts regarding logical partitions
> > within an extended partition?
> 
> Would you like to distinguish a bit more between these partition types in the
> GUI?

Distinguishing between the partition types would be useful for MSDOS partition tables.  Did you have some ideas on how we might do this?


> > Do you think a screen mock up useful so that we can confirm
> > we are on the same line of thinking?
> 
> I do not think that another picture is needed to show a mount status column
> which will contain check boxes.

I was thinking of a screen mockup when we have finished identifying the improvements.  From reading your response it appears that we have a few more ideas to discuss.

(In reply to comment #35)
> Did you have some ideas on how we might do this?

Will a corresponding clarification belong to a new feature request?


> From reading your response it appears that we have a few more ideas to discuss.

Which details would you like to clarify a bit further here? (Will the discussion of any issues be continued with other "bug reports"?)

Who should start with an implementation candidate for the accepted changes?

(In reply to comment #36)
> (In reply to comment #35)
> > Did you have some ideas on how we might do this?
> 
> Will a corresponding clarification belong to a new feature request?

Good point Markus.  I think perhaps we should not expand the scope of this change too far.  This bug report deals with confusion over the lock icon and how to grow an extended partition.  Let's focus on addressing that problem.


> > From reading your response it appears that we have a few more ideas to
> > discuss.
> 
> Which details would you like to clarify a bit further here? (Will the
> discussion of any issues be continued with other "bug reports"?)

Assuming we limit the scope of this change as mentioned above, I think we are ready to implement the new changes.  A new bug report can be created to track each additional issue (such as a separate column for the "Gtk::Stock::DIALOG_WARNING".


> Who should start with an implementation candidate for the accepted changes?

I would appreciate if you could start the implementation candidate.

(In reply to comment #37)

I am curious if the following feature requests will also result in constructive discussions.
- Bug #660466: Sort support for notifications
- Bug #660483: Reuse of software architecture "Model-View-Controller"

(In reply to comment #38)

Yes, we can have constructive discussions on these other feature requests.

My preference is to focus on a small number of issues at one time.  Since I am also working to make GParted compliant with GNOME 3 (see Bug #652044), I would prefer that we address this issue first before launching into discussion on the other feature requests.

To summarize our discussion on this bug report, I believe we landed on the following:

1)  To move the in-use notification (currently a lock icon) from the
    "Partition" column to the "Mount Point" column.

2)  To change the in-use notification from
    "Gtk::Stock::DIALOG_AUTHENTICATION" (lock icon) to a tri-state checkbox.

3)  To enable to the tri-state checkbox to initiate unmount and swapoff of
    partitions.
    Correspondingly activating a checkbox could initiate mount and swapon
    of partitions if a mount point exists or the partition type is linux-swap
    respectively.

4)  To display a confirmation dialog when a user has clicked on a tri-state
    checkbox before changing the in-use state of the partition.

(In reply to comment #39)

I am curious on another implementation detail. Which label would you like to use for the new (narrow) column header?
Do you want to switch between a text display and a specific ideogram (for languages that do not use logographies)?

Do you know any dedicated gtkmm class for such a display feature?

Which new (narrow) column header are you referring to?

I thought we decided to place the tri-state checkbox at the front of the "Mount Point" column (points #1 and #2 in comment #39).

(In reply to comment #41)

I suggest to insert a column "is mounted" between the columns "File System" and "Mount Point". It might be that this new label (and translated variants) will make the column a bit too wide.

(In reply to comment #42)

I agree that such a column would be too wide to be practical on small screens.

One way we might work-around this limitation might be to only display the column when at least one file system is mounted.

Since the "is mounted" column would represent more than just mounted file systems (e.g., active swap space, and also an extended partition with at least one mounted logical partition), perhaps we should call the column "Active", "Is Active", or "In Use"?

(In reply to comment #43)
> One way we might work-around this limitation might be to only display the
> column when at least one file system is mounted.

Should the column "Mount Point" also be hidden in this special case?

Would you still like to support the partition mounting/activation by ticking an entry in the table view?


> Since the "is mounted" column would represent more than just mounted file
> systems (e.g., active swap space, and also an extended partition with at least
> one mounted logical partition), perhaps we should call the column "Active", "Is
> Active", or "In Use"?

However you choose a meaningful textual label it will become wider in some languages than the width of a check box when you really need it, won't it?

Would you like to use a customised widget which might enable an alternative display for the corresponding column header?

(In reply to comment #44)
> (In reply to comment #43)
> > One way we might work-around this limitation might be to only display the
> > column when at least one file system is mounted.
> 
> Should the column "Mount Point" also be hidden in this special case?

The "Mount Point" column already has special display handling.  The "Mount Point" column is only displayed when at last one mount point can be found.  The mount point does not need to be active (e.g., contained in /etc/fstab, but not currently mounted).


> Would you still like to support the partition mounting/activation by ticking
> an entry in the table view?

I would like to do this.  This is why I think that we do not need an extra column for the tristate checkbox.  I think it would work well if placed at the front of the data inside the "Mount Point" column.

 
> > Since the "is mounted" column would represent more than just mounted file
> > systems (e.g., active swap space, and also an extended partition with at least
> > one mounted logical partition), perhaps we should call the column "Active", "Is
> > Active", or "In Use"?
> 
> However you choose a meaningful textual label it will become wider in some
> languages than the width of a check box when you really need it, won't it?
> 
> Would you like to use a customised widget which might enable an alternative
> display for the corresponding column header?

Since we have had difficulty with what icons represent, I would prefer to not to use icons.  Also I propose again that we do not need a separate column for the tristate checkbox.

(In reply to comment #45)
> I think it would work well if placed at the front of the data
> inside the "Mount Point" column.

I prefer to keep such fields separate. This separation would prepare for sort support for each column (if you would ever like to enable this feature).


> Since we have had difficulty with what icons represent,
> I would prefer to not to use icons.

We try to resolve the open issue from a reference to a specific symbol with an inappropriate meaning. But I do not want to exclude them altogether. Additional stock icons could be eventually considered for your application.

Ideograms result in communication challenges which are unavoidable.
http://en.wikipedia.org/wiki/Computer_icon#Cultural_context


> Also I propose again that we do not need a separate column
> for the tristate checkbox.

I have got a different opinion.

(In reply to comment #46)
> > Also I propose again that we do not need a separate column
> > for the tristate checkbox.
> 
> I have got a different opinion.

You will need to sell me more on the usefulness of a separate column.  At the moment the added complexity does not seem to be worth the extra screen real estate to me.

What real world partition editing problem would benefit by having a separate (even sortable) "in-use" column?

How would the separate "in-use" column help solve the partition editing problem?

Is there a reason why we can not solve this bug report without a separate "in-use" column?

(In reply to comment #47)
> What real world partition editing problem would benefit by having a separate
> (even sortable) "in-use" column?

Do table widgets benefit from sort support for their columns?
http://developer.gnome.org/gtkmm-tutorial/stable/sec-treeview-sort.html#treeview-sort-headers

How do you think about the use of the abbreviation "IU" as a label while tool tips will display longer descriptions?

Does your desire for "parsimony" with screen space need it really that two fields should share the same column header?

Created attachment 198651 [details]
Sample 3 - GParted with new check box column before mount point

(In reply to comment #47)

Do you find this preview acceptable from my openSUSE 11.4 system?

The picture does look good to me.  With a title of "IU", the column does not take up much room.  I would be in favor of proceeding with the solution you outline in the picture from comment #49.

With the extended partition, it is not possible for a person to umount or swapoff the partition if it is active.  Instead the active logical partitions within the extended partitions must be swapped off or unmounted.  Would it be possible to indicate this with the tri-state checkbox (a greyed out checkbox)?

(In reply to comment #50)
> With a title of "IU", the column does not take up much room.

I guess that we will need also consensus on a hint about this abbreviation for translators.


> I would be in favor of proceeding with the solution you
> outline in the picture from comment #49.

Thanks for your agreement.


> Would it be possible to indicate this with the tri-state checkbox
> (a greyed out checkbox)?

Yes. - But I admit that I struggle still with the implementation for the (automatic) synchronisation between a "Gtk::TreeModelColumn" and a corresponding "Gtk::CheckButton" in the view. I hope that I can try out a mapping to a widget property like "inconsistent" soon.
http://developer.gnome.org/gtkmm-tutorial/stable/sec-treeview.html.en#treeview-cellrenderer-details
http://developer.gnome.org/gtkmm/3.2/classGtk_1_1ToggleButton.html#aa307db71584e2165b590e175b80feb5b

(In reply to comment #51)
> (In reply to comment #50)
> > With a title of "IU", the column does not take up much room.
> 
> I guess that we will need also consensus on a hint about this abbreviation for
> translators.

I am okay if we add a comment directly above the line of code containing "IU" to be translated.  That way we can inform translators the purpose of the column, and also that we are trying to keep the column narrow.


Do you need answers to any other bug reports to be able to start work on this enhancement?

(In reply to comment #52)
> I am okay if we add a comment directly above the line of code containing "IU"
> to be translated.

Would we like to start the fine-tuning for a corresponding wording here?


> Do you need answers to any other bug reports to be able to start work on this
> enhancement?

Yes. - But this depends on the kind of reports and stories you might be interested in.

Examples:
- I have to cope with a recent failure from my computer hardware. I can give you feedback here from a different computer because of the nice support from a local neighbour.
  I hope to build a new software development system in the next two weeks.

- I admit that I see also still some other challenges.
  * I try to become more familiar with GTK+ (or gtkmm) implementation details.
  * I dared to ask some detailed questions on corresponding mailing lists. I'm unsure if these requests are interpreted as topics for constructive discussions by the involved software development community which can lead to useful changes.

(In reply to comment #53)
> (In reply to comment #52)
> > I am okay if we add a comment directly above the line of code containing "IU"
> > to be translated.
> 
> Would we like to start the fine-tuning for a corresponding wording here?

We can look into fine tuning the wording when you have the first patch ready.  Getting the code to work is the hard part.  :-)


> > Do you need answers to any other bug reports to be able to start work on this
> > enhancement?
> 
> Yes. - But this depends on the kind of reports and stories you might be
> interested in.
> 
> Examples:
> - I have to cope with a recent failure from my computer hardware. I can give
> you feedback here from a different computer because of the nice support from a
> local neighbour.
>   I hope to build a new software development system in the next two weeks.
> 
> - I admit that I see also still some other challenges.
>   * I try to become more familiar with GTK+ (or gtkmm) implementation details.
>   * I dared to ask some detailed questions on corresponding mailing lists. I'm
> unsure if these requests are interpreted as topics for constructive discussions
> by the involved software development community which can lead to useful
> changes.

My question was more related to open bug reports that you have created for GParted.

Regarding learning GTK+ (or gtkmm), I find that searching the Internet, reading, testing code examples, and writing your own code is the best way to learn.

(In reply to comment #54)
> Regarding learning GTK+ (or gtkmm), I find that searching the Internet,
> reading, testing code examples, and writing your own code is the best way
> to learn.

Have you got any more experiences for corresponding classes than me eventually?
Would you like to clarify any open issues for implementation details by a cooperation on mailing list disussions?
(I hope that my hardware failure can be bridged with other constructive approaches until my next personal software development system will become usable. Does any progress become more attractive for other GParted feature requests in the meantime?)

The most effective way I have found to fix bugs is to start with a patch.  Then testing and constructive review can occur.  Small patches are preferred.  For examples of this approach see the following bug reports:

   Bug #438573 - cancel out overlapping actions
   Bug #171215 - Support lost partition recovery

If you currently are not in a position to develop a patch, perhaps you could help other users with problems they might be experiencing.  There are many forums and mailing lists with users that could benefit from your knowledge.

(In reply to comment #56)
> The most effective way I have found to fix bugs is to start with a patch.

I find alternative approaches which do not need to specify changes in the source code language also useful. It is often possible to achieve progress for involved details by simple communication without actions that require the compilation of source files and linking of object code.

Clarification candidates for GTK+:
1. Representation of nullable data types
2. Consistent document attributes (base/display modell) for editing
3. Is a custom "CheckButton" class needed?

Created attachment 205643 [details] [review]
intermediate update suggestion

(In reply to comment #56)
> The most effective way I have found to fix bugs is to start with a patch.

I hope that the started discussion can be continued in constructive ways with this unfinished change try.

I imagine that some efforts will still be needed to resolve open issues like the following.
- How to forward accesses from model attributes to other class attributes?
  http://mail.gnome.org/archives/gtkmm-list/2011-October/msg00063.html

- Function completion for GVariant maybe types?
  http://mail.gnome.org/archives/gtk-devel-list/2011-December/msg00021.html

This bug appears to have meandered around a lot in discussion.  Could the title be updated to reflect what actually needs changed?

Good point Phillip.

If I recall correctly, the original report dealt with being unable to move the beginning of the extended partition.  The cause was due to the extended partition being busy since at least one logical partition was active (linux-swap in use).  To be able to move the extended partition, all of the logical partitions had to be de-activated (not in-use).

I agree that this report does meander around a lot and is very difficult to follow.

Perhaps the title could be "Improve partition in-use indicator means actions unavailable" or something like that.

Overall I really don't know what to improve this situation.

(In reply to comment #60)
> Overall I really don't know what to improve this situation.

Would any more software designers and developers like to contribute useful information for issues that were mentioned in comment #13 and comment #57 / comment #58?

Perhaps this should be closed then since we already have a bug to ship our own lock icon instead of relying on that provided by the distribution?

I am inclined to follow Phillip's suggestion in comment #62.  

Specifically close this report as duplicate of:
Bug #667414 - gparted should ship its own padlock icon

In response to Markus' comment #61, currently I do not see value in adding an extra column in the tree view for an "In-Use" indicator.  Firstly because it takes up extra space unnecessarily.  And secondly because I see no value in being able to sort by "In-Use" indicators.  The tree view listing should remain as an ordered list of partitions.

As Markus mentioned, are there any other developers that would like to comment on this?

(In reply to comment #63)
> I am inclined to follow Phillip's suggestion in comment #62.  

Would you like to consider differences in accessibility and understandability between icon display and the use of extra table column(s)?
http://developer.gnome.org/hig-book/stable/controls-lists.html#controls-lists-sortable

The only difference I see is whether you can sort on that attribute or not, and as Curtis said, there doesn't seem to be any reason to do that.

(In reply to comment #65)

Can tables be navigated better by screen readers for example than other graphical representations?

(In reply to comment #66)
> Can tables be navigated better by screen readers for example than other
> graphical representations?

This question fits better with the following report:
Bug #539185 - Improve knowledge presentation about partitions

Since there have been no further comments I am closing this bug report as discussed in comment #63.

*** This bug has been marked as a duplicate of bug 667414 ***