[R-gui] TR: [BioC] XML specifs for R GUIs dialog boxes

[Philippe Grosjean]

C'est un message de format MIME en plusieurs parties.

------=_NextPart_000_004E_01C2963C.A8668390
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I receive this from Robert Gentleman

>-----Message d'origine-----
>De : Robert Gentleman [mailto:rgentlem@jimmy.harvard.edu]
>Envoye : mardi 26 novembre 2002 16:31
>A : Philippe Grosjean
>Objet : Re: [BioC] XML specifs for R GUIs dialog boxes


>Hi,
> thanks for including us. If you look at the tkWidgets package
> (available from www.bioconductor.org) you will see a document (in
> inst/doc where all good documents belong) that details our plans for
> some of these issues. We are in the process of formalizing the
> interactions in a MVC framework (probably by mid-Dec), which we hope
> will make things much simpler (eg switching widget sets).

> We are fairly far along (been doing this for more than a year now)
> with some of the things that you are mentioning (and I have tried to
> point this out before). We would be quite happy to share ideas and
> results.

>  Robert

I attach a copy of the corresponding document to this mail. For me it seems
that people at bioconductor work more on the implementation of widgets for
dialog boxes, while here we are establishing a way to describe
specifications. Thus, a complementary work.

Thank you, Thomas for providing the basis of a working document! Many
reactions today. It seems obvious that we should try to stay as close as
possible to established standards like HTML as possible. However, I believe
that we really need to define our own XML specification, because this is
quite specific (at least if we keep the idea to make something really
portable). Of course, it does not hurt to get inspiration from QT or Gtk, or
.... If I understand what you propose the XML specification is voluntary
incomplete (understand, leaves some freedom for each particular
implementation). Why not...

For those who are still skeptical and consider that the current
implementation of Tcl/Tk in the tcltk R package could be just perfect, I
would like to say that I have some problems with it (for instance, the tk
windows appears _behind_ de main window in RGui.exe under Windows; not a
good behaviour for dialog boxes). For simple dialog boxes, it is perfectly
usable, but for a complex GUI frontend with lot of context menus and
toolbars and interactions with an object explorer, a message window, etc.,
it is not optimal in the current state, in my own opinion.

To stay constructive, we should now focus on the modification of the
document provided by Thomas. I formatted it (and made some comments). You
can download it from http://www.sciviews.org/_rgui/Rplugin.pdf, or from
http://www.sciviews.org/_rgui/Rplugin.rtf for a modifiable RTF version. I do
not want to favor Thomas point of view, and everybody can, of course,
propose modifications. One could also continue to discuss pros ad cons (or
may be why what we are doing is completely silly). If we go wrong, it is
better to stop as soon as possible! Otherwise, I would like to move forward.

The definitive test will be when we will implement it in various ways (I'll
do that in the "Windows sphere" for SciViews, probably in Visual Basic, or
Delphi,... although now, I spend much time in more basic part of the
Sciviews code). For faster tests, we should limit the first version to a
very limited core of features, I think.
Best,

Philippe

...........]<(({?<...............<?}))><...............................
( ( ( ( (
 ) ) ) ) )      Philippe Grosjean
( ( ( ( (
 ) ) ) ) )      IFREMER Nantes - DEL/AO
( ( ( ( (       rue de l'Ile d'Yeu, BP 21105, 44311 Nantes Cedex 3
 ) ) ) ) )      tel: (33) 02.40.37.42.29, fax: (33) 02.40.37.42.41
( ( ( ( ( 
 ) ) ) ) )      SciViews project coordinator (http://www.sciviews.org)
( ( ( ( (       e-mail: phgrosjean@sciviews.org
 ) ) ) ) ) 
( ( ( ( (       "I'm 100% confident that p is between 0 and 1"
 ) ) ) ) )                                L. Gonick & W. Smith (1993)
.......................................................................



------=_NextPart_000_004E_01C2963C.A8668390
Content-Type: application/octet-stream;
	name="widgetPlans.tex"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="widgetPlans.tex"

\documentclass{article}=0A=
=0A=
\begin{document}=0A=
=0A=
\title{RFC: Widget Plans}=0A=
\maketitle=0A=
=0A=
=0A=
\section*{Some ideas}=0A=
=0A=
Here are some simple ideas for building widgets. While this document=0A=
lives in the tkWidgets directory (for now) the plan is not to be=0A=
limited by that functionality. Gtk and other things -- Java etc,=0A=
seem like reasonable targets.=0A=
=0A=
Let's start with some definitions.=0A=
=0A=
A primitive widget (pwidget) is simply a set of linked interactive=0A=
tools.=0A=
Some examples:=0A=
\begin{itemize}=0A=
\item A text string, a type--in box and a button.=0A=
\item A set of linked radio buttons=0A=
\item A set of linked check boxes=0A=
\item A list-box=0A=
\item A button -- can have an arbitrary R function associated with it.=0A=
\end{itemize}=0A=
=0A=
A widget is an ordered collection (list) of pwidgets.=0A=
These get rendered in a single dialog box.=0A=
The default values are given by the input list and on exit the state=0A=
of the different pwidgets is recorded in the list, which is returned.=0A=
A widget can have two hooks, these are not rendered. One is a=0A=
pre--rendering hook (a function that takes no arguments) and if=0A=
present is run before the widget is rendered.=0A=
A post--rendering hook which is run when the widget is closed.=0A=
The pre--hook is run on entry and the post--hook is registered with =0A=
\verb+on.exit+. This ensures that it is run when the function is=0A=
exited regardless of how. It might be nice (but this will take some=0A=
time) to allow it to determine how the exit was achieved (is it an end=0A=
or a next or an error or ...).=0A=
=0A=
Widgets are rendered by the \verb+widgetRender+ function.=0A=
It returns an object of the \verb+iWidget+ which is a list of=0A=
lists. If the exit is normal (ie via the {\em end} button) then the=0A=
users changes will be contained in the return value and an element=0A=
"end" whose value will be "END". For all other forms of exit the input=0A=
will be returned. The rendered widget by default will have a=0A=
\verb+cancel+ button and an \verb+end+ button if there is no=0A=
definition for an end button in the controlbuttons list. =0A=
=0A=
In the not too distant future the pwidgets will be implemented as S4=0A=
classes. This will give them more structure. In the first=0A=
implementation they will be lists. However, we will attempt to use an=0A=
abstract data type implementation that should let us reuse much of the=0A=
code when the methods and classes are implemented.=0A=
=0A=
Next we introduce the concept of {\em chained widgets},=0A=
\verb+cWidgets+. Basically this is simply a list of widgets that will=0A=
be rendered sequentially. The \verb+cWidgets+ will also have pre and=0A=
post rendering hooks (these happen once for the entire=0A=
process). except for the first and last widgets in the list of=0A=
cWidgets who will have a \verb+next+ (first) or \verb+previous+=0A=
(last). The last widget will also have an \verb+end+ button. A counter=0A=
to indicate state is maintained and used for navigation.  =0A=
=0A=
The buttons will be defined by a list named controlbuttons that has a=0A=
bottonText and buttonFun defining the label and behavior of the button=0A=
respectively.  =0A=
=0A=
We need to decide how to run the pre and post widget hooks when the=0A=
different buttons are pushed (does \verb+next+ run the hook or does=0A=
any exit from the widget?).=0A=
=0A=
If the user pushes \verb+cancel+ the whole thing exits (again, we need=0A=
some decision about what gets returned). Here one might want to return=0A=
both the exit status and the list of widgets actually visited.=0A=
Duncan M. suggested that we want the exit status but not the list of=0A=
widgets visited.=0A=
=0A=
He also proposed a paged control. In this type of widget the different=0A=
controls are represented by tabs. They can be selected in any order=0A=
and navigated as desired by the user.=0A=
=0A=
Duncan M. also suggested that widgets should know why they are=0A=
exiting.=0A=
=0A=
Another suggestion is that there should be platform specific labels.=0A=
I think that this could be done by using \verb+options+ and installing=0A=
some package specific ones for {\em tkWidgets}.=0A=
=0A=
\section*{Some specifics}=0A=
=0A=
An example of what seems to be easy and useful is the following.=0A=
We can have a list of the form=0A=
\begin{verbatim}=0A=
list(Wtype=3D"Typein", Name=3D"aaa", Value=3DNULL, ButtonText =3D =
"Brows",=0A=
     ButtonFun=3DfileBrowser) =0A=
\end{verbatim}=0A=
This would get rendered as a typein box with name \verb+aaa+. The box=0A=
would initially be empty since \verb+Value+ was set to \verb+NULL+=0A=
(maybe it should be the empty string). There is a button labeled=0A=
"Brows" off the end of the box that is linked to the=0A=
\verb+fileBrowser+ function. This button when clicked will evaluate=0A=
the \verb+fileBrowser+ function and put its return value into the=0A=
typein box. =0A=
=0A=
Ok, there is a problem here. It seems that we need an additional layer=0A=
of abstraction. The problem: suppose that the Button is linked to=0A=
\verb+objectBrowser+ and that the user has selected multiple=0A=
objects. How do we associate those with the text in the typein box?=0A=
It does not appear that we can do that directly. So an extra layer of=0A=
abstraction might be enough for most purposes. There is a \verb+Value+=0A=
slot. This value is supplied by the user or it is the return value of=0A=
the function associated with the button. There is a \verb+toText+=0A=
function that takes that value and renders it for the text box.=0A=
Some care to deal with multiple values (which might not be character=0A=
strings will be needed). Also, I believe that if the return type=0A=
should not be a character string then editing of the box manually=0A=
should be prevented, here we could just render the text.=0A=
=0A=
Each \verb+pWidget+ has the following slots:=0A=
\begin{itemize}=0A=
\item Name: the print name for the item=0A=
\item Value: a value associated with this item=0A=
\item toText: a function that takes the value and turns it into a text=0A=
  string suitable for rendering in the text box.=0A=
\item canEdit: a boolean, can the user edit this box directly or only=0A=
  make changes via the button=0A=
\item buttonFun: a function associated with the button, the return=0A=
  value is put into Value=0A=
\item buttonText: the text to appear in the button=0A=
\item fromText: a function that takes the text from the text box and=0A=
  turns it into a value for the Value slot. If the user is allowed to=0A=
  type things in then this will be needed.=0A=
\end{itemize}=0A=
=0A=
We will need a boolean vector for the set of pWidgets to monitor=0A=
changes. The return value will be a list with components that include=0A=
\begin{itemize}=0A=
\item wList: the returned input list with values changed.=0A=
\item exit: a character string indicating which button was pushed,=0A=
  maybe even error?=0A=
\end{itemize}=0A=
=0A=
When a button is clicked and a return value retrieved it is put into=0A=
the Value slot and toText is run on it to ensure the text box has up=0A=
to date data.=0A=
=0A=
At some point we need to worry about the layout of the primitive=0A=
widgets on a widget to be built by \verb+widgetRender+. tk has three=0A=
types of geometry managers namely pack, grid, and place. pack puts=0A=
widgets in four sides namely top, right, bottom, and left. grid puts=0A=
widgets in grids, and place places widgets at specified lacations=0A=
based on absolute or relative values. For our purpose, pack and grid=0A=
would be our options. With the help of frames, we should be able to=0A=
have the widgets rendered nicely on a widget.=0A=
=0A=
\end{document}=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=

------=_NextPart_000_004E_01C2963C.A8668390--