Date: Mon, 30 May 2022 14:02:31 -0600 From: Warner Losh <imp@bsdimp.com> To: Devin Teske <dteske@freebsd.org> Cc: "Alfonso S. Siciliano" <alfix86@gmail.com>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: bsdinstall TUI utility Message-ID: <CANCZdfqw_-KFsEAT9J7f_FZEQ0z5Ya5o7pnV=w1e%2BfSWeuZBLw@mail.gmail.com> In-Reply-To: <D6B5E127-4D36-41AF-AC17-EF2EED902C16@freebsd.org> References: <7a4a099f-213b-b055-4c67-c4b89f7744fe@gmail.com> <6D8C34A7-3219-4562-BA10-E6A96355A237@freebsd.org> <017a6c90-ea52-40e2-fb7b-d2d7ee1a86de@gmail.com> <B401CCCA-BD44-4644-B98D-462060C34ABB@freebsd.org> <CANCZdfqtoJMJBk36QfCmyoFemx2dSvpgZxEjsk1nsQuPFyxn-Q@mail.gmail.com> <D6B5E127-4D36-41AF-AC17-EF2EED902C16@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000008c82a105e040231d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, May 30, 2022 at 11:40 AM Devin Teske <dteske@freebsd.org> wrote: > > > On May 30, 2022, at 9:18 AM, Warner Losh <imp@bsdimp.com> wrote: > > > > On Mon, May 30, 2022, 9:59 AM Devin Teske <dteske@freebsd.org> wrote: > >> >> >> > 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 wit= h >> > 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 wa= y >> > to handle: $DIALOG, $USE_DIALOG, and `dialog` in last 4 scripts becaus= e >> > 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=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. >> >> >> >> > >> > On 5/29/22 01:02, Devin Teske wrote: >> > > >> > > >> > >> On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano <alfix86@gmail.co= m> >> 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 som= e >> > >> "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/bsdcon= fig >> < >> https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdcon= fig >> > >> > > >> > > There is also work to resolve the namespace issues in bsdinstall >> > > >> > > >> https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bs= dconfig >> < >> https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bs= dconfig >> > >> > > >> > > I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support where i= t >> exists until those efforts can be completed. >> > > >> > > ASIDE: bsdinstall doesn=E2=80=99t 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. >> > > Any chance we could unify the efforts? > > 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, an= d >> 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 on= ly just >> returned to the office last week and had been entirely remote for over 2= 4 >> 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 t= he >> fridge is freshly stocked with the same exact foods that were in the fri= dge >> the day we closed the office; it=E2=80=99s Twilight Zone levels of freak= y). >> >> >> > 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 >> > >> > ... >> > >> > EXTRA_DISTS=3D$( eval dialog \ >> > --backtitle \"$OSNAME Installer\" \ >> > >> > ``` >> > >> > Please note, I have not a strong opinion, if you confirm your needs fo= r >> > $DIALOG, Xdialog, USE_GNU_DIALOG, switch USE_DIALOG, etc. in bsdinstal= l >> > 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 issue= s: >> >> 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 b= e >> 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 throu= gh >> 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 tex= t >> > > 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 determin= e 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 l= ess >> work to just allow bsdconfig to likely treat bsddialog as it is dialog a= nd >> 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-tur= n >> 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 o= wn >> 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=3D50e244964e9b06528b84720e09da7b= df8cec6d32 >> > >> >> 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=3D4d1ba6febfa7c7808027fd1ef60b3b= ffadd17853 >> > 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 differe= nt >> > 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 LGP= L >> 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 tre= e >> with the LGPL handling code and make changes blindly which will only bec= ome >> more and more difficult as the old code without bsddialog support and ne= w >> code (as you propose) without LGPL handling code drift further and furth= er >> apart. >> >> I don=E2=80=99t understand what is so difficult about separating the tas= k of >> =E2=80=9Cadding support=E2=80=9D and =E2=80=9Cremoving deprecated featur= es=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 o= n >> > BSD licensed code. >> >> Cool! >> >> >> >> > The complete unicode support is a TODO, although bsddialog provides so= me >> > feature already https://bugs.freebsd.org/248968 >> > >> >> Interesting. Will have a look. >> >> >> > This is probably another misunderstanding. My goal, after some email a= nd >> > chat with others, is to provide a BSD licensed alternative to dialog >> > for the "BASE needs"; similar not equal, otherwise the effort would no= t >> > be feasible for a single. >> > Indeed, also the command lines are quite different. Example >> > >> https://cgit.freebsd.org/src/commit/?id=3D6833ac673d98275ef72a8873372714= 011c73eb15 >> > >> >> Well, let=E2=80=99s *add* support (leaving LGPL dialog code in-place for >> transitional period, to come back later and remove old, obsolete/depreca= ted >> 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=E2=80=99t need notification as a principled author/maintainer. >> > > I've found that having a herald rule in phabricator facilitates this. Whi= le > you are listed in the MAINTAINERs file, it's use has been falling out > of fashion in the years since we've adopted phabricator. Also, you've > been kinda AWOL for the last couple of years with activity trailing off > in the 2018 or 2019 time frame, so it's an understandable, though now > corrected, oversight. 3 or 4 years is a long time in 'project time' to be > away > from the caretaking of things. > > > I was not AWOL. I was (and am) working on my roadmaps. > I meant was that there aren't many commits in the last 3-4 years for bsdinstall that were authored by you, but there were a large number authored by others. It was a way of explaining why people might have thought the entry in MAINTAINERS was stale. It was a poor choice of words, and implied much more than I'd intended. It was a sloppy shortcut in expressing this. I'm sorry. Bsdconfig is over 30,000 lines of code. It wasn=E2=80=99t written in a day. > > I have 5 large projects I am working on: > > 1. Bsdinstall namespace > 2. Bsdconfig zenity > 3. libfigput > 4. Sysconf > 5. cmb > > I am working on them in GitHub instead of an f.o branch because I have > never been shown how. > Great! That's the new model. It's easier for the project to setup, but it makes it harder for people to see progress on. there's not been a lot about these things on the mailing lists, but they all sound interesting. Regardless, consider this my notification to be added to add future reviews= . >> > > You'll find you are happier if you add the herald rule yourself. It's a > bit hidden, > but if you go to reviews.freebsd.org and click on the "More Applications" > button > on the left you'll be able to scroll down to find Herald. It makes it so > people > don't have to remember, and you'll see everything relevant to the path of > the > tree that you register. Obviously people should remember, but this will > also > catch new people that are interested in contributing that haven't seen > this thread. > > > Thanks. Didn=E2=80=99t know MAINTAINERS was on the way out. Will look int= o Herald > Sure thing. It's quite helpful. Warner > > > I am available again for review =E2=80=94 though with a child, it may tak= e some >> days before I can respond, since I am new to being a parent. >> > > Good luck with your child. They are a joy, but can also take up a lot of > time. > One of the hardest lessons I learned when I had my child was that sometim= es > you don't have enough time to influence things as much as you'd have done > before the child and that things in the project will continue to happen > nonetheless. > The shared nature of FreeBSD allows for these transitions, and the passin= g > of > code from hand to hand sometimes since there are no 'hard locks' anymore. > > > Thanks. > > I have a non-working spouse, so theoretically only part of what you said > applies. > --0000000000008c82a105e040231d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">= <div dir=3D"ltr" class=3D"gmail_attr">On Mon, May 30, 2022 at 11:40 AM Devi= n Teske <<a href=3D"mailto:dteske@freebsd.org" target=3D"_blank">dteske@= freebsd.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style= =3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding= -left:1ex"><div><br><div><br><blockquote type=3D"cite"><div>On May 30, 2022= , at 9:18 AM, Warner Losh <<a href=3D"mailto:imp@bsdimp.com" target=3D"_= blank">imp@bsdimp.com</a>> wrote:</div><br><div><div dir=3D"ltr"><div di= r=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" class= =3D"gmail_attr">On Mon, May 30, 2022, 9:59 AM Devin Teske <<a href=3D"ma= ilto:dteske@freebsd.org" target=3D"_blank">dteske@freebsd.org</a>> wrote= :<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.= 8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> <br> > On May 29, 2022, at 9:01 AM, Alfonso S. Siciliano <<a href=3D"mailt= o:alfix86@gmail.com" rel=3D"noreferrer" target=3D"_blank">alfix86@gmail.com= </a>> wrote:<br> > <br> > Obviously, I made some mistake writing in English.<br> > <br> <br> No, your English is fine. Perhaps I did not explain myself well.<br> <br> <br> <br> > <br> > Currently, I am working to replace dialog(1) and dialog(3) in BASE wit= h<br> > a BSD licensed alternative <<a href=3D"https://wiki.freebsd.org/GPL= inBase" rel=3D"noreferrer noreferrer" target=3D"_blank">https://wiki.freebs= d.org/GPLinBase</a>>.<br> > I have almost completed the task<br> > <<a href=3D"https://wiki.freebsd.org/RoadmapFromDialogToBSDDialog" = rel=3D"noreferrer noreferrer" target=3D"_blank">https://wiki.freebsd.org/Ro= admapFromDialogToBSDDialog</a>>.<br> <br> Well understood.<br> <br> I have been observing the work.<br> <br> <br> > luckily somebody helped me, I will thank at the end.<br> > <br> > <br> > The topic of the email is not bsdconfig.<br> <br> Also understood.<br> <br> <br> <br> <br> > It has already a review,<br> <br> Link?<br> <br> <br> <br> > it preserves the $DIALOG variable to handle a multitude of front-end:<= br> > bsddialog for the needs in BASE, dialog, Zenity, Xdialog, and so on.<b= r> <br> Good.<br> <br> <br> <br> > I would continue the discussion for bsdconfig in phabricator;<br> > although I should update it after some recent commit.<br> > <<a href=3D"https://reviews.freebsd.org/D34755" rel=3D"noreferrer n= oreferrer" target=3D"_blank">https://reviews.freebsd.org/D34755</a>>.<br= > > <br> <br> I have commented that I request time to review.<br> <br> <br> <br> > <br> > The topic of this email is bsdinstall.<br> <br> Correct.<br> <br> <br> <br> > I have to update the last few<br> > scripts to delete LGPL-dialog from BASE. Properly I asked the right wa= y<br> > to handle: $DIALOG, $USE_DIALOG, and `dialog` in last 4 scripts becaus= e<br> > the others used only and called directly `dialog` without any<br> > bsdconfig's help.<br> > <br> <br> When you look at the bsdinstall code and you see that it calls dialog witho= ut bsdconfig=E2=80=99s help, that is because I have not written the code ye= t. When I am done with bsdinstall, it will use bsdconfig=E2=80=99s API (see= =E2=80=9Cbsdconfig api=E2=80=9D)<br> <br> So removing it will only see it added again later.<br> <br> <br> <br> > <br> > On 5/29/22 01:02, Devin Teske wrote:<br> > ><br> > ><br> > >> On May 28, 2022, at 2:59 PM, Alfonso S. Siciliano <<a href= =3D"mailto:alfix86@gmail.com" rel=3D"noreferrer" target=3D"_blank">alfix86@= gmail.com</a>> wrote:<br> > >><br> > >> Hello,<br> > >><br> > >><br> > >> So far I replaced and adapted `dialog` with `bsddialog` in<br= > > >> bsdinstall/scripts.<br> > >> <<a href=3D"https://wiki.freebsd.org/RoadmapFromDialogToBS= DDialog" rel=3D"noreferrer noreferrer" target=3D"_blank">https://wiki.freeb= sd.org/RoadmapFromDialogToBSDDialog</a>><br> > >><br> > >><br> > >> Currently, I am addressing the last 4 scripts: auto, bootconf= ig, keymap,<br> > >> and wlanconfig. These scripts use also the $DIALOG variable a= nd some<br> > >> "if" to handle Xdialog(1).<br> > >> For example 'auto' uses $DIALOG, $USE_XDIALOG, and `d= ialog`.<br> > >><br> > ><br> > > Can we simply add USE_GNU_DIALOG and switch USE_DIALOG to mean bs= ddialog?<br> > ><br> > <br> > OK.<br> > <br> > ><br> > >> * $DIALOG: I seem bsdinstall(8) uses only dialog(1) as TUI ut= ility.<br> > ><br> > > bsdinstall(8) uses only dialog(1) in the context of $DIALOG<br> > <br> > <br> > Exactly 1.<br> > <br> > <br> > ><br> > > ASIDE: It also uses dialog(3) and dpv(3)/dpv(1)<br> > ><br> > ><br> > >> * I seem bsdconfig(8) does not "call" these 4 scrip= ts, so, probably,<br> > >>=C2=A0 =C2=A0Xdialog(1) is not used in this context (that is `= bsdconfig -X`).<br> > >><br> > ><br> > > Correct, bsdconfig does use bsdinstall<br> > ><br> > <br> > <br> > Exactly 2.<br> > <br> > <br> > ><br> > >> Is there any objection to delete $DIALOG/LGPL-dialog/Xdialog = to<br> > >> provide only the support for bsddialog(1) in bsdinstall(8)?<b= r> > >><br> > ><br> > > I object.<br> > ><br> > > I and another developer are adding support for zenity<br> > ><br> > > <a href=3D"https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/ze= nity/depend/bsdconfig" rel=3D"noreferrer noreferrer" target=3D"_blank">http= s://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconfig</a>= <<a href=3D"https://github.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/= depend/bsdconfig" rel=3D"noreferrer noreferrer" target=3D"_blank">https://g= ithub.com/FrauBSD/pkgcenter/tree/bsdconfig/zenity/depend/bsdconfig</a>><= br> > ><br> > > There is also work to resolve the namespace issues in bsdinstall<= br> > ><br> > > <a href=3D"https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/n= amespace/depend/bsdconfig" rel=3D"noreferrer noreferrer" target=3D"_blank">= https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bsdco= nfig</a> <<a href=3D"https://github.com/FrauBSD/pkgcenter/tree/bsdinstal= l/namespace/depend/bsdconfig" rel=3D"noreferrer noreferrer" target=3D"_blan= k">https://github.com/FrauBSD/pkgcenter/tree/bsdinstall/namespace/depend/bs= dconfig</a>><br> > ><br> > > I am in favor of keeping $DIALOG/LGPL-dialog/Xdialog support wher= e it exists until those efforts can be completed.<br> > ><br> > > ASIDE: bsdinstall doesn=E2=80=99t use Xdialog<br> > <br> > <br> > Exactly 3.<br> > <br> > <br> > Anyway, probably the misunderstanding is at this point. My question is= <br> > not for bsdconfig but for 4 scripts in bsdinstall.<br> <br> No, the confusion is that I have my own roadmap that includes fixing namesp= ace issues in bsdinstall before then merging bsdinstall with bsdconfig so t= hat they use a single API.<br></blockquote></div></div><div dir=3D"auto"><b= r></div><div dir=3D"auto">Any chance we could unify the efforts?</div><div = dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote"><blockq= uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p= x solid rgb(204,204,204);padding-left:1ex"> 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 the= n 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 f= ridge the day we closed the office; it=E2=80=99s Twilight Zone levels of fr= eaky).<br> <br> <br> > Let' s say: "should bsdinstall/scripts/auto have the code to = handle<br> > $DIALOG/LGPL-dialog/Xdialog"<br> > ```<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0if [ "$USE_XDIALOG" ]; then<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yes=3Dok no=3Dca= ncel defaultno=3Ddefault-no<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0extra_args=3D&qu= ot;--wrap --left"<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"$= passed_msg"<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0else<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yes=3Dyes no=3Dn= o defaultno=3Ddefaultno<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0extra_args=3D&qu= ot;--cr-wrap"<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0format=3D"$= passed_msg"<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0fi<br> > <br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0...<br> > <br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0EXTRA_DISTS=3D$( eval dialog \<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--= backtitle \"$OSNAME Installer\" \<br> > <br> > ```<br> > <br> > Please note, I have not a strong opinion, if you confirm your needs fo= r<br> > $DIALOG, Xdialog, USE_GNU_DIALOG, switch USE_DIALOG, etc. in bsdinstal= l<br> > I'll add and preserve these features in the 4 scripts.<br> > Please let me know, so I can complete the dialog/bsddialog replacement= <br> > soon.<br> > <br> <br> My answer is YES, the code could continue to handle that for three very sim= ple reasons:<br> <br> 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:<br> <br> 1.a. Reaching parity<br> <br> 1.b. Removing deprecated code<br> <br> 2. Removing old while adding new means if there is ever a discrepancy:<br> <br> 2.a. I have to go to git to see how old code worked<br> <br> 2.b. I have to install old code to run it (opposed to installing old dialog= and=C2=A0 setting some environment variables)<br> <br> 3. Making fixes to correct an unintended consequence may introduce issues:<= br> <br> 3.a. When I cannot run the head (as described in 2 above) code with old dia= log<br> <br> 3.b. =E2=80=A6 as I have to run two codeines and merge between the two<br> <br> 3.c. =E2=80=A6 and there will be a time in the future when this should be e= xpected to break and that should trigger removal, but not before completing= the transitional period on a roadmap to reach parity<br> <br> <br> <br> > <br> > ><br> > ><br> > >> I would prefer this solution because I can avoid: to handle s= ome<br> > >> dialog/Xdialog/bsddialog command line difference and to hook = some<br> > >> bsdconfig function built on dialog(1) incompatible with bsddi= alog(1)<br> > >> (for example autosizing, implemented in bsddialog(3) already)= .<br> > >><br> > ><br> > > The differences in command line should be handled through conditi= onals, but can be the default and opt to handle LGPL-dialog through a USE_G= NU_DIALOG flag<br> > ><br> > > bsddialog may support auto-sizing, but so does dialog and Xdialog= .<br> > ><br> > > However, ...<br> > ><br> > > The sizing code in bsdconfig (used indirectly by bsdinstall) was = written because the auto-sizing that does exist and is available in both di= alog 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 dial= ogs.<br> > ><br> > > The sizing code makes sure that regardless of which utility you a= re using that the experience is uniform in what is presented to the user.<b= r> > ><br> > > Attempting to rely solely on the auto-sizing available from these= separate utilities (including bsddialog) would change the UI/UX.<br> > ><br> > > The problem was solved by:<br> > ><br> > > 1. Making the stored text used for dialogs dictate how it will lo= ok<br> > > 2. Painstakingly determining where each utility failed given the = text<br> > > 3. Determining how to make the utility display the text properly<= br> > ><br> > > For example, stored text will contain newlines instead of attempt= ing to rely on line wrapping on a box of given size.<br> > ><br> > > I would have to evaluate bsddialog=E2=80=99s auto-sizing to deter= mine 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 les= s work to just allow bsdconfig to likely treat bsddialog as it is dialog an= d let it perform the size calculations for you.<br> > ><br> > > If bsddialog is top be a drop-in replacement, I=E2=80=99m more th= an a little surprised that it cannot accept the sizes calculated for dialog= being passed to it.<br> > ><br> > ><br> > >><br> > >> Please note these considerations are only for bsdinstall, bsd= config is<br> > >> unchanged.<br> > >><br> > ><br> > > What of dpv? bsdinstall uses dpv(3) to unpack the dists which in-= turn relies on dlg_gauge_reallocate(3) from LGPL-dialog?<br> > <br> > <br> > <br> > I seem these considerations are for bsdconfig so the discussion can<br= > > continue in phabricator. Of course I made some error in English in the= <br> > first email.<br> <br> 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 an= d timelines.<br> <br> <br> <br> > <br> > Here the topic is bsdinstall.<br> > <br> > bsdinstall(8) in CURRENT did not use LGPL-dialog(3) since months,<br> > all the components (written in C) were adapted or rewritten to<br> > use bsddialog(3). Example<br> > <a href=3D"https://cgit.freebsd.org/src/commit/?id=3D50e244964e9b06528= b84720e09da7bdf8cec6d32" rel=3D"noreferrer noreferrer" target=3D"_blank">ht= tps://cgit.freebsd.org/src/commit/?id=3D50e244964e9b06528b84720e09da7bdf8ce= c6d32</a><br> > <br> <br> I will review and get back with comment.<br> <br> <br> > Most bsdinstall scripts "call" just `dialog` using its autos= izing<br> > (without any bsdconfig's=C2=A0 help).<br> > So far I replaced `dialog 0 0` with `bsddialog 0 0`. Example<br> > <a href=3D"https://cgit.freebsd.org/src/commit/?id=3D4d1ba6febfa7c7808= 027fd1ef60b3bffadd17853" rel=3D"noreferrer noreferrer" target=3D"_blank">ht= tps://cgit.freebsd.org/src/commit/?id=3D4d1ba6febfa7c7808027fd1ef60b3bffadd= 17853</a><br> > The important question was asked above. I would want to understand the= <br> > right way to handle $DIALOG/Xdialog/`dialog` in the last 4 bsdinstall<= br> > scripts.<br> > <br> <br> Correct. It is part of my roadmap to remove said auto-sizing in bsdinstall.= <br> <br> <br> <br> > I had some problem using the autosizing functions of bsdconfig for<br> > bsddialog,<br> <br> I do not fully understand this. The API examines the text and determines th= e proper size to pass. Can bsddialog not accept a size?<br> <br> <br> <br> <br> > probably bacause dialog(3) and bsddialog(3) implement<br> > different auto text wrapping algorithms, or the utilities have differe= nt<br> > command lines.<br> <br> Does bsddialog have support for specifying the size of a widget?<br> <br> <br> <br> <br> > Honestly I am not interested in investigating,<br> <br> That is an unfortunate statement. I am interested in the work being done, p= erhaps you could be interested in the work I am doing that I have been work= ing on for longer than you have been working on bsddialog.<br> <br> <br> <br> > I would<br> > like to improve bsddialog instead of wasting time on a LGPL software<b= r> > almost ready to leave the BASE.<br> <br> Leaving existing code in place does not waste time on LGPL software because= :<br> <br> 1. Someone like myself will be installing LGPL dialog from ports and relyin= g on the old code to utilize it:<br> <br> 1.a. expressly so I can flip bsdinstall/bsdconfig back and forth (using env= ironment variables) between LGPL dialog and bsdialog<br> <br> 1.b. so that I can compare the two against each other and fix any regressio= ns<br> <br> Removing the code to handle LGPL dialog at the same time as removing LGPL d= ialog 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= .<br> <br> I don=E2=80=99t understand what is so difficult about separating the task o= f =E2=80=9Cadding support=E2=80=9D and =E2=80=9Cremoving deprecated feature= s=E2=80=9D to accommodate a transitional period is so difficult =E2=80=94 i= t 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.<br> <br> <br> <br> > For dpv(3) in distfetch.c, I implemented an "improved mixedgauge&= quot; in<br> > bsddialog(3) with colors, a callback and bottom info" depending o= nly on<br> > BSD licensed code.<br> <br> Cool!<br> <br> <br> <br> > The complete unicode support is a TODO, although bsddialog provides so= me<br> > feature already <a href=3D"https://bugs.freebsd.org/248968" rel=3D"nor= eferrer noreferrer" target=3D"_blank">https://bugs.freebsd.org/248968</a><b= r> > <br> <br> Interesting. Will have a look.<br> <br> <br> > This is probably another misunderstanding. My goal, after some email a= nd<br> > chat with others, is to provide a BSD licensed alternative to dialog<b= r> > for the "BASE needs"; similar not equal, otherwise the effor= t would not<br> > be feasible for a single.<br> > Indeed, also the command lines are quite different. Example<br> > <a href=3D"https://cgit.freebsd.org/src/commit/?id=3D6833ac673d98275ef= 72a8873372714011c73eb15" rel=3D"noreferrer noreferrer" target=3D"_blank">ht= tps://cgit.freebsd.org/src/commit/?id=3D6833ac673d98275ef72a8873372714011c7= 3eb15</a><br> > <br> <br> Well, let=E2=80=99s *add* support (leaving LGPL dialog code in-place for tr= ansitional period, to come back later and remove old, obsolete/deprecated c= ode referring to LGPL dialog).<br> <br> <br> <br> > So far the replacement process was in phabricator with author(s),<br> > maintainer(s) and 2/3 members of the core team. Anyone interested can<= br> > notify me to be added in future reviews.<br> > <br> <br> I shouldn=E2=80=99t need notification as a principled author/maintainer.<br= ></blockquote></div></div><div dir=3D"auto"><br></div><div>I've found t= hat having a herald rule in phabricator facilitates this. While</div><div>y= ou are listed in the MAINTAINERs file, it's use has been falling out</d= iv><div>of fashion in the years since we've adopted phabricator. Also, = you've</div><div>been kinda AWOL for the last couple of years with acti= vity trailing off</div><div>in the 2018 or 2019 time frame, so it's an = understandable, though now</div><div>corrected, oversight. 3 or 4 years is = a long time in 'project time' to be away</div><div>from the caretak= ing of things.</div></div></div></div></blockquote><div><br></div><div>I wa= s not AWOL. I was (and am) working on my roadmaps.</div></div></div></block= quote><div><br></div><div>I meant was that there aren't many commits in= the last 3-4 years for bsdinstall<br></div><div>that were authored by you,= =C2=A0but there were a large number authored by others. It</div><div>was a = way of explaining why people might have thought the entry in MAINTAINERS</d= iv><div>was stale. It was a poor choice of words, and implied much more tha= n I'd intended.</div><div>It was=C2=A0a sloppy=C2=A0shortcut in express= ing this. I'm sorry.</div><div><br></div><blockquote class=3D"gmail_quo= te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204= );padding-left:1ex"><div><div><div>Bsdconfig is over 30,000 lines of code. = It wasn=E2=80=99t written in a day.</div><div><br></div><div>I have 5 large= projects I am working on:</div><div><br></div><div>1. Bsdinstall namespace= </div><div>2. Bsdconfig zenity</div><div>3. libfigput</div><div>4. Sysconf<= /div><div>5. cmb</div><div><br></div><div>I am working on them in GitHub in= stead of an f.o branch because I have never been shown how.</div></div></di= v></blockquote><div><br></div><div>Great! That's the new model. It'= s easier for the project to setup, but it makes</div><div>it harder for peo= ple to see progress on. there's not been a lot about these things</div>= <div>on the mailing lists, but they all sound interesting.</div><div><br></= div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= der-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type= =3D"cite"><div><div dir=3D"ltr"><div dir=3D"auto"><div dir=3D"auto"><div cl= ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0= px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Regar= dless, consider this my notification to be added to add future reviews.<br>= </blockquote><div><br></div><div>You'll find you are happier if you add= the herald rule yourself. It's a bit hidden,</div><div>but if you go t= o <a href=3D"http://reviews.freebsd.org/" target=3D"_blank">reviews.freebsd= .org</a> and click on the "More Applications" button</div><div>on= the left you'll be able to scroll down to find Herald. It makes it so = people</div><div>don't have to remember, and you'll see everything = relevant to the path of the</div><div>tree that you register. Obviously peo= ple should remember, but this will also</div><div>catch new people that are= interested in contributing that haven't seen this thread.</div></div><= /div></div></div></div></blockquote><div><br></div><div>Thanks. Didn=E2=80= =99t know MAINTAINERS was on the way out. Will look into Herald</div></div>= </blockquote><div><br></div><div>Sure thing. It's quite helpful.</div><= div><br></div><div>Warner</div><div>=C2=A0</div><blockquote class=3D"gmail_= quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,= 204);padding-left:1ex"><div><div>=C2=A0</div><blockquote type=3D"cite"><div= dir=3D"ltr"><div dir=3D"auto"><div dir=3D"auto"><div class=3D"gmail_quote"= ><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border= -left:1px solid rgb(204,204,204);padding-left:1ex"> 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.<br></bloc= kquote><div><br></div><div>Good luck with your child. They are a joy, but c= an also take up a lot of time.</div><div>One of the hardest lessons=C2=A0I = learned when I had my child was that sometimes</div><div>you don't have= enough time to influence things as much as you'd have done</div><div>b= efore the child and that things in the project will continue to happen none= theless.</div><div>The shared nature of FreeBSD allows for these transition= s, and the passing of</div><div>code from hand to hand sometimes since ther= e are no 'hard locks' anymore.</div><div><br></div></div></div></di= v></div></blockquote><div><br></div><div>Thanks.</div><div><br></div><div>I= have a non-working spouse, so theoretically only part of what you said app= lies.</div></div></blockquote></div></div> --0000000000008c82a105e040231d--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqw_-KFsEAT9J7f_FZEQ0z5Ya5o7pnV=w1e%2BfSWeuZBLw>