Hob 1.2 design - Settings dialogue

Hob 1.2 design - Settings dialogue

[Barros Pena, Belen]

I've uploaded a document detailing the design of the Settings dialogue for Hob 1.2 at

https://wiki.yoctoproject.org/wiki/File:Settings-dialogue-design-spec-v1.0.pdf

Sorry it's a boring document instead of a video: it seemed the only way to provide the necessary level of detail

Let me know if you have any questions or comments.

Belen
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: Hob 1.2 design - visuals

[Barros Pena, Belen]

Mikael, our visual designer, has been working full speed on Hob 1.2. His
work is now in the wiki too:

https://wiki.yoctoproject.org/wiki/File:Hob_1.2_screens_inventory.pdf


Belen

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

>I've uploaded a document detailing the design of the Settings dialogue
>for Hob 1.2 at
>
>https://wiki.yoctoproject.org/wiki/File:Settings-dialogue-design-spec-v1.0
>.pdf
>
>Sorry it's a boring document instead of a video: it seemed the only way
>to provide the necessary level of detail
>
>Let me know if you have any questions or comments.
>
>Belen
>---------------------------------------------------------------------
>Intel Corporation (UK) Limited
>Registered No. 1134945 (England)
>Registered Office: Pipers Way, Swindon SN3 1RJ
>VAT No: 860 2173 47
>
>This e-mail and any attachments may contain confidential material for
>the sole use of the intended recipient(s). Any review or distribution
>by others is strictly prohibited. If you are not the intended
>recipient, please contact the sender and delete all copies.
>
>_______________________________________________
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: Hob 1.2 design - visuals

[Joshua Lock]

I really like the look Mikael has created here.

A couple of related questions, this could just be mis-calibrated 
expectation from visual design on my part so please don't take them as 
criticism - merely an attempt to clarify:

1) where the visual design differentiates from the toolkit (Gtk+) is the 
intention that we should use the toolkit provided widgets or create our 
own to more closely match the visual design?
(for example the tabs for notebook pages in the 'Building Packages' screen).

2) When implementing Hob v1 I tried to follow the GNOME HIG[1] to ensure 
the app would fit in with the common Linux desktop environments. Should 
v2 continue that trend? Where the visual design might differ with the 
HIG which should be preferred?
(i.e. the button being flush with the bottom of the window in the Image 
Configuration screen is what first struck me here).

3) where the visual design uses various colours I assume the intention 
is to use the colours from the operating systems theme? This is slightly 
more difficult programatically than hard-coding colours but leads to (in 
my opinion) a much more pleasing visual experience.
(i.e. tooltip and button colours)

Finally, I notice that the titlebar calls it HOB, instead of Hob - was 
that intentional? Hob was always mean as a name, not an acronym.

I'm probably confusing visual design for a spec but it's been a while 
since I worked with the design team and my engineers mind is very literal.

This is looking really good!

Cheers,
Joshua

1. http://developer.gnome.org/hig-book/3.0/

On 02/02/12 09:24, Barros Pena, Belen wrote:
> Mikael, our visual designer, has been working full speed on Hob 1.2. His
> work is now in the wiki too:
>
> https://wiki.yoctoproject.org/wiki/File:Hob_1.2_screens_inventory.pdf
>
>
> Belen
>
> On 02/02/2012 16:58, "Barros Pena, Belen"<belen.barros.pena@intel.com>
> wrote:
>
>> I've uploaded a document detailing the design of the Settings dialogue
>> for Hob 1.2 at
>>
>> https://wiki.yoctoproject.org/wiki/File:Settings-dialogue-design-spec-v1.0
>> .pdf
>>
>> Sorry it's a boring document instead of a video: it seemed the only way
>> to provide the necessary level of detail
>>
>> Let me know if you have any questions or comments.
>>
>> Belen
>> ---------------------------------------------------------------------
>> Intel Corporation (UK) Limited
>> Registered No. 1134945 (England)
>> Registered Office: Pipers Way, Swindon SN3 1RJ
>> VAT No: 860 2173 47
>>
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
> ---------------------------------------------------------------------
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
Joshua Lock
         Yocto Project "Johannes factotum"
         Intel Open Source Technology Centre

Re: Hob 1.2 design - visuals

[Barros Pena, Belen]

Hi Joshua,

Thanks for the feedback. I don't have definite answers to your questions:
I think they should come out of a discussion between design and dev teams.

My first stab to some answers below.

> 1) where the visual design differentiates from the toolkit (Gtk+) is the
> intention that we should use the toolkit provided widgets or create our
> own to more closely match the visual design?
> (for example the tabs for notebook pages in the 'Building Packages'
>screen).

I have no experience with GTK, but I would hope that standard widgets can
be themed. So the idea would be using toolkit widgets themed to match the
visual style. Is this assumption incorrect?

If no toolkit widget exist for a certain UI control, we have to either
replace it with a toolkit widget or create our own, but I really hope this
is the exception rather than the rule.



> 2) When implementing Hob v1 I tried to follow the GNOME HIG[1] to ensure
> the app would fit in with the common Linux desktop environments. Should
> v2 continue that trend? Where the visual design might differ with the
> HIG which should be preferred?
> (i.e. the button being flush with the bottom of the window in the Image
> Configuration screen is what first struck me here).

Nothing in the design should blatantly contradict the GNOME HIG: in
general they are good design practice and we wouldn't ignore them without
a reason to do so. If there are any exceptions (like the primary action
button one) we could look at them on a case by case basis. I don't think
leaving 12 pixels between the bottom of the window edge and the button
will make or break the interface. What's important is that the location
and spacing of those 'primary action' buttons are consistent across the
whole Hob. If we feel we shouldn't break the 12px rule, I am sure Mikael
will agree that the button effect is not that important, and that we can
lift it up to fit the spacing GNOME rules.

> 3) where the visual design uses various colours I assume the intention
> is to use the colours from the operating systems theme? This is slightly
> more difficult programatically than hard-coding colours but leads to (in
> my opinion) a much more pleasing visual experience.
> (i.e. tooltip and button colours)

Yes, using the colours from the OS theme is probably the best thing to do.

> Finally, I notice that the titlebar calls it HOB, instead of Hob - was
> that intentional? Hob was always mean as a name, not an acronym.

It's a typo: sorry about that. It should say Hob of course.

Belen


On 02/02/2012 21:19, "Joshua Lock" <josh@linux.intel.com> wrote:


