From owner-freebsd-sysinstall@FreeBSD.ORG Mon Nov 8 03:33:50 2010 Return-Path: Delivered-To: freebsd-sysinstall@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 375191065670 for ; Mon, 8 Nov 2010 03:33:50 +0000 (UTC) (envelope-from sektie@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id AEE498FC0C for ; Mon, 8 Nov 2010 03:33:49 +0000 (UTC) Received: by qyk7 with SMTP id 7so4363061qyk.13 for ; Sun, 07 Nov 2010 19:33:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=oLvhhpjX1/io+6Qa4k+IZy3yqwKmx+zBgu0p0lw2tg8=; b=hNwmRM8aCJeJdqHOSTEJjAcJaGWOhUdG6GV6Lkr2rdZ7Y+dMtZMvdqyHcXUYrgrXvW rqwAnZuh8v00bunNr9I8GroLUCq4m2GXatw++vfjFzwqwKGcOSyGcI0k/cn57noitkJM lowcaCkNDydALfmDUAnunIYN8T1kbggVT+jr8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Q80vgL2EIr0xIIBE5gp4Vu8BMTfulQgJX2vzuxdei76h8VvmM/FwiY0ssx2xzj2XLL RFAi66uMgkGaMZkoqk4sfWpkrRt+tX3hJ3HbKdVM1ruIKMg3lMhl0I27dMm/JA60Hv/+ sWX/VpWMlzLh9u4seocccK5TumoQxooOCCu4w= MIME-Version: 1.0 Received: by 10.224.137.147 with SMTP id w19mr3543214qat.371.1289187228775; Sun, 07 Nov 2010 19:33:48 -0800 (PST) Sender: sektie@gmail.com Received: by 10.220.10.208 with HTTP; Sun, 7 Nov 2010 19:33:48 -0800 (PST) In-Reply-To: References: <4CD4602C.2080804@FreeBSD.org> Date: Sun, 7 Nov 2010 19:33:48 -0800 X-Google-Sender-Auth: AyNs8beFdfWT5YXKMo3G6cQpw2w Message-ID: From: Randi Harper To: Eitan Adler Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: babt@freebsd.org, Mark Linimon , Doug Barton , pav@freebsd.org, freebsd-sysinstall@freebsd.org Subject: Re: Proposed OPTIONS replacement X-BeenThere: freebsd-sysinstall@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Sysinstall Work List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 03:33:50 -0000 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 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 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 >