Jim:

>> Reading these materials, it wasn't initially clear to me how this
>> project is different than zenity (which allows you to display GTK+
>> dialogs from shell scripts).  After checking the dialog website, I
>> found that it is used for displaying curses (or text-based) widgets.
>> So that is how it is different.  It would be nice if the case materials
>> could be updated to make this more clear.
> This application provides a set of curses widgets which can be
> used to create nice user interfaces to shell scripts. It is non-
> graphical (it uses curses) so it can be run in the console or an
> xterm. This allows a developer of a script to interact with the
> user in a much friendlier manner.
> 
> How about this?

This seems like a better description to me.

>> Also, I am curious what projects we plan to integrate might depend on
>> or use this interface.  Are we providing this so that Solaris users
>> can simply use the dialog interfaces if they want, or are there
>> particular programs we plan on integrating which use these interfaces?
>>
> Yes, Just provides Solaris users another friendly dialog interface 
> whatever they want to use it in console or shell script. For example, 
> user can enter the following comand line to go through the calendar in 
> console:
> $> dialog --calendar "My Calendar" -1 -1
> Currently we don't have any programs which directly use these interfaces.

Right, though it doesn't seem like there is strong business
justification for adding these interfaces.  However, that's no reason
we can't get ARC approval to integrate it when we do have reasonable
business justification.

>> If these interfaces are intended for Solaris users to make use of,
>> then should the interfaces be Uncommitted rather than Volatile?  It
>> doesn't seem much good to provide interfaces for providing dialogs
>> via shell scripts if the interfaces might change or break.
>>
> As matter of fact, dialog is just a executable utility which is for 
> OpenSolaris.  That's the reason why I defined it as Volatile.

This doesn't seem like a good argument to me.  I still don't see
the value in adding interfaces that users are expected to use, that
we also tell them we may change in an ad-hoc fashion.

Brian


Reply via email to