>I really like the look Mikael has created here.
>
>A couple of related questions, this could just be mis-calibrated
>expectation from visual design on my part so please don't take them as
>criticism - merely an attempt to clarify:
>
>1) where the visual design differentiates from the toolkit (Gtk+) is the
>intention that we should use the toolkit provided widgets or create our
>own to more closely match the visual design?
>(for example the tabs for notebook pages in the 'Building Packages'
>screen).
>
>2) When implementing Hob v1 I tried to follow the GNOME HIG[1] to ensure
>the app would fit in with the common Linux desktop environments. Should
>v2 continue that trend? Where the visual design might differ with the
>HIG which should be preferred?
>(i.e. the button being flush with the bottom of the window in the Image
>Configuration screen is what first struck me here).
>
>3) where the visual design uses various colours I assume the intention
>is to use the colours from the operating systems theme? This is slightly
>more difficult programatically than hard-coding colours but leads to (in
>my opinion) a much more pleasing visual experience.
>(i.e. tooltip and button colours)
>
>Finally, I notice that the titlebar calls it HOB, instead of Hob - was
>that intentional? Hob was always mean as a name, not an acronym.
>
>I'm probably confusing visual design for a spec but it's been a while
>since I worked with the design team and my engineers mind is very literal.
>
>This is looking really good!
>
>Cheers,
>Joshua
>
>1. http://developer.gnome.org/hig-book/3.0/
>
>On 02/02/12 09:24, Barros Pena, Belen wrote:
>> Mikael, our visual designer, has been working full speed on Hob 1.2. His
>> work is now in the wiki too:
>>
>> https://wiki.yoctoproject.org/wiki/File:Hob_1.2_screens_inventory.pdf
>>
>>
>> Belen
>>
>> On 02/02/2012 16:58, "Barros Pena, Belen"<belen.barros.pena@intel.com>
>> wrote:
>>
>>> I've uploaded a document detailing the design of the Settings dialogue
>>> for Hob 1.2 at
>>>
>>> 
>>>https://wiki.yoctoproject.org/wiki/File:Settings-dialogue-design-spec-v1
>>>.0
>>> .pdf
>>>
>>> Sorry it's a boring document instead of a video: it seemed the only way
>>> to provide the necessary level of detail
>>>
>>> Let me know if you have any questions or comments.
>>>
>>> Belen
>>> ---------------------------------------------------------------------
>>> Intel Corporation (UK) Limited
>>> Registered No. 1134945 (England)
>>> Registered Office: Pipers Way, Swindon SN3 1RJ
>>> VAT No: 860 2173 47
>>>
>>> This e-mail and any attachments may contain confidential material for
>>> the sole use of the intended recipient(s). Any review or distribution
>>> by others is strictly prohibited. If you are not the intended
>>> recipient, please contact the sender and delete all copies.
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>> ---------------------------------------------------------------------
>> Intel Corporation (UK) Limited
>> Registered No. 1134945 (England)
>> Registered Office: Pipers Way, Swindon SN3 1RJ
>> VAT No: 860 2173 47
>>
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>-- 
>Joshua Lock
>         Yocto Project "Johannes factotum"
>         Intel Open Source Technology Centre

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: Hob 1.2 design - visuals

[Joshua Lock]

On 03/02/12 03:52, Barros Pena, Belen wrote:
> Hi Joshua,
>
> Thanks for the feedback. I don't have definite answers to your questions:
> I think they should come out of a discussion between design and dev teams.

I agree.

> My first stab to some answers below.
>
>> 1) where the visual design differentiates from the toolkit (Gtk+) is the
>> intention that we should use the toolkit provided widgets or create our
>> own to more closely match the visual design?
>> (for example the tabs for notebook pages in the 'Building Packages'
>> screen).
>
> I have no experience with GTK, but I would hope that standard widgets can
> be themed. So the idea would be using toolkit widgets themed to match the
> visual style. Is this assumption incorrect?

The widgets can indeed be themed, but in the favour of visual 
consistency across the system I usually try to avoid it unless there's a 
compelling reason to do so.

Perhaps we can address differences between visual design and toolkit on 
a case-by-case basis? Implement with the toolkit provided widgets and OS 
theme and review which things we might want to enhance later?

> If no toolkit widget exist for a certain UI control, we have to either
> replace it with a toolkit widget or create our own, but I really hope this
> is the exception rather than the rule.

Oh yes, I don't think that's the case for Hob. It was the exception for 
some work I did on Moblin but certainly not the rule, in fact that 
widget is part of the standard toolkit now.

>> 2) When implementing Hob v1 I tried to follow the GNOME HIG[1] to ensure
>> the app would fit in with the common Linux desktop environments. Should
>> v2 continue that trend? Where the visual design might differ with the
>> HIG which should be preferred?
>> (i.e. the button being flush with the bottom of the window in the Image
>> Configuration screen is what first struck me here).
>
> Nothing in the design should blatantly contradict the GNOME HIG: in
> general they are good design practice and we wouldn't ignore them without
> a reason to do so. If there are any exceptions (like the primary action
> button one) we could look at them on a case by case basis. I don't think
> leaving 12 pixels between the bottom of the window edge and the button
> will make or break the interface. What's important is that the location
> and spacing of those 'primary action' buttons are consistent across the
> whole Hob. If we feel we shouldn't break the 12px rule, I am sure Mikael
> will agree that the button effect is not that important, and that we can
> lift it up to fit the spacing GNOME rules.

This is great to read. I was hoping to elicit such a response and just 
wanted to make sure engineering and design are on the same page here. It 
feels like we are?

I understand that 12px won't make or break the interface but I'm 
definitely pro consistent UI across the whole OS where possible. I 
expect I'm preaching to the choir here, so I'll leave it at that.

>> 3) where the visual design uses various colours I assume the intention
>> is to use the colours from the operating systems theme? This is slightly
>> more difficult programatically than hard-coding colours but leads to (in
>> my opinion) a much more pleasing visual experience.
>> (i.e. tooltip and button colours)
>
> Yes, using the colours from the OS theme is probably the best thing to do.

Awesome! I'd go so far as to say it's definitely the best thing to do. I 
didn't manage it with Hob 1 and had some ugly screenshots sent my way 
from poor users who dared to use a different theme than me.

>> Finally, I notice that the titlebar calls it HOB, instead of Hob - was
>> that intentional? Hob was always mean as a name, not an acronym.
>
> It's a typo: sorry about that. It should say Hob of course.

No need to apologise. Just wanted to make sure.

Thanks for your response,
Joshua
-- 
Joshua Lock
         Yocto Project "Johannes factotum"
         Intel Open Source Technology Centre

Re: Hob 1.2 design - visuals

[Barros Pena, Belen]

Hi all,

It looks like there are some design implementation principles laid out on
the email below. Just to summarise:

1. Implement the Hob design with the toolkit provided widgets and OS theme
and review which things we might want to enhance later. I understand this
excludes icons: we will use the ones provided by the visual design.

2. Make sure that all action buttons in windows and dialogues follow up
the spacing GNOME rules set by the Human Interface Guidelines at
http://developer.gnome.org/hig-book/3.0/index.html.en

