Bug 2083

I've mocked up the desired functionality outside of hob and determined that we can implement the layers dialogue per the attached design.

Now I *just* need to integrate this into Hob.

Created attachment 372 [details]
WIP implementation of the layer dialogue

I've begun working on the layer dialogue to make it more closely match the design. Three outstanding items remain.

The WIP implementation retains the label and info button at the top of the dialogue, this is not present on the design. Should it be removed?

My WIP also includes a close button at the bottom, this is required so that users of Gnome Shell (i.e. on Fedora) can dismiss the dialogue - modal dialogues in the Gnome Shell do not include close buttons.

Created attachment 378 [details]
Layer dialog visual design (no mouseover)

Created attachment 379 [details]
Layer dialog visual design (mouseover)

Created attachment 380 [details]
delete button

Created attachment 381 [details]
delete button (mouseover)

Created attachment 382 [details]
add icon

Created attachment 383 [details]
add icon mouseover

Created attachment 384 [details]
Screenshot showing current layer dialogue

The attached screenshot shows the layer dialogue with the assets recently attached to this bug (thanks!).

The main ways in which this currently differs from the design are:
1) close button style
2) the presence of a save button

Dongxiao has requested we gather feedback from the design team before removing the save button. Specifically he asked:

"If users did some trial operations, for example deleted some layers, is
it better that we provide a "cancel" button for users to ignore their
changes?"[1]

1. http://lists.linuxtogo.org/pipermail/bitbake-devel/2012-March/002274.html

Hi all,

First of all, it looks good! :)

About the 'Save' action: from the beginning the layers dialog was conceived as an 'Instant apply window' as described in:

http://developer.gnome.org/hig-book/3.0/windows-utility.html.en

The reasons:

1. This window type reduces the amount of controls required by the interface (this is always a good thing)
2. This window type reduces the amount of actions required by the user (I don't need to click 'Apply' to see my changes go through)
2. The interface provides appropriate feedback for both dialog actions. When I delete, the deleted layer disappears from the layers list. When I add, a layer appears in the layers list. Therefore, there is no need to 'reinforce' the feedback with a 'Save' button. 

If users added a layer and they no longer want it, deleting it is a very economical operation (just one click on the delete icon next to the layer). If they deleted a layer and they want it back, adding it again it's also straightforward. 

About the 'Close' button style, this is linked to bug 2105 about applying the visual design for secondary actions across Hob. We can therefore verify this bug and close it with the 'Close' button as is: we'll tackle the visual style as part of 2105.

Cheers

Belen

Great work!

Could you please add the dialog title 'Layers'?

Several changes merged which bring the implementation closer to the design. Another patch will be submitted today to ensure the layers which can't be disabled are sorted together at the top of the list.

Additional conversations about this bug happening on the BitBake mailing list are below:

On 26/03/2012 15:58, "Barros Pena, Belen" <belen.barros.pena@intel.com> wrote:

Hi all,

Just a few comments:

>still users may miss deleted some critical layers. For example, in
>our Yocto project, users may wrongly deleted meta-yocto, which will
>cause the system reporting error like: "DISTRO poky not found. Please set
>a valid DISTRO in your local.conf"
>This is because the poky distro is defined in meta-yocto layer, and user
>deleted meta-yocto by mistake.

We designed the Layers dialog so that it is not possible to delete the
meta layer. If deleting the meta-yocto layer is also going to cause
problems that a novice might not be able to recover from, then we should
consider applying the same approach to the meta-yocto layer so that it
cannot be removed. If anybody has any reasons why this is not a good idea,
please let me know.

>I saw in the design document(Hob_1.2_screens_inventory.pdf), there are
>"save" and "cancel" button in advanced setting page.

Quoting the Gnome HIG
(http://developer.gnome.org/hig-book/3.0/windows-utility.html.en):

Do not make the user press an OK or Apply button to make the changes
happen, unless either:

* the change will take more than about one second to apply, in which case
applying the change immediately could make the system feel slow or
unresponsive, or
* the changes in the window have to be applied simultaneously to prevent
the system entering a potentially unstable state. For example, the
hostname and proxy fields in a network properties window.

The Settings dialog is so complex and edits so many different variables
that I assumed it could fall into one of the 2 points above. That's why I
designed it as an Explicit Apply window. If my assumption it's incorrect,
please go ahead and remove the Save and Cancel buttons: I'll be very happy
to see them go :) Keep in mind that we'll still need a close button to
dismiss the dialog.

>The design team wants to make few interactions and make things simple.
>The engineering team wants to give the users a chance to restore to the
>default or skip the changes he/she has made.
>What if the user removes a layer in error?

These are the reasons why we have designed the Layers dialog as an instant
apply window:

1. Because it's how the Gnome HIG recommends doing things, and we have no
evidence of any kind suggesting this is the wrong approach for the Layers
dialog.
2. Because deleting a layer by mistake constitutes an edge case: I am sure
you will agree users will probably not be deleting layers by mistake all
the time. I try not to optimise designs for edge cases, but for the main
use cases while preventing catastrophic errors (hence the decision to make
the meta layer non-removable).

Having said this, feel free to make the decision you consider appropriate
:)

>Do you think if it is reasonable to add a confirmation dialog when user
>trying to delete a layer?

I can see why you are suggesting this approach (particularly in the case
of the meta-yocto layer), but I rather not add an extra step to any
process unless it is absolutely necessary. I tend to favour providing undo
functionality instead.

I am going to copy this thread on the relevant bug to make sure we have
all our conversations in the same place. Otherwise it'll be hard to follow
and fully understand our design decisions if we need to go back to them in
the future.


Cheers

Belen



On 26/03/2012 07:10, "Xu, Dongxiao" <dongxiao.xu@intel.com> wrote:

On Mon, 2012-03-26 at 12:07 +0800, Wang, Shane wrote:
That is really conflict.
The design team wants to make few interactions and make things simple.
The engineering team wants to give the users a chance to restore to the
default or skip the changes he/she has made.
The previous solution with "Save" and "Cancel" is an option.
The current solution with "Close" is an option. What if the user
removes a layer in error?
What Dongxiao suggested to ask users to confirm is also an option. But
what if there are a lot of layers to remove and a lot of confirmation
dialogs for impatient users?
I also have a bug filed by Josh to remember settings between Hob
sessions. QA raised an issue today that in Hob 1.1, when the user
changes some settings and save, which is supposed to cause an error and
make Hob not runable. Then, QA doesn't have any chance to initiate a
clean running, unless the build directory is deleted and "source" to
another directory.
Comments?

I saw in the design document(Hob_1.2_screens_inventory.pdf), there are
"save" and "cancel" button in advanced setting page.

I still for the layer dialog, the question is still open. I think my
point of view is similar with Shane's, that is to allow users have the
chance to ignore the change that he/she made in mistake.

Thanks,
Dongxiao

On 26/03/2012 07:10, "Xu, Dongxiao" <dongxiao.xu@intel.com> wrote:

On Mon, 2012-03-26 at 12:07 +0800, Wang, Shane wrote:
That is really conflict.
The design team wants to make few interactions and make things simple.
The engineering team wants to give the users a chance to restore to the default or skip the changes he/she has made.
The previous solution with "Save" and "Cancel" is an option.
The current solution with "Close" is an option. What if the user removes a layer in error?
What Dongxiao suggested to ask users to confirm is also an option. But what if there are a lot of layers to remove and a lot of confirmation dialogs for impatient users?
I also have a bug filed by Josh to remember settings between Hob sessions. QA raised an issue today that in Hob 1.1, when the user changes some settings and save, which is supposed to cause an error and make Hob not runable. Then, QA doesn't have any chance to initiate a clean running, unless the build directory is deleted and "source" to another directory.
Comments?

I saw in the design document(Hob_1.2_screens_inventory.pdf), there are
"save" and "cancel" button in advanced setting page.

I still for the layer dialog, the question is still open. I think my
point of view is similar with Shane's, that is to allow users have the
chance to ignore the change that he/she made in mistake.

Thanks,
Dongxiao

--
Shane
Xu, Dongxiao wrote on 2012-03-24:
> On Fri, 2012-03-23 at 18:07 -0700, Joshua Lock wrote:
>> On 23/03/12 18:00, Xu, Dongxiao wrote:
>>> On Fri, 2012-03-23 at 17:23 -0700, Joshua Lock wrote:
>>>> The design calls for primary buttons which are orange and large and
>>>> secondary buttons which are subtle with pale blue text. This is so
>>>> that the user is drawn towards the primary action and their use of
>>>> the application is more guided.
>>>>
>>>> This patch uses HobButton and HobAltButton classes to style all dialogue
>>>> buttons accordingly.
>>>>
>>>> Fixes [YOCTO #2125]
>>>>
>>>> Signed-off-by: Joshua Lock<josh@linux.intel.com>
>>>> ---
>>>>   lib/bb/ui/crumbs/builder.py |  106
>>>>   +++++++++++++++++++++++++++---------------- lib/bb/ui/crumbs/hig.py
>>>>       |   34 ++++++++------ 2 files changed, 87 insertions(+), 53
>>>>   deletions(-)
>>>> diff --git a/lib/bb/ui/crumbs/builder.py b/lib/bb/ui/crumbs/builder.py
>>>> index 4eb374c..e27a239 100755
>>>> --- a/lib/bb/ui/crumbs/builder.py
>>>> +++ b/lib/bb/ui/crumbs/builder.py
>>>> @@ -32,7 +32,7 @@ from bb.ui.crumbs.recipeselectionpage import
> RecipeSelectionPage
>>>>   from bb.ui.crumbs.packageselectionpage import PackageSelectionPage
>>>>   from bb.ui.crumbs.builddetailspage import BuildDetailsPage from
>>>>   bb.ui.crumbs.imagedetailspage import ImageDetailsPage
>>>> -from bb.ui.crumbs.hobwidget import hwc
>>>> +from bb.ui.crumbs.hobwidget import hwc, HobButton, HobAltButton
>>>>   from bb.ui.crumbs.hig import CrumbsMessageDialog,
> ImageSelectionDialog, \
>>>>                                AdvancedSettingDialog,
>>>>                                LayerSelectionDialog, \
>>>>                                DeployImageDialog
>>>> @@ -435,7 +435,8 @@ class Builder(gtk.Window):
>>>>               lbl = "<b>Error</b>\n"
>>>>               lbl = lbl + "%s\n\n" % msg
>>>>               dialog = CrumbsMessageDialog(self, lbl,
> gtk.STOCK_DIALOG_WARNING)
>>>> -            dialog.add_button(gtk.STOCK_OK, gtk.RESPONSE_OK)
>>>> +            button = dialog.add_button("Close", gtk.RESPONSE_OK)
>>>> +            HobButton.style_button(button)
>>>>               response = dialog.run()
>>>>               dialog.destroy()
>>>>           self.handler.clear_busy()
>>>> @@ -608,8 +609,10 @@ class Builder(gtk.Window):
>>>>       def destroy_window_cb(self, widget, event):
>>>>           lbl = "<b>Do you really want to exit the Hob image
>>>>           creator?</b>" dialog = CrumbsMessageDialog(self, lbl,
> gtk.STOCK_DIALOG_INFO)
>>>> -        dialog.add_button("Keep using Hob", gtk.RESPONSE_NO)
>>>> -        dialog.add_button("Exit Hob", gtk.RESPONSE_YES)
>>>> +        button = dialog.add_button("Cancel", gtk.RESPONSE_NO)
>>>> +        HobAltButton.style_button(button)
>>>> +        button = dialog.add_button("Exit Hob", gtk.RESPONSE_YES)
>>>> +        HobButton.style_button(button)
>>>>           dialog.set_default_response(gtk.RESPONSE_YES)
>>>>           response = dialog.run()
>>>>           dialog.destroy()
>>>> @@ -625,7 +628,8 @@ class Builder(gtk.Window):
>>>>               lbl = "<b>No selections made</b>\nYou have not made any
>>>>               selections" lbl = lbl + " so there isn't anything to
>>>>               bake at this time." dialog = CrumbsMessageDialog(self,
>>>>               lbl,
> gtk.STOCK_DIALOG_INFO)
>>>> -            dialog.add_button(gtk.STOCK_OK, gtk.RESPONSE_OK)
>>>> +            button = dialog.add_button("Close", gtk.RESPONSE_OK)
>>>> +            HobButton.style_button(button)
>>>>               dialog.run() dialog.destroy() return @@ -637,7 +641,8
>>>>               @@ class Builder(gtk.Window): lbl = "<b>No selections
>>>>               made</b>\nYou have not made any selections" lbl = lbl +
>>>>               " so there isn't anything to bake at this time." dialog
>>>>               = CrumbsMessageDialog(self, lbl,
> gtk.STOCK_DIALOG_INFO)
>>>> -            dialog.add_button(gtk.STOCK_OK, gtk.RESPONSE_OK)
>>>> +            button = dialog.add_button("Close", gtk.RESPONSE_OK)
>>>> +            HobButton.style_button(button)
>>>>               dialog.run() dialog.destroy() return @@ -652,7 +657,8
>>>>               @@ class Builder(gtk.Window): lbl = "<b>No selections
>>>>               made</b>\nYou have not made any selections" lbl = lbl +
>>>>               " so there isn't anything to bake at this time." dialog
>>>>               = CrumbsMessageDialog(self, lbl,
> gtk.STOCK_DIALOG_INFO)
>>>> -            dialog.add_button(gtk.STOCK_OK, gtk.RESPONSE_OK)
>>>> +            button = dialog.add_button("Close", gtk.RESPONSE_OK)
>>>> +            HobButton.style_button(button)
>>>>               dialog.run()
>>>>               dialog.destroy()
>>>>               return
>>>> @@ -672,8 +678,9 @@ class Builder(gtk.Window):
>>>>                        parent = self,
>>>>                        flags = gtk.DIALOG_MODAL
>>>>                            |
> gtk.DIALOG_DESTROY_WITH_PARENT
>>>> -                         | gtk.DIALOG_NO_SEPARATOR, -              
>>>>      buttons = (gtk.STOCK_CLOSE, gtk.RESPONSE_YES)) +                
>>>>         | gtk.DIALOG_NO_SEPARATOR) +        button =
>>>> dialog.add_button("Close", gtk.RESPONSE_YES) +      
>>>> HobButton.style_button(button)
>>>>           response = dialog.run()
>>>>           if response == gtk.RESPONSE_YES:
>>>>               self.configuration.layers = dialog.layers
>>>
>>> As my previous point, I still strongly suggest we keep the "cancel"
>>> button in the layer selection and advanced setting dialog to avoid
>>> user's wrong operation. Need Belen or Giulia's input.
>>
>> They both responded via Bugzilla, I mistakenly thought you were on CC -
>> apologies.
>>
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2083
>
> Thanks for the information.
>
> For Layer, I accept design team's idea to remove save and cancel button.
> But still users may miss deleted some critical layers. For example, in
> our Yocto project, users may wrongly deleted meta-yocto, which will
> cause the system reporting error like:
>
> "DISTRO poky not found. Please set a valid DISTRO in your local.conf"
>
> This is because the poky distro is defined in meta-yocto layer, and user
> deleted meta-yocto by mistake.
>
> Do you think if it is reasonable to add a confirmation dialog when user
> trying to delete a layer?
>
> What about the save/cancel buttons in advanced setting dialog? Now I
> only saw a "close" button there. What can we do if user miss configured
> something that he/she doesn't want to save?
>
> Thanks,
> Dongxiao
>
>>
>> Cheers,
>> Joshua
>
>
>
> _______________________________________________
> bitbake-devel mailing list
> bitbake-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel



_______________________________________________
bitbake-devel mailing list
bitbake-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/bitbake-devel

Since applying layer changes is a time consuming process, the dialog will be implemented as an explicit apply, requiring users to click a Save button in order to apply any changes made to the layers.

On 27/03/2012 02:04, "Xu, Dongxiao" <dongxiao.xu@intel.com> wrote:

From other point of view, the change of layers will definitely cost more
than one second to happen. There are two cases:

1) Change the layer when MACHINE is not selected.
This process contains: init_cooker() --> set_layer() --> parse_config()
--> get available machine/distro/sdk list, etc.
The above process costs about 1~2 seconds.

2) Change the layer when MACHINE is already selected.
This process contains: init_cooker() --> set_layer() --> parse_config()
--> get available machine/distro/sdk list. --> Parse BB files
The above process costs about 10~30 seconds, depending on the existing
parsing cache.

Therefore I think if we follow the HIG standard, we may also need a
"save" and "cancel" button for the layer selection.

(In reply to comment #14)
> Since applying layer changes is a time consuming process, the dialog will be
> implemented as an explicit apply, requiring users to click a Save button in
> order to apply any changes made to the layers.

Okey dokes, will make that change promptly.

I'm struggling with the semantics of the Apply/Cancel/OK paradigm for utility windows[1].

The apply button doesn't make a lot of sense to me as clicking it won't change anything in the layer dialogue - it will just trigger a re-parse (blocking the GUI).

Do we need to change the Layer selection dialogue so that when a user clicks remove the layer is still displayed in the dialogue but is marked for removal - then removal happens on clicking Apply or OK?

We could have a button for the user to undo removal/restore the layer for transient layers where we currently have the delete button.

Thoughts?

I think short term I'm just going to change the dialogue to use Cancel/OK buttons until we figure out how the Apply button should work.

http://developer.gnome.org/hig-book/3.0/windows-utility.html.en#windows-explicit-apply

Hi Joshua,

I like your idea of changing the Layer selection dialogue so that when a user clicks
remove the layer is still displayed in the dialogue but it is marked for removal. 

As we don't have time to design this behaviour at the moment though, I also agree that the best short term solution will be changing the dialogue to use the Cancel/OK buttons (where cancel reset any previous action, and OK confirm changes).

I've also noticed that, even when users haven't made any changes in the Layer dialogue, if users click 'close', the parsing recipe process starts again. We should avoid that step and make the dialogue work so that:
- if users press 'Cancel' or 'OK' without making any changes to Layers, the window is closed without the 'parsing recipe' process starting again?
- if users add or remove layers, the 'parsing recipe' process will start again.

Hi Giulia,

(In reply to comment #17) 
> I like your idea of changing the Layer selection dialogue so that when a user
> clicks
> remove the layer is still displayed in the dialogue but it is marked for
> removal. 
> 
> As we don't have time to design this behaviour at the moment though, I also
> agree that the best short term solution will be changing the dialogue to use
> the Cancel/OK buttons (where cancel reset any previous action, and OK confirm
> changes).

Sounds good, I'll submit a patch to do so.

> I've also noticed that, even when users haven't made any changes in the Layer
> dialogue, if users click 'close', the parsing recipe process starts again. We
> should avoid that step and make the dialogue work so that:
> - if users press 'Cancel' or 'OK' without making any changes to Layers, the
> window is closed without the 'parsing recipe' process starting again?
> - if users add or remove layers, the 'parsing recipe' process will start again.

Ugh, that's no good! I'll work on this today also.

Created attachment 431 [details]
Layer design when more than one layer can't be removed

Find in attachment how the Layer dialogue should look when more than one layer can't be removed (instead of repeating the tile many times, layers should be listed one after the other using the same background). Also the 'X' icon is missing the mouseover functionality and a feedback (as the layer disappears too quickly, consider adding a transition like 'fade-out').