Belen – nice work!&= nbsp; This just gets better all the time. I really like the enhanceme= nts to the work flow.

<= /p>

Quick question – ar= ound 6:40 in the video, once you successfully build there is a “Deplo= y Image” button. Then at 7:44 there is a “Write to Storage̶= 1; button. Are these both doing the same thing?

<= /p>

Thank you for making some= thing so functional and so beautiful.

<= /p>

Dave

<= /p>

From: yocto-bo= unces@yoctoproject.org [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Wang, Shane
Sent: Wednesday, February 01, 2012 9:39 AM
To: yocto@yoctoproject.org
Subject: [yocto] RFC: Hob 1.2 design

<= o:p>

<= a href=3D"https://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast2.mov">h= ttps://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast2.mov

To: "yocto@yoctoproject.org" Thread-Topic: [yocto] Hob 1.2 design Thread-Index: AQHM4ZZ8cmNZ+QhP2E2sZucRJX0/sA== Date: Thu, 2 Feb 2012 10:36:14 +0000 Message-ID: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.252.22.131] MIME-Version: 1.0 Subject: Re: Hob 1.2 design X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 10:37:38 -0000 Content-Language: en-US Content-ID: <340A54AF6A9E69478DB1A3B180D50CC4@intel.com> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" You are right, Dave. "Deploy image" and "Write to storage" are the same thi= ng. I meant to use "Write to storage" everywhere (it seemed a more accurate= description), but a "Deploy" slipped through! Thanks for the nice feedback. Belen From: "Stewart, David C" > Date: Wed, 1 Feb 2012 03:15:55 +0000 To: "Wang, Shane" >, "yoc= to@yoctoproject.org" > Subject: Re: [yocto] Hob 1.2 design Belen =96 nice work! This just gets better all the time. I really like th= e enhancements to the work flow. Quick question =96 around 6:40 in the video, once you successfully build th= ere is a =93Deploy Image=94 button. Then at 7:44 there is a =93Write to Sto= rage=94 button. Are these both doing the same thing? Thank you for making something so functional and so beautiful. Dave From: yocto-bounces@yoctoproject.org= [mailto:yocto-bounces@yoctoproject.org] On Behalf Of Wang, Shane Sent: Wednesday, February 01, 2012 9:39 AM To: yocto@yoctoproject.org Subject: [yocto] RFC: Hob 1.2 design Hi, all, Belen has a new video for Hob2 workflow and design. https://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast2.mov Please comment. Thanks. -- Shane _______________________________________________ yocto mailing list yocto@yo= ctoproject.org https://lists.yoctoproject.or= g/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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id B9F05E0059B for ; Thu, 2 Feb 2012 04:48:47 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 02 Feb 2012 04:48:47 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,217";a="119645332" Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81]) by fmsmga002.fm.intel.com with ESMTP; 02 Feb 2012 04:48:45 -0800 Received: from pgsmsx103.gar.corp.intel.com (10.221.44.82) by pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 2 Feb 2012 20:48:06 +0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by PGSMSX103.gar.corp.intel.com (10.221.44.82) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 2 Feb 2012 20:48:05 +0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.36]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.142]) with mapi id 14.01.0355.002; Thu, 2 Feb 2012 20:48:04 +0800 From: "Wang, Shane" To: "Wang, Shane" , "Barros Pena, Belen" , "Xu, Dongxiao" , "Lu, Lianhao" Thread-Topic: RFC: Hob 1.2 design Thread-Index: AQHM1ghN2ta+vDnY0kiXcbK0irRQ85YS108ggAGuLCCAAHlrgIAGmYWAgAb8MNCAAqn0gIACotQAgABGdBCAAFS8AIAAmk2AgABm6zA= Date: Thu, 2 Feb 2012 12:48:03 +0000 Message-ID: <3AB6CE7F274E534CAFD089D127A8A1FC0FCEB255@SHSMSX102.ccr.corp.intel.com> References: <3AB6CE7F274E534CAFD089D127A8A1FC0FCE9F5F@SHSMSX102.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "Purdie, Richard" , "Lock, Joshua" , "yocto@yoctoproject.org" , "Eggleton, Paul" Subject: Re: RFC: Hob 1.2 design X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 12:48:48 -0000 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_3AB6CE7F274E534CAFD089D127A8A1FC0FCEB255SHSMSX102ccrcor_" --_000_3AB6CE7F274E534CAFD089D127A8A1FC0FCEB255SHSMSX102ccrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see my feedbacks embedded in red. Thanks. -- Shane From: "Wang, Shane" > Date: Wed, 1 Feb 2012 14:49:38 +0000 To: "Belen Barros Pena (Intel)" >, "Xu, Dongxiao" >, "Lu, Lianhao" > Subject: RE: Hob 1.2 next steps Thank you for making the video. We three have some comments and questions on the video. 1) the style of the package view is not consistent with the one of recipe v= iew. True. I was planning to redesign the recipe view and the package view to b= ring them in line with the Packages screen. I think I need to clarify the d= ifference between windows and dialogues in the interface. In the design sho= wn in the video, Hob has one window, which changes depending on the buildin= g stage to show one of the following screens: Image configuration, Building= packages, Packages, Building image and Image details. The 'recipe view' an= d the 'package view' are dialogues that you launch via the 'view recipes' a= nd 'view packages' buttons. Therefore, the Packages screen that displays af= ter the packages are built, and the package dialogue you launch using the '= view packages' button, are 2 different things. [Shane]: OK, I understand they are 2 difference screens. But actually both = can reuse the same screen, because I didn't see any functional difference b= etween the Packages screen and the Packages dialog. In your previous video, recipe view has sort of "summary" which lists all r= ecipes selected on the right side. Can we remove the tab "Included" and mak= e a "summary" for the package view? And with the tab "Included", we need to= scroll down to find a package or locate it in the search box, and then do = "Remove" for example, it is not better than the "summary" because the "summ= ary" can show all or more. I agree that the Packages screen should look similar to the Recipes dialogu= e and the Packages dialogue. But after seeing the 'summary' working it seem= s to me that it is not the best solution. The goals of the summary were: 1. Allow users to easily see what's selected to be included in their ima= ge 2. Allow users to easily understand what's brought by what I am not sure the existing summary does a good job at any of the two. Space= restrictions make reading what's included quite difficult (particularly wh= en the names of packages or recipes wrap), and the layout does not facilita= te skimming content, which is what you'll do with the summary (you won't re= ad it all from top to bottom: you'll skim the recipes/packages to find some= thing you are looking for). The relationship between what brings what, repr= esented by the highlight, is lost once you perform a new selection. The sum= mary also creates a lot of clutter in the interface: the screen is so busy,= it's hard to know what to look at. [Shane]: I agree with you on "you won't read it all from top to bottom". Bu= t I found the summary had another advantage which "Included" in the current= Packages screen doesn't have. That is: when I select one more package, wha= t is brought by it will be highlighted, so I can see the difference between= before and after I select. The existing Packages screen presents less information at any given time: i= t feels cleaner and easier to read. It's true that it requires users to sel= ect the Included tab in order to see what's to be included in their image, = but it provides a much more focused interface. The 'brought by' column avoi= ds losing the relationship between what brings what, and the sorting and se= arching mechanisms should minimise the need for scrolling. After multiple iterations (it took a very long time to design that screen),= I believe the Included tab is a better solution than the Summary. If you a= re convinced that the Summary is better, we'll go for it, but I felt I had = to explain my concerns with it. [Shane]: Both have advantages and disadvantages. I don't think it is hard t= o implement "Included". On the contrary, the Summary is;-) I also like to h= ear some feedbacks from the community and the others. BTW: do you mean in the Recipes dialog, we also replace the Summary with th= e tab "Included"? 2) ditto, I see there is a button "Build Image" in the package view. I know= what the purpose is. But for the recipe view, there is no button. We also = can "build image" or "build package" in the recipe view without going back = to the main window at 1:39. Do you mind that we simplify by removing "Build= Image" in the package view? I think there is some confusion about the Packages screen (which is a windo= w), and what you call the 'package view' and 'recipe view', which are dialo= gues. This is really my fault: I should have explained this better. I've designed the Hob interface as a multi-step process with 3 steps, each = represented by a screen displayed in the main Hob window: Step 1 - Image configuration screen: users input the build parameters, such= as machine, base image and recipes Step 2 - Package screen: this is not a mandatory step. You can skip it by s= electing 'Build image' in Step 1. Users review and might edit the list of p= ackages to be included in their image, and then proceed to build the image.= The 'Build image' button is required to proceed to Step 3 Step 3 - Image details screen: the image has been built, and users can sele= ct from a range of possible actions [Shane]: I see. They are 2 different things. Since the above screens are steps in a process, they require an action (i.e= . a button) to move to the next step of the process. The recipes and packages dialogues are not steps in the building process: t= hey are contained pieces of functionality that can be displayed on demand. = The recipes dialogue allows users to see and edit the recipes included in t= he base image. I assume the packages dialogue allows users to include alrea= dy built packages in the base image (if this is not correct please let me k= now). [Shane]: Your assumption is right. The actions in any dialogue should be 'Save' and 'Cancel'. Those actions we= re not included in the original design because I didn't think of them as di= alogues: more as inspectors like the ones in Gimp. You implemented them as = dialogues, which I think works really well (probably better than as inspect= ors I must say): we just need to add those 'Save' and 'Cancel' buttons to t= hem. I hope this explains why we have a 'Build image' button in the Packages scr= een, but not in the recipes and packages dialogues. [Shane]: Understand. 3) After clicking "My images" to open an image, how does UI determine to sh= ow "Run Image" or "Write to Storage", or "Deploy" or "View Image files"? First of all, you are right: 'Deploy' and 'Write to storage' are exactly th= e same thing. I meant to use 'Write to storage' everywhere: sorry about tha= t. My bad :( - If the building output included a live image, the Image details screen sh= ows the 'Write to storage' button - If the image is a qemu image, the Image details screen shows the 'Run ima= ge' button. Clicking the button starts up the virtual machine [Shane]: Makes sense. A technical question for expert in the mail list, how= can we distinguish whether an image is a QEMU image or an image for real h= ardware, regarding the fact users can change the image name as they want? - Otherwise the Image details screen shows the 'View image files' button [Shane]: Can you give an example about "Otherwise"? I hope this makes sense. Otherwise let me know. 4) At 6:36, how can the user go back to the main window at 1:39? Should the= user wait until the build is finished or stop it by clicking "Stop build"? Exactly: the only option at that point is to stop the build. I haven't desi= gned what happens when you stop the build yet, but I'd say something simila= r to what happens now: a prompt asks users to confirm that they want to sto= p the build, and if yes Hob reverts back to the screen from which the user = started the building image process, which can be the Image configuration sc= reen or the Packages screen. [Shane]: Understand. If any error happens when building, it will stay there= because I assume users want to see the log. Then how can users get back to= the Image configuration screen or the Package screen, after closing it? 5) For "save template" and "load template", the only chance for users to do= "save template" is when the build is done, yes? Well, I don't know. That's the way it seems to work in the latest version o= f Hob, but it doesn't mean it has to stay that way. However, we think users can save any settings for build environments, and a= ny selection of packages or recipes in an image even though the build doesn= 't start. Then next time he/she can resume the job by starting with the stu= ffs saved. I totally agree with you that users should be able to save a template befor= e building the image. Again, we are considering whether it is good to put "load template" and "sa= ve template" together, because they are similar actions. I don't think I would do it that way. 'Load template' is a way to initiate = the building process, and therefore something you might want to do at any t= ime. As such, it makes sense to make it an option in the toolbar, like 'ope= ning an image', where is always available. 'Save template' is something that sequentially comes after configuring the = image parameters. It's like a function that takes as parameters a machine a= nd a base image (with its recipes or packages). Therefore the action of sav= ing a template only makes sense when a machine and base image have been sel= ected. If you represent it as a button in the toolbar, you will have to sho= w it in an inactive state until a machine and base image have been selected= . Otherwise, what are you saving as a template? As such, it makes sense to = display it after those parameters have been set, i.e., after the 'View reci= pes' and 'View packages' buttons. If you agree with the above, I can review the Image configuration screen an= d add a 'Save as template' action to it. [Shane]: OK, I agree to enable the button "Save as template" after all para= meters in the Image configuration screen have been set. Keep this open, ple= ase. 6) At 7:07, "view files" is the same as "My images"? I don't think so. 'My images' would open a File Chooser Dialog http://developer.gnome.org/gtk3/stable/GtkFileChooserDialog.html Selecting an image file from the file chooser dialog would open the Hob "Im= age details' screen for the selected image file. "View files" would open a regular file manager window in the tmp/deploy/ima= ges directory. Selecting the image file from this file manager window would= simply open the image in the default application assigned to the file exte= nsion (it would not open the image details screen in Hob). "View files" is = just a quick way to navigate to the tmp/deploy/images directory. [Shane]: OK, I see. 7) We are thinking "My images" is similar as "Load template", because the i= mage contains the info of settings etc. so does the template. The only diff= is after opening an image, we can deploy it or run it. But for template, i= t is sort of "virtual" stuff, we have to build according to the definitions= of the template. So, to some extent, "My images" =3D "Template" + able to = deploy and run, what do you think? I agree, but I also think that the ability to deploy and run that comes wit= h images and is missing from templates is a significant difference. It mean= s that the logical next steps after opening a template and opening an image= are very different too. After opening a template the logical next steps are: edit the parameters if= you wish, then build. That's why loading a template brings you to the Imag= e configuration screen, where you can edit parameters and build. After opening an image the logical next steps are deploy / run. That's why = opening an image brings you to the Image details screen, where you can depl= oy / run. [Shane]: But on the Image details screen, you can click "Edit Configuration= " to go to the Image configuration screen. Then the rest is totally the sam= e as the above. A technical question comes to me, it is also for experts. Is there a way to= modify bitbake to write some more information into the target image, and f= or Hob to unpack and fetch the information later? For this part, we also consider the client/server mode with XMLRPC: We have= the capability to run bitbake server on the server side, but UI on the cli= ent side. So the image in "My images" always is generated on the server sid= e, and the template in "Load template" is a config file on the client side. It sort of makes sense to me that templates are local files, while images a= re kept on a server where they can be shared, but I definitely don't know e= nough to have an opinion. You guys are the experts on this! :) I guess that if no client / server mode is set up and I am running everythi= ng locally, then images will also be kept locally. Is that the case? [Shane]: Yes, that is. Temporarily we can skip the case running on client a= nd server. We assume all are on the client. 8) We already saw some buttons "Settings", "Deploy image", "Run image", "Lo= ad Template" and "Save Template", "Build New image", "Edit Configuration" o= r "Edit packages", "View image files" on different windows. So probably tha= t makes switching between windows a bit complex. For instance, At 8:24, cli= cking "Edit packages" will go back to the package view. But what if users j= ust make a mistake on the UI and want to go back to the window at 8:24? Well, they can't :) The Packages screen is an intermediate step that allows= you to view and edit the packages to be included in your image: nothing el= se. If you land there by mistake, you can still get out via the 'Back to im= age configuration' option. From there, you can go back to the Image configu= ration screen by opening the image you built. We could change the "Build image" button into a go forward button, and if t= he user makes any changes to the packages display again the 'Build image' b= utton, but I am not sure if it would be worth the development effort. Providing access to all previous screens could be done by some kind of brea= dcrumb (a representation of each step in the process you can click on to ac= cess the step), but breadcrumbs are problematic when the number of steps in= a process can change, like in Hob. Remember than you can decide to go thro= ugh the packages step, or skip it and build the image directly. [Shane]: Personally, I don't like to change "Build image" to a "Go forward"= button, because it would be possible that users want to rebuild the image = without any change. With many buttons on many windows, we have a lot of combinations, then we h= ave a lot of states for the UI. True: there are a few things you can do in the Image details screen. You ca= n save your image as a template, you can edit the image, you can view the i= mage files, you can deploy or run the image when applicable, and you can b= uild a new image. You can also open a Template or a different image. All th= ose are reasonable next steps once you have reached the end of building pro= cess, and all of them should be present in the interface. And we are thinking "Settings", "Deploy image", "Run image", "Load Template= " and "Save Template" are important for us, and whether we can use menus or= buttons on a toolbar. We prefer the latter, and prefer we have a main wind= ow and others are all dialogs inherited from the main window. What do you t= hink on this? I can see your point here. I did consider that structure after I saw it wor= king. It's quite nice. However, I can see a couple of problems with it: 1. It brings the concept of progressive disclosure (new options displayi= ng as a result of user selections) that we use in the Image configuration s= creen to a breaking point. There are too many things happening in that main= window. When you start building, the progress bar has to display at the bo= ttom of the screen, which looks awkward, and there is not enough space to p= rovide clear next steps after the packages and image have been built. 2. Having 'Deploy image' and 'Run image' buttons in the toolbar will cau= se problems. They fire actions that require a parameter (an image to deploy= or run). They could get this parameter by taking the last image that has b= een built, and deploy or run that image. But what if no image has been buil= t yet? What if the last image was built a few days ago and it's not at all = the image you want to deploy or run? The alternative would be asking the us= er what's the image she wants to deploy or run. You would open a file choos= er dialog for that. But imagine the following situation: I've just finished= building a qemu image. The "congratulations" message and the path to my im= age are displayed at the bottom of the main screen. I want to run my image,= so I click on the 'run image' button in the toolbar, expecting it of cours= e to run the qemu image I've just built. Instead, it pops up a file chooser= dialog and I have to select the image I just built to run it! Such a syste= m would feel a bit dumb: why is it asking me which image do I want to run? = Isn't it obvious I want to run the qemu image I've just built? To avoid thi= s type of 'dumb' reactions by the UI, actions should be displayed where and= when applicable. Actions in toolbars and menus are always present, which m= eans they are always applicable, they make sense at all times, independentl= y of the system state: I call them global actions. Opening a template, open= ing an image or accessing settings are kind of global actions. Running or d= eploying an image are 'contextual' actions, they only make sense when the s= ystem is in a certain state: for example, right after building a qemu image= . If you position global actions in toolbars or menus, you will have to mak= e extensive use of inactive states, which means displaying things that don'= t make sense in such a way that you cannot use them (which is just noise), = or make them behave in different ways depending on the system state (which = is confusing). 9) a small question as Dave has, what is the diff between "deploy image"and= "write to storage"? We think they are the same. Dave is completely right: 'Deploy' and 'Write to storage' are exactly the s= ame thing. I meant to use 'Write to storage' everywhere: sorry about that. = My bad :( [Shane]: Three more we want to consider: 1. we want to add proxy setting into "Settings" to support proxy 2. When users fail to build images, there is no option or button to clean a= ll (like sstate) but bitbake command has (bitbake -c cleanall). We hope to = add it into the GUI. 3. can the button "Settings" be there only on the Image configuration scree= n? It doesn't make any sense to set the parameters on the Image details scr= een, agree? Ditto for "Load Template" on the Image details screen. We also can init= iate a new build by "Build new image" and "Load Template", thoughts? Sorry, many feedbacks;-) And we are also thinking to simplify the rest of t= he design and finalize asap so we can finish the implementation before the = end of M3. (the end of Feb). I totally understand you might not have time to implement the design I've s= ent. If this is the problem, please do let me know, and let's talk about wh= at's feasible. Maybe we could keep the current structure (all steps in the = main screen), but look for some alternative options to position the 'Deploy= image', 'Run image' and 'Save as template' actions ... not in the toolbar = or menus, please! ;) [Shane]: We will try our best. Another FYI, we get your feedbacks in the two pdf files you sent previously= and are revising the UI. Thanks. --_000_3AB6CE7F274E534CAFD089D127A8A1FC0FCEB255SHSMSX102ccrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please see my feedbacks emb= edded in red.