3. Inherit colour scheme from applied OS theme in host computer

Shane, Dongxiao: if you have any comments about the above, please let us
know.

Cheers

Belen

On 03/02/2012 18:32, "Joshua Lock" <josh@linux.intel.com> wrote:

>On 03/02/12 03:52, Barros Pena, Belen wrote:
>> Hi Joshua,
>>
>> Thanks for the feedback. I don't have definite answers to your
>>questions:
>> I think they should come out of a discussion between design and dev
>>teams.
>
>I agree.
>
>> My first stab to some answers below.
>>
>>> 1) where the visual design differentiates from the toolkit (Gtk+) is
>>>the
>>> intention that we should use the toolkit provided widgets or create our
>>> own to more closely match the visual design?
>>> (for example the tabs for notebook pages in the 'Building Packages'
>>> screen).
>>
>> I have no experience with GTK, but I would hope that standard widgets
>>can
>> be themed. So the idea would be using toolkit widgets themed to match
>>the
>> visual style. Is this assumption incorrect?
>
>The widgets can indeed be themed, but in the favour of visual
>consistency across the system I usually try to avoid it unless there's a
>compelling reason to do so.
>
>Perhaps we can address differences between visual design and toolkit on
>a case-by-case basis? Implement with the toolkit provided widgets and OS
>theme and review which things we might want to enhance later?
>
>> If no toolkit widget exist for a certain UI control, we have to either
>> replace it with a toolkit widget or create our own, but I really hope
>>this
>> is the exception rather than the rule.
>
>Oh yes, I don't think that's the case for Hob. It was the exception for
>some work I did on Moblin but certainly not the rule, in fact that
>widget is part of the standard toolkit now.
>
>>> 2) When implementing Hob v1 I tried to follow the GNOME HIG[1] to
>>>ensure
>>> the app would fit in with the common Linux desktop environments. Should
>>> v2 continue that trend? Where the visual design might differ with the
>>> HIG which should be preferred?
>>> (i.e. the button being flush with the bottom of the window in the Image
>>> Configuration screen is what first struck me here).
>>
>> Nothing in the design should blatantly contradict the GNOME HIG: in
>> general they are good design practice and we wouldn't ignore them
>>without
>> a reason to do so. If there are any exceptions (like the primary action
>> button one) we could look at them on a case by case basis. I don't think
>> leaving 12 pixels between the bottom of the window edge and the button
>> will make or break the interface. What's important is that the location
>> and spacing of those 'primary action' buttons are consistent across the
>> whole Hob. If we feel we shouldn't break the 12px rule, I am sure Mikael
>> will agree that the button effect is not that important, and that we can
>> lift it up to fit the spacing GNOME rules.
>
>This is great to read. I was hoping to elicit such a response and just
>wanted to make sure engineering and design are on the same page here. It
>feels like we are?
>
>I understand that 12px won't make or break the interface but I'm
>definitely pro consistent UI across the whole OS where possible. I
>expect I'm preaching to the choir here, so I'll leave it at that.
>
>>> 3) where the visual design uses various colours I assume the intention
>>> is to use the colours from the operating systems theme? This is
>>>slightly
>>> more difficult programatically than hard-coding colours but leads to
>>>(in
>>> my opinion) a much more pleasing visual experience.
>>> (i.e. tooltip and button colours)
>>
>> Yes, using the colours from the OS theme is probably the best thing to
>>do.
>
>Awesome! I'd go so far as to say it's definitely the best thing to do. I
>didn't manage it with Hob 1 and had some ugly screenshots sent my way
>from poor users who dared to use a different theme than me.
>
>>> Finally, I notice that the titlebar calls it HOB, instead of Hob - was
>>> that intentional? Hob was always mean as a name, not an acronym.
>>
>> It's a typo: sorry about that. It should say Hob of course.
>
>No need to apologise. Just wanted to make sure.
>
>Thanks for your response,
>Joshua
>-- 
>Joshua Lock
>         Yocto Project "Johannes factotum"
>         Intel Open Source Technology Centre

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: Hob 1.2 design - visuals

[Wang, Shane]

Barros Pena, Belen wrote on 2012-02-06:

> Hi all,
> 
> It looks like there are some design implementation principles laid out on
> the email below. Just to summarise:
> 
> 1. Implement the Hob design with the toolkit provided widgets and OS theme
> and review which things we might want to enhance later. I understand this
> excludes icons: we will use the ones provided by the visual design.
> 
> 2. Make sure that all action buttons in windows and dialogues follow up
> the spacing GNOME rules set by the Human Interface Guidelines at
> http://developer.gnome.org/hig-book/3.0/index.html.en
> 
> 3. Inherit colour scheme from applied OS theme in host computer
> 
Is it to say we use the default colors from OS, and don't specify any color?
For example, Jessica wants progress bars to be green but in Ubuntu it should be orange.
If so, Belen, I agree with you.

> Shane, Dongxiao: if you have any comments about the above, please let us
> know.
> 
> Cheers
> 
> Belen

Re: Hob 1.2 design - visuals

[Barros Pena, Belen]

[-- Attachment #1: Type: text/plain, Size: 2227 bytes --]

>>3. Inherit colour scheme from applied OS theme in host computer
>Is it to say we use the default colors from OS, and don't specify any
>color?
>For example, Jessica wants progress bars to be green but in Ubuntu it
>should be orange.
>If so, Belen, I agree with you.

Yes, I think that's what Joshua recommended, and I can see why it makes
sense. Joshua, could you confirm when you have a chance?

If we decide to implement this way, people will need to understand that
this applies to all UI elements without exceptions. Any particular
requests (like Jessica's) could be looked at on a case by case basis.

Cheers

Belen



On 06/02/2012 11:42, "Wang, Shane" <shane.wang@intel.com> wrote:

>Barros Pena, Belen wrote on 2012-02-06:
>
>> Hi all,
>> 
>> It looks like there are some design implementation principles laid out
>>on
>> the email below. Just to summarise:
>> 
>> 1. Implement the Hob design with the toolkit provided widgets and OS
>>theme
>> and review which things we might want to enhance later. I understand
>>this
>> excludes icons: we will use the ones provided by the visual design.
>> 
>> 2. Make sure that all action buttons in windows and dialogues follow up
>> the spacing GNOME rules set by the Human Interface Guidelines at
>> http://developer.gnome.org/hig-book/3.0/index.html.en
>> 
>> 3. Inherit colour scheme from applied OS theme in host computer
>> 
>Is it to say we use the default colors from OS, and don't specify any
>color?
>For example, Jessica wants progress bars to be green but in Ubuntu it
>should be orange.
>If so, Belen, I agree with you.
>
>> Shane, Dongxiao: if you have any comments about the above, please let us
>> know.
>> 
>> Cheers
>> 
>> Belen

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[-- Attachment #2: Type: message/rfc822, Size: 57920 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 8045 bytes --]

Hi Shane and team,

In general all sounds good. I just have a couple of small comments, which
I've added below.

Belen

From:  "Wang, Shane" <shane.wang@intel.com>
Date:  Fri, 3 Feb 2012 05:29:57 +0000
To:  "Xu, Dongxiao" <dongxiao.xu@intel.com>, "Belen Barros Pena (Intel)"
<belen.barros.pena@intel.com>, "Lu, Lianhao" <lianhao.lu@intel.com>
Cc:  "Eggleton, Paul" <paul.eggleton@intel.com>, "Purdie, Richard"
<richard.purdie@intel.com>, "Zhang, Jessica" <jessica.zhang@intel.com>,
"Lock, Joshua" <joshua.lock@intel.com>, "Liu, Song" <song.liu@intel.com>,
"Stewart, David C" <david.c.stewart@intel.com>, "yocto@yoctoproject.org"
<yocto@yoctoproject.org>
Subject:  RE: RFC: Hob 1.2 design

Dongxiao and I have a discussion on that again.
 
Belen, please ignore the issue for the deployment button below, and we have
several suggestions.
 
1. To make the Packages Screen and the Packages dialog the same.
The Packages Screen is shown after users click ³Build packages². That is one
step of the process.
However, the content shown in the Package dialog is all what we have built
out last time. It is very possible users start from there and don¹t want to
go back to the Image configuration screen and click ³Build Image².

Sorry, I am not sure I understand. What you seem to be saying is that we
will eliminate the 'View packages' button from the Image configuration
screen and the Packages dialogue. Users will access packages information via
the 'Build packages' option, which will bring them to the Packages screen.
Is this correct?
 
2. As mentioned in my last email, we want to add ³Clean² in the GUI. The
reason is the build will fail, say, do_fetch, then we have an option to
allow users to clean what we built out and rebuild. Otherwise, the sstate
could be reused for the next build. Users can do it by running ³bitbake ­c
cleanall² in the command line. But we hope to provide this feature in the
GUI.
If you agree the above, then the action ³Clean² is for a recipe or multiple
recipes, and clicking ³Clean² will go to the screen at 4:00, since cleaning
includes some tasks.
Then we could make the Recipes dialog to be a screen, do you agree?

Yes: I agree with you. Making Recipes a screen instead of a dialogue seems
like a good solution. However, I am not sure the 'Clean' function should be
in the Recipes screen: it should probably be an option that is displayed
when the build fails. If you select it you go to the screen at 4:00 to
provide information about the cleaning tasks and once they are done, you get
the Recipes screen ready for you to build again. I think this 'build failed'
scenario is very important, and I would like to design it carefully. Would
it be ok if I work on it this week and send you some suggestions?

The other reason is users can view recipes and click ³Build Packages², no
need go back to the Image configuration screen.
The use case is: 
1) View Recipes in the Image configuration -> the Recipes screen -> Select
recipes and Build packages -> Log -> the Packages screen Š
2) View Recipes in the Image configuration -> the Recipes screen -> Select
recipes and Build packages -> Log -> Failure -> Go back to the Recipes
screen -> Clean something -> Log -> the Recipes screen -> Build packages
again -> Log -> Success -> the Packages screen Š
3) View Recipes in the Image configuration -> the Recipes screen -> Select
recipes -> Go back to the Image configuraion -> ³Build Image²
4) Nothing want to view in the Image configuration after choosing ³base
image² -> ³Build packages² -> Log -> the Packages screen Š
5) Nothing want to view in the Image configuration after choosing ³base
image² -> ³Build packages² -> Log -> Failure -> Go back to the Image
configuration -> View Recipes -> the Recipes screen -> Clean something ->
Log -> the Recipe screen -> Š
6) Nothing want to view in the Image configuration after choosing ³base
image² -> ³Build Image² -> Log -> the Image details Š
and so onŠ

This seems to make sense. Just a small comment about the use case number 3.
I think the Recipes screen should have 2 actions: "build packages" and
"build image", so that users who want to build an image directly from the
Recipes screen don't need to go back to the Image configuration screen in
order to build the image.
 
3. When build is failed, there is a ³Back² button. But go back to where is
determined by where you come from.

I'll keep this in mind when designing the 'build failed' scenario.
 
4. After users open an image by ³My images², some time there should not be a
³Save Template² because we don¹t have build process.
Let¹s show ³Save Template² when ³Congratulations! Your image is ready!² is
shown, OK?

This sounds ok to me. Should we have a 'save as template' option in the
Image configuration screen? Or will we just have it in the Image details
screen when you get there after completing the build process?
 
5. In the Image details screen, ³Settings² is obviously not good to be shown
there. Can we remove ³Load Template²? Because it will initiate a new build.
Let¹s ask users to click ³Build new image² to be on the Image configuration
and click ³Load Template².
We just keep ³My Images² in the last screen (the Image details screen), is
it OK?
And remove ³Edit Packages² and ³Edit Configuration², if the build process is
not executed this time. (ditto for ³Save Template² in 4.)

Happy with this.
 
6. In Josh¹s email, FRI 2 image can also be run, though it is an image for
real machine. Can we keep two buttons ³Run² and ³Deploy² on the Image
details screen and let uses decide what he/she wants? I admit an error
possibly happens if the image doesn¹t match the action, but we just report
the error.

Not so happy with this one ;) If an option is going to generate an error
when selected, it should not be there at all. GUI's must be defensive: they
must prevent user errors. This is a fundamental principle of interaction
design. We should only present the  'Run' (on qemu) option if the image is
suitable for qemu running. We should only display the 'Deploy' option for
live images. If there is no way to reliably determine what type of image we
are dealing with and which options are suitable for them, the 'Run' and
'Deploy' functionality should not be there at all. Better wait until we find
a work around.

Having said that, it seems to me that using the file extension to determine
what's the appropriate action for each image should work the vast majority
of times. If someone has changed the extension of the image, well, that
would be an edge case (how likely are people to do that?), and we should not
get into the trap of designing for the edge case, which is what we would be
doing if we were to display both 'run' and 'deploy' for all images.
 
Thoughts?
Thanks.
--
Shane
 

From: Xu, Dongxiao 
Sent: Friday, February 03, 2012 8:57 AM
To: Wang, Shane; Barros Pena, Belen; Lu, Lianhao
Cc: Eggleton, Paul; Purdie, Richard; Zhang, Jessica; Lock, Joshua; Liu,
Song; Stewart, David C; yocto@yoctoproject.org
Subject: RE: RFC: Hob 1.2 design
 
