From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <belen.barros.pena@intel.com>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
	by yocto-www.yoctoproject.org (Postfix) with ESMTP id 68F97E00444
	for <toaster@yoctoproject.org>; Fri, 14 Feb 2014 08:27:24 -0800 (PST)
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
	by fmsmga101.fm.intel.com with ESMTP; 14 Feb 2014 08:27:24 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.95,845,1384329600"; d="scan'208";a="475308143"
Received: from irsmsx104.ger.corp.intel.com ([163.33.3.159])
	by fmsmga001.fm.intel.com with ESMTP; 14 Feb 2014 08:27:23 -0800
Received: from irsmsx106.ger.corp.intel.com ([169.254.8.96]) by
	IRSMSX104.ger.corp.intel.com ([169.254.5.244]) with mapi id
	14.03.0123.003; Fri, 14 Feb 2014 16:27:21 +0000
From: "Barros Pena, Belen" <belen.barros.pena@intel.com>
To: "Reyna, David L (Wind River)" <david.reyna@windriver.com>, "Damian,
	Alexandru" <alexandru.damian@intel.com>
Thread-Topic: review request for configure details page
Thread-Index: Ac8pVTipvr/OHTyCSgC2T6rxfhlFdAAGaNqwAAyxdgA=
Date: Fri, 14 Feb 2014 16:27:21 +0000
Message-ID: <CF23D4F4.3D3EB%belen.barros.pena@intel.com>
References: <5E53D14CE4667A45B9A06760DE5D13D055DC6CC6@ALA-MBB.corp.ad.wrs.com>
	<5E53D14CE4667A45B9A06760DE5D13D055DC6D12@ALA-MBB.corp.ad.wrs.com>
In-Reply-To: <5E53D14CE4667A45B9A06760DE5D13D055DC6D12@ALA-MBB.corp.ad.wrs.com>
Accept-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.237.224.31]
MIME-Version: 1.0
Cc: "toaster@yoctoproject.org" <toaster@yoctoproject.org>
Subject: Re: review request for configure details page
X-BeenThere: toaster@yoctoproject.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Web based interface for BitBake <toaster.yoctoproject.org>
List-Unsubscribe: <https://lists.yoctoproject.org/options/toaster>,
	<mailto:toaster-request@yoctoproject.org?subject=unsubscribe>
List-Archive: <http://lists.yoctoproject.org/pipermail/toaster>
List-Post: <mailto:toaster@yoctoproject.org>
List-Help: <mailto:toaster-request@yoctoproject.org?subject=help>
List-Subscribe: <https://lists.yoctoproject.org/listinfo/toaster>,
	<mailto:toaster-request@yoctoproject.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2014 16:27:27 -0000
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <82DD3819D16BF44793985C6FEFD6EFC1@intel.com>
Content-Transfer-Encoding: quoted-printable

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.=20

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:=20

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=E9n


On 14/02/2014 10:26, "Reyna, David" <david.reyna@windriver.com> wrote:

>Hi again,
>=20
>> =B3I have the filter for the descriptions, but is depends on the presenc=
e
>>of a space character=B2
>=20
>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.
>=20
>    ('Show only variables with description', 'description__regex:.+'),
>=20
>- David
>=20
>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
>
>
>=20
>Hi Belen and Alex,
>
>=20
>
>I have the configuration page ready for review at:
>=B3dreyna/configure-detail-view=B2
>
>=20
>
>Implementation Notes:
>
>=20
>
>* In the file list pop-up dialog, I truncate the variable=B9s value to 200
>characters max.
>
>
>=20
>
>The reason is that I discovered for variables (like =B3BBINCLUDE=B2) 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.
>
>=20
>
>* I have the file filters working for each of the indicated categories.
>
>
>=20
>
>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.
>
>=20
>
>    poky/meta/classes/*
>
>    poky/bitbake/lib/bb/*
>
>=20
>
>* I have the filter for the descriptions.
>
>=20
>
>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.
>
>=20
>
>* I implemented the file list such the last file is the one shown.
>
>=20
>
>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.
>
>=20
>
>Thanks,
>
>David
>
>=20
>
>=20
>
>
>