Thanks.

Shane

From: "Wang, Shane" <<= span style=3D"font-size:12.0pt">shane.wang@intel.com>
Date: Wed, 1 Feb 2012 14:49:38 +0000
To: "Belen Barros Pena (Intel)" <belen.barros.pena@intel.com= >, "Xu, Dongxiao" <dongxiao.xu@intel.com>, "Lu, Lianhao" <l= ianhao.lu@intel.com>
Subject: RE: Hob 1.2 next steps

Thank you for making the video.

We three have some comments and questions on= the video.

1) the style of the package view is not cons= istent with the one of recipe view.

True. I was planning to redes= ign the recipe view and the package view to bring them in line with t= he Packages screen. I think I need to clarify the difference between windows and dialogues in the interface. In the design shown in the video, = Hob has one window, which changes depending on the building stage to show o= ne of the following screens: Image configuration, Building packages, P= ackages, Building image and Image details. The 'recipe view' and the 'package view' are dialogues that you launch via= the 'view recipes' and 'view packages' buttons. Therefore, the Packages sc= reen that displays after the packages are built, and the package dialogue y= ou launch using the 'view packages' button, are 2 different things.

= ;

[Shane]: OK, I understand they = are 2 difference screens. But actually both can reuse the same screen, beca= use I didn’t see any functional difference between the Packages screen and the Packages dialog.

In your previous video, recipe view has sort of “summary”= which lists all recipes selected on the right side. Can we remove the tab “Included” and make a “summary” for the package vi= ew? And with the tab “Included”, we need to scroll down to find= a package or locate it in the search box, and then do “Remove”= for example, it is not better than the “summary” because the &= #8220;summary” can show all or more.

I agree that the Packages screen should look similar to the Recipes dia= logue and the Packages dialogue. But after seeing the 'summary' working it seems to me that it is not the best solution. The goals of the = summary were:

Allow users to easily see what'= s selected to be included in their image
Allow users to easily understan= d what's brought by what

I am not sure the existing su= mmary does a good job at any of the two. Space restrictions make reading wh= at's included quite difficult (particularly when the names of packages or recipes wrap), and the layout does not facilitate skimming = content, which is what you'll do with the summary (you won't read it all fr= om top to bottom: you'll skim the recipes/packages to find something you ar= e looking for). The relationship between what brings what, represented by the highlight, is lost once you p= erform a new selection. The summary also creates a lot of clutter in the in= terface: the screen is so busy, it's hard to know what to look at.

= ;

[Shane]: I agree with you on &#= 8220;you won't read it all from top to bottom= ”. But I found the summary had another advantage which “Included”= in the current Packages screen doesn’t have. That is: when I select = one more package, what is brought by it will be highlighted, so I can see t= he difference between before and after I select.

The existing Packages screen = presents less information at any given time: it feels cleaner and easier to= read. It's true that it requires users to select the Included tab in order to see what's to be included in their image, but it provides = a much more focused interface. The 'brought by' column avoids losing the re= lationship between what brings what, and the sorting and searching mechanis= ms should minimise the need for scrolling.

After multiple iterations (it= took a very long time to design that screen), I believe the Included tab i= s a better solution than the Summary. If you are convinced that the Summary is better, we'll go for it, but I felt I had to explain m= y concerns with it.

= ;

[Shane]: Both have advantages a= nd disadvantages. I don’t think it is hard to implement “Includ= ed”. On the contrary, the Summary is;-) I also like to hear some feed= backs from the community and the others.

BTW: do you mean in the Recipes= dialog, we also replace the Summary with the tab “Included”?

2) ditto, I see there is a button “Bui= ld Image” in the package view. I know what the purpose is. But for the recipe view, there is no button. We also can “build image”= or “build package” in the recipe view without going back to th= e main window at 1:39. Do you mind that we simplify by removing “Buil= d Image” in the package view?

I think there is some confusion about the Packages screen (which = is a window), and what you call the 'package view' and 'recipe view', which are dialogues. This is really my fault: I s= hould have explained this better.

I've designed the Hob interface as a multi-step process with 3 st= eps, each represented by a screen displayed in the main Hob window:

Step 1 &= #8211; Image configuration screen: users input the build parameters, such a= s machine, base image and recipes

Step 2 &= #8211; Package screen: this is not a mandatory step. You can skip it by sel= ecting 'Build image' in Step 1. Users review and might edit the list of packages to be included in their image, and then proceed to build the i= mage. The 'Build image' button is required to proceed to Step 3

Step 3 &= #8211; Image details screen: the image has been built, and users can select= from a range of possible actions

= ;

[Shane]: I see. They are 2 diff= erent things.

Since th= e above screens are steps in a process, they require an action (i.e. a butt= on) to move to the next step of the process.<= /o:p>

The reci= pes and packages dialogues are not steps in the building process: they are = contained pieces of functionality that can be displayed on demand. The recipes dialogue allows users to see and edit the recipes included in = the base image. I assume the packages dialogue allows users to include alre= ady built packages in the base image (if this is not correct please let me = know).

= ;

[Shane]: Your assumption is rig= ht.

The acti= ons in any dialogue should be 'Save' and 'Cancel'. Those actions were not i= ncluded in the original design because I didn't think of them as dialogues: more as inspectors like the ones in Gimp. You implemented th= em as dialogues, which I think works really well (probably better than as i= nspectors I must say): we just need to add those 'Save' and 'Cancel' button= s to them.

I hope t= his explains why we have a 'Build image' button in the Packages screen, but= not in the recipes and packages dialogues.

[Shane]: Understand.=

3) After clicking “My images” to open an image, how does = UI determine to show “Run Image” or “Write to StorageR= 21;, or “Deploy” or “View Image files”?