One more from me that, Hob may work as a deploy tool, and in the new movie,
the approach is to select ³My images² and then click deploy button. I think
normal user may not have such knowledge. I am still wondering if adding a
³deploy² button in the tool bar?
 
Thanks,
Dongxiao
 

From: Wang, Shane 
Sent: Friday, February 03, 2012 8:26 AM
To: Wang, Shane; Barros Pena, Belen; Xu, Dongxiao; Lu, Lianhao
Cc: Eggleton, Paul; Purdie, Richard; Zhang, Jessica; Lock, Joshua; Liu,
Song; Stewart, David C; yocto@yoctoproject.org
Subject: RE: RFC: Hob 1.2 design
 

I get one more:
 
In the Image details screen, after opening an image file by clicking ³My
images², we don¹t allow to ³Edit Package², I think.
Because with an image only, we can¹t generate the packages from it, you
can¹t assume there is a build directory (tmp/), is my understanding correct?
 
--
Shane



[-- Attachment #2.1.2: Type: text/html, Size: 45398 bytes --]

Re: Hob 1.2 design - visuals

[Joshua Lock]

On 06/02/12 05:54, Barros Pena, Belen wrote:
>>> 3. Inherit colour scheme from applied OS theme in host computer
>> Is it to say we use the default colors from OS, and don't specify any
>> color?
>> For example, Jessica wants progress bars to be green but in Ubuntu it
>> should be orange.
>> If so, Belen, I agree with you.
>
> Yes, I think that's what Joshua recommended, and I can see why it makes
> sense. Joshua, could you confirm when you have a chance?

Indeed, that's precisely what I'm recommending. Further, when we need to 
colour a widget that isn't usually coloured in the theme (like the 
red/green colouring of build items in the hobv1) we should try and use a 
colour from the palette defined in the current theme to avoid issues 
like #1701[1][2] and another example from the wild[3][4].

I found a reasonable resource on the how and why[5].

> If we decide to implement this way, people will need to understand that
> this applies to all UI elements without exceptions. Any particular
> requests (like Jessica's) could be looked at on a case by case basis.

But should be well justified, and generated from the host theme's palette.

Cheers,
Joshua

1. http://bugzilla.pokylinux.org/attachment.cgi?id=276
2. http://bugzilla.pokylinux.org/show_bug.cgi?id=1701
3. http://itmages.ru/image/view/52705/9663bad0
4. http://redmine.yorba.org/issues/2483
5. http://ometer.com/gtk-colors.html
-- 
Joshua Lock
         Yocto Project "Johannes factotum"
         Intel Open Source Technology Centre

Re: Hob 1.2 design - Settings dialogue

[Saul Wold]

On 02/02/2012 08:58 AM, Barros Pena, Belen wrote:
> I've uploaded a document detailing the design of the Settings dialogue for Hob 1.2 at
>
> https://wiki.yoctoproject.org/wiki/File:Settings-dialogue-design-spec-v1.0.pdf
>
> Sorry it's a boring document instead of a video: it seemed the only way to provide the necessary level of detail
>
> Let me know if you have any questions or comments.
>
Belen, great start, we talked the last couple of days of possibly adding 
a proxies tab that can read the site.conf and set up proxies and save them.

Dexcaun was looking into that.

Sau!

> Belen
> ---------------------------------------------------------------------
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: Hob 1.2 design - Settings dialogue

[Barros Pena, Belen]

That should be no problem. I just need a list of all parameters required
to set up the proxy (server, port, username, password...).

If you guys can provide that, I'll add them to the Settings dialogue.

Cheers

Belen

On 02/02/2012 21:43, "Saul Wold" <sgw@linux.intel.com> wrote:

>On 02/02/2012 08:58 AM, Barros Pena, Belen wrote:
>> I've uploaded a document detailing the design of the Settings dialogue
>>for Hob 1.2 at
>>
>> 
>>https://wiki.yoctoproject.org/wiki/File:Settings-dialogue-design-spec-v1.
>>0.pdf
>>
>> Sorry it's a boring document instead of a video: it seemed the only way
>>to provide the necessary level of detail
>>
>> Let me know if you have any questions or comments.
>>
>Belen, great start, we talked the last couple of days of possibly adding
>a proxies tab that can read the site.conf and set up proxies and save
>them.
>
>Dexcaun was looking into that.
>
>Sau!
>
>> Belen
>> ---------------------------------------------------------------------
>> Intel Corporation (UK) Limited
>> Registered No. 1134945 (England)
>> Registered Office: Pipers Way, Swindon SN3 1RJ
>> VAT No: 860 2173 47
>>
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: Hob 1.2 design - Settings dialogue

[Joshua Lock]

Hi Belen,

Sorry this is so long, I don't know how to turn off my verbose switch.

On page 4 you mention Shane's intention to have proxy settings in the UI 
- I just want to point out that this is usually an OS level 
configuration and we should be wary about how we implement it.
I'd suggest we go so far as to just have a "Change system proxy 
settings" button which launches the OS's network configuration settings.

Of course, this opens us up to potential issues around supporting the 
multitude of available network configuration tools on Linux but I'd 
suggest we start with a lowest common denominator approach and have the 
program behave intelligently.

Explicitly we can detect whether the binary gnome-control-center and the 
so file /usr/lib64/control-center-1/panels/libnetwork.so exist (being 
clever about that path, too) and if so we can execute:

"gnome-control-center display network"

Which will display the network configuration (and therefore proxy) 
settings for stock Fedora and Ubuntu desktops.


I understand why the Machines option might be more useful as a list 
widget (p5), rather than a combo box, but feel that this is devalued at 
least slightly by the fact that the list of available Machines isn't 
static and therefore it's not unlikely a user would have to scroll that 
list.
One suggestion might be to favour machines with a higher layer priority 
by listing them higher in the list?

Although the next page, 5, mentions that the machine list is a combo 
box. Is that the case?

Love the package format selection pieces!

For the two parallel threads buttons we should recommend a default value 
and set a maximum based on the number of CPU cores - I think there's 
been a lot of discussion about this but I'm not certain what the 
recommendation which came out of it was.

For the directories on page 13 would it make sense to have a reset 
button to more easily get back to the defaults?

That's all folks,
Joshua


On 02/02/12 08:58, Barros Pena, Belen wrote:
> I've uploaded a document detailing the design of the Settings dialogue for Hob 1.2 at
>
> https://wiki.yoctoproject.org/wiki/File:Settings-dialogue-design-spec-v1.0.pdf
>
> Sorry it's a boring document instead of a video: it seemed the only way to provide the necessary level of detail
>
> Let me know if you have any questions or comments.
>
> Belen
> ---------------------------------------------------------------------
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
Joshua Lock
         Yocto Project "Johannes factotum"
         Intel Open Source Technology Centre

Re: Hob 1.2 design - Settings dialogue

[Joshua Lock]

On 02/02/12 13:51, Joshua Lock wrote:
> Hi Belen,
>
> Sorry this is so long, I don't know how to turn off my verbose switch.
>
> On page 4 you mention Shane's intention to have proxy settings in the UI
> - I just want to point out that this is usually an OS level
> configuration and we should be wary about how we implement it.
> I'd suggest we go so far as to just have a "Change system proxy
> settings" button which launches the OS's network configuration settings.
>
> Of course, this opens us up to potential issues around supporting the
> multitude of available network configuration tools on Linux but I'd
> suggest we start with a lowest common denominator approach and have the
> program behave intelligently.
>
> Explicitly we can detect whether the binary gnome-control-center and the
> so file /usr/lib64/control-center-1/panels/libnetwork.so exist (being
> clever about that path, too) and if so we can execute:
>
> "gnome-control-center display network"
>
> Which will display the network configuration (and therefore proxy)
> settings for stock Fedora and Ubuntu desktops.
>

The above is all moot if we're just going to configure the proxy through 
sites.conf as per Saul's recent mail.

Cheers,
Joshua
-- 
Joshua Lock
         Yocto Project "Johannes factotum"
         Intel Open Source Technology Centre

Re: Hob 1.2 design - Settings dialogue

[Scott Garman]

On 02/02/2012 02:01 PM, Joshua Lock wrote:
>
>
> On 02/02/12 13:51, Joshua Lock wrote:
>> Hi Belen,
>>
>> Sorry this is so long, I don't know how to turn off my verbose switch.
>>
>> On page 4 you mention Shane's intention to have proxy settings in the UI
>> - I just want to point out that this is usually an OS level
>> configuration and we should be wary about how we implement it.
>> I'd suggest we go so far as to just have a "Change system proxy
>> settings" button which launches the OS's network configuration settings.
>>
>> Of course, this opens us up to potential issues around supporting the
>> multitude of available network configuration tools on Linux but I'd
>> suggest we start with a lowest common denominator approach and have the
>> program behave intelligently.
>>
>> Explicitly we can detect whether the binary gnome-control-center and the
>> so file /usr/lib64/control-center-1/panels/libnetwork.so exist (being
>> clever about that path, too) and if so we can execute:
>>
>> "gnome-control-center display network"
>>
>> Which will display the network configuration (and therefore proxy)
>> settings for stock Fedora and Ubuntu desktops.
>>
>
> The above is all moot if we're just going to configure the proxy through
> sites.conf as per Saul's recent mail.

Will sites.conf setup proxy settings for git, subversion, and cvs?

The proxy situation is a mess under Linux. This is likely to be a 
non-trivial problem.

http://www.yoctoproject.org/blogs/sgarman/2011/proxy-problem

Scott

-- 
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center

Re: Hob 1.2 design - Settings dialogue

[Barros Pena, Belen]

Your verbose mode it's pretty helpful (as it happens with most verbose
modes), so please don't turn it off.

