After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 583888 - Resize/move dialog does not unfade 'Resize' button when size entered using keyboard
Resize/move dialog does not unfade 'Resize' button when size entered using ke...
Status: RESOLVED OBSOLETE
Product: gparted
Classification: Other
Component: application
GIT HEAD
Other All
: Normal minor
: ---
Assigned To: gparted maintainers alias
gparted maintainers alias
Depends on:
Blocks:
 
 
Reported: 2009-05-26 12:38 UTC by Jan Claeys
Modified: 2020-11-13 10:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jan Claeys 2009-05-26 12:38:54 UTC
When the position or size in the resize/move dialog is entered using the keyboard, the 'Resize' button does not become active until after you move the focus to another widget.

Reported in Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/115860

Reproducable steps from the Ubuntu report copied below:
----
To reproduce:

* Right click on a partition and choose Resize/Move.

* Observe that the Resize button is faded as no choice has yet been made

* Click in either the New Size or Free Space Following text entry fields and enter a new value

* Observe that the Resize button has not been unfaded, and the graphical control at the top of the dialogue has not been updated

Workaround (not obvious to inexperienced user):

* Press tab after entering the new size; the dialogue is correctly updated
Comment 1 Curtis Gedak 2009-11-05 19:33:58 UTC
Thank you Jan for posting this bug report upstream.

There are a few ways to tackle this issue, but I am not sure which is the right way to do it from a GNOME user interface perspective.

Currently GParted allows a user to enter in any number in one of "Free space preceeding", "New size", or "Free space following".  Then when the user changes the focus, GParted will recalculate appropriate values for other fields and update the graphic display.  If the number entered is invalid, GParted will return the numbers to the original values.

A second way to address this issue is to have GParted actively monitor each digit that the user types.  If a digit is entered that makes the field value too large or too small, then the digit can be ignored (not entered or displayed in the field).  This can pose a different type of frustration for the user in that the keyboard appears unresponsive.

A third way is to always have the resize/move button enabled.  If the user clicks on the button and no changes have been made, then no resize operation would be added to the operations queue.  This might be the method with the least drawbacks from a user perspective.

Perhaps there is better way to address this issue?

Your thoughts on this issue would be appreciated.
Comment 2 André Klapper 2020-11-13 10:40:44 UTC
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time.

If you still use gparted and if you still see this bug / want this feature in a recent and currently supported version, then please feel free to report it at
https://gitlab.gnome.org/GNOME/gparted/-/issues/
by following the guidelines at
https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines

Thank you for creating this report and we are sorry it could not be implemented so far (volunteer workforce and time is limited).