* Hob 1.2 design - Settings dialogue
@ 2012-02-02 16:58 Barros Pena, Belen
2012-02-02 17:24 ` Hob 1.2 design - visuals Barros Pena, Belen
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: Barros Pena, Belen @ 2012-02-02 16:58 UTC (permalink / raw)
To: yocto@yoctoproject.org
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.
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: Hob 1.2 design - visuals 2012-02-02 16:58 Hob 1.2 design - Settings dialogue Barros Pena, Belen @ 2012-02-02 17:24 ` Barros Pena, Belen 2012-02-02 21:19 ` Joshua Lock 2012-02-02 21:43 ` Hob 1.2 design - Settings dialogue Saul Wold 2012-02-02 21:51 ` Joshua Lock 2 siblings, 1 reply; 18+ messages in thread From: Barros Pena, Belen @ 2012-02-02 17:24 UTC (permalink / raw) To: yocto@yoctoproject.org; +Cc: Metthey, Mikael 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Hob 1.2 design - visuals 2012-02-02 17:24 ` Hob 1.2 design - visuals Barros Pena, Belen @ 2012-02-02 21:19 ` Joshua Lock 2012-02-03 11:52 ` Barros Pena, Belen 0 siblings, 1 reply; 18+ messages in thread From: Joshua Lock @ 2012-02-02 21:19 UTC (permalink / raw) To: yocto; +Cc: mikael.metthey 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Hob 1.2 design - visuals 2012-02-02 21:19 ` Joshua Lock @ 2012-02-03 11:52 ` Barros Pena, Belen 2012-02-03 18:32 ` Joshua Lock 0 siblings, 1 reply; 18+ messages in thread From: Barros Pena, Belen @ 2012-02-03 11:52 UTC (permalink / raw) To: Joshua Lock, yocto@yoctoproject.org; +Cc: Metthey, Mikael 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Hob 1.2 design - visuals 2012-02-03 11:52 ` Barros Pena, Belen @ 2012-02-03 18:32 ` Joshua Lock 2012-02-06 10:29 ` Barros Pena, Belen 0 siblings, 1 reply; 18+ messages in thread From: Joshua Lock @ 2012-02-03 18:32 UTC (permalink / raw) To: Barros Pena, Belen; +Cc: yocto@yoctoproject.org, Metthey, Mikael 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Hob 1.2 design - visuals 2012-02-03 18:32 ` Joshua Lock @ 2012-02-06 10:29 ` Barros Pena, Belen 2012-02-06 11:42 ` Wang, Shane 0 siblings, 1 reply; 18+ messages in thread From: Barros Pena, Belen @ 2012-02-06 10:29 UTC (permalink / raw) To: Joshua Lock, Wang, Shane, Xu, Dongxiao Cc: yocto@yoctoproject.org, Metthey, Mikael 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Hob 1.2 design - visuals 2012-02-06 10:29 ` Barros Pena, Belen @ 2012-02-06 11:42 ` Wang, Shane 2012-02-06 13:54 ` Barros Pena, Belen 0 siblings, 1 reply; 18+ messages in thread From: Wang, Shane @ 2012-02-06 11:42 UTC (permalink / raw) To: Barros Pena, Belen, Joshua Lock, Xu, Dongxiao Cc: yocto@yoctoproject.org, Metthey, Mikael 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Hob 1.2 design - visuals 2012-02-06 11:42 ` Wang, Shane @ 2012-02-06 13:54 ` Barros Pena, Belen 2012-02-06 21:56 ` Joshua Lock 0 siblings, 1 reply; 18+ messages in thread From: Barros Pena, Belen @ 2012-02-06 13:54 UTC (permalink / raw) To: Wang, Shane, Joshua Lock, Xu, Dongxiao Cc: yocto@yoctoproject.org, Metthey, Mikael [-- 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 --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Hob 1.2 design - visuals 2012-02-06 13:54 ` Barros Pena, Belen @ 2012-02-06 21:56 ` Joshua Lock 0 siblings, 0 replies; 18+ messages in thread From: Joshua Lock @ 2012-02-06 21:56 UTC (permalink / raw) To: Barros Pena, Belen; +Cc: Metthey, Mikael, yocto@yoctoproject.org 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Hob 1.2 design - Settings dialogue 2012-02-02 16:58 Hob 1.2 design - Settings dialogue Barros Pena, Belen 2012-02-02 17:24 ` Hob 1.2 design - visuals Barros Pena, Belen @ 2012-02-02 21:43 ` Saul Wold 2012-02-03 11:55 ` Barros Pena, Belen 2012-02-02 21:51 ` Joshua Lock 2 siblings, 1 reply; 18+ messages in thread From: Saul Wold @ 2012-02-02 21:43 UTC (permalink / raw) To: Barros Pena, Belen; +Cc: yocto@yoctoproject.org 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 > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Hob 1.2 design - Settings dialogue 2012-02-02 21:43 ` Hob 1.2 design - Settings dialogue Saul Wold @ 2012-02-03 11:55 ` Barros Pena, Belen 0 siblings, 0 replies; 18+ messages in thread From: Barros Pena, Belen @ 2012-02-03 11:55 UTC (permalink / raw) To: Saul Wold; +Cc: yocto@yoctoproject.org 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Hob 1.2 design - Settings dialogue 2012-02-02 16:58 Hob 1.2 design - Settings dialogue Barros Pena, Belen 2012-02-02 17:24 ` Hob 1.2 design - visuals Barros Pena, Belen 2012-02-02 21:43 ` Hob 1.2 design - Settings dialogue Saul Wold @ 2012-02-02 21:51 ` Joshua Lock 2012-02-02 22:01 ` Joshua Lock 2012-02-03 14:42 ` Barros Pena, Belen 2 siblings, 2 replies; 18+ messages in thread From: Joshua Lock @ 2012-02-02 21:51 UTC (permalink / raw) To: Barros Pena, Belen; +Cc: yocto@yoctoproject.org 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Hob 1.2 design - Settings dialogue 2012-02-02 21:51 ` Joshua Lock @ 2012-02-02 22:01 ` Joshua Lock 2012-02-03 17:04 ` Scott Garman 2012-02-03 14:42 ` Barros Pena, Belen 1 sibling, 1 reply; 18+ messages in thread From: Joshua Lock @ 2012-02-02 22:01 UTC (permalink / raw) To: Barros Pena, Belen; +Cc: yocto@yoctoproject.org 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Hob 1.2 design - Settings dialogue 2012-02-02 22:01 ` Joshua Lock @ 2012-02-03 17:04 ` Scott Garman 0 siblings, 0 replies; 18+ messages in thread From: Scott Garman @ 2012-02-03 17:04 UTC (permalink / raw) To: yocto 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Hob 1.2 design - Settings dialogue 2012-02-02 21:51 ` Joshua Lock 2012-02-02 22:01 ` Joshua Lock @ 2012-02-03 14:42 ` Barros Pena, Belen 2012-02-03 18:23 ` Joshua Lock 1 sibling, 1 reply; 18+ messages in thread From: Barros Pena, Belen @ 2012-02-03 14:42 UTC (permalink / raw) To: Joshua Lock; +Cc: yocto@yoctoproject.org 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Hob 1.2 design - Settings dialogue 2012-02-03 14:42 ` Barros Pena, Belen @ 2012-02-03 18:23 ` Joshua Lock 2012-02-06 10:20 ` Barros Pena, Belen 2012-02-07 14:27 ` Barros Pena, Belen 0 siblings, 2 replies; 18+ messages in thread From: Joshua Lock @ 2012-02-03 18:23 UTC (permalink / raw) To: Barros Pena, Belen; +Cc: yocto@yoctoproject.org 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 ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Hob 1.2 design - Settings dialogue 2012-02-03 18:23 ` Joshua Lock @ 2012-02-06 10:20 ` Barros Pena, Belen 2012-02-07 14:27 ` Barros Pena, Belen 1 sibling, 0 replies; 18+ messages in thread From: Barros Pena, Belen @ 2012-02-06 10:20 UTC (permalink / raw) To: Joshua Lock, yocto@yoctoproject.org 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Hob 1.2 design - Settings dialogue 2012-02-03 18:23 ` Joshua Lock 2012-02-06 10:20 ` Barros Pena, Belen @ 2012-02-07 14:27 ` Barros Pena, Belen 1 sibling, 0 replies; 18+ messages in thread From: Barros Pena, Belen @ 2012-02-07 14:27 UTC (permalink / raw) To: Joshua Lock; +Cc: yocto@yoctoproject.org 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2012-02-07 14:28 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-02-02 16:58 Hob 1.2 design - Settings dialogue Barros Pena, Belen 2012-02-02 17:24 ` Hob 1.2 design - visuals Barros Pena, Belen 2012-02-02 21:19 ` Joshua Lock 2012-02-03 11:52 ` Barros Pena, Belen 2012-02-03 18:32 ` Joshua Lock 2012-02-06 10:29 ` Barros Pena, Belen 2012-02-06 11:42 ` Wang, Shane 2012-02-06 13:54 ` Barros Pena, Belen 2012-02-06 21:56 ` Joshua Lock 2012-02-02 21:43 ` Hob 1.2 design - Settings dialogue Saul Wold 2012-02-03 11:55 ` Barros Pena, Belen 2012-02-02 21:51 ` Joshua Lock 2012-02-02 22:01 ` Joshua Lock 2012-02-03 17:04 ` Scott Garman 2012-02-03 14:42 ` Barros Pena, Belen 2012-02-03 18:23 ` Joshua Lock 2012-02-06 10:20 ` Barros Pena, Belen 2012-02-07 14:27 ` Barros Pena, Belen
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.