Answers below.

Belen

On 02/02/2012 21:51, "Joshua Lock" <josh@linux.intel.com> wrote:

>Hi Belen,
>
>Sorry this is so long, I don't know how to turn off my verbose switch.
>
>On page 4 you mention Shane's intention to have proxy settings in the UI
>- I just want to point out that this is usually an OS level
>configuration and we should be wary about how we implement it.
>I'd suggest we go so far as to just have a "Change system proxy
>settings" button which launches the OS's network configuration settings.
>
>Of course, this opens us up to potential issues around supporting the
>multitude of available network configuration tools on Linux but I'd
>suggest we start with a lowest common denominator approach and have the
>program behave intelligently.
>
>Explicitly we can detect whether the binary gnome-control-center and the
>so file /usr/lib64/control-center-1/panels/libnetwork.so exist (being
>clever about that path, too) and if so we can execute:
>
>"gnome-control-center display network"
>
>Which will display the network configuration (and therefore proxy)
>settings for stock Fedora and Ubuntu desktops.

You guys are the experts. You tell me how you want it to work and I'll
design the UI for it! :)

>
>
>I understand why the Machines option might be more useful as a list
>widget (p5), rather than a combo box, but feel that this is devalued at
>least slightly by the fact that the list of available Machines isn't
>static and therefore it's not unlikely a user would have to scroll that
>list.

Yes, the list will scroll at some point. I am not too worried about it
though, since I don't think that changing the image types will be
something users will do very often. I might be wrong though.


>One suggestion might be to favour machines with a higher layer priority
>by listing them higher in the list?

I don¹t know how the layer priorities work. Who sets those priorities? Are
they aligned with user's priorities? If they are, yes, we should use the
layer priorities to determine the order of that list of machines.

>
>Although the next page, 5, mentions that the machine list is a combo
>box. Is that the case?

It is the case in the Image configuration screen, where users, before
building an image, select their machine using a combo box. This screen is
different from the Settings dialogue, where you set some BibBake output
and system variables (the image output types between them). This document
in the wiki 

http://wiki.yoctoproject.org/wiki/File:Hob_1.2_screens_inventory.pdf

might help making sense of the different screens.

>
>Love the package format selection pieces!
>
>For the two parallel threads buttons we should recommend a default value
>and set a maximum based on the number of CPU cores - I think there's
>been a lot of discussion about this but I'm not certain what the
>recommendation which came out of it was.

That would be really useful. Is it easy to accurately determine how many
cores are supported by the CPU of the machine running Hob?

>
>For the directories on page 13 would it make sense to have a reset
>button to more easily get back to the defaults?

Yes, this probably makes sense. I'll add that to the document next week.

>
>That's all folks,
>Joshua
>
>
>On 02/02/12 08:58, Barros Pena, Belen wrote:
>> I've uploaded a document detailing the design of the Settings dialogue
>>for Hob 1.2 at
>>
>> 
>>https://wiki.yoctoproject.org/wiki/File:Settings-dialogue-design-spec-v1.
>>0.pdf
>>
>> Sorry it's a boring document instead of a video: it seemed the only way
>>to provide the necessary level of detail
>>
>> Let me know if you have any questions or comments.
>>
>> Belen
>> ---------------------------------------------------------------------
>> Intel Corporation (UK) Limited
>> Registered No. 1134945 (England)
>> Registered Office: Pipers Way, Swindon SN3 1RJ
>> VAT No: 860 2173 47
>>
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>-- 
>Joshua Lock
>         Yocto Project "Johannes factotum"
>         Intel Open Source Technology Centre

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: Hob 1.2 design - Settings dialogue

[Joshua Lock]

