From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2C4BEC5DF97 for ; Wed, 26 Aug 2026 15:16:00 +0000 (UTC) Subject: Re: [PATCH] knotty: show elapsed time on the task progress bar To: bitbake-devel@lists.openembedded.org From: "WXbet" X-Originating-Location: Falkenstein, Saxony, DE (49.12.78.234) X-Originating-Platform: Windows Edge 151 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Wed, 26 Aug 2026 08:15:56 -0700 References: <20260819093321.3451-1-wxbet.oe@gmail.com> In-Reply-To: Message-ID: <2789044.1787757356219607465@lists.openembedded.org> Content-Type: multipart/alternative; boundary="rLtsf1AvrCFnz7nufPB2" List-Id: X-Webhook-Received: from 45-33-107-173.ip.linodeusercontent.com [45.33.107.173] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Wed, 26 Aug 2026 15:16:00 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/bitbake-devel/message/20059 --rLtsf1AvrCFnz7nufPB2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 26, 2026 at 04:41 PM, Peter Kjellerstedt wrote: >=20 > On the other hand, the progress bars that are shown during the initial > phase before the build tasks starts all use Progressbar's own Timer > widget. I think it makes more sense to just use progressbar.Timer() > rather than BBTimer(). The formatting is deliberate. The running-task lines right below the bar pr= int their time through TerminalFilter.elapsed() , e.g. 16m34s. With progres= sbar.Timer the bar reads 0:16:34 , so the same screen would show two differ= ent time formats. The parsing-phase bars are gone by the time the task bar = appears, so they never compete with it. Timer.format_time is a staticmethod and Timer defines __slots__ , so it can= not be replaced per instance, hence the small subclass. If you prefer consistency with progressbar's own format, this one-liner doe= s it instead and I am happy to send it as v2: -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 widgets =3D [' ', = progressbar.Percentage(), ' ', progressbar.Bar()] + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0widgets =3D [' ', = progressbar.Percentage(), ' ', progressbar.Bar(), ' ', progressbar.Timer(fo= rmat=3D'Elapsed: %s')] --rLtsf1AvrCFnz7nufPB2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 26, 2026 at 04:41 PM, Peter Kjellerstedt wrote:
On the other hand, the progress bars that are shown during the = initial
phase before the build tasks starts all use Progressbar's own= Timer
widget. I think it makes more sense to just use progressbar.Ti= mer()
rather than BBTimer().

The formatting is deliberate. The running-task lines right b= elow the bar print their time through TerminalFilter.elapsed()= , e.g. 16m34s. With progressbar.Timer the bar rea= ds 0:16:34, so the same screen would show two different time f= ormats. The parsing-phase bars are gone by the time the task bar appears, s= o they never compete with it.

Timer.format_time is a staticmethod and T= imer defines __slots__, so it cannot be replaced per in= stance, hence the small subclass.

If you prefer consistency with progressbar's own format, thi= s one-liner does it instead and I am happy to send it as v2:

-              &nbs= p; widgets =3D [' ', progressbar.Percentage(), ' ', progressbar.Bar()]
+                widgets =3D [' ',= progressbar.Percentage(), ' ', progressbar.Bar(), ' ', progressbar.Timer(f= ormat=3D'Elapsed: %s')]

--rLtsf1AvrCFnz7nufPB2--