Date: Mon, 30 May 2022 08:58:41 -0700 From: Devin Teske <dteske@freebsd.org> To: "Alfonso S. Siciliano" <alfix86@gmail.com> Cc: freebsd-arch@freebsd.org, dteske@freebsd.org Subject: Re: bsdinstall TUI utility Message-ID: <B401CCCA-BD44-4644-B98D-462060C34ABB@freebsd.org> In-Reply-To: <017a6c90-ea52-40e2-fb7b-d2d7ee1a86de@gmail.com> References: <7a4a099f-213b-b055-4c67-c4b89f7744fe@gmail.com> <6D8C34A7-3219-4562-BA10-E6A96355A237@freebsd.org> <017a6c90-ea52-40e2-fb7b-d2d7ee1a86de@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On May 29, 2022, at 9:01 AM, Alfonso S. Siciliano <alfix86@gmail.com> = wrote: >=20 > Obviously, I made some mistake writing in English. >=20 No, your English is fine. Perhaps I did not explain myself well. >=20 > Currently, I am working to replace dialog(1) and dialog(3) in BASE = with > a BSD licensed alternative <https://wiki.freebsd.org/GPLinBase>. > I have almost completed the task > <https://wiki.freebsd.org/RoadmapFromDialogToBSDDialog>. Well understood. I have been observing the work. > luckily somebody helped me, I will thank at the end. >=20 >=20 > The topic of the email is not bsdconfig. Also understood. > It has already a review, Link? > it preserves the $DIALOG variable to handle a multitude of front-end: > bsddialog for the needs in BASE, dialog, Zenity, Xdialog, and so on. Good. > I would continue the discussion for bsdconfig in phabricator; > although I should update it after some recent commit. > <https://reviews.freebsd.org/D34755>. >=20 I have commented that I request time to review. >=20 > The topic of this email is bsdinstall. Correct. > I have to update the last few > scripts to delete LGPL-dialog from BASE. Properly I asked the right = way > to handle: $DIALOG, $USE_DIALOG, and `dialog` in last 4 scripts = because > the others used only and called directly `dialog` without any > bsdconfig's help. >=20 When you look at the bsdinstall code and you see that it calls dialog = without bsdconfig=E2=80=99s help, that is because I have not written the = code yet. When I am done with bsdinstall, it will use bsdconfig=E2=80=99s = API (see =E2=80=9Cbsdconfig api=E2=80=9D) So removing it will only see it added again later. >=20 > On 5/29/22 01:02, Devin Teske wrote: > > > > > >> On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano = <alfix86@gmail.com> wrote: > >> > >> Hello, > >> > >> > >> So far I replaced and adapted `dialog` with `bsddialog` in > >> bsdinstall/scripts. > >> <https://wiki.freebsd.org/RoadmapFromDialogToBSDDialog>; > >> > >> > >> Currently, I am addressing the last 4 scripts: auto, bootconfig, = keymap, > >> and wlanconfig. These scripts use also the $DIALOG variable and = some > >> "if" to handle Xdialog(1). > >> For example 'auto' uses $DIALOG, $USE_XDIALOG, and `dialog`. > >> > > > > Can we simply add USE_GNU_DIALOG and switch USE_DIALOG to mean = bsddialog? > > >=20 > OK. >=20 > > > >> * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI utility. > > > > bsdinstall(8) uses only dialog(1) in the context of $DIALOG >=20 >=20 > Exactly 1. >=20 >=20 > > > > ASIDE: It also uses dialog(3) and dpv(3)/dpv(1) > > > > > >> * I seem bsdconfig(8) does not "call" these 4 scripts, so, = probably, > >> Xdialog(1) is not used in this context (that is `bsdconfig -X`). > >> > > > > Correct, bsdconfig does use bsdinstall > > >=20 >=20 > Exactly 2. >=20 >=20 > > > >> Is there any objection to delete $DIALOG/LGPL-dialog/Xdialog to > >> provide only the support for bsddialog(1) in bsdinstall(8)? > >> > > > > I object. > > > > I and another developer are adding support for zenity > > > > = https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconfi= g = <https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconf= ig> > > > > There is also work to resolve the namespace issues in bsdinstall > > > > = https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsdc= onfig = <https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsd= config> > > > > I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support where = it exists until those efforts can be completed. > > > > ASIDE: bsdinstall doesn=E2=80=99t use Xdialog >=20 >=20 > Exactly 3. >=20 >=20 > Anyway, probably the misunderstanding is at this point. My question is > not for bsdconfig but for 4 scripts in bsdinstall. No, the confusion is that I have my own roadmap that includes fixing = namespace issues in bsdinstall before then merging bsdinstall with = bsdconfig so that they use a single API. As the code I previously linked to in GitHub demonstrates, I was working = on it in 2020 last, and then the pandemic hit and then I had a child, = and then two root canals, and then some issues due to a data breech, so = it=E2=80=99s been a very busy couple of years, pandemic aside =E2=80=94 = at work we only just returned to the office last week and had been = entirely remote for over 24 months (and to be honest, it is a little = strange to come back into the office and find *everything* exactly as it = was, even to the point that the fridge is freshly stocked with the same = exact foods that were in the fridge the day we closed the office; it=E2=80= =99s Twilight Zone levels of freaky). > Let' s say: "should bsdinstall/scripts/auto have the code to handle > $DIALOG/LGPL-dialog/Xdialog" > ``` > if [ "$USE_XDIALOG" ]; then > yes=3Dok no=3Dcancel defaultno=3Ddefault-no > extra_args=3D"--wrap --left" > format=3D"$passed_msg" > else > yes=3Dyes no=3Dno defaultno=3Ddefaultno > extra_args=3D"--cr-wrap" > format=3D"$passed_msg" > fi >=20 > ... >=20 > EXTRA_DISTS=3D$( eval dialog \ > --backtitle \"$OSNAME Installer\" \ >=20 > ``` >=20 > Please note, I have not a strong opinion, if you confirm your needs = for > $DIALOG, Xdialog, USE_GNU_DIALOG, switch USE_DIALOG, etc. in = bsdinstall > I'll add and preserve these features in the 4 scripts. > Please let me know, so I can complete the dialog/bsddialog replacement > soon. >=20 My answer is YES, the code could continue to handle that for three very = simple reasons: 1. The effort of your roadmap is to *introduce* bsdinstall and = introduction of something new is easier when remnants of the past can be = referenced as we work toward the goal of: 1.a. Reaching parity 1.b. Removing deprecated code 2. Removing old while adding new means if there is ever a discrepancy: 2.a. I have to go to git to see how old code worked 2.b. I have to install old code to run it (opposed to installing old = dialog and setting some environment variables) 3. Making fixes to correct an unintended consequence may introduce = issues: 3.a. When I cannot run the head (as described in 2 above) code with old = dialog 3.b. =E2=80=A6 as I have to run two codeines and merge between the two 3.c. =E2=80=A6 and there will be a time in the future when this should = be expected to break and that should trigger removal, but not before = completing the transitional period on a roadmap to reach parity >=20 > > > > > >> I would prefer this solution because I can avoid: to handle some > >> dialog/Xdialog/bsddialog command line difference and to hook some > >> bsdconfig function built on dialog(1) incompatible with = bsddialog(1) > >> (for example autosizing, implemented in bsddialog(3) already). > >> > > > > The differences in command line should be handled through = conditionals, but can be the default and opt to handle LGPL-dialog = through a USE_GNU_DIALOG flag > > > > bsddialog may support auto-sizing, but so does dialog and Xdialog. > > > > However, ... > > > > The sizing code in bsdconfig (used indirectly by bsdinstall) was = written because the auto-sizing that does exist and is available in both = dialog and Xdialog (as well as Zenity) does not provide a cohesive = experience when trying to write a program that is in-reality a series of = bespoke dialogs. > > > > The sizing code makes sure that regardless of which utility you are = using that the experience is uniform in what is presented to the user. > > > > Attempting to rely solely on the auto-sizing available from these = separate utilities (including bsddialog) would change the UI/UX. > > > > The problem was solved by: > > > > 1. Making the stored text used for dialogs dictate how it will look > > 2. Painstakingly determining where each utility failed given the = text > > 3. Determining how to make the utility display the text properly > > > > For example, stored text will contain newlines instead of attempting = to rely on line wrapping on a box of given size. > > > > I would have to evaluate bsddialog=E2=80=99s auto-sizing to = determine if it is trust-worthy given not only all the stored texts, but = all the translations as well (as bsdconfig is i18n compatible). It is = actually less work to just allow bsdconfig to likely treat bsddialog as = it is dialog and let it perform the size calculations for you. > > > > If bsddialog is top be a drop-in replacement, I=E2=80=99m more than = a little surprised that it cannot accept the sizes calculated for dialog = being passed to it. > > > > > >> > >> Please note these considerations are only for bsdinstall, bsdconfig = is > >> unchanged. > >> > > > > What of dpv? bsdinstall uses dpv(3) to unpack the dists which = in-turn relies on dlg_gauge_reallocate(3) from LGPL-dialog? >=20 >=20 >=20 > I seem these considerations are for bsdconfig so the discussion can > continue in phabricator. Of course I made some error in English in the > first email. No, your English was fine. I perhaps did not explain the we are at = perhaps cross efforts with our distinctly separate roadmaps with their = own goals and timelines. >=20 > Here the topic is bsdinstall. >=20 > bsdinstall(8) in CURRENT did not use LGPL-dialog(3) since months, > all the components (written in C) were adapted or rewritten to > use bsddialog(3). Example > = https://cgit.freebsd.org/src/commit/?id=3D50e244964e9b06528b84720e09da7bdf= 8cec6d32 >=20 I will review and get back with comment. > Most bsdinstall scripts "call" just `dialog` using its autosizing > (without any bsdconfig's help). > So far I replaced `dialog 0 0` with `bsddialog 0 0`. Example > = https://cgit.freebsd.org/src/commit/?id=3D4d1ba6febfa7c7808027fd1ef60b3bff= add17853 > The important question was asked above. I would want to understand the > right way to handle $DIALOG/Xdialog/`dialog` in the last 4 bsdinstall > scripts. >=20 Correct. It is part of my roadmap to remove said auto-sizing in = bsdinstall. > I had some problem using the autosizing functions of bsdconfig for > bsddialog, I do not fully understand this. The API examines the text and determines = the proper size to pass. Can bsddialog not accept a size? > probably bacause dialog(3) and bsddialog(3) implement > different auto text wrapping algorithms, or the utilities have = different > command lines. Does bsddialog have support for specifying the size of a widget? > Honestly I am not interested in investigating, That is an unfortunate statement. I am interested in the work being = done, perhaps you could be interested in the work I am doing that I have = been working on for longer than you have been working on bsddialog. > I would > like to improve bsddialog instead of wasting time on a LGPL software > almost ready to leave the BASE. Leaving existing code in place does not waste time on LGPL software = because: 1. Someone like myself will be installing LGPL dialog from ports and = relying on the old code to utilize it: 1.a. expressly so I can flip bsdinstall/bsdconfig back and forth (using = environment variables) between LGPL dialog and bsdialog 1.b. so that I can compare the two against each other and fix any = regressions Removing the code to handle LGPL dialog at the same time as removing = LGPL dialog from base kind of makes that hard. As previously explained, = that will force me to perform a series of hacks where I pull down the = old tree with the LGPL handling code and make changes blindly which will = only become more and more difficult as the old code without bsddialog = support and new code (as you propose) without LGPL handling code drift = further and further apart. I don=E2=80=99t understand what is so difficult about separating the = task of =E2=80=9Cadding support=E2=80=9D and =E2=80=9Cremoving = deprecated features=E2=80=9D to accommodate a transitional period is so = difficult =E2=80=94 it makes reaching feature parity (which is in = bsddialog=E2=80=99s interest) very difficult if you try and do both of = those things at the same time. > For dpv(3) in distfetch.c, I implemented an "improved mixedgauge" in > bsddialog(3) with colors, a callback and bottom info" depending only = on > BSD licensed code. Cool! > The complete unicode support is a TODO, although bsddialog provides = some > feature already https://bugs.freebsd.org/248968 >=20 Interesting. Will have a look. > This is probably another misunderstanding. My goal, after some email = and > chat with others, is to provide a BSD licensed alternative to dialog > for the "BASE needs"; similar not equal, otherwise the effort would = not > be feasible for a single. > Indeed, also the command lines are quite different. Example > = https://cgit.freebsd.org/src/commit/?id=3D6833ac673d98275ef72a887337271401= 1c73eb15 >=20 Well, let=E2=80=99s *add* support (leaving LGPL dialog code in-place for = transitional period, to come back later and remove old, = obsolete/deprecated code referring to LGPL dialog). > So far the replacement process was in phabricator with author(s), > maintainer(s) and 2/3 members of the core team. Anyone interested can > notify me to be added in future reviews. >=20 I shouldn=E2=80=99t need notification as a principled author/maintainer. Regardless, consider this my notification to be added to add future = reviews. I am available again for review =E2=80=94 though with a child, it may = take some days before I can respond, since I am new to being a parent. =E2=80=94=20 Devin=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B401CCCA-BD44-4644-B98D-462060C34ABB>