On 03/02/12 06:42, Barros Pena, Belen wrote:
> Your verbose mode it's pretty helpful (as it happens with most verbose
> modes), so please don't turn it off.
>
> Answers below.
>
> Belen
>
> On 02/02/2012 21:51, "Joshua Lock"<josh@linux.intel.com>  wrote:
>
>> Hi Belen,
>>
>> Sorry this is so long, I don't know how to turn off my verbose switch.
>>
>> On page 4 you mention Shane's intention to have proxy settings in the UI
>> - I just want to point out that this is usually an OS level
>> configuration and we should be wary about how we implement it.
>> I'd suggest we go so far as to just have a "Change system proxy
>> settings" button which launches the OS's network configuration settings.
>>
>> Of course, this opens us up to potential issues around supporting the
>> multitude of available network configuration tools on Linux but I'd
>> suggest we start with a lowest common denominator approach and have the
>> program behave intelligently.
>>
>> Explicitly we can detect whether the binary gnome-control-center and the
>> so file /usr/lib64/control-center-1/panels/libnetwork.so exist (being
>> clever about that path, too) and if so we can execute:
>>
>> "gnome-control-center display network"
>>
>> Which will display the network configuration (and therefore proxy)
>> settings for stock Fedora and Ubuntu desktops.
>
> You guys are the experts. You tell me how you want it to work and I'll
> design the UI for it! :)

My concern here was not to duplicate OS GUI to change OS settings, feels 
to me that this is generally a bad idea. However I see from an 
alternative thread that the intention is to only set the proxy 
configuration for Yocto, if this is achievable through the site.conf I'm 
all for it!

>> I understand why the Machines option might be more useful as a list
>> widget (p5), rather than a combo box, but feel that this is devalued at
>> least slightly by the fact that the list of available Machines isn't
>> static and therefore it's not unlikely a user would have to scroll that
>> list.
>
> Yes, the list will scroll at some point. I am not too worried about it
> though, since I don't think that changing the image types will be
> something users will do very often. I might be wrong though.

I've made similar assumptions too, and as we don't have any data I'm in 
no rush to disagree with either of us :-)

>> One suggestion might be to favour machines with a higher layer priority
>> by listing them higher in the list?
>
> I don¹t know how the layer priorities work. Who sets those priorities? Are
> they aligned with user's priorities? If they are, yes, we should use the
> layer priorities to determine the order of that list of machines.

Layer priority currently is set by the layers author, but is editable by 
the layers user (it's "just" a text file).

Maybe something to consider for future. There's been discussion about 
making it easier to enable system users to alter the layer priority, 
perhaps we'll make GUI changes if something like that happens? Or 
perhaps we'll make the change for the sake of the GUI? More thought 
required.

>> Although the next page, 5, mentions that the machine list is a combo
>> box. Is that the case?
>
> It is the case in the Image configuration screen, where users, before
> building an image, select their machine using a combo box. This screen is
> different from the Settings dialogue, where you set some BibBake output
> and system variables (the image output types between them). This document
> in the wiki
>
> http://wiki.yoctoproject.org/wiki/File:Hob_1.2_screens_inventory.pdf
>
> might help making sense of the different screens.

Gotcha!

>> Love the package format selection pieces!
>>
>> For the two parallel threads buttons we should recommend a default value
>> and set a maximum based on the number of CPU cores - I think there's
>> been a lot of discussion about this but I'm not certain what the
>> recommendation which came out of it was.
>
> That would be really useful. Is it easy to accurately determine how many
> cores are supported by the CPU of the machine running Hob?

We can easily detect that, yes. The difficulty with enabling this kind 
of feature in the past has been balancing between providing an accurate 
recommendation and allowing the user to ignore it.

I wonder if this would be better as a feature for later to allow us more 
time to get it right?


>> For the directories on page 13 would it make sense to have a reset
>> button to more easily get back to the defaults?
>
> Yes, this probably makes sense. I'll add that to the document next week.

Great, thanks.

Joshua
-- 
Joshua Lock
         Yocto Project "Johannes factotum"
         Intel Open Source Technology Centre

Re: Hob 1.2 design - Settings dialogue

[Barros Pena, Belen]

Hi Joshua,

I am keeping a list of features to be considered for future Hob versions.
I've added to it changing the layer priorities through the GUI and
recommending appropriate values for parallel threads based on supported
cores.

Cheers

Belen

On 03/02/2012 18:23, "Joshua Lock" <josh@linux.intel.com> wrote:

>On 03/02/12 06:42, Barros Pena, Belen wrote:
>> Your verbose mode it's pretty helpful (as it happens with most verbose
>> modes), so please don't turn it off.
>>
>> Answers below.
>>
>> Belen
>>
>> On 02/02/2012 21:51, "Joshua Lock"<josh@linux.intel.com>  wrote:
>>
>>> Hi Belen,
>>>
>>> Sorry this is so long, I don't know how to turn off my verbose switch.
>>>
>>> On page 4 you mention Shane's intention to have proxy settings in the
>>>UI
>>> - I just want to point out that this is usually an OS level
>>> configuration and we should be wary about how we implement it.
>>> I'd suggest we go so far as to just have a "Change system proxy
>>> settings" button which launches the OS's network configuration
>>>settings.
>>>
>>> Of course, this opens us up to potential issues around supporting the
>>> multitude of available network configuration tools on Linux but I'd
>>> suggest we start with a lowest common denominator approach and have the
>>> program behave intelligently.
>>>
>>> Explicitly we can detect whether the binary gnome-control-center and
>>>the
>>> so file /usr/lib64/control-center-1/panels/libnetwork.so exist (being
>>> clever about that path, too) and if so we can execute:
>>>
>>> "gnome-control-center display network"
>>>
>>> Which will display the network configuration (and therefore proxy)
>>> settings for stock Fedora and Ubuntu desktops.
>>
>> You guys are the experts. You tell me how you want it to work and I'll
>> design the UI for it! :)
>
>My concern here was not to duplicate OS GUI to change OS settings, feels
>to me that this is generally a bad idea. However I see from an
>alternative thread that the intention is to only set the proxy
>configuration for Yocto, if this is achievable through the site.conf I'm
>all for it!
>
>>> I understand why the Machines option might be more useful as a list
>>> widget (p5), rather than a combo box, but feel that this is devalued at
>>> least slightly by the fact that the list of available Machines isn't
>>> static and therefore it's not unlikely a user would have to scroll that
>>> list.
>>
>> Yes, the list will scroll at some point. I am not too worried about it
>> though, since I don't think that changing the image types will be
>> something users will do very often. I might be wrong though.
>
>I've made similar assumptions too, and as we don't have any data I'm in
>no rush to disagree with either of us :-)
>
>>> One suggestion might be to favour machines with a higher layer priority
>>> by listing them higher in the list?
>>
>> I don¹t know how the layer priorities work. Who sets those priorities?
>>Are
>> they aligned with user's priorities? If they are, yes, we should use the
>> layer priorities to determine the order of that list of machines.
>
>Layer priority currently is set by the layers author, but is editable by
>the layers user (it's "just" a text file).
>
>Maybe something to consider for future. There's been discussion about
>making it easier to enable system users to alter the layer priority,
>perhaps we'll make GUI changes if something like that happens? Or
>perhaps we'll make the change for the sake of the GUI? More thought
>required.
>
>>> Although the next page, 5, mentions that the machine list is a combo
>>> box. Is that the case?
>>
>> It is the case in the Image configuration screen, where users, before
>> building an image, select their machine using a combo box. This screen
>>is
>> different from the Settings dialogue, where you set some BibBake output
>> and system variables (the image output types between them). This
>>document
>> in the wiki
>>
>> http://wiki.yoctoproject.org/wiki/File:Hob_1.2_screens_inventory.pdf
>>
>> might help making sense of the different screens.
>
>Gotcha!
>
>>> Love the package format selection pieces!
>>>
>>> For the two parallel threads buttons we should recommend a default
>>>value
>>> and set a maximum based on the number of CPU cores - I think there's
>>> been a lot of discussion about this but I'm not certain what the
>>> recommendation which came out of it was.
>>
>> That would be really useful. Is it easy to accurately determine how many
>> cores are supported by the CPU of the machine running Hob?
>
>We can easily detect that, yes. The difficulty with enabling this kind
>of feature in the past has been balancing between providing an accurate
>recommendation and allowing the user to ignore it.
>
>I wonder if this would be better as a feature for later to allow us more
>time to get it right?
>
>
>>> For the directories on page 13 would it make sense to have a reset
>>> button to more easily get back to the defaults?
>>
>> Yes, this probably makes sense. I'll add that to the document next week.
>
>Great, thanks.
>
>Joshua
>-- 
>Joshua Lock
>         Yocto Project "Johannes factotum"
>         Intel Open Source Technology Centre

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: Hob 1.2 design - Settings dialogue

[Barros Pena, Belen]

I've added the reset option (restores the directories' default values) to
the Settings design document. The new version is at:

https://wiki.yoctoproject.org/wiki/File:Settings-dialogue-design-spec-v1.1.
pdf


Belen


On 03/02/2012 18:23, "Joshua Lock" <josh@linux.intel.com> wrote:

>On 03/02/12 06:42, Barros Pena, Belen wrote:
>> Your verbose mode it's pretty helpful (as it happens with most verbose
>> modes), so please don't turn it off.
>>
>> Answers below.
>>
>> Belen
>>
>> On 02/02/2012 21:51, "Joshua Lock"<josh@linux.intel.com>  wrote:
>>
>>> Hi Belen,
>>>
>>> Sorry this is so long, I don't know how to turn off my verbose switch.
>>>
>>> On page 4 you mention Shane's intention to have proxy settings in the
>>>UI
>>> - I just want to point out that this is usually an OS level
>>> configuration and we should be wary about how we implement it.
>>> I'd suggest we go so far as to just have a "Change system proxy
>>> settings" button which launches the OS's network configuration
>>>settings.
>>>
>>> Of course, this opens us up to potential issues around supporting the
>>> multitude of available network configuration tools on Linux but I'd
>>> suggest we start with a lowest common denominator approach and have the
>>> program behave intelligently.
>>>
>>> Explicitly we can detect whether the binary gnome-control-center and
>>>the
>>> so file /usr/lib64/control-center-1/panels/libnetwork.so exist (being
>>> clever about that path, too) and if so we can execute:
>>>
>>> "gnome-control-center display network"
>>>
>>> Which will display the network configuration (and therefore proxy)
>>> settings for stock Fedora and Ubuntu desktops.
>>
>> You guys are the experts. You tell me how you want it to work and I'll
>> design the UI for it! :)
>
>My concern here was not to duplicate OS GUI to change OS settings, feels
>to me that this is generally a bad idea. However I see from an
>alternative thread that the intention is to only set the proxy
>configuration for Yocto, if this is achievable through the site.conf I'm
>all for it!
>
>>> I understand why the Machines option might be more useful as a list
>>> widget (p5), rather than a combo box, but feel that this is devalued at
>>> least slightly by the fact that the list of available Machines isn't
>>> static and therefore it's not unlikely a user would have to scroll that
>>> list.
>>
>> Yes, the list will scroll at some point. I am not too worried about it
>> though, since I don't think that changing the image types will be
>> something users will do very often. I might be wrong though.
>
>I've made similar assumptions too, and as we don't have any data I'm in
>no rush to disagree with either of us :-)
>
>>> One suggestion might be to favour machines with a higher layer priority
>>> by listing them higher in the list?
>>
>> I don¹t know how the layer priorities work. Who sets those priorities?
>>Are
>> they aligned with user's priorities? If they are, yes, we should use the
>> layer priorities to determine the order of that list of machines.
>
>Layer priority currently is set by the layers author, but is editable by
>the layers user (it's "just" a text file).
>
>Maybe something to consider for future. There's been discussion about
>making it easier to enable system users to alter the layer priority,
>perhaps we'll make GUI changes if something like that happens? Or
>perhaps we'll make the change for the sake of the GUI? More thought
>required.
>
>>> Although the next page, 5, mentions that the machine list is a combo
>>> box. Is that the case?
>>
>> It is the case in the Image configuration screen, where users, before
>> building an image, select their machine using a combo box. This screen
>>is
>> different from the Settings dialogue, where you set some BibBake output
>> and system variables (the image output types between them). This
>>document
>> in the wiki
>>
>> http://wiki.yoctoproject.org/wiki/File:Hob_1.2_screens_inventory.pdf
>>
>> might help making sense of the different screens.
>
>Gotcha!
>
>>> Love the package format selection pieces!
>>>
>>> For the two parallel threads buttons we should recommend a default
>>>value
>>> and set a maximum based on the number of CPU cores - I think there's
>>> been a lot of discussion about this but I'm not certain what the
>>> recommendation which came out of it was.
>>
>> That would be really useful. Is it easy to accurately determine how many
>> cores are supported by the CPU of the machine running Hob?
>
>We can easily detect that, yes. The difficulty with enabling this kind
>of feature in the past has been balancing between providing an accurate
>recommendation and allowing the user to ignore it.
>
>I wonder if this would be better as a feature for later to allow us more
>time to get it right?
>
>
>>> For the directories on page 13 would it make sense to have a reset
>>> button to more easily get back to the defaults?
>>
>> Yes, this probably makes sense. I'll add that to the document next week.
>
>Great, thanks.
>
>Joshua
>-- 
>Joshua Lock
>         Yocto Project "Johannes factotum"
>         Intel Open Source Technology Centre

---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.