From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: alex.kanavin@gmail.com
Cc: openembedded-core@lists.openembedded.org,
Alexander Kanavin <alex@linutronix.de>
Subject: Re: [OE-core] [PATCH v3 3/3] bitbake-config-build: add a plugin for config fragments
Date: Tue, 10 Dec 2024 15:27:34 +0000 [thread overview]
Message-ID: <4254d23ae9ad100e70f199fa4949ce00bfe7063c.camel@linuxfoundation.org> (raw)
In-Reply-To: <CANNYZj_ONOGam=9um4qqqAc_D0gQHrQML3a9eXBEgHLCiRtM1A@mail.gmail.com>
On Tue, 2024-12-10 at 14:05 +0100, Alexander Kanavin via
lists.openembedded.org wrote:
> On Mon, 9 Dec 2024 at 18:00, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > 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
> > """
>
> This is fine, I can fix it.
Right, this on is not too hard to implement from a code perspective.
>
> > 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
>
> If we start going down this path, we might as well write an
> interactive curses UI, and keep the command line output 'flat' like it
> is now. I'm also not sure what is the best approach, we'd need to take
> fragments into practical use and accumulate a sizable amount of them
> perhaps. Such things can be easily tweaked from experience.
Having experimented with curses UIs, they're a pain and don't really do
what you hope/think they would.
Some of the other tools like bitbake-layers do "group" output for ease
of usability so this is something our commandline tools do to some
extent already. I'm not saying we have to do this, or do it now. I did
want to at least put the idea out there to see what people's thoughts
were.
I just know from experience that showing users large blocks of text
without something to guide the eye can make them harder to use.
We can leave this part for now...
Cheers,
Richard
next prev parent reply other threads:[~2024-12-10 15:27 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-18 16:26 [PATCH v3 1/3] patchtest: use HEAD commit as base for the selftest and not master Alexander Kanavin
2024-11-18 16:26 ` [PATCH v3 2/3] bitbake.conf: add an addfragments directive for oe-core and dependent layers Alexander Kanavin
2024-11-18 16:26 ` [PATCH v3 3/3] bitbake-config-build: add a plugin for config fragments Alexander Kanavin
2024-11-18 16:32 ` Patchtest results for " patchtest
2024-12-09 16:33 ` [OE-core] " Richard Purdie
2024-12-10 12:22 ` Alexander Kanavin
2024-12-09 17:00 ` Richard Purdie
2024-12-10 13:05 ` Alexander Kanavin
2024-12-10 15:27 ` Richard Purdie [this message]
2024-12-11 11:24 ` Alexander Kanavin
2024-12-16 16:58 ` Richard Purdie
2024-12-20 17:39 ` Joshua Watt
2024-12-25 15:29 ` Alexander Kanavin
2024-12-25 15:33 ` Joshua Watt
2024-12-27 18:12 ` Joshua Watt
2024-12-27 18:44 ` Alexander Kanavin
2024-12-27 19:47 ` Joshua Watt
2024-11-18 16:33 ` [OE-core] [PATCH v3 1/3] patchtest: use HEAD commit as base for the selftest and not master Trevor Gamblin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4254d23ae9ad100e70f199fa4949ce00bfe7063c.camel@linuxfoundation.org \
--to=richard.purdie@linuxfoundation.org \
--cc=alex.kanavin@gmail.com \
--cc=alex@linutronix.de \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox