Re: review request for configure details page

["Reyna, David" <david.reyna@windriver.com>]

Hi Belen,

Thank you for the review. Here are some comments for you while I make my fixes.

> SUMMARY TAB

Oh of course. I focused on the second (harder) page since this paged look fine out of the gate. I will fix this.

> BITBAKE VARIABLES TAB
> 
> * The path for the bitbake.conf file is not the full path (it only says
> conf/bitbake.conf)
> 

These are however the actual values from the database. I assumed that for some reason they were local paths. This is not something I can fix.

> * But the Set in file heading should be sortable

But can we sort on a synthetic field where the values only exist through a filter? I will try to find a way.

> * In the filter modal dialogs, the headings and the "All" radio button
> labels say "configvars" instead of "variables". This also happens in the
> applied filter tooltip (in the "Show all" button) and in the placeholder
> text in the search input field (which should say "Search BitBake
> variables")

That needs my patch set for the "Disk IO". "CPU Usage", and "Build Time" pages, which allows me to explicitly set those values different from the page's "cookie" value.

> * The Description filter should be applied when you load this page
> * The Value heading is not sortable

Will fix.

> ** how do we show the operation and line number for the variables touched
> by only one file?

That is why I show the dialog when there are any values available.

- David

> -----Original Message-----
> From: Barros Pena, Belen [mailto:belen.barros.pena@intel.com]
> Sent: Friday, February 14, 2014 8:27 AM
> To: Reyna, David; Damian, Alexandru
> Cc: toaster@yoctoproject.org
> Subject: Re: review request for configure details page
> 
> Thanks, David. Those file filters are really neat :)
> 
> I have reviewed this page. There are a few little things
> implementation-related, and there are other (bigger) issues that are
> design problems.
> 
> The implementation first:
> 
> SUMMARY TAB
> 
> * The Summary values in the Build configuration section don't seem to be
> coming in (for my Beagleboard build, I see machine 'atom-pc', which
> doesn't seem right). That section should list:
> 
> ** BitBake version (BB_VERSION)
> 
> ** Build system (BUILD_SYS)
> 
> ** Host distribution (NATIVELSBSTRING)
> 
> ** Target system (TARGET_SYS)
> 
> ** Machine (MACHINE)
> 
> ** Distro (DISTRO)
> 
> ** Distro version (DISTRO_VERSION)
> 
> ** Tune features (TUNE_FEATURES)
> 
> ** Target FPU (TARGET_FPU)
> 
> ** Target(s), i.e. the name(s) of the image recipe(s) or recipe(s) you are
> building (e.g. core-image-minimal). If more than one, please mark them up
> within an unnumbered list (<ul>)
> 
> If any of the above variables has no value, we don't list the variable
> 
> * We should take out the blue icon next to the layer name
> 
> BITBAKE VARIABLES TAB
> 
> * The Description filter should be applied when you load this page
> 
> * The Value heading is not sortable
> 
> * But the Set in file heading should be sortable
> 
> * The path for the bitbake.conf file is not the full path (it only says
> conf/bitbake.conf)
> 
> * In the filter modal dialogs, the headings and the "All" radio button
> labels say "configvars" instead of "variables". This also happens in the
> applied filter tooltip (in the "Show all" button) and in the placeholder
> text in the search input field (which should say "Search BitBake
> variables")
> 
> There are also some design problems with this page that I need to think
> about:
> 
> 
> * As it was designed, the modal dialog for the history should only exist
> if the number of config files touching the variable is higher than one.
> This causes a few issues:
> 
> ** how do we show the operation and line number for the variables touched
> by only one file?
> 
> 
> ** Search and filtering work across all entries, which means it might not
> be obvious why you get certain results since they are hidden inside the
> history modal dialog
> 
> 
> * How do we deal with very long values (both in the table and in the
> history modal dialogs)?
> 
> * The design specification says that the page h1 should not be manipulated
> by search results: for pages with tabs, like this one, it says to display
> a h2 right above the search field with the number of results returned by
> the search query. Having said that, I am not particularly happy with that
> design either. On the other hand, manipulating the h1 causes some weird
> interactions in the page that could be confusing. This is the kind of
> thing you need to test with users to actually find out. I am inclined to
> leave it as is for the moment, and see how it goes. We can always refine
> it in the next release cycle.
> 
> 
> * What do we do with the B_* variables (in a core-image-minimal build you
> get about 600 of those). We knew we were going to hit this problem at some
> point, but I am not sure how we can exclude those entries within our
> existing filtering patterns. The only easy solution seems to be removing
> the B variable from documentation.conf, which means that neither B nor any
> of the 600 B_* variables will show by default, since we apply the
> Variables with description filter.
> 
> * I have been thinking about how we can keep the links to the full
> variable descriptions in the Yocto Project manual. Right now, we do know
> that an entry in the manual exists for each variable that has a
> description, so it is safe to show the link. We also know their structure
> should be:
> 
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var- +
> <variableName>
> 
> For example:
> 
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-ALL
> OW_EMPTY
> 
> The question is: what's the best way to generate the URLs?
> 
> 
> Sorry for the brain dump: I thought I'd share my pains with you all ;) I
> will try and look into the design issues above as soon as possible. If you
> have any suggestions for any of them, please let me know.
> 
> Belén
> 
> 
> On 14/02/2014 10:26, "Reyna, David" <david.reyna@windriver.com> wrote:
> 
> >Hi again,
> >
> >> ³I have the filter for the descriptions, but is depends on the presence
> >>of a space character²
> >
> >Ok, I was able to redo and push the filter using a regex, so that will
> >allow the possibility of a description that has characters but no spaces.
> >
> >    ('Show only variables with description', 'description__regex:.+'),
> >
> >- David
> >
> >From: toaster-bounces@yoctoproject.org
> >[mailto:toaster-bounces@yoctoproject.org]
> >On Behalf Of Reyna, David
> >Sent: Friday, February 14, 2014 1:20 AM
> >To: belen.barros.pena@intel.com; Damian, Alexandru
> >(alexandru.damian@intel.com)
> >Cc: toaster@yoctoproject.org
> >Subject: [Toaster] review request for configure details page
> >
> >
> >
> >Hi Belen and Alex,
> >
> >
> >
> >I have the configuration page ready for review at:
> >³dreyna/configure-detail-view²
> >
> >
> >
> >Implementation Notes:
> >
> >
> >
> >* In the file list pop-up dialog, I truncate the variable¹s value to 200
> >characters max.
> >
> >
> >
> >
> >The reason is that I discovered for variables (like ³BBINCLUDE²) with
> >very long values, the pop-up is in fact unable by design to scroll to the
> >end, to show the file list.
> > I think that 200 characters give the right idea, and the result looks
> >consistent with the more normal pop-ups.
> >
> >
> >
> >* I have the file filters working for each of the indicated categories.
> >
> >
> >
> >
> >I will note that in my examinations that there were a few file types that
> >were not covered by the existing categories, and I wondered if you were
> >ok that.
> >
> >
> >
> >    poky/meta/classes/*
> >
> >    poky/bitbake/lib/bb/*
> >
> >
> >
> >* I have the filter for the descriptions.
> >
> >
> >
> >I ended on filtering on the presence of a space character, because I
> >could not find an appropriate alternate field lookup. I suppose I could
> >try a regex test.
> >
> >
> >
> >* I implemented the file list such the last file is the one shown.
> >
> >
> >
> >I was however curious if it is absolutely the case that the foreign key
> >select on the VariableHistory table is guaranteed to be in time order. I
> >did manually examine the
> > first 100 rows and found that indeed that the rows were in primary key
> >sequential order, but that is not proof.
> >
> >
> >
> >Thanks,
> >
> >David
> >
> >
> >
> >
> >
> >
> >
>