Re: [OE-core] [PATCH v3 3/3] bitbake-config-build: add a plugin for config fragments

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Mon, 2024-11-18 at 17:26 +0100, Alexander Kanavin via
lists.openembedded.org wrote:
> From: Alexander Kanavin <alex@linutronix.de>
> 
> This allows fine-tuning local configurations with pre-frabricated
> configuration snippets in a structured, controlled way. It's also
> an important building block for bitbake-setup.
> 
> There are three (and a half) operations (list/enable/disable/disable
> all), and here's the 'list' output:
> 
> alex@Zen2:/srv/storage/alex/yocto/build-64$ bitbake-config-build list-fragments
> NOTE: Starting bitbake server...
> Available fragments in selftest layer located in /srv/work/alex/poky/meta-selftest:
> 
> selftest/test-fragment	(disabled)	This is a configuration fragment intended for testing in oe-selftest context
> selftest/more-fragments-here/test-another-fragment	(disabled)	This is a second configuration fragment intended for testing in oe-selftest context
> 
> The tool requires that each fragment contains a one-line summary, and one or more
> lines of description, as BB_CONF_FRAGMENT_SUMMARY[layerid/fragmentname] style metadata.

The other area I've been wondering about is this output. I think we
need to take a quick step back and look at it from a usability
perspective and make sure we're showing the information in the optimal
way.

I'm far from a UI expert, in fact I've been told I shouldn't comment on
such things however I do have some thoughts.

Firstly, I think the "(disabled)" is the wrong way to show that
information. It would be more compact and perhaps more usable to show
the elements sorted into two sections along the lines of:

"""
Enabled fragments:

selftest/test-fragment - This is a configuration fragment intended for testing in oe-selftest context

Unused fragments:

selftest/more-fragments-here/test-another-fragment - This is a second configuration fragment intended for testing in oe-selftest context
"""

Secondly when listing the fragments, the current approach does lend
itself to cut and past but also doesn't group neatly. For example you
could do something like:

selftest/
  test-fragment - This is a configuration fragment intended for testing in oe-selftest context
  more-fragments-here/test-another-fragment - This is a second configuration fragment intended for testing in oe-selftest context

I'm torn on that but it may be easier for people to read. We should
also think about how terminal line wrapping will effect the output and
try to ensure it remains readable.

As with the previous email, I'm open to other thoughts on this.

Cheers,

Richard