Date: Sun, 7 Nov 2010 19:33:48 -0800 From: Randi Harper <randi@freebsd.org> To: Eitan Adler <lists@eitanadler.com> Cc: babt@freebsd.org, Mark Linimon <linimon@lonesome.com>, Doug Barton <dougb@freebsd.org>, pav@freebsd.org, freebsd-sysinstall@freebsd.org Subject: Re: Proposed OPTIONS replacement Message-ID: <AANLkTimJS%2Bd-h6ub6Q_Ff7vX134exr-7s73o=%2BjY4af%2B@mail.gmail.com> In-Reply-To: <AANLkTi=9-tgiH2QH7wODncG8D9aw_z2guSUNQK_pajkF@mail.gmail.com> References: <AANLkTikV4nCaZeFH-OEq94LXHikibitcyv%2BVPnGH8TFt@mail.gmail.com> <4CD4602C.2080804@FreeBSD.org> <AANLkTi=9-tgiH2QH7wODncG8D9aw_z2guSUNQK_pajkF@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Top-posting (sorry) and adding sysinstall@ since I know a few people there would be very interested in such a project. +1. Please, please, please. Yes. >From what I understand - and someone please correct me if I'm wrong - ports and sysinstall are the only tools I know of in base that make all that much use of libdialog. There are bugs in libdialog (and brucec@ probably has more info on this than me) that need fixing. If someone was willing to work on a new libdialog and fix these bugs, I'd be willing to work on updating sysinstall's dialog calls with any necessary changes. I have no special requests as far as things I'd like to see added other than a less confusing way of navigation. I've run into a lot of new users that are all "When do I hit tab? Why do I have to hit space? Why doesn't this work the way I expect?" and I have no good answers for them. libdialog blows goats. -- randi On Fri, Nov 5, 2010 at 3:01 PM, Eitan Adler <lists@eitanadler.com> wrote: > adding randi@ - might be interested in some of what I have to say > below re a bsdl libdialog. > > On Fri, Nov 5, 2010 at 3:51 PM, Doug Barton <dougb@freebsd.org> wrote: > > ... >> >> As I told you last night on IRC I like the idea. Here is a more detailed >> list of reasons: >> >> 1. Replace dialog with something bsdl, and more importantly more >> feature-full. You might also cast your sights on making the code flexibl= e >> enough to help with sysinstall, talk to Randi about that if you're >> interested. > > I willing to license this under the most most free license available > to me. I believe that ncurses is MITL and I'm willing to use that (or > the BSDL 2 clause if legally allowed). > > Regarding replacing dialog and libdialog. I am interested on working > on such a project, perhaps as a GSOC of code project. However my > present goal is only replace dialog's use in ports - and the > flexibility that a new dialog would require more time than I have at > this point. It would also require a complete rewrite of the API used > to call it. > > Furthermore I'd probably use the forms library instead of the menu > library for a dialog replacement. > >> >> 2. The current OPTIONS framework is as good as can be expected given the >> limitations of dialog and mk, but we need better. >> >> One feature we definitely need is the ability to make defaults in the po= rt's >> Makefile "hard" and "soft." A soft default would be the default as speci= fied >> in the Makefile unless the user has a different default in their environ= ment >> (shell env, /etc/make.conf, etc.). > > This is doable using my system. Because it only inherits defaults from > the environment the "soft" default would just be the Makefile setting > options first and /etc/make.conf getting set last. I believe this is > the way things work now. > > > A "hard" default is a concept that we've discussed in the past where a > given port/set of ports needs a feature that is otherwise optional. > For example port foo has a requirement for feature bar. Port baz is > something that can stand alone, but in this case is also a dependency > for foo, and has bar as an option. When the user gets to the option > screen for baz the option for bar should be in selected+grayed out >> mode, preferably with an explanation (required by foo). > > This is interesting - but requires more information than the ports > system has now. I can easily add some code that would grey out and > auto select options marked with an "!" as the option type. However > since this is called from each individual port's folder that > information would already have to be in the environment. > > In addition to >> flexibility in the tools for the screen (like radio buttons, which you h= ave) > > Small note: they are not actually radio buttons - but a menu that > makes mutually exclusive options unselectable - same idea though. > > >> In regards to your idea to allow a "user input" field, while reasonable >> minds can differ con that topic I'm not convinced of its utility. I thin= k >> that such a feature would lead to a lot of user frustration when they >> provide reasonable-seeming strings that the port maintainer did not >> anticipate. I am however willing to be convinced that I'm wrong on this >> point. > > I generally agree with you. This feature is meant for two situations > a) A user selected name, default value, file location, username, etc > b) =A0LOCALIZED_LANG as used by OpenOffice.org > >> As for the code, you might want to consider the idea of making the worki= ng >> parts a shared library and the application itself just a stub (ala libfe= tch, >> libarchive, etc.) That would make the code itself more generally useful = for >> other things like sysinstall, etc. > > Agreed. As I mentioned above I would not be against doing such a > project - perhaps a GSOC project. As of now the code is very ports > specific and can not be easily turned into a library. > > >> >> As for _running_ the code, I'm having issues. :) =A0On recent -current r= unning >> gnome I get: >> >> ./foo.sh: line 7: 13210 Bus error: 10 =A0 =A0 =A0 =A0 =A0 (core dumped) > > bapt@ also reported that he was unable to run it on -current. I have > no clue why. Valgrind offers no clues to me (although I admit I do not > know how to use it very well) > > If you could offer any more information to determine what line is > actually failing - that would be very useful. > >> >> Finally as for your question about direction, I think this is definitely >> something that should be adopted when it's mature. FWIW I also think it'= s >> something that should be a port itself, since that will allow us maximum >> flexibility in updating the code. Of course, my prejudice on that topic >> should be well known by now. :) > > I agree with you that port tools should be part of ports for what that > is worth :-) > However as of now I don't see that changing and this code will likely > need approval to be imported into the base system. > > > > -- > Eitan Adler >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTimJS%2Bd-h6ub6Q_Ff7vX134exr-7s73o=%2BjY4af%2B>