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
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