First of= all, you are right: 'Deploy' and 'Write to storage' are exactly the same t= hing. I meant to use 'Write to storage' everywhere: sorry about that. My bad :(

- If the= building output included a live image, the Image details screen shows the = 'Write to storage' button

- If the= image is a qemu image, the Image details screen shows the 'Run image' butt= on. Clicking the button starts up the virtual machine

[Shane]: Makes sense. A technical question for expert in the mail list, h= ow can we distinguish whether an image is a QEMU image or an image for real hardware, regarding the fact users can change the image nam= e as they want?

- Otherw= ise the Image details screen shows the 'View image files' button

= ;

[Shane]: Can you give an exampl= e about “Otherwise”?

= ;

I hope t= his makes sense. Otherwise let me know.=

4) At 6:36, how can the user go back to the = main window at 1:39? Should the user wait until the build is finished or stop it by clicking “Stop build”?

Exactly:= the only option at that point is to stop the build. I haven't designed wha= t happens when you stop the build yet, but I'd say something similar to what happens now: a prompt asks users to confirm that they want= to stop the build, and if yes Hob reverts back to the screen from which th= e user started the building image process, which can be the Image configura= tion screen or the Packages screen.

= ;

[Shane]: Understand. If any err= or happens when building, it will stay there because I assume users want to= see the log. Then how can users get back to the Image configuration screen or the Package screen, after closing it?

5) For “save template” and ̶= 0;load template”, the only chance for users to do “save templat= e” is when the build is done, yes?

Well, I = don't know. That's the way it seems to work in the latest version of Hob, b= ut it doesn't mean it has to stay that way.

However, we think users can save any setting= s for build environments, and any selection of packages or recipes in an image even though the build doesn’t start. Then next time he/s= he can resume the job by starting with the stuffs saved.

I totall= y agree with you that users should be able to save a template before buildi= ng the image.

Again, we are considering whether it is good= to put “load template” and “save template” togethe= r, because they are similar actions.

I don't = think I would do it that way. 'Load template' is a way to initiate the buil= ding process, and therefore something you might want to do at any time. As such, it makes sense to make it an option in the toolbar, lik= e 'opening an image', where is always available.

'Save te= mplate' is something that sequentially comes after configuring the image pa= rameters. It's like a function that takes as parameters a machine and a base image (with its recipes or packages). Therefore the action of s= aving a template only makes sense when a machine and base image have been s= elected. If you represent it as a button in the toolbar, you will have to s= how it in an inactive state until a machine and base image have been selected. Otherwise, what are you = saving as a template? As such, it makes sense to display it after thos= e parameters have been set, i.e., after the 'View recipes' and 'View packag= es' buttons.

If you a= gree with the above, I can review the Image configuration screen and add a = 'Save as template' action to it.=

[Shane]: OK, I agree to enable = the button “Save as template” after all parameters in the Image= configuration screen have been set. Keep this open, please.

6) At 7:07, “view files” is the same as “My i= mages”?

I don't = think so. 'My images' would open a File Chooser Dialog

http://developer.gnome.org/gtk3/stable/GtkFileChooserDialog.h= tml

Selectin= g an image file from the file chooser dialog would open the Hob "Image= details' screen for the selected image file.=

"Vi= ew files" would open a regular file manager window in the tmp/deploy/i= mages directory. Selecting the image file from this file manager window would simply open the image in the default application assigned to the fil= e extension (it would not open the image details screen in Hob). "View= files" is just a quick way to navigate to the tmp/deploy/images direc= tory.

= ;

[Shane]: OK, I see.<= /span>

7) We are thinking “My images” i= s similar as “Load template”, because the image contains the in= fo of settings etc. so does the template. The only diff is after opening an image, we can= deploy it or run it. But for template, it is sort of “virtual”= stuff, we have to build according to the definitions of the template. So, = to some extent, “My images” =3D “Template” + ab= le to deploy and run, what do you think?

I agree, but I also think that the ability to deploy and run that= comes with images and is missing from templates is a significant difference. It means that the logical next steps after op= ening a template and opening an image are very different too. =

After op= ening a template the logical next steps are: edit the parameters if you wis= h, then build. That's why loading a template brings you to the Image configuration screen, where you can edit parameters and build. =

After op= ening an image the logical next steps are deploy / run. That's why opening = an image brings you to the Image details screen, where you can deploy / run.

[Shane]: But on the Image detai= ls screen, you can click “Edit Configuration” to go to the Imag= e configuration screen. Then the rest is totally the same as the above.

A technical question comes to m= e, it is also for experts. Is there a way to modify bitbake to write some m= ore information into the target image, and for Hob to unpack and fetch the information later?

For this part, we also consider the client/s= erver mode with XMLRPC: We have the capability to run bitbake server on the server side, but UI on the client side. So the image in R= 20;My images” always is generated on the server side, and the templat= e in “Load template” is a config file on the client side.

It sort of makes sense to me that templates are local files, whil= e images are kept on a server where they can be shared, but I definitely don't know enough to have an opinion. You guys= are the experts on this! :) =

I guess = that if no client / server mode is set up and I am running everything local= ly, then images will also be kept locally. Is that the case?

= ;

[Shane]: Yes, that is. Temporar= ily we can skip the case running on client and server. We assume all are on= the client.

8) We already saw some buttons “Settin= gs”, “Deploy image”, “Run image”, “Load= Template” and “Save Template”, “Build New image”, “Edit Configuration” or “= Edit packages”, “View image files” on different windows. = So probably that makes switching between windows a bit complex. For instanc= e, At 8:24, clicking “Edit packages” will go back to the packag= e view. But what if users just make a mistake on the UI and want to go back to the window a= t 8:24?

Well, th= ey can't :) The Packages screen is an intermediate step that allows you to = view and edit the packages to be included in your image: nothing else. If you land there by mistake, you can still get out via the 'Back to= image configuration' option. From there, you can go back to the Image conf= iguration screen by opening the image you built.

We could= change the "Build image" button into a go forward button, and if= the user makes any changes to the packages display again the 'Build image' button, but I am not sure if it would be worth the development effort.&nbs= p;

Providin= g access to all previous screens could be done by some kind of breadcrumb (= a representation of each step in the process you can click on to access the step), but breadcrumbs are problematic when the number of st= eps in a process can change, like in Hob. Remember than you can decide to g= o through the packages step, or skip it and build the image directly.&= nbsp;

= ;

[Shane]: Personally, I don̵= 7;t like to change “Build image” to a “Go forward” = button, because it would be possible that users want to rebuild the image w= ithout any change.

With many buttons on many windows, we have a= lot of combinations, then we have a lot of states for the UI.

True: th= ere are a few things you can do in the Image details screen. You can save y= our image as a template, you can edit the image, you can view the image files, you can deploy or run the image when applicable, an= d you can build a new image. You can also open a Template or a different im= age. All those are reasonable next steps once you have reached the end of b= uilding process, and all of them should be present in the interface.

And we are thinking “Settings”, “Deploy image= ”, “Run image”, “Load Template” and “Sa= ve Template” are important for us, and whether we can use menus or buttons on a toolbar. We prefer th= e latter, and prefer we have a main window and others are all dialogs inher= ited from the main window. What do you think on this?

I can se= e your point here. I did consider that structure after I saw it working. It= 's quite nice. However, I can see a couple of problems with it:

It brings the concept of progre= ssive disclosure (new options displaying as a result of user selections) th= at we use in the Image configuration screen to a breaking point. There are too many things happening in that main window. When you s= tart building, the progress bar has to display at the bottom of the screen,= which looks awkward, and there is not enough space to provide clear next s= teps after the packages and image have been built.
Having 'Deploy image' and 'Run = image' buttons in the toolbar will cause problems. They fire actions that r= equire a parameter (an image to deploy or run). They could get this parameter by taking the last image that has been built, and deplo= y or run that image. But what if no image has been built yet? What if the l= ast image was built a few days ago and it's not at all the image you want t= o deploy or run? The alternative would be asking the user what's the image she wants to deploy or run. You = would open a file chooser dialog for that. But imagine the following situat= ion: I've just finished building a qemu image. The "congratulations&qu= ot; message and the path to my image are displayed at the bottom of the main screen. I want to run my image, so I click on th= e 'run image' button in the toolbar, expecting it of course to run the qemu= image I've just built. Instead, it pops up a file chooser dialog and I hav= e to select the image I just built to run it! Such a system would feel a bit dumb: why is it asking me which = image do I want to run? Isn't it obvious I want to run the qemu image I've = just built? To avoid this type of 'dumb' reactions by the UI, actions shoul= d be displayed where and when applicable. Actions in toolbars and menus are always present, which means they are alw= ays applicable, they make sense at all times, independently of the system s= tate: I call them global actions. Opening a template, opening an image or a= ccessing settings are kind of global actions. Running or deploying an image are 'contextual' actions, they only= make sense when the system is in a certain state: for example, right after= building a qemu image. If you position global actions in toolbars or menus= , you will have to make extensive use of inactive states, which means displaying things that don’t mak= e sense in such a way that you cannot use them (which is just noise), or ma= ke them behave in different ways depending on the system state (which is co= nfusing).

9) a small question as Dave has, what is the= diff between “deploy image”and “write to storage”?= We think they are the same.

Dave is = completely right: 'Deploy' and 'Write to storage' are exactly the same thin= g. I meant to use 'Write to storage' everywhere: sorry about that. My bad :(

[Shane]: Three more we want to = consider:

1. we want to add proxy setting= into “Settings” to support proxy

2. When users fail to build ima= ges, there is no option or button to clean all (like sstate) but bitbake co= mmand has (bitbake –c cleanall). We hope to add it into the GUI.

3. can the button “Settin= gs” be there only on the Image configuration screen? It doesn’t= make any sense to set the parameters on the Image details screen, agree?

Ditto for &#= 8220;Load Template” on the Image details screen. We also can initiate= a new build by “Build new image” and “Load Template̶= 1;, thoughts?

Sorry, many feedbacks;-) And we are also thi= nking to simplify the rest of the design and finalize asap so we can finish the implementation before the end of M3. (the end of Feb).=

I totall= y understand you might not have time to implement the design I've sent. If = this is the problem, please do let me know, and let's talk about what's feasible. Maybe we could keep the current structure (all steps in t= he main screen), but look for some alternative options to position the 'Dep= loy image', 'Run image' and 'Save as template' actions … not in the t= oolbar or menus, please! ;)

= ;

[Shane]: We will try our best.<= o:p>

Another FYI, we get your feedbacks in the two pdf files you sen= t previously and are revising the UI.

Thanks.

--_000_3AB6CE7F274E534CAFD089D127A8A1FC0FCEB255SHSMSX102ccrcor_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id B9253E00307 for ; Thu, 2 Feb 2012 14:29:38 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 02 Feb 2012 14:29:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="105630170" Received: from unknown (HELO [10.7.199.78]) ([10.7.199.78]) by orsmga002.jf.intel.com with ESMTP; 02 Feb 2012 14:29:38 -0800 Message-ID: <4F2B0E51.8030902@intel.com> Date: Thu, 02 Feb 2012 14:29:37 -0800 From: Joshua Lock User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: "Wang, Shane" References: <3AB6CE7F274E534CAFD089D127A8A1FC0FCE9F5F@SHSMSX102.ccr.corp.intel.com> <3AB6CE7F274E534CAFD089D127A8A1FC0FCEB255@SHSMSX102.ccr.corp.intel.com> In-Reply-To: <3AB6CE7F274E534CAFD089D127A8A1FC0FCEB255@SHSMSX102.ccr.corp.intel.com> Cc: "Purdie, Richard" , "yocto@yoctoproject.org" , "Eggleton, Paul" Subject: Re: RFC: Hob 1.2 design X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2012 22:29:38 -0000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Some thoughts inline, I've snipped out text unrelated to my comments. On 02/02/12 04:48, Wang, Shane wrote: > In your previous video, recipe view has sort of �summary� which lists > all recipes selected on the right side. Can we remove the tab �Included� > and make a �summary� for the package view? And with the tab �Included�, > we need to scroll down to find a package or locate it in the search box, > and then do �Remove� for example, it is not better than the �summary� > because the �summary� can show all or more. > > I agree that the Packages screen should look similar to the Recipes > dialogue and the Packages dialogue. But after seeing the 'summary' > working it seems to me that it is not the best solution. The goals of > the summary were: > > 1. Allow users to easily see what's selected to be included in their image > 2. Allow users to easily understand what's brought by what > > I am not sure the existing summary does a good job at any of the two. > Space restrictions make reading what's included quite difficult > (particularly when the names of packages or recipes wrap), and the > layout does not facilitate skimming content, which is what you'll do > with the summary (you won't read it all from top to bottom: you'll skim > the recipes/packages to find something you are looking for). The > relationship between what brings what, represented by the highlight, is > lost once you perform a new selection. The summary also creates a lot of > clutter in the interface: the screen is so busy, it's hard to know what > to look at. > > [Shane]: I agree with you on �you won't read it all from top to bottom�. > But I found the summary had another advantage which �Included� in the > current Packages screen doesn�t have. That is: when I select one more > package, what is brought by it will be highlighted, so I can see the > difference between before and after I select. > > The existing Packages screen presents less information at any given > time: it feels cleaner and easier to read. It's true that it requires > users to select the Included tab in order to see what's to be included > in their image, but it provides a much more focused interface. The > 'brought by' column avoids losing the relationship between what brings > what, and the sorting and searching mechanisms should minimise the need > for scrolling. > > After multiple iterations (it took a very long time to design that > screen), I believe the Included tab is a better solution than the > Summary. If you are convinced that the Summary is better, we'll go for > it, but I felt I had to explain my concerns with it. One idea is that we could offer filters on the list, so that the user can click the "included" filter and only the packages selected for inclusion will be shown - this suggestion is inspired by Thunderbirds mail view which can be filtered on unread, starred, etc. > 3) After clicking �My images� to open an image, how does UI determine to > show �Run Image� or �Write to Storage�, or �Deploy� or �View Image files�? > > First of all, you are right: 'Deploy' and 'Write to storage' are exactly > the same thing. I meant to use 'Write to storage' everywhere: sorry > about that. My bad :( > > - If the building output included a live image, the Image details screen > shows the 'Write to storage' button > > - If the image is a qemu image, the Image details screen shows the 'Run > image' button. Clicking the button starts up the virtual machine > > [Shane]: Makes sense. A technical question for expert in the mail list, > how can we distinguish whether an image is a QEMU image or an image for > real hardware, regarding the fact users can change the image name as > they want? I don't know of a way to do this, though someone else may suggest one. A way we could provide such functionality within Hob might be to set a filesystem extended attribute on the files of which MACHINE they were build for. Then Hob can read this attribute back and if it's not set assume it's not a qemu image. Thoughts? > 5) For �save template� and �load template�, the only chance for users to > do �save template� is when the build is done, yes? > > Well, I don't know. That's the way it seems to work in the latest > version of Hob, but it doesn't mean it has to stay that way. Hmm, really? That's more by oversight than by design ;-) > A technical question comes to me, it is also for experts. Is there a way > to modify bitbake to write some more information into the target image, > and for Hob to unpack and fetch the information later? Once again, I don't know of a current way but could suggest Extended Attributes as one option. Finally, whilst discussing this in the office Darren raised a concern about restricting the 'launch in emulator' option to only images built for the qemu machine types citing his use of qemu with FRI2 images. He suggested: "For images with an ext[234] or other FS image suitable for qemu, present the "launch in qemu" button. For images that have the hddimg extension, present the Burn to Disk option." Cheers, Joshua -- Joshua Lock Yocto Project "Johannes factotum" Intel Open Source Technology Centre From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id D9928E00307 for ; Thu, 2 Feb 2012 16:26:41 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 02 Feb 2012 16:26:41 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208,217";a="105682297" Received: from pgsmsx601.gar.corp.intel.com ([10.221.43.69]) by orsmga002.jf.intel.com with ESMTP; 02 Feb 2012 16:26:40 -0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by pgsmsx601.gar.corp.intel.com (10.221.43.69) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 3 Feb 2012 08:25:57 +0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.36]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.142]) with mapi id 14.01.0355.002; Fri, 3 Feb 2012 08:25:55 +0800 From: "Wang, Shane" To: "Wang, Shane" , "Barros Pena, Belen" , "Xu, Dongxiao" , "Lu, Lianhao" Thread-Topic: RFC: Hob 1.2 design Thread-Index: AQHM1ghN2ta+vDnY0kiXcbK0irRQ85YS108ggAGuLCCAAHlrgIAGmYWAgAb8MNCAAqn0gIACotQAgABGdBCAAFS8AIAAmk2AgABm6zCAAOoDcA== Date: Fri, 3 Feb 2012 00:25:54 +0000 Message-ID: <3AB6CE7F274E534CAFD089D127A8A1FC0FCEBC20@SHSMSX102.ccr.corp.intel.com> References: <3AB6CE7F274E534CAFD089D127A8A1FC0FCE9F5F@SHSMSX102.ccr.corp.intel.com> <3AB6CE7F274E534CAFD089D127A8A1FC0FCEB255@SHSMSX102.ccr.corp.intel.com> In-Reply-To: <3AB6CE7F274E534CAFD089D127A8A1FC0FCEB255@SHSMSX102.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "Purdie, Richard" , "Lock, Joshua" , "yocto@yoctoproject.org" , "Eggleton, Paul" Subject: Re: RFC: Hob 1.2 design X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 00:26:42 -0000 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_3AB6CE7F274E534CAFD089D127A8A1FC0FCEBC20SHSMSX102ccrcor_" --_000_3AB6CE7F274E534CAFD089D127A8A1FC0FCEBC20SHSMSX102ccrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I get one more: In the Image details screen, after opening an image file by clicking "My im= ages", 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 --_000_3AB6CE7F274E534CAFD089D127A8A1FC0FCEBC20SHSMSX102ccrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I get one = more:

= ;

In the Ima= ge details screen, after opening an image file by clicking “My images= ”, we don’t allow to “Edit Package”, I think.<= /o:p>

Because wi= th an image only, we can’t generate the packages from it, you canR= 17;t assume there is a build directory (tmp/), is my understanding correct?=

= ;

Shane=

--_000_3AB6CE7F274E534CAFD089D127A8A1FC0FCEBC20SHSMSX102ccrcor_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 191E3E00307 for ; Thu, 2 Feb 2012 16:36:09 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 02 Feb 2012 16:36:08 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,217";a="119986961" Received: from pgsmsx602.gar.corp.intel.com ([10.221.43.81]) by fmsmga002.fm.intel.com with ESMTP; 02 Feb 2012 16:35:50 -0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by pgsmsx602.gar.corp.intel.com (10.221.43.81) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 3 Feb 2012 08:35:20 +0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.36]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id 14.01.0355.002; Fri, 3 Feb 2012 08:35:18 +0800 From: "Xu, Dongxiao" To: "Wang, Shane" , "Barros Pena, Belen" , "Lu, Lianhao" Thread-Topic: RFC: Hob 1.2 design Thread-Index: AQHM1ghN2ta+vDnY0kiXcbK0irRQ85YS108ggAGuLCCAAHlrgIAGmYWAgAb8MNCAAqn0gIACotQAgABGdBCAAFS8AIAAmk2AgABm6zCAAEu8wA== Date: Fri, 3 Feb 2012 00:35:17 +0000 Message-ID: <40776A41FC278F40B59438AD47D147A90FCD04A0@SHSMSX102.ccr.corp.intel.com> References: <3AB6CE7F274E534CAFD089D127A8A1FC0FCE9F5F@SHSMSX102.ccr.corp.intel.com> <3AB6CE7F274E534CAFD089D127A8A1FC0FCEB255@SHSMSX102.ccr.corp.intel.com> In-Reply-To: <3AB6CE7F274E534CAFD089D127A8A1FC0FCEB255@SHSMSX102.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "Purdie, Richard" , "Lock, Joshua" , "yocto@yoctoproject.org" , "Eggleton, Paul" Subject: Re: RFC: Hob 1.2 design X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 00:36:09 -0000 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_40776A41FC278F40B59438AD47D147A90FCD04A0SHSMSX102ccrcor_" --_000_40776A41FC278F40B59438AD47D147A90FCD04A0SHSMSX102ccrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My feedbacks in "blue". Thanks, Dongxiao From: Wang, Shane Sent: Thursday, February 02, 2012 8:48 PM To: Wang, Shane; Barros Pena, Belen; Xu, Dongxiao; Lu, Lianhao Cc: Eggleton, Paul; Purdie, Richard; Zhang, Jessica; Lock, Joshua; Liu, Son= g; Stewart, David C; yocto@yoctoproject.org Subject: Re: RFC: Hob 1.2 design Please see my feedbacks embedded in red. Thanks. -- Shane From: "Wang, Shane" > Date: Wed, 1 Feb 2012 14:49:38 +0000 To: "Belen Barros Pena (Intel)" >, "Xu, Dongxiao" >, "Lu, Lianhao" > Subject: RE: Hob 1.2 next steps Thank you for making the video. We three have some comments and questions on the video. 1) the style of the package view is not consistent with the one of recipe v= iew. True. I was planning to redesign the recipe view and the package view to b= ring them in line with the Packages screen. I think I need to clarify the d= ifference between windows and dialogues in the interface. In the design sho= wn in the video, Hob has one window, which changes depending on the buildin= g stage to show one of the following screens: Image configuration, Building= packages, Packages, Building image and Image details. The 'recipe view' an= d the 'package view' are dialogues that you launch via the 'view recipes' a= nd 'view packages' buttons. Therefore, the Packages screen that displays af= ter the packages are built, and the package dialogue you launch using the '= view packages' button, are 2 different things. [Shane]: OK, I understand they are 2 difference screens. But actually both = can reuse the same screen, because I didn't see any functional difference b= etween the Packages screen and the Packages dialog. [Dongxiao]: In case you are trying to re-design the recipe view and package= view, some thoughts here - package view and package screen actually are showing the same contents, c= an we merge them together? I mean if user clicks the package view, they are= moved to the "Package" stage. - Will recipe view and package view also be design to be "window" instead o= f screen? In your previous video, recipe view has sort of "summary" which lists all r= ecipes selected on the right side. Can we remove the tab "Included" and mak= e a "summary" for the package view? And with the tab "Included", we need to= scroll down to find a package or locate it in the search box, and then do = "Remove" for example, it is not better than the "summary" because the "summ= ary" can show all or more. I agree that the Packages screen should look similar to the Recipes dialogu= e and the Packages dialogue. But after seeing the 'summary' working it seem= s to me that it is not the best solution. The goals of the summary were: 1. Allow users to easily see what's selected to be included in their ima= ge 2. Allow users to easily understand what's brought by what I am not sure the existing summary does a good job at any of the two. Space= restrictions make reading what's included quite difficult (particularly wh= en the names of packages or recipes wrap), and the layout does not facilita= te skimming content, which is what you'll do with the summary (you won't re= ad it all from top to bottom: you'll skim the recipes/packages to find some= thing you are looking for). The relationship between what brings what, repr= esented by the highlight, is lost once you perform a new selection. The sum= mary also creates a lot of clutter in the interface: the screen is so busy,= it's hard to know what to look at. [Shane]: I agree with you on "you won't read it all from top to bottom". Bu= t I found the summary had another advantage which "Included" in the current= Packages screen doesn't have. That is: when I select one more package, wha= t is brought by it will be highlighted, so I can see the difference between= before and after I select. The existing Packages screen presents less information at any given time: i= t feels cleaner and easier to read. It's true that it requires users to sel= ect the Included tab in order to see what's to be included in their image, = but it provides a much more focused interface. The 'brought by' column avoi= ds losing the relationship between what brings what, and the sorting and se= arching mechanisms should minimise the need for scrolling. After multiple iterations (it took a very long time to design that screen),= I believe the Included tab is a better solution than the Summary. If you a= re convinced that the Summary is better, we'll go for it, but I felt I had = to explain my concerns with it. [Shane]: Both have advantages and disadvantages. I don't think it is hard t= o implement "Included". On the contrary, the Summary is;-) I also like to h= ear some feedbacks from the community and the others. BTW: do you mean in the Recipes dialog, we also replace the Summary with th= e tab "Included"? 2) ditto, I see there is a button "Build Image" in the package view. I know= what the purpose is. But for the recipe view, there is no button. We also = can "build image" or "build package" in the recipe view without going back = to the main window at 1:39. Do you mind that we simplify by removing "Build= Image" in the package view? I think there is some confusion about the Packages screen (which is a windo= w), and what you call the 'package view' and 'recipe view', which are dialo= gues. This is really my fault: I should have explained this better. I've designed the Hob interface as a multi-step process with 3 steps, each = represented by a screen displayed in the main Hob window: Step 1 - Image configuration screen: users input the build parameters, such= as machine, base image and recipes Step 2 - Package screen: this is not a mandatory step. You can skip it by s= electing 'Build image' in Step 1. Users review and might edit the list of p= ackages to be included in their image, and then proceed to build the image.= The 'Build image' button is required to proceed to Step 3 Step 3 - Image details screen: the image has been built, and users can sele= ct from a range of possible actions [Shane]: I see. They are 2 different things. Since the above screens are steps in a process, they require an action (i.e= . a button) to move to the next step of the process. The recipes and packages dialogues are not steps in the building process: t= hey are contained pieces of functionality that can be displayed on demand. = The recipes dialogue allows users to see and edit the recipes included in t= he base image. I assume the packages dialogue allows users to include alrea= dy built packages in the base image (if this is not correct please let me k= now). [Shane]: Your assumption is right. The actions in any dialogue should be 'Save' and 'Cancel'. Those actions we= re not included in the original design because I didn't think of them as di= alogues: more as inspectors like the ones in Gimp. You implemented them as = dialogues, which I think works really well (probably better than as inspect= ors I must say): we just need to add those 'Save' and 'Cancel' buttons to t= hem. I hope this explains why we have a 'Build image' button in the Packages scr= een, but not in the recipes and packages dialogues. [Shane]: Understand. 3) After clicking "My images" to open an image, how does UI determine to sh= ow "Run Image" or "Write to Storage", or "Deploy" or "View Image files"? First of all, you are right: 'Deploy' and 'Write to storage' are exactly th= e same thing. I meant to use 'Write to storage' everywhere: sorry about tha= t. My bad :( - If the building output included a live image, the Image details screen sh= ows the 'Write to storage' button - If the image is a qemu image, the Image details screen shows the 'Run ima= ge' button. Clicking the button starts up the virtual machine [Shane]: Makes sense. A technical question for expert in the mail list, how= can we distinguish whether an image is a QEMU image or an image for real h= ardware, regarding the fact users can change the image name as they want? - Otherwise the Image details screen shows the 'View image files' button [Shane]: Can you give an example about "Otherwise"? I hope this makes sense. Otherwise let me know. [Dongxiao]: Does it make sense if a user opens a .tar.gz file in our GUI an= d then it jumps to the image information page? I think as a Linux user, I w= ill not try to open any .tar.gz file by file chooser because in my straight= understanding, those .tar.gz files may be large and opening them will caus= e a lot of time or may hang. 4) At 6:36, how can the user go back to the main window at 1:39? Should the= user wait until the build is finished or stop it by clicking "Stop build"? Exactly: the only option at that point is to stop the build. I haven't desi= gned what happens when you stop the build yet, but I'd say something simila= r to what happens now: a prompt asks users to confirm that they want to sto= p the build, and if yes Hob reverts back to the screen from which the user = started the building image process, which can be the Image configuration sc= reen or the Packages screen. [Shane]: Understand. If any error happens when building, it will stay there= because I assume users want to see the log. Then how can users get back to= the Image configuration screen or the Package screen, after closing it? 5) For "save template" and "load template", the only chance for users to do= "save template" is when the build is done, yes? Well, I don't know. That's the way it seems to work in the latest version o= f Hob, but it doesn't mean it has to stay that way. However, we think users can save any settings for build environments, and a= ny selection of packages or recipes in an image even though the build doesn= 't start. Then next time he/she can resume the job by starting with the stu= ffs saved. I totally agree with you that users should be able to save a template befor= e building the image. Again, we are considering whether it is good to put "load template" and "sa= ve template" together, because they are similar actions. I don't think I would do it that way. 'Load template' is a way to initiate = the building process, and therefore something you might want to do at any t= ime. As such, it makes sense to make it an option in the toolbar, like 'ope= ning an image', where is always available. 'Save template' is something that sequentially comes after configuring the = image parameters. It's like a function that takes as parameters a machine a= nd a base image (with its recipes or packages). Therefore the action of sav= ing a template only makes sense when a machine and base image have been sel= ected. If you represent it as a button in the toolbar, you will have to sho= w it in an inactive state until a machine and base image have been selected= . Otherwise, what are you saving as a template? As such, it makes sense to = display it after those parameters have been set, i.e., after the 'View reci= pes' and 'View packages' buttons. If you agree with the above, I can review the Image configuration screen an= d add a 'Save as template' action to it. [Shane]: OK, I agree to enable the button "Save as template" after all para= meters in the Image configuration screen have been set. Keep this open, ple= ase. 6) At 7:07, "view files" is the same as "My images"? I don't think so. 'My images' would open a File Chooser Dialog http://developer.gnome.org/gtk3/stable/GtkFileChooserDialog.html Selecting an image file from the file chooser dialog would open the Hob "Im= age details' screen for the selected image file. "View files" would open a regular file manager window in the tmp/deploy/ima= ges directory. Selecting the image file from this file manager window would= simply open the image in the default application assigned to the file exte= nsion (it would not open the image details screen in Hob). "View files" is = just a quick way to navigate to the tmp/deploy/images directory. [Shane]: OK, I see. 7) We are thinking "My images" is similar as "Load template", because the i= mage contains the info of settings etc. so does the template. The only diff= is after opening an image, we can deploy it or run it. But for template, i= t is sort of "virtual" stuff, we have to build according to the definitions= of the template. So, to some extent, "My images" =3D "Template" + able to = deploy and run, what do you think? I agree, but I also think that the ability to deploy and run that comes wit= h images and is missing from templates is a significant difference. It mean= s that the logical next steps after opening a template and opening an image= are very different too. After opening a template the logical next steps are: edit the parameters if= you wish, then build. That's why loading a template brings you to the Imag= e configuration screen, where you can edit parameters and build. After opening an image the logical next steps are deploy / run. That's why = opening an image brings you to the Image details screen, where you can depl= oy / run. [Shane]: But on the Image details screen, you can click "Edit Configuration= " to go to the Image configuration screen. Then the rest is totally the sam= e as the above. A technical question comes to me, it is also for experts. Is there a way to= modify bitbake to write some more information into the target image, and f= or Hob to unpack and fetch the information later? For this part, we also consider the client/server mode with XMLRPC: We have= the capability to run bitbake server on the server side, but UI on the cli= ent side. So the image in "My images" always is generated on the server sid= e, and the template in "Load template" is a config file on the client side. It sort of makes sense to me that templates are local files, while images a= re kept on a server where they can be shared, but I definitely don't know e= nough to have an opinion. You guys are the experts on this! :) I guess that if no client / server mode is set up and I am running everythi= ng locally, then images will also be kept locally. Is that the case? [Shane]: Yes, that is. Temporarily we can skip the case running on client a= nd server. We assume all are on the client. 8) We already saw some buttons "Settings", "Deploy image", "Run image", "Lo= ad Template" and "Save Template", "Build New image", "Edit Configuration" o= r "Edit packages", "View image files" on different windows. So probably tha= t makes switching between windows a bit complex. For instance, At 8:24, cli= cking "Edit packages" will go back to the package view. But what if users j= ust make a mistake on the UI and want to go back to the window at 8:24? Well, they can't :) The Packages screen is an intermediate step that allows= you to view and edit the packages to be included in your image: nothing el= se. If you land there by mistake, you can still get out via the 'Back to im= age configuration' option. From there, you can go back to the Image configu= ration screen by opening the image you built. We could change the "Build image" button into a go forward button, and if t= he user makes any changes to the packages display again the 'Build image' b= utton, but I am not sure if it would be worth the development effort. Providing access to all previous screens could be done by some kind of brea= dcrumb (a representation of each step in the process you can click on to ac= cess the step), but breadcrumbs are problematic when the number of steps in= a process can change, like in Hob. Remember than you can decide to go thro= ugh the packages step, or skip it and build the image directly. [Shane]: Personally, I don't like to change "Build image" to a "Go forward"= button, because it would be possible that users want to rebuild the image = without any change. With many buttons on many windows, we have a lot of combinations, then we h= ave a lot of states for the UI. True: there are a few things you can do in the Image details screen. You ca= n save your image as a template, you can edit the image, you can view the i= mage files, you can deploy or run the image when applicable, and you can b= uild a new image. You can also open a Template or a different image. All th= ose are reasonable next steps once you have reached the end of building pro= cess, and all of them should be present in the interface. And we are thinking "Settings", "Deploy image", "Run image", "Load Template= " and "Save Template" are important for us, and whether we can use menus or= buttons on a toolbar. We prefer the latter, and prefer we have a main wind= ow and others are all dialogs inherited from the main window. What do you t= hink on this? I can see your point here. I did consider that structure after I saw it wor= king. It's quite nice. However, I can see a couple of problems with it: 1. It brings the concept of progressive disclosure (new options displayi= ng as a result of user selections) that we use in the Image configuration s= creen to a breaking point. There are too many things happening in that main= window. When you start building, the progress bar has to display at the bo= ttom of the screen, which looks awkward, and there is not enough space to p= rovide clear next steps after the packages and image have been built. 2. Having 'Deploy image' and 'Run image' buttons in the toolbar will cau= se problems. They fire actions that require a parameter (an image to deploy= or run). They could get this parameter by taking the last image that has b= een built, and deploy or run that image. But what if no image has been buil= t yet? What if the last image was built a few days ago and it's not at all = the image you want to deploy or run? The alternative would be asking the us= er what's the image she wants to deploy or run. You would open a file choos= er dialog for that. But imagine the following situation: I've just finished= building a qemu image. The "congratulations" message and the path to my im= age are displayed at the bottom of the main screen. I want to run my image,= so I click on the 'run image' button in the toolbar, expecting it of cours= e to run the qemu image I've just built. Instead, it pops up a file chooser= dialog and I have to select the image I just built to run it! Such a syste= m would feel a bit dumb: why is it asking me which image do I want to run? = Isn't it obvious I want to run the qemu image I've just built? To avoid thi= s type of 'dumb' reactions by the UI, actions should be displayed where and= when applicable. Actions in toolbars and menus are always present, which m= eans they are always applicable, they make sense at all times, independentl= y of the system state: I call them global actions. Opening a template, open= ing an image or accessing settings are kind of global actions. Running or d= eploying an image are 'contextual' actions, they only make sense when the s= ystem is in a certain state: for example, right after building a qemu image= . If you position global actions in toolbars or menus, you will have to mak= e extensive use of inactive states, which means displaying things that don'= t make sense in such a way that you cannot use them (which is just noise), = or make them behave in different ways depending on the system state (which = is confusing). [Dongxiao]: Hob can have the functionality that, even if user didn't build = an image at this time, it could still be used as a deploy tool to burn prev= ious built images to usb disks, or run those pre-built images by QEMU. What= about designing to buttons, one is "Burn Lastest Built Image" and "Burn Pr= evious Built Image"? (Ignore my poor button name) 9) a small question as Dave has, what is the diff between "deploy image"and= "write to storage"? We think they are the same. Dave is completely right: 'Deploy' and 'Write to storage' are exactly the s= ame thing. I meant to use 'Write to storage' everywhere: sorry about that. = My bad :( [Shane]: Three more we want to consider: 1. we want to add proxy setting into "Settings" to support proxy 2. When users fail to build images, there is no option or button to clean a= ll (like sstate) but bitbake command has (bitbake -c cleanall). We hope to = add it into the GUI. 3. can the button "Settings" be there only on the Image configuration scree= n? It doesn't make any sense to set the parameters on the Image details scr= een, agree? Ditto for "Load Template" on the Image details screen. We also can init= iate a new build by "Build new image" and "Load Template", thoughts? Sorry, many feedbacks;-) And we are also thinking to simplify the rest of t= he design and finalize asap so we can finish the implementation before the = end of M3. (the end of Feb). I totally understand you might not have time to implement the design I've s= ent. If this is the problem, please do let me know, and let's talk about wh= at's feasible. Maybe we could keep the current structure (all steps in the = main screen), but look for some alternative options to position the 'Deploy= image', 'Run image' and 'Save as template' actions ... not in the toolbar = or menus, please! ;) [Shane]: We will try our best. Another FYI, we get your feedbacks in the two pdf files you sent previously= and are revising the UI. Thanks. --_000_40776A41FC278F40B59438AD47D147A90FCD04A0SHSMSX102ccrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My feedbacks in “blue̶= 1;.

Thanks,

Dongxiao

From: Wang, Shane
Sent: Thursday, February 02, 2012 8:48 PM
To: Wang, Shane; Barros Pena, Belen; Xu, Dongxiao; Lu, Lianhao
Cc: Eggleton, Paul; Purdie, Richard; Zhang, Jessica; Lock, Joshua; L= iu, Song; Stewart, David C; yocto@yoctoproject.org
Subject: Re: RFC: Hob 1.2 design

Please see my feedbacks emb= edded in red.

Thanks.

Shane

Thank you for making the video.

We three have some comments and questions on= the video.

1) the style of the package view is not cons= istent with the one of recipe view.

= ;

[Dongxiao]: In case you are tryi= ng to re-design the recipe view and package view, some thoughts here

- pa= ckage view and package screen actually are showing the same contents, can w= e merge them together? I mean if user clicks the package view, they are moved to the “Package” stage.=

- Wi= ll recipe view and package view also be design to be “window” i= nstead of screen?

Allow users to easily see what'= s selected to be included in their image
Allow users to easily understan= d what's brought by what

= ;

BTW: do you mean in the Recipes= dialog, we also replace the Summary with the tab “Included”?

I've designed the Hob interface as a multi-step process with 3 st= eps, each represented by a screen displayed in the main Hob window:

