Re: bsdinstall TUI utility

> On May 29, 2022, at 9:01 AM, Alfonso S. Siciliano <alfix86@gmail.com> wrote:
> 
> Obviously, I made some mistake writing in English.
> 

No, your English is fine. Perhaps I did not explain myself well.



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

I have commented that I request time to review.



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

When you look at the bsdinstall code and you see that it calls dialog without bsdconfig’s help, that is because I have not written the code yet. When I am done with bsdinstall, it will use bsdconfig’s API (see “bsdconfig api”)

So removing it will only see it added again later.



> 
> 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?
> >
> 
> OK.
> 
> >
> >> * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI utility.
> >
> > bsdinstall(8) uses only dialog(1) in the context of $DIALOG
> 
> 
> Exactly 1.
> 
> 
> >
> > 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
> >
> 
> 
> Exactly 2.
> 
> 
> >
> >> 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/bsdconfig <https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconfig>
> >
> > There is also work to resolve the namespace issues in bsdinstall
> >
> > https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsdconfig <https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsdconfig>
> >
> > I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support where it exists until those efforts can be completed.
> >
> > ASIDE: bsdinstall doesn’t use Xdialog
> 
> 
> Exactly 3.
> 
> 
> 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’s been a very busy couple of years, pandemic aside — 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’s 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=ok no=cancel defaultno=default-no
> 		extra_args="--wrap --left"
> 		format="$passed_msg"
> 	else
> 		yes=yes no=no defaultno=defaultno
> 		extra_args="--cr-wrap"
> 		format="$passed_msg"
> 	fi
> 
> 	...
> 
> 	EXTRA_DISTS=$( eval dialog \
> 		    --backtitle \"$OSNAME Installer\" \
> 
> ```
> 
> 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.
> 

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. … as I have to run two codeines and merge between the two

3.c. … 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



> 
> >
> >
> >> 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’s 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’m 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?
> 
> 
> 
> 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.



> 
> Here the topic is bsdinstall.
> 
> 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=50e244964e9b06528b84720e09da7bdf8cec6d32
> 

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=4d1ba6febfa7c7808027fd1ef60b3bffadd17853
> 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.
> 

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’t understand what is so difficult about separating the task of “adding support” and “removing deprecated features” to accommodate a transitional period is so difficult — it makes reaching feature parity (which is in bsddialog’s 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
> 

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=6833ac673d98275ef72a8873372714011c73eb15
> 

Well, let’s *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.
> 

I shouldn’t 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 — though with a child, it may take some days before I can respond, since I am new to being a parent.
— 
Devin