Bug 450176

Summary:	Partitioner User Interface
Product:	[openSUSE] openSUSE 11.1	Reporter:	Jim Omura <jimomura>
Component:	YaST2	Assignee:	Arvin Schnell <aschnell>
Status:	RESOLVED FIXED	QA Contact:	Jiri Srain <jsrain>
Severity:	Minor
Priority:	P3 - Medium	CC:	aschnell, forgotten_h13THG8RK1
Version:	RC 1
Target Milestone:	---
Hardware:	x86
OS:	SUSE Other
Whiteboard:
Found By:	Beta-Customer	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	FsTab menu shot YaST2 logs after Partitioner "Next" button

Description Jim Omura 2008-11-28 21:05:19 UTC

This report concerns a bug found while attempting to reproduce a
problem reported in Bug #446349.  The following is an edited summary:

- turn off "desktop effects"

- start partitioner [warning window comes up]

- click on "yes"

 [it detects the drivers, gives me a warning window about an SD card in a slot
which cannot be fully handled by parted]

- select the hard driver "/dev/sda"

- click on the "next" button

 [* At this point the program exits without warning and the window disappears]

I tried the "/sbin/yast2 disk --qt" with "Desktop Effects on" and it behaves
about the same.

The Issue:

The "Next" option aborts the editor if there is no task awaiting execution.
This is probably because it was intended to be used in the context of the
"Installer".  As it is, this is not really a good idea in either on its own or
even when used in the installer because the interface is not sufficiently
explicit.  Unless you are very familiar with it, or you are sitting with the
documentation in your lap, there is a good chance that you will hit the
"next" button expecting more options (which is what I did).  In such a case,
you should have another dialog box saying something like:

"No changes to be made.  Exit the Partition Editor?

[Return To Partition Editor] [Exit]"

> ------- Comment #11 From Ricardo Cruz 2008-11-26 17:11:48 MST -------

(In reply to comment #9 from Jim Omura) 

. . .

> Yeah, that's definitively a bug. (It should be renamed to "Ok" according to
> the new yast style guide.) Arvin has removed himself from this bug report
> though; could you open a new report for that one? A couple of searches don't
> catch it reported.

Comment 1 Andreas Jaeger 2008-11-29 08:37:49 UTC

Please attach the YaST log files for the failure as explained at http://en.opensuse.org/Bugs/YaST

Comment 2 Forgotten User h13THG8RK1 2008-11-30 20:01:36 UTC

Surely, the yast logs aren't needed. It's a UI bug. "Next" being used instead of "Ok".

Comment 3 Forgotten User h13THG8RK1 2008-11-30 20:08:09 UTC

Created attachment 256812 [details]
FsTab menu shot

Arvin, can you have a look at this issue as well. It's what Jim was referring to in bug 446349. We probably want dialogs to fit in a 800x600 display with the default fonts. Maybe we could layout some of those horizontally. I would think that those spacings would break first before the ButtonBox -- maybe not using spacings? (btw, gtk layout is done at the libyui level just like qt).

Comment 4 Arvin Schnell 2008-11-30 20:46:29 UTC

Ok, I'll look at the button text.

Comment 5 Jim Omura 2008-12-01 03:45:15 UTC

Created attachment 256830 [details]
YaST2 logs after Partitioner "Next" button

These are the YaST2 logs after running the Partitioner and ending with the "Next" button (11.1 RC1).  "Desktop Effects" was "off".

Comment 6 Katarina Machalkova 2008-12-11 09:09:51 UTC

(at least) three options how to solve this

1) Label the button as 'Finish' and re-label it to 'Next' as soon as any change to be saved is made. Drawback: checking for "have any changes been made?" can be too expensive operation to be done in (almost) every single event handler

2) Keep 'Next' label and show a pop-up saying something like "There are no unsaved changes. Exit the partitioner? [yes] [no]" Drawback: it worked that way in past, we removed the pop-up recently because users were disturbed and annoyed with it

3) Keep 'Next' label and show full-screen summary with "Changes to partitioning: no unsaved changes exist" (or alike) text. Drawback: one extra dialog (useless in this case), full-screen summary looks empty

Pick your poison ...

Comment 7 Arvin Schnell 2008-12-11 10:20:07 UTC

*** Bug 458198 has been marked as a duplicate of this bug. ***

Comment 8 Arvin Schnell 2008-12-11 13:42:19 UTC

I'll look at implementing solution 1 but only check for changes after
modification have been done. Most (unfortunately not all) functions doing
modification call UpdateNavigationTree already. So the check can either be implemented there or some extra function must be called.

Comment 9 Arvin Schnell 2008-12-11 13:59:38 UTC

Done as explained in comment #8 in yast2-storage 2.17.62.

Comment 10 Jim Omura 2008-12-16 00:24:08 UTC

(In reply to comment #6 from Katarina Machalkova)
> (at least) three options how to solve this

> 1) Label the button as 'Finish' and re-label it to 'Next' as soon as any change
> to be saved is made. Drawback: checking for "have any changes been made?" can
> be too expensive operation to be done in (almost) every single event handler

> 2) Keep 'Next' label and show a pop-up saying something like "There are no
> unsaved changes. Exit the partitioner? [yes] [no]" Drawback: it worked that way
> in past, we removed the pop-up recently because users were disturbed and
> annoyed with it

> 3) Keep 'Next' label and show full-screen summary with "Changes to
> partitioning: no unsaved changes exist" (or alike) text. Drawback: one extra
> dialog (useless in this case), full-screen summary looks empty

For options 2 and 3, you could also add either a -v (verbose) or -q (quiet) mode switch.  In "quiet" mode the last window would not be used.  If you default to "quiet" then you will not get the window in installer.  When you install the program's icon, you would add a "-v" switch which a user could remove.

As for the first option, it may seem "expensive", but if you think about it, the only time this is being done is when a human being is mucking around setting up partitions.  A few thousand extra cycles is nothing in that context. . . .