Step 1 &= #8211; Image configuration screen: users input the build parameters, such a= s machine, base image and recipes

Step 3 &= #8211; Image details screen: the image has been built, and users can select= from a range of possible actions

[Shane]: I see. They are 2 diff= erent things.

Since th= e above screens are steps in a process, they require an action (i.e. a butt= on) to move to the next step of the process.<= /o:p>

[Shane]: Your assumption is rig= ht.

I hope t= his explains why we have a 'Build image' button in the Packages screen, but= not in the recipes and packages dialogues.

[Shane]: Understand.=

3) After clicking “My images” to open an image, how does = UI determine to show “Run Image” or “Write to StorageR= 21;, or “Deploy” or “View Image files”?

First of= all, you are right: 'Deploy' and 'Write to storage' are exactly the same t= hing. I meant to use 'Write to storage' everywhere: sorry about that. My bad :(

- If the= building output included a live image, the Image details screen shows the = 'Write to storage' button

- If the= image is a qemu image, the Image details screen shows the 'Run image' butt= on. Clicking the button starts up the virtual machine

- Otherw= ise the Image details screen shows the 'View image files' button

= ;

[Shane]: Can you give an exampl= e about “Otherwise”?

= ;

I hope t= his makes sense. Otherwise let me know.

[Dongxiao]: Does it make sense i= f a user opens a .tar.gz file in our GUI and then it jumps to the image inf= ormation page? I think as a Linux user, I will not try to open any .tar.gz file by file chooser because in my straight unders= tanding, those .tar.gz files may be large and opening them will cause a lot= of time or may hang.

4) At 6:36, how can the user go back to the = main window at 1:39? Should the user wait until the build is finished or stop it by clicking “Stop build”?

5) For “save template” and ̶= 0;load template”, the only chance for users to do “save templat= e” is when the build is done, yes?

Well, I = don't know. That's the way it seems to work in the latest version of Hob, b= ut it doesn't mean it has to stay that way.

I totall= y agree with you that users should be able to save a template before buildi= ng the image.

Again, we are considering whether it is good= to put “load template” and “save template” togethe= r, because they are similar actions.

If you a= gree with the above, I can review the Image configuration screen and add a = 'Save as template' action to it.=

[Shane]: OK, I agree to enable = the button “Save as template” after all parameters in the Image= configuration screen have been set. Keep this open, please.

6) At 7:07, “view files” is the same as “My i= mages”?

I don't = think so. 'My images' would open a File Chooser Dialog

http://developer.gnome.org/gtk3/stable/GtkFileChooserDialog.h= tml

Selectin= g an image file from the file chooser dialog would open the Hob "Image= details' screen for the selected image file.=

[Shane]: OK, I see.<= /span>

After op= ening an image the logical next steps are deploy / run. That's why opening = an image brings you to the Image details screen, where you can deploy / run.

[Shane]: But on the Image detai= ls screen, you can click “Edit Configuration” to go to the Imag= e configuration screen. Then the rest is totally the same as the above.

I guess = that if no client / server mode is set up and I am running everything local= ly, then images will also be kept locally. Is that the case?

[Shane]: Yes, that is. Temporar= ily we can skip the case running on client and server. We assume all are on= the client.

[Shane]: Personally, I don̵= 7;t like to change “Build image” to a “Go forward” = button, because it would be possible that users want to rebuild the image w= ithout any change.

With many buttons on many windows, we have a= lot of combinations, then we have a lot of states for the UI.

I can se= e your point here. I did consider that structure after I saw it working. It= 's quite nice. However, I can see a couple of problems with it:

It brings the concept of progre= ssive disclosure (new options displaying as a result of user selections) th= at we use in the Image configuration screen to a breaking point. There are too many things happening in that main window. When you s= tart building, the progress bar has to display at the bottom of the screen,= which looks awkward, and there is not enough space to provide clear next s= teps after the packages and image have been built.
Having 'Deploy image' and 'Run = image' buttons in the toolbar will cause problems. They fire actions that r= equire a parameter (an image to deploy or run). They could get this parameter by taking the last image that has been built, and deplo= y or run that image. But what if no image has been built yet? What if the l= ast image was built a few days ago and it's not at all the image you want t= o deploy or run? The alternative would be asking the user what's the image she wants to deploy or run. You = would open a file chooser dialog for that. But imagine the following situat= ion: I've just finished building a qemu image. The "congratulations&qu= ot; message and the path to my image are displayed at the bottom of the main screen. I want to run my image, so I click on th= e 'run image' button in the toolbar, expecting it of course to run the qemu= image I've just built. Instead, it pops up a file chooser dialog and I hav= e to select the image I just built to run it! Such a system would feel a bit dumb: why is it asking me which = image do I want to run? Isn't it obvious I want to run the qemu image I've = just built? To avoid this type of 'dumb' reactions by the UI, actions shoul= d be displayed where and when applicable. Actions in toolbars and menus are always present, which means they are alw= ays applicable, they make sense at all times, independently of the system s= tate: I call them global actions. Opening a template, opening an image or a= ccessing settings are kind of global actions. Running or deploying an image are 'contextual' actions, they only= make sense when the system is in a certain state: for example, right after= building a qemu image. If you position global actions in toolbars or menus= , you will have to make extensive use of inactive states, which means displaying things that don’t mak= e sense in such a way that you cannot use them (which is just noise), or ma= ke them behave in different ways depending on the system state (which is co= nfusing).

[Dongxiao]: Hob can have the functionality tha= t, even if user didn’t build an image at this time, it could still be used as a deploy tool to burn previous built images to u= sb disks, or run those pre-built images by QEMU. What about designing to bu= ttons, one is “Burn Lastest Built Image” and “Burn Previo= us Built Image”? (Ignore my poor button name)

9) a small question as Dave has, what is the= diff between “deploy image”and “write to storage”?= We think they are the same.

Dave is = completely right: 'Deploy' and 'Write to storage' are exactly the same thin= g. I meant to use 'Write to storage' everywhere: sorry about that. My bad :(

[Shane]: Three more we want to = consider:

1. we want to add proxy setting= into “Settings” to support proxy

2. When users fail to build ima= ges, there is no option or button to clean all (like sstate) but bitbake co= mmand has (bitbake –c cleanall). We hope to add it into the GUI.

3. can the button “Settin= gs” be there only on the Image configuration screen? It doesn’t= make any sense to set the parameters on the Image details screen, agree?

Ditto for &#= 8220;Load Template” on the Image details screen. We also can initiate= a new build by “Build new image” and “Load Template̶= 1;, thoughts?

Sorry, many feedbacks;-) And we are also thi= nking to simplify the rest of the design and finalize asap so we can finish the implementation before the end of M3. (the end of Feb).=

[Shane]: We will try our best.<= o:p>

Another FYI, we get your feedbacks in the two pdf files you sen= t previously and are revising the UI.

Thanks.

--_000_40776A41FC278F40B59438AD47D147A90FCD04A0SHSMSX102ccrcor_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 09A07E00307 for ; Thu, 2 Feb 2012 16:57:10 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 02 Feb 2012 16:57:10 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,217";a="119994460" Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87]) by fmsmga002.fm.intel.com with ESMTP; 02 Feb 2012 16:56:40 -0800 Received: from pgsmsx509.gar.corp.intel.com (172.30.13.17) by pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 3 Feb 2012 08:56:38 +0800 Received: from shsmsx101.ccr.corp.intel.com (10.239.4.153) by PGSMSX509.gar.corp.intel.com (172.30.13.17) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 3 Feb 2012 08:56:38 +0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.36]) by SHSMSX101.ccr.corp.intel.com ([169.254.1.142]) with mapi id 14.01.0355.002; Fri, 3 Feb 2012 08:56:36 +0800 From: "Xu, Dongxiao" To: "Wang, Shane" , "Barros Pena, Belen" , "Lu, Lianhao" Thread-Topic: RFC: Hob 1.2 design Thread-Index: AQHM1ghN2ta+vDnY0kiXcbK0irRQ85YS108ggAGuLCCAAHlrgIAGmYWAgAb8MNCAAqn0gIACotQAgABGdBCAAFS8AIAAmk2AgABm6zCAAOoDcIAACL3w Date: Fri, 3 Feb 2012 00:56:36 +0000 Message-ID: <40776A41FC278F40B59438AD47D147A90FCD04D6@SHSMSX102.ccr.corp.intel.com> References: <3AB6CE7F274E534CAFD089D127A8A1FC0FCE9F5F@SHSMSX102.ccr.corp.intel.com> <3AB6CE7F274E534CAFD089D127A8A1FC0FCEB255@SHSMSX102.ccr.corp.intel.com> <3AB6CE7F274E534CAFD089D127A8A1FC0FCEBC20@SHSMSX102.ccr.corp.intel.com> In-Reply-To: <3AB6CE7F274E534CAFD089D127A8A1FC0FCEBC20@SHSMSX102.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "Purdie, Richard" , "Lock, Joshua" , "yocto@yoctoproject.org" , "Eggleton, Paul" Subject: Re: RFC: Hob 1.2 design X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 00:57:11 -0000 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_40776A41FC278F40B59438AD47D147A90FCD04D6SHSMSX102ccrcor_" --_000_40776A41FC278F40B59438AD47D147A90FCD04D6SHSMSX102ccrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 thin= k 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, Son= g; 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 im= ages", 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 --_000_40776A41FC278F40B59438AD47D147A90FCD04D6SHSMSX102ccrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One more from me that, Hob may w= ork as a deploy tool, and in the new movie, the approach is to select ̶= 0;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; L= iu, Song; Stewart, David C; yocto@yoctoproject.org
Subject: RE: RFC: Hob 1.2 design

I get one = more:

= ;

In the Ima= ge details screen, after opening an image file by clicking “My images= ”, we don’t allow to “Edit Package”, I think.<= /o:p>

Because wi= th an image only, we can’t generate the packages from it, you canR= 17;t assume there is a build directory (tmp/), is my understanding correct?=

= ;

Shane=

--_000_40776A41FC278F40B59438AD47D147A90FCD04D6SHSMSX102ccrcor_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id BF649E00592 for ; Thu, 2 Feb 2012 21:30:03 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 02 Feb 2012 21:30:02 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208,217";a="120117352" Received: from pgsmsx603.gar.corp.intel.com ([10.221.43.87]) by fmsmga002.fm.intel.com with ESMTP; 02 Feb 2012 21:30:01 -0800 Received: from pgsmsx101.gar.corp.intel.com (10.221.44.78) by pgsmsx603.gar.corp.intel.com (10.221.43.87) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 3 Feb 2012 13:29:59 +0800 Received: from shsmsx151.ccr.corp.intel.com (10.239.6.50) by PGSMSX101.gar.corp.intel.com (10.221.44.78) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Feb 2012 13:29:59 +0800 Received: from shsmsx102.ccr.corp.intel.com ([169.254.2.36]) by SHSMSX151.ccr.corp.intel.com ([169.254.3.91]) with mapi id 14.01.0355.002; Fri, 3 Feb 2012 13:29:57 +0800 From: "Wang, Shane" To: "Xu, Dongxiao" , "Barros Pena, Belen" , "Lu, Lianhao" Thread-Topic: RFC: Hob 1.2 design Thread-Index: AQHM1ghN2ta+vDnY0kiXcbK0irRQ85YS108ggAGuLCCAAHlrgIAGmYWAgAb8MNCAAqn0gIACotQAgABGdBCAAFS8AIAAmk2AgABm6zCAAOoDcIAACL3wgAA+c2A= Date: Fri, 3 Feb 2012 05:29:57 +0000 Message-ID: <3AB6CE7F274E534CAFD089D127A8A1FC0FCEBEDF@SHSMSX102.ccr.corp.intel.com> References: <3AB6CE7F274E534CAFD089D127A8A1FC0FCE9F5F@SHSMSX102.ccr.corp.intel.com> <3AB6CE7F274E534CAFD089D127A8A1FC0FCEB255@SHSMSX102.ccr.corp.intel.com> <3AB6CE7F274E534CAFD089D127A8A1FC0FCEBC20@SHSMSX102.ccr.corp.intel.com> <40776A41FC278F40B59438AD47D147A90FCD04D6@SHSMSX102.ccr.corp.intel.com> In-Reply-To: <40776A41FC278F40B59438AD47D147A90FCD04D6@SHSMSX102.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] MIME-Version: 1.0 Cc: "Purdie, Richard" , "Lock, Joshua" , "yocto@yoctoproject.org" , "Eggleton, Paul" Subject: Re: RFC: Hob 1.2 design X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 05:30:04 -0000 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_3AB6CE7F274E534CAFD089D127A8A1FC0FCEBEDFSHSMSX102ccrcor_" --_000_3AB6CE7F274E534CAFD089D127A8A1FC0FCEBEDFSHSMSX102ccrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 on= e 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". 2. As mentioned in my last email, we want to add "Clean" in the GUI. The re= ason 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 cleana= ll" 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 cleanin= g includes some tasks. Then we could make the Recipes dialog to be a screen, do you agree? The other reason is users can view recipes and click "Build Packages", no n= eed 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 scre= en -> 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 ima= ge" -> "Build packages" -> Log -> the Packages screen ... 5) Nothing want to view in the Image configuration after choosing "base ima= ge" -> "Build packages" -> Log -> Failure -> Go back to the Image configura= tion -> View Recipes -> the Recipes screen -> Clean something -> Log -> the= Recipe screen -> ... 6) Nothing want to view in the Image configuration after choosing "base ima= ge" -> "Build Image" -> Log -> the Image details ... and so on... 3. When build is failed, there is a "Back" button. But go back to where is = determined by where you come from. 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? 5. In the Image details screen, "Settings" is obviously not good to be show= n there. Can we remove "Load Template"? Because it will initiate a new buil= d. Let's ask users to click "Build new image" to be on the Image configurat= ion 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 i= s not executed this time. (ditto for "Save Template" in 4.) 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 detai= ls 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= . 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, Son= g; 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 thin= k 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, Son= g; 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 im= ages", 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 --_000_3AB6CE7F274E534CAFD089D127A8A1FC0FCEBEDFSHSMSX102ccrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dongxiao and = I have a discussion on that again.

Belen, please= ignore the issue for the deployment button below, and we have several sugg= estions.

1. To make th= e 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&= #8221;.

2. As mention= ed in my last email, we want to add “Clean” in the GUI. The rea= son 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 = 211;c cleanall” in the command line. But we hope to provide this feat= ure 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, si= nce cleaning includes some tasks.

Then we could= make the Recipes dialog to be a screen, do you agree?

The other rea= son is users can view recipes and click “Build Packages”, no ne= ed go back to the Image configuration screen.

The use case = is:

1) View Recip= es in the Image configuration -> the Recipes screen -> Select recipes= and Build packages -> Log -> the Packages screen …<= /span>

2) View Recip= es 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 -> Buil= d packages again -> Log -> Success -> the Packages screen …<= o:p>

3) View Recip= es in the Image configuration -> the Recipes screen -> Select recipes= -> Go back to the Image configuraion -> “Build Image”

4) Nothing wa= nt to view in the Image configuration after choosing “base image̶= 1; -> “Build packages” -> Log -> the Packages screen &= #8230;

5) Nothing wa= nt to view in the Image configuration after choosing “base image̶= 1; -> “Build packages” -> Log -> Failure -> Go back= to the Image configuration -> View Recipes -> the Recipes screen -> Clean something -> Lo= g -> the Recipe screen -> …

6) Nothing wa= nt to view in the Image configuration after choosing “base image̶= 1; -> “Build Image” -> Log -> the Image details …= ;

and so onR= 30;

3. When build= is failed, there is a “Back” button. But go back to where is d= etermined by where you come from.

4. After user= s open an image by “My images”, some time there should not be a= “Save Template” because we don’t have build process.

Let’s s= how “Save Template” when “Congratulations! Your image is = ready!” is shown, OK?

5. In the Ima= ge 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 i= t OK?

And remove &#= 8220;Edit Packages” and “Edit Configuration”, if the buil= d process is not executed this time. (ditto for “Save Template”= in 4.)

6. In Josh= 217;s email, FRI 2 image can also be run, though it is an image for real ma= chine. Can we keep two buttons “Run” and “Deploy” o= n the Image details screen and let uses decide what he/she wants? I admit an error possibly ha= ppens if the image doesn’t match the action, but we just report the e= rror.

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; L= iu, Song; Stewart, David C; yocto@yoctoproject.org
Subject: RE: RFC: Hob 1.2 design

Thanks,

Dongxiao

I get one = more:

= ;

In the Ima= ge details screen, after opening an image file by clicking “My images= ”, we don’t allow to “Edit Package”, I think.<= /o:p>

Because wi= th an image only, we can’t generate the packages from it, you canR= 17;t assume there is a build directory (tmp/), is my understanding correct?=

= ;

Shane=

--_000_3AB6CE7F274E534CAFD089D127A8A1FC0FCEBEDFSHSMSX102ccrcor_-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 3BC0CE01389 for ; Fri, 3 Feb 2012 07:01:41 -0800 (PST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 03 Feb 2012 07:01:40 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="103569156" Received: from irsmsx601.ger.corp.intel.com ([163.33.7.164]) by orsmga001.jf.intel.com with ESMTP; 03 Feb 2012 07:01:39 -0800 Received: from irsmsx152.ger.corp.intel.com (163.33.192.66) by irsmsx601.ger.corp.intel.com (163.33.7.164) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 3 Feb 2012 15:01:38 +0000 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.99]) by IRSMSX152.ger.corp.intel.com ([169.254.6.46]) with mapi id 14.01.0355.002; Fri, 3 Feb 2012 15:01:37 +0000 From: "Barros Pena, Belen" To: "Wang, Shane" , "Xu, Dongxiao" , "Lu, Lianhao" Thread-Topic: RFC: Hob 1.2 design Thread-Index: AQHM4oS6yiYUtHb0d0KhmqVM+D5XmQ== Date: Fri, 3 Feb 2012 15:01:37 +0000 Message-ID: In-Reply-To: <3AB6CE7F274E534CAFD089D127A8A1FC0FCEBEDF@SHSMSX102.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.254.53.57] MIME-Version: 1.0 Cc: "Purdie, Richard" , "Lock, Joshua" , "yocto@yoctoproject.org" , "Eggleton, Paul" Subject: Re: RFC: Hob 1.2 design X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 15:01:41 -0000 Content-Language: en-US Content-ID: <9B1D9122D4C4DF4B8CF96432053E8CBD@intel.com> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" Hi Shane and team, Thanks for the suggestions. Loads of interesting stuff there. I'll take some time to look at them in detail and come back to you next wee= k. Have a great weekend. Belen From: "Wang, Shane" > Date: Fri, 3 Feb 2012 05:29:57 +0000 To: "Xu, Dongxiao" >, "= Belen Barros Pena (Intel)" >, "Lu, Lianhao" > Cc: "Eggleton, Paul" >, "Purdie, Richard" >, "Zhang, Jessica" >, "Lock, Joshua" >, "Liu, Song" >, "Stewart,= David C" >, "y= octo@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 =93Build packages=94. That i= s 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=92t want = to go back to the Image configuration screen and click =93Build Image=94. 2. As mentioned in my last email, we want to add =93Clean=94 in the GUI. Th= e reason is the build will fail, say, do_fetch, then we have an option to a= llow users to clean what we built out and rebuild. Otherwise, the sstate co= uld be reused for the next build. Users can do it by running =93bitbake =96= c cleanall=94 in the command line. But we hope to provide this feature in t= he GUI. If you agree the above, then the action =93Clean=94 is for a recipe or mult= iple recipes, and clicking =93Clean=94 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? The other reason is users can view recipes and click =93Build Packages=94, = 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 =85 2) View Recipes in the Image configuration -> the Recipes screen -> Select = recipes and Build packages -> Log -> Failure -> Go back to the Recipes scre= en -> Clean something -> Log -> the Recipes screen -> Build packages again = -> Log -> Success -> the Packages screen =85 3) View Recipes in the Image configuration -> the Recipes screen -> Select = recipes -> Go back to the Image configuraion -> =93Build Image=94 4) Nothing want to view in the Image configuration after choosing =93base i= mage=94 -> =93Build packages=94 -> Log -> the Packages screen =85 5) Nothing want to view in the Image configuration after choosing =93base i= mage=94 -> =93Build packages=94 -> Log -> Failure -> Go back to the Image c= onfiguration -> View Recipes -> the Recipes screen -> Clean something -> Lo= g -> the Recipe screen -> =85 6) Nothing want to view in the Image configuration after choosing =93base i= mage=94 -> =93Build Image=94 -> Log -> the Image details =85 and so on=85 3. When build is failed, there is a =93Back=94 button. But go back to where= is determined by where you come from. 4. After users open an image by =93My images=94, some time there should not= be a =93Save Template=94 because we don=92t have build process. Let=92s show =93Save Template=94 when =93Congratulations! Your image is rea= dy!=94 is shown, OK? 5. In the Image details screen, =93Settings=94 is obviously not good to be = shown there. Can we remove =93Load Template=94? Because it will initiate a = new build. Let=92s ask users to click =93Build new image=94 to be on the Im= age configuration and click =93Load Template=94. We just keep =93My Images=94 in the last screen (the Image details screen),= is it OK? And remove =93Edit Packages=94 and =93Edit Configuration=94, if the build p= rocess is not executed this time. (ditto for =93Save Template=94 in 4.) 6. In Josh=92s email, FRI 2 image can also be run, though it is an image fo= r real machine. Can we keep two buttons =93Run=94 and =93Deploy=94 on the I= mage details screen and let uses decide what he/she wants? I admit an error= possibly happens if the image doesn=92t match the action, but we just repo= rt the error. 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, Son= g; 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 =93My images=94 and then click deploy button. I = think normal user may not have such knowledge. I am still wondering if addi= ng a =93deploy=94 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, Son= g; 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 =93My = images=94, we don=92t allow to =93Edit Package=94, I think. Because with an image only, we can=92t generate the packages from it, you c= an=92t assume there is a build directory (tmp/), is my understanding correc= t? -- Shane --------------------------------------------------------------------- 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 5276DE01217 for ; Mon, 6 Feb 2012 03:54:02 -0800 (PST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 06 Feb 2012 03:54:02 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="114567210" Received: from irsmsx602.ger.corp.intel.com ([163.33.3.242]) by fmsmga001.fm.intel.com with ESMTP; 06 Feb 2012 03:54:01 -0800 Received: from irsmsx104.ger.corp.intel.com (163.33.3.159) by irsmsx602.ger.corp.intel.com (163.33.3.242) with Microsoft SMTP Server (TLS) id 8.2.255.0; Mon, 6 Feb 2012 11:54:00 +0000 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.99]) by IRSMSX104.ger.corp.intel.com ([169.254.5.165]) with mapi id 14.01.0355.002; Mon, 6 Feb 2012 11:53:59 +0000 From: "Barros Pena, Belen" To: "Wang, Shane" , "Xu, Dongxiao" , "Lu, Lianhao" Thread-Topic: RFC: Hob 1.2 design Thread-Index: AQHM5MYCyiYUtHb0d0KhmqVM+D5XmQ== Date: Mon, 6 Feb 2012 11:53:59 +0000 Message-ID: In-Reply-To: <3AB6CE7F274E534CAFD089D127A8A1FC0FCEBEDF@SHSMSX102.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.252.18.204] MIME-Version: 1.0 Cc: "Purdie, Richard" , "Lock, Joshua" , "yocto@yoctoproject.org" , "Eggleton, Paul" Subject: Re: RFC: Hob 1.2 design X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 11:54:02 -0000 Content-Language: en-US Content-ID: <003E07208D57C247874096C22B637715@intel.com> Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" 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" > Date: Fri, 3 Feb 2012 05:29:57 +0000 To: "Xu, Dongxiao" >, "= Belen Barros Pena (Intel)" >, "Lu, Lianhao" > Cc: "Eggleton, Paul" >, "Purdie, Richard" >, "Zhang, Jessica" >, "Lock, Joshua" >, "Liu, Song" >, "Stewart,= David C" >, "y= octo@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 =93Build packages=94. That i= s 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=92t want = to go back to the Image configuration screen and click =93Build Image=94. Sorry, I am not sure I understand. What you seem to be saying is that we wi= ll 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 t= his correct? 2. As mentioned in my last email, we want to add =93Clean=94 in the GUI. Th= e reason is the build will fail, say, do_fetch, then we have an option to a= llow users to clean what we built out and rebuild. Otherwise, the sstate co= uld be reused for the next build. Users can do it by running =93bitbake =96= c cleanall=94 in the command line. But we hope to provide this feature in t= he GUI. If you agree the above, then the action =93Clean=94 is for a recipe or mult= iple recipes, and clicking =93Clean=94 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 w= hen the build fails. If you select it you go to the screen at 4:00 to provi= de 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' s= cenario 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 =93Build Packages=94, = 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 =85 2) View Recipes in the Image configuration -> the Recipes screen -> Select = recipes and Build packages -> Log -> Failure -> Go back to the Recipes scre= en -> Clean something -> Log -> the Recipes screen -> Build packages again = -> Log -> Success -> the Packages screen =85 3) View Recipes in the Image configuration -> the Recipes screen -> Select = recipes -> Go back to the Image configuraion -> =93Build Image=94 4) Nothing want to view in the Image configuration after choosing =93base i= mage=94 -> =93Build packages=94 -> Log -> the Packages screen =85 5) Nothing want to view in the Image configuration after choosing =93base i= mage=94 -> =93Build packages=94 -> Log -> Failure -> Go back to the Image c= onfiguration -> View Recipes -> the Recipes screen -> Clean something -> Lo= g -> the Recipe screen -> =85 6) Nothing want to view in the Image configuration after choosing =93base i= mage=94 -> =93Build Image=94 -> Log -> the Image details =85 and so on=85 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 "bu= ild image", so that users who want to build an image directly from the Reci= pes 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 =93Back=94 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 =93My images=94, some time there should not= be a =93Save Template=94 because we don=92t have build process. Let=92s show =93Save Template=94 when =93Congratulations! Your image is rea= dy!=94 is shown, OK? This sounds ok to me. Should we have a 'save as template' option in the Ima= ge configuration screen? Or will we just have it in the Image details scree= n when you get there after completing the build process? 5. In the Image details screen, =93Settings=94 is obviously not good to be = shown there. Can we remove =93Load Template=94? Because it will initiate a = new build. Let=92s ask users to click =93Build new image=94 to be on the Im= age configuration and click =93Load Template=94. We just keep =93My Images=94 in the last screen (the Image details screen),= is it OK? And remove =93Edit Packages=94 and =93Edit Configuration=94, if the build p= rocess is not executed this time. (ditto for =93Save Template=94 in 4.) Happy with this. 6. In Josh=92s email, FRI 2 image can also be run, though it is an image fo= r real machine. Can we keep two buttons =93Run=94 and =93Deploy=94 on the I= mage details screen and let uses decide what he/she wants? I admit an error= possibly happens if the image doesn=92t match the action, but we just repo= rt the error. Not so happy with this one ;) If an option is going to generate an error wh= en selected, it should not be there at all. GUI's must be defensive: they m= ust prevent user errors. This is a fundamental principle of interaction des= ign. We should only present the 'Run' (on qemu) option if the image is sui= table 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 'Deplo= y' functionality should not be there at all. Better wait until we find a wo= rk 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 wo= uld 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, Son= g; 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 =93My images=94 and then click deploy button. I = think normal user may not have such knowledge. I am still wondering if addi= ng a =93deploy=94 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, Son= g; 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 =93My = images=94, we don=92t allow to =93Edit Package=94, I think. Because with an image only, we can=92t generate the packages from it, you c= an=92t assume there is a build directory (tmp/), is my understanding correc= t? -- Shane --------------------------------------------------------------------- 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 61905E0030B for ; Mon, 6 Feb 2012 13:32:36 -0800 (PST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 06 Feb 2012 13:32:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="104673163" Received: from unknown (HELO [10.7.199.63]) ([10.7.199.63]) by orsmga001.jf.intel.com with ESMTP; 06 Feb 2012 13:32:36 -0800 Message-ID: <4F3046F3.80102@linux.intel.com> Date: Mon, 06 Feb 2012 13:32:35 -0800 From: Joshua Lock User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: yocto@yoctoproject.org, "Barros Pena, Belen" , "Wang, Shane" References: <3AB6CE7F274E534CAFD089D127A8A1FC0FCE9634@SHSMSX102.ccr.corp.intel.com> In-Reply-To: <3AB6CE7F274E534CAFD089D127A8A1FC0FCE9634@SHSMSX102.ccr.corp.intel.com> Subject: Re: RFC: Hob 1.2 design X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 21:32:36 -0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 31/01/12 17:39, Wang, Shane wrote: > Hi, all, > > Belen has a new video for Hob2 workflow and design. > > https://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast2.mov It just came to my attention through another channel that the description column of the packages table is no longer present. There had been some discussion about how to show relevant description information in that column, so I'm surprised to see it go. Belen, I assume from a design perspective this field was removed as it didn't show anything particularly useful? If we have useful data to include in that field is there a more appropriate way to integrate it into the UI? Perhaps a tooltip? Or an information overlay as has been used in other areas of the design? I'm concerned that if we give the user a list of packages without any more information we aren't making it easy for them to build an OS image without already understanding exactly all of the components they need - thoughts? Cheers, Joshua -- Joshua Lock Yocto Project "Johannes factotum" Intel Open Source Technology Centre From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 787BFE0030B for ; Tue, 7 Feb 2012 03:23:36 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 07 Feb 2012 03:23:35 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,351,1309762800"; d="scan'208";a="107277088" Received: from irsmsx601.ger.corp.intel.com ([163.33.7.164]) by orsmga002.jf.intel.com with ESMTP; 07 Feb 2012 03:23:34 -0800 Received: from irsmsx104.ger.corp.intel.com (163.33.3.159) by irsmsx601.ger.corp.intel.com (163.33.7.164) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 7 Feb 2012 11:23:28 +0000 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.99]) by IRSMSX104.ger.corp.intel.com ([169.254.5.165]) with mapi id 14.01.0355.002; Tue, 7 Feb 2012 11:23:28 +0000 From: "Barros Pena, Belen" To: Joshua Lock , "yocto@yoctoproject.org" , "Wang, Shane" Thread-Topic: [yocto] RFC: Hob 1.2 design Thread-Index: AQHM5Yrp5BarafXGYUmHwyFKKMBbiA== Date: Tue, 7 Feb 2012 11:23:28 +0000 Message-ID: In-Reply-To: <4F3046F3.80102@linux.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.254.196.68] MIME-Version: 1.0 Subject: Re: RFC: Hob 1.2 design X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 11:23:36 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-ID: <2024714E3C950640AECABED7B38F6B82@intel.com> Content-Transfer-Encoding: quoted-printable Hi Joshua, Additional package details appear on clicking the package name using an information bubble. The bubble is also dismissed on click using a 'close' button. This functionality is shown on the first video (not on the second one: I skipped it to keep it short). Cheers Belen On 06/02/2012 21:32, "Joshua Lock" wrote: >On 31/01/12 17:39, Wang, Shane wrote: >> Hi, all, >> >> Belen has a new video for Hob2 workflow and design. >> >> https://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast2.mov > >It just came to my attention through another channel that the >description column of the packages table is no longer present. > >There had been some discussion about how to show relevant description >information in that column, so I'm surprised to see it go. > >Belen, I assume from a design perspective this field was removed as it >didn't show anything particularly useful? If we have useful data to >include in that field is there a more appropriate way to integrate it >into the UI? Perhaps a tooltip? Or an information overlay as has been >used in other areas of the design? > >I'm concerned that if we give the user a list of packages without any >more information we aren't making it easy for them to build an OS image >without already understanding exactly all of the components they need - >thoughts? > >Cheers, >Joshua >--=20 >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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 86EB2E0136A for ; Tue, 7 Feb 2012 08:17:04 -0800 (PST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 07 Feb 2012 08:17:04 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="122023955" Received: from unknown (HELO [10.255.15.17]) ([10.255.15.17]) by fmsmga002.fm.intel.com with ESMTP; 07 Feb 2012 08:17:03 -0800 Message-ID: <4F314E7F.7060108@linux.intel.com> Date: Tue, 07 Feb 2012 08:17:03 -0800 From: Joshua Lock User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: "Barros Pena, Belen" References: In-Reply-To: Cc: "yocto@yoctoproject.org" Subject: Re: RFC: Hob 1.2 design X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 16:17:04 -0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Belen, Thanks for clarifying. Shane - I noticed at least one bug has been closed because the second video didn't show the features (#1804) - seems like this isn't what was intended by features 'disappearing' in the latest video. http://bugzilla.pokylinux.org/show_bug.cgi?id=1804 Cheers, Joshua On 07/02/12 03:23, Barros Pena, Belen wrote: > Hi Joshua, > > Additional package details appear on clicking the package name using an > information bubble. The bubble is also dismissed on click using a 'close' > button. This functionality is shown on the first video (not on the second > one: I skipped it to keep it short). > > Cheers > > Belen > > On 06/02/2012 21:32, "Joshua Lock" wrote: > >> On 31/01/12 17:39, Wang, Shane wrote: >>> Hi, all, >>> >>> Belen has a new video for Hob2 workflow and design. >>> >>> https://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast2.mov >> >> It just came to my attention through another channel that the >> description column of the packages table is no longer present. >> >> There had been some discussion about how to show relevant description >> information in that column, so I'm surprised to see it go. >> >> Belen, I assume from a design perspective this field was removed as it >> didn't show anything particularly useful? If we have useful data to >> include in that field is there a more appropriate way to integrate it >> into the UI? Perhaps a tooltip? Or an information overlay as has been >> used in other areas of the design? >> >> I'm concerned that if we give the user a list of packages without any >> more information we aren't making it easy for them to build an OS image >> without already understanding exactly all of the components they need - >> thoughts? >> >> Cheers, >> Joshua >> -- >> Joshua Lock >> Yocto Project "Johannes factotum" >> Intel Open Source Technology Centre > -- Joshua Lock Yocto Project "Johannes factotum" Intel Open Source Technology Centre From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 083B7E01372 for ; Wed, 8 Feb 2012 02:24:32 -0800 (PST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 08 Feb 2012 02:24:32 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.71,315,1320652800"; d="scan'208";a="115388755" Received: from irsmsx602.ger.corp.intel.com ([163.33.3.242]) by fmsmga001.fm.intel.com with ESMTP; 08 Feb 2012 02:24:31 -0800 Received: from irsmsx102.ger.corp.intel.com (163.33.3.155) by irsmsx602.ger.corp.intel.com (163.33.3.242) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 8 Feb 2012 10:23:07 +0000 Received: from irsmsx101.ger.corp.intel.com ([169.254.1.99]) by IRSMSX102.ger.corp.intel.com ([169.254.2.194]) with mapi id 14.01.0355.002; Wed, 8 Feb 2012 10:23:06 +0000 From: "Barros Pena, Belen" To: Joshua Lock Thread-Topic: [yocto] RFC: Hob 1.2 design Thread-Index: AQHM5kulEORhW2hRwEWGTPgji6fKMA== Date: Wed, 8 Feb 2012 10:23:06 +0000 Message-ID: In-Reply-To: <4F314E7F.7060108@linux.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.254.196.27] MIME-Version: 1.0 Cc: "yocto@yoctoproject.org" Subject: Re: RFC: Hob 1.2 design X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 10:24:33 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Just to clarify: videos show relevant functionality to a specific design piece. The fact that a video does not show something it doesn't mean the functionality has gone away. If I showed everything on each video they would be very very long (and very very boring) videos. I hope this explains.=20 Given the time constraints we have, the little design documentation I am producing is incomplete. Therefore, it is very important that if you have any questions, doubts, thoughts, feedback, general comments etc about the Hob UI, you get in touch with me. Even if the question sounds very small or trivial: that's what I am here for. Cheers Belen On 07/02/2012 16:17, "Joshua Lock" wrote: >Hi Belen, > >Thanks for clarifying. > >Shane - I noticed at least one bug has been closed because the second >video didn't show the features (#1804) - seems like this isn't what was >intended by features 'disappearing' in the latest video. > >http://bugzilla.pokylinux.org/show_bug.cgi?id=3D1804 > >Cheers, >Joshua > >On 07/02/12 03:23, Barros Pena, Belen wrote: >> Hi Joshua, >> >> Additional package details appear on clicking the package name using an >> information bubble. The bubble is also dismissed on click using a >>'close' >> button. This functionality is shown on the first video (not on the >>second >> one: I skipped it to keep it short). >> >> Cheers >> >> Belen >> >> On 06/02/2012 21:32, "Joshua Lock" wrote: >> >>> On 31/01/12 17:39, Wang, Shane wrote: >>>> Hi, all, >>>> >>>> Belen has a new video for Hob2 workflow and design. >>>> >>>> https://wiki.yoctoproject.org/wiki/File:Hob1.2-screencast2.mov >>> >>> It just came to my attention through another channel that the >>> description column of the packages table is no longer present. >>> >>> There had been some discussion about how to show relevant description >>> information in that column, so I'm surprised to see it go. >>> >>> Belen, I assume from a design perspective this field was removed as it >>> didn't show anything particularly useful? If we have useful data to >>> include in that field is there a more appropriate way to integrate it >>> into the UI? Perhaps a tooltip? Or an information overlay as has been >>> used in other areas of the design? >>> >>> I'm concerned that if we give the user a list of packages without any >>> more information we aren't making it easy for them to build an OS image >>> without already understanding exactly all of the components they need - >>> thoughts? >>> >>> Cheers, >>> Joshua >>> -- >>> Joshua Lock >>> Yocto Project "Johannes factotum" >>> Intel Open Source Technology Centre >> > >--=20 >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.