[R-gui] Another R-GUI

The major reason why r-sig-gui is idle for the moment is that there are
currently no really collaborative projects undergone. Personally, I spend
all my spare time to progress in SciViews. As I understand it, several
other people (including you ;-) are also focused on progressing in their
own code. This is nice, because it means we will probably have several
solid ideas for DSC 2003. I hope we will cook something there that will
ravive the discussion on r-sig-gui.

Well, there might be one thing we should be discussing before March 2003. I 
don't know, how all of you are approaching this, but I had a short 
conversation with the obveRsive-people, and we seem to have had some rather 
similar ideas on this topic:
Probably all GUIs will at some places want to show some dialogs, read a few 
settings (which variables/options to use etc) in those dialogs and then 
generate R-code from that. The projects might differ in how those dialogs 
should look, whether R-code is passed to R transparently or in the background 
etc. but in many ways, the functionality to be provided will likely be 
similar or even the same.
For my project, I therefore decided to implement access to tests and the like 
(should probably be extended to mostly any operation) as a sort of "plugins". 
That is, the dialog for calculating a t-test (the only thing I implemented so 
far, as a demonstrational example: http://rkward.sf.net/pics.php ) is 
actually constructed at run-time from an XML-file.
Similarily, the obveRsive-project is planning to use an XML-extension called 
Jelly, in order to implement such functionality as "actions".
Most likely other projects are using similar approaches, or might at least be 
interested. If we could agree on a common syntax/semantics for defining 
actions/plugins/whatever-we-chose-to-call-them, I think this would be of 
great benefit to all projects. It would mean, that we can easily share at 
least some parts of our work, even across projects that might be rather 
dissimilar on the surface.
Now in order to not have to do everything over again later, I think, we should 
try to agree on such a plugin-language as early as possible. Therefore, I'm 
attaching a copy of the sample XML-file, the t-test on my screenshot-page is 
created from. It certainly does have it's weaknesses and can be criticized in 
many ways, but will hopefully serve as a starting-point for a discussion of 
what the requirements for such a "plugin-language" would be and later on, 
what exactly it should look like.

Thomas

Example XML-file is below. I hope your mail-client does not try to interpret 
it as HTML - in which case you will not see much. If it does, you'll have to 
view the raw message.


<!DOCTYPE rkplugin>

<!-- This is a simple example, of how a "plugin" might be configured. -->

<document>

<!-- The location-section determines, where the function will be placed in the
menu-structure and how it will be labeled. The "tag"-attributes are used
to identify the same menu across different plugins. The "label"-attributes 
will have to be translated somehow. -->

	<location tag="analyse" label="&amp;Analyse">
		<location tag="means" label="Means">
			<location tag="t_tests" label="T-Tests">
				<entry label="Independed Samples T-Test"/>
			</location>
		</location>
	</location>

<!-- The layout-section takes care of the layout of the GUI for this plugin. 
-->

	<layout>
		<row>
			<column>
				<varselector id="vars"/>
			</column>
			<column>
				<varslot type="numeric" id="x" source="vars" required="true" 
label="compare"/>
				<varslot type="numeric" id="y" source="vars" required="true" 
label="against"/>
				<radio id="hypothesis" label="using test hypothesis">
					<option value="two.sided" label="Two-sided"/>
					<option value="greater" label="First is greater"/>
					<option value="less" label="Second is greater"/>
				</radio>
			</column>
		</row>
	</layout>

<!-- The code-section specifies, how the selected options will be translated
into code. Code generation is based on a simple search an replace-mechanism. 
-->

	<code>
		t.test ($x$, $y$, "$hypothesis$")
	</code>
</document>

thomas <thomas.friedrichsmeier@ruhr-uni-bochum.de> writes:

That is, the dialog for calculating a t-test (the only thing I
implemented so far, as a demonstrational example:
http://rkward.sf.net/pics.php ) is actually constructed at run-time
from an XML-file. Similarily, the obveRsive-project is planning to
use an XML-extension called Jelly, in order to implement such
functionality as "actions".

Interesting. I think someone in BioConductor is thinking along similar
XML lines too. Personally, I'm still playing the game "bottom-up", but
I'll likely get to the specification issue at some point too. 

(BTW, minor typo: I don't think you want an 'e' in 'issuing')

O__  ---- Peter Dalgaard             Blegdamsvej 3  
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N   
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

Yes, Thomas, your are perfectly right: one has to establish a standard for
describing dialog boxes. Your XML-file implementation is interesting. I
don't think most complex dialog boxes should be constructed this way on the
fly, but this should be useful for 95% of our needs. I am willing to add a
page in http://www.r-project.org/GUI for proposing such a standard. Thomas,
would you like to propose a draft? Does somebody else want to participate? I
also think that people at Bioconductor, Omegahat and, of course, R-Core Team
should contribute to this, if they like. I just look at respective lists of
participants in R-SIG-GUI in one hand and Bioconductor in the other hand:
there are very few people involved in both. Peter, do you know who should I
contact directly at Bioconductor?

Also, probably related to this: I am thinking on a context sensitive user
interface organized around an object explorer. Items in the object explorer
would have context menus that trigger context sensitive dialog boxes
(pertinent analyses for, let's say, a data frame or a ts object are
obviously not the same) and an associated tabbed "explorer view window" that
allow to look at objects [most tabs of the view window would correspond to
methods of the object like summary(), plot(), hist(),...]. I think this
could be added in the XML specifications too. A context-sensitive "clipping
list" (list of R code templates, pertinent in the current context) could be
another nice addition too.
Best,

Philippe Grosjean


-----Message d'origine-----
De : r-sig-gui-admin@stat.math.ethz.ch
[mailto:r-sig-gui-admin@stat.math.ethz.ch]De la part de Peter Dalgaard
BSA
Envoye : dimanche 17 novembre 2002 15:08
A : thomas.friedrichsmeier@ruhr-uni-bochum.de
Cc : r-sig-gui@stat.math.ethz.ch
Objet : Re: [R-gui] Another R-GUI


thomas <thomas.friedrichsmeier@ruhr-uni-bochum.de> writes:

That is, the dialog for calculating a t-test (the only thing I
implemented so far, as a demonstrational example:
http://rkward.sf.net/pics.php ) is actually constructed at run-time
from an XML-file. Similarily, the obveRsive-project is planning to
use an XML-extension called Jelly, in order to implement such
functionality as "actions".

Interesting. I think someone in BioConductor is thinking along similar
XML lines too. Personally, I'm still playing the game "bottom-up", but
I'll likely get to the specification issue at some point too.

(BTW, minor typo: I don't think you want an 'e' in 'issuing')

--
   O__  ---- Peter Dalgaard             Blegdamsvej 3
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard@biostat.ku.dk)             FAX: (+45) 35327907

_______________________________________________
R-SIG-GUI mailing list
R-SIG-GUI@stat.math.ethz.ch
http://www.stat.math.ethz.ch/mailman/listinfo/r-sig-gui

On Mon, 25 Nov 2002 11:20:35 +0100, you wrote in message
<MABBLJDICACNFOLGIHJOMEDGDBAA.phgrosje@ulb.ac.be>:

Yes, Thomas, your are perfectly right: one has to establish a standard for
describing dialog boxes. Your XML-file implementation is interesting. I
don't think most complex dialog boxes should be constructed this way on the
fly, but this should be useful for 95% of our needs. I am willing to add a
page in http://www.r-project.org/GUI for proposing such a standard. Thomas,
would you like to propose a draft? Does somebody else want to participate?

I'm also interested.  

The way I see XML is as a standard way of storing hierarchical
information.  I think complex dialog boxes should normally be
constructed hierarchically, so I don't see any problem with thinking
about all of them as being made of XML.  Internally, they may
sometimes be stored differently for efficiency reasons, but there
should always be a 1-1 map to XML, so that other standard tools can be
written to work on them.

I would say what we need is some flexibility.  Sometimes dialog boxes
would be constructed in a Delphi (or Visual Basic) drag-and-drop mode;
other times a user would want to be able to say "give me a dialog box
to ask about the elements of this list".  Both should be possible.

Duncan Murdoch

I must probably explain a little bit, because when I talk about "complex
dialog boxes", it is not very clear what I mean. Nobody will contradict me
when I say that the dynamic dialog boxes, as described in a XML file should
be as portable as possible. In particular, it should be possible to create
similar dialog boxes using different graphical toolkits, from the same XML
specification file (Visual Basic/Delphi/VC++ for SciViews; Swing for
ObveRsive; Qt for RKward; Tcl/Tk or GTK for other projects). However, this
would limit the building blocks -the widgets- to a core basic set that is
common to all toolkits. There will certainly be some cases where the
programmer would like to use specific widgets, or exotic features. For
instance, I have some ideas on how to implement dynamically a dialog box
composed of standard widgets in Visual Basic, but it is not obvious to me
how I could dynamically add some exotic OCXes at run time! Consequently, I
suppose that a few percentage of the dialog boxes will not be portable and
will probably not benefit the dynamic implementation (they will be much
easier to build at design time and be embedded in a shared library, for
instance).

Anyway, I will submit the draft to all interested people in time.
Best,

Philippe Grosjean

P.S.: Duncan, I recently showed your RGL (R interface to OpenGL) at a
R/PASTECS formation,... and I got a lot of Aahh! and Oohhh! By the way, in
the choosen example, some particular features in the data set where only
revealed by playing with the 3D graph in RGL, but not, for instance in a
contour plot [image() followed by contour()].


-----Message d'origine-----
De : r-sig-gui-admin@stat.math.ethz.ch
[mailto:r-sig-gui-admin@stat.math.ethz.ch]De la part de Duncan Murdoch
Envoye : lundi 25 novembre 2002 15:26
A : Philippe Grosjean
Cc : r-sig-gui@stat.math.ethz.ch
Objet : Re: [R-gui] Another R-GUI


On Mon, 25 Nov 2002 11:20:35 +0100, you wrote in message
<MABBLJDICACNFOLGIHJOMEDGDBAA.phgrosje@ulb.ac.be>:

Yes, Thomas, your are perfectly right: one has to establish a standard for
describing dialog boxes. Your XML-file implementation is interesting. I
don't think most complex dialog boxes should be constructed this way on the
fly, but this should be useful for 95% of our needs. I am willing to add a
page in http://www.r-project.org/GUI for proposing such a standard. Thomas,
would you like to propose a draft? Does somebody else want to participate?

I'm also interested.

The way I see XML is as a standard way of storing hierarchical
information.  I think complex dialog boxes should normally be
constructed hierarchically, so I don't see any problem with thinking
about all of them as being made of XML.  Internally, they may
sometimes be stored differently for efficiency reasons, but there
should always be a 1-1 map to XML, so that other standard tools can be
written to work on them.

I would say what we need is some flexibility.  Sometimes dialog boxes
would be constructed in a Delphi (or Visual Basic) drag-and-drop mode;
other times a user would want to be able to say "give me a dialog box
to ask about the elements of this list".  Both should be possible.

Duncan Murdoch

_______________________________________________
R-SIG-GUI mailing list
R-SIG-GUI@stat.math.ethz.ch
http://www.stat.math.ethz.ch/mailman/listinfo/r-sig-gui

"philippe" == Philippe Grosjean <phgrosjean@sciviews.org> writes:

philippe> Anyway, I will submit the draft to all interested people in time.
    philippe> Best,

Please post to the list -- I'm assuming that all subscribers ought to
be interested.

best,
-tony

A.J. Rossini				Rsrch. Asst. Prof. of Biostatistics
U. of Washington Biostatistics		rossini@u.washington.edu	
FHCRC/SCHARP/HIV Vaccine Trials Net	rossini@scharp.org
-------------- http://software.biostat.washington.edu/ ----------------
FHCRC: M: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email
UW:   Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX
(my tuesday/wednesday/friday locations are completely unpredictable.)

On Mon, 25 Nov 2002 16:31:51 +0100, you wrote in message
<MABBLJDICACNFOLGIHJOEEEADBAA.phgrosjean@sciviews.org>:

There will certainly be some cases where the
programmer would like to use specific widgets, or exotic features. For
instance, I have some ideas on how to implement dynamically a dialog box
composed of standard widgets in Visual Basic, but it is not obvious to me
how I could dynamically add some exotic OCXes at run time! 

I think the way Delphi handles this is good.  It doesn't use XML, it
uses its own language, but I think there's a 1-1 map to XML.  A
typical form definition file might look like this:

object Form3: TForm3

Delphi calls windows "forms".  This is a dialog box declared to be of
type "TForm3", which I just created.  The compiler would see the
declaration and would know what TForm3 means.

 Left = 247
 Top = 122
 Width = 870
 Height = 640
 Caption = 'Form3'
 Color = clBtnFace
 Font.Charset = DEFAULT_CHARSET
 Font.Color = clWindowText
 Font.Height = -13
 Font.Name = 'MS Sans Serif'
 Font.Style = []
 OldCreateOrder = False
 PixelsPerInch = 120
 TextHeight = 16

These are a number of properties of the form that have been set to
non-default values.

 object Button1: TButton
   Left = 168
   Top = 32
   Width = 75
   Height = 25
   Caption = 'Button1'
   TabOrder = 0
 end

This is a button that has been added to the form, with some
non-default properties.  Delphi knows that TButton is a button,
because it has been registered with the system.  If I wanted an OCX,
I'd register TMyOCX with the system, and it would be allowed here too.

end

If other components had been added to the form, their descriptions
would follow the button definition.  Some components can have other
components nested within them.

P.S.: Duncan, I recently showed your RGL (R interface to OpenGL) at a
R/PASTECS formation,... and I got a lot of Aahh! and Oohhh! By the way, in
the choosen example, some particular features in the data set where only
revealed by playing with the 3D graph in RGL, but not, for instance in a
contour plot [image() followed by contour()].

Sounds great!  By the way, there's some progress on getting it past
being just a "prototype".  I'm hoping to get some help translating to
C++ early next year, at which point I can clean up some ugliness in
the original version, make it available on more platforms, and start
adding requested features to it.

Duncan Murdoch

OK, now I see why we are not in phase: you speak about a dialog box
definition file used by the compiler. At this point it is very easy to add
other "widgets". It is exactly the same for Visual Basic. On the other hand,
I talk about a dialog box specification file that can be used to create a
dialog box *at run time*, that is by a compiled program (being written in
Delphi, Visual Basic, Java, C, or whatever,...). This is definitively a
different matter! Especially if we should be able to implement that dialog
box with various languages and different graphical toolkits on all platforms
supported by R,... a more difficult but not completelly inaccessible goal.

Philippe

-----Message d'origine-----
De : Duncan Murdoch [mailto:murdoch@stats.uwo.ca]
Envoye : lundi 25 novembre 2002 17:25
A : phgrosjean@sciviews.org
Cc : r-sig-gui@stat.math.ethz.ch
Objet : Re: [R-gui] Another R-GUI


On Mon, 25 Nov 2002 16:31:51 +0100, you wrote in message
<MABBLJDICACNFOLGIHJOEEEADBAA.phgrosjean@sciviews.org>:

There will certainly be some cases where the
programmer would like to use specific widgets, or exotic features. For
instance, I have some ideas on how to implement dynamically a dialog box
composed of standard widgets in Visual Basic, but it is not obvious to me
how I could dynamically add some exotic OCXes at run time!

I think the way Delphi handles this is good.  It doesn't use XML, it
uses its own language, but I think there's a 1-1 map to XML.  A
typical form definition file might look like this:

object Form3: TForm3

Delphi calls windows "forms".  This is a dialog box declared to be of
type "TForm3", which I just created.  The compiler would see the
declaration and would know what TForm3 means.

 Left = 247
 Top = 122
 Width = 870
 Height = 640
 Caption = 'Form3'
 Color = clBtnFace
 Font.Charset = DEFAULT_CHARSET
 Font.Color = clWindowText
 Font.Height = -13
 Font.Name = 'MS Sans Serif'
 Font.Style = []
 OldCreateOrder = False
 PixelsPerInch = 120
 TextHeight = 16

These are a number of properties of the form that have been set to
non-default values.

 object Button1: TButton
   Left = 168
   Top = 32
   Width = 75
   Height = 25
   Caption = 'Button1'
   TabOrder = 0
 end

This is a button that has been added to the form, with some
non-default properties.  Delphi knows that TButton is a button,
because it has been registered with the system.  If I wanted an OCX,
I'd register TMyOCX with the system, and it would be allowed here too.

end

If other components had been added to the form, their descriptions
would follow the button definition.  Some components can have other
components nested within them.

P.S.: Duncan, I recently showed your RGL (R interface to OpenGL) at a
R/PASTECS formation,... and I got a lot of Aahh! and Oohhh! By the way, in
the choosen example, some particular features in the data set where only
revealed by playing with the 3D graph in RGL, but not, for instance in a
contour plot [image() followed by contour()].

Sounds great!  By the way, there's some progress on getting it past
being just a "prototype".  I'm hoping to get some help translating to
C++ early next year, at which point I can clean up some ugliness in
the original version, make it available on more platforms, and start
adding requested features to it.

Duncan Murdoch

"philippe" == Philippe Grosjean <phgrosjean@sciviews.org> writes:

philippe> OK, now I see why we are not in phase: you speak about a dialog box
    philippe> definition file used by the compiler. At this point it is very easy to add
    philippe> other "widgets". It is exactly the same for Visual Basic. On the other hand,
    philippe> I talk about a dialog box specification file that can be used to create a
    philippe> dialog box *at run time*, that is by a compiled program (being written in
    philippe> Delphi, Visual Basic, Java, C, or whatever,...). This is definitively a
    philippe> different matter! Especially if we should be able to implement that dialog
    philippe> box with various languages and different graphical toolkits on all platforms
    philippe> supported by R,... a more difficult but not completelly inaccessible goal.

No it isn't.  Just a matter of translation, for the most part (I'm
thinking about how I'd use either Java (Swing) or R (tcltk or Java) or
Emacs to do this, and it really is more a matter of
translation/construction rather than the activity being different. 

How it looks isn't of interest (except that some forms require less
translation -- Duncan's example or XML would be equally annoying (or
easy, depending on how you view additional programming needs to a
project).

A.J. Rossini				Rsrch. Asst. Prof. of Biostatistics
U. of Washington Biostatistics		rossini@u.washington.edu	
FHCRC/SCHARP/HIV Vaccine Trials Net	rossini@scharp.org
-------------- http://software.biostat.washington.edu/ ----------------
FHCRC: M: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email
UW:   Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX
(my tuesday/wednesday/friday locations are completely unpredictable.)

I must probably explain a little bit, because when I talk about "complex
dialog boxes", it is not very clear what I mean. Nobody will contradict me
when I say that the dynamic dialog boxes, as described in a XML file should
be as portable as possible. In particular, it should be possible to create
similar dialog boxes using different graphical toolkits, from the same XML
specification file (Visual Basic/Delphi/VC++ for SciViews; Swing for
ObveRsive; Qt for RKward; Tcl/Tk or GTK for other projects). However, this
would limit the building blocks -the widgets- to a core basic set that is
common to all toolkits. There will certainly be some cases where the
programmer would like to use specific widgets, or exotic features. For
instance, I have some ideas on how to implement dynamically a dialog box
composed of standard widgets in Visual Basic, but it is not obvious to me
how I could dynamically add some exotic OCXes at run time!

I'm not sure, whether we're not already thinking along the same lines, anyway, 
but to clarify: The XML-specification I'm talking about should IMHO use some 
rather high level "widgets", which simply make sense for an R-frontend, and 
not orient itself at the widgets available in a certain toolkit.
E.g. the "varslot"-widget in the example I posted, is something that will 
likely occur at many places in many different R-frontends, but likely is not 
a widget contained in any toolkit. Rather all frontends, that would like to 
use the "plugin" would have to implement some way to construct something that 
can act as a "varslot". Internally in RKWard, this is acutally composed of 
three Qt-widgets (a button, a label and a lineedit), in another project it 
might look different, as long as it provides the same core functionality.
Moreover, projects should be free to offer extended functionality for the 
"varslot", such as applying some transformations on the selected object - 
this would not be described in the XML-file, however. The definition for that 
dialog still remain the same and be useful across different projects, that 
offer different functionality.
This means, that not every nifty feature we plan to implement in our projects 
might be possible to describe this way, but for lots of "simple standard" 
stuff like analyses of variance, correlations... it shouldn't be a problem. 
For other features, we would have to create custom solutions that can not 
easily be shared across projects.

Consequently, I
suppose that a few percentage of the dialog boxes will not be portable and
will probably not benefit the dynamic implementation (they will be much
easier to build at design time and be embedded in a shared library, for
instance).

Agreed.

I think we're pretty much on a good way concerning the specification of what a 
dialog should look like (we probably don't need more layouting-functionality 
than rows and columns and potentially tabs), and I guess we should be able to 
agree fairly quickly on a set of "widgets" we need. The ones that come to my 
mind are:

- some sort of widget that lists available objects (the "varselector" in my 
example)
- a widget that can hold a (single) object (the "varslot"), and will probably 
make some specifications about what types of objects it can hold (like the 
attribute type="numeric" in the example)
- maybe a separate widget that can hold one or more objects, but basically 
acts the same (might instead simply use a more generalized "varslot")
- maybe a separate widget that can hold a single constant value (number or 
string)
- a widget that can be used to select interactions between variables selected 
in a "varslot"
- radio-buttons
- checkboxes
- a widget representing a text/label not directly attached to any of the other 
widgets
- a widget represent a line or other separation used for layouting purposes

Did I forget anything important? Anyway, the list is probably not all that 
long, which also means, that implementing a parser and GUI-builder for this 
XML will not be too hard to do.

Another thing, that might however deserve some further consideration, is, how 
the selections made in a dialog created this way, should be transformed into 
R-code. The example I sent, simply uses a search-and-replace mechanism, that 
works surprisingly well, but might be too inflexible. This means, that we 
might have to agree on either some "if" and "else" tags in our XML, or on 
some sort of scripting language like e.g. PHP, that will be used to generate 
the code.

Anyway, I will submit the draft to all interested people in time.

I'm very interested.

Thomas

OK, now I see why we are not in phase: you speak about a dialog box
definition file used by the compiler. At this point it is very easy to add
other "widgets". It is exactly the same for Visual Basic. On the other hand,
I talk about a dialog box specification file that can be used to create a
dialog box *at run time*, that is by a compiled program (being written in
Delphi, Visual Basic, Java, C, or whatever,...). This is definitively a
different matter! 

No, not necessarily.  For example, Delphi can create the dialog box
based on the text representation at run time or at compile time.  At
compile time, all it does is translate the text representation into a
binary equivalent, and include that as a resource in the executable;
when the program starts, the dialog is constructed based on that data.

If you wanted to create it at run-time, you just create the binary
structure in some other way, and then execute the same code to
actually create the dialog.  For example, the IDE of Delphi is written
in Delphi, and that's how it creates the forms at design time.

There are still issues of registering types (it needs to know what
TButton or TForm3 means).

Duncan Murdoch

This is definitively a different matter!

No, not necessarily.  For example, Delphi can create the dialog box
based on the text representation at run time or at compile time.  At
compile time, all it does is translate the text representation into a
binary equivalent, and include that as a resource in the executable;
when the program starts, the dialog is constructed based on that data.

If you wanted to create it at run-time, you just create the binary
structure in some other way, and then execute the same code to
actually create the dialog.  For example, the IDE of Delphi is written
in Delphi, and that's how it creates the forms at design time.

Well, the difference might not be between creation at run-time or at compile 
time, but there still is an important difference in the level at which the 
GUI is described.
What you're talking about is at a rather low level. It allows for maximum 
control, but it certainly is not something that can easily be shared across 
projects using different toolkits.
What I'm talking about is at a much higher level. It's about using a single 
tag for defining a complex control potentially composed of several 
VB/VC/Qt/GtK/Delphi/whatever-widgets, and it's about describing only a rough 
layout/core functionality. It certainly does not allow for as much control, 
and as mentioned, it might not be suited for all purposes, but it can easily 
be shared across totally different projects. 
BTW, a nice side effect of using a high-level description is that you get a 
consistent look and feel across different dialogs (created by different 
people), and that the description is simple to read and simple to write.

Thomas

"thomas" == thomas  <thomas.friedrichsmeier@ruhr-uni-bochum.de> writes:

thomas> Well, the difference might not be between creation at run-time or at compile 
    thomas> time, but there still is an important difference in the level at which the 
    thomas> GUI is described.
    thomas> What you're talking about is at a rather low level. It allows for maximum 
    thomas> control, but it certainly is not something that can easily be shared across 
    thomas> projects using different toolkits.

The level isn't terribly critical -- we will need both, to describe
both fine grained as well as higher level control of widgets,
especially if there is to be any hope for crafting similar UIs.  

While they can initially be hardcoded,  flex-coding the underlying
components will be preferred in the long run.  

(usual disclaimers on top-down vs. bottom-up design arguments, yadda yadda...).

best,
-tony

A.J. Rossini				Rsrch. Asst. Prof. of Biostatistics
U. of Washington Biostatistics		rossini@u.washington.edu	
FHCRC/SCHARP/HIV Vaccine Trials Net	rossini@scharp.org
-------------- http://software.biostat.washington.edu/ ----------------
FHCRC: M: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email
UW:   Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX
(my tuesday/wednesday/friday locations are completely unpredictable.)

I think we're pretty much on a good way concerning the specification of what a 
dialog should look like (we probably don't need more layouting-functionality 
than rows and columns and potentially tabs),

I think there should be finer granularity than that.  We shouldn't use
Delphi's scheme of counting things in pixels (Delphi has problems when
you change fonts, or change screen resolutions), but some sort of
device independent coordinates (e.g. the dialog coordinates run from 0
to 1 in each direction) would be better than assuming it's a grid.

- some sort of widget that lists available objects (the "varselector" in my 
example)

I think we should start at a lower level (a widget that gives a list
of strings to select from), and then implement a list of available
objects as a string list widget that has been populated by the names
of available objects.

- a widget that can hold a (single) object (the "varslot"), and will probably 
make some specifications about what types of objects it can hold (like the 
attribute type="numeric" in the example)
- maybe a separate widget that can hold one or more objects, but basically 
acts the same (might instead simply use a more generalized "varslot")
- maybe a separate widget that can hold a single constant value (number or 
string)
- a widget that can be used to select interactions between variables selected 
in a "varslot"

In the same way, we want the lower level components that make these up
to be available.

- radio-buttons
- checkboxes

These are low level.

- a widget representing a text/label not directly attached to any of the other 
widgets

No need to make this special now, it's just a low level label...

- a widget represent a line or other separation used for layouting purposes

We often want boxes, so it might make sense for that to be the lowest
level, with one style being a box with only one side visible.

We also need buttons, and the ability to attach actions to user
actions.  (E.g. click on a button  or change the entry in a widget and
execute some R code).  I'm not sure how many of these we want, but
there could be a lot.  For example, Delphi allows 16 different kinds
of events to be triggered by a button:  clicks, mouse
move/push/release, context sensitive help popup, 3 for drag and drop
functions, 2 for "docking" functions, 2 for focus entering/leaving the
button, and 3 for key presses while the button is focussed.  Since we
don't want all of these from the beginning, but we might want some of
them later, I think we should make it easy to add additional events to
components.

We should also have a tree view widget, and a free text entry widget.

Another thing, that might however deserve some further consideration, is, how 
the selections made in a dialog created this way, should be transformed into 
R-code. The example I sent, simply uses a search-and-replace mechanism, that 
works surprisingly well, but might be too inflexible. This means, that we 
might have to agree on either some "if" and "else" tags in our XML, or on 
some sort of scripting language like e.g. PHP, that will be used to generate 
the code.

I'm not sure why this needs to generate R code.  Why not just have a
function to retrieve the values of all widgets that have values?

Duncan Murdoch

On 25 Nov 2002 09:43:16 -0800, you wrote in message
<87znrxh7ez.fsf@jeeves.blindglobe.net>:

The level isn't terribly critical -- we will need both, to describe
both fine grained as well as higher level control of widgets,
especially if there is to be any hope for crafting similar UIs.  

Yes, that's right. 

One other thing:  like XML, we should allow details to be put into the
widget description even if they are meaningless on some systems,
instead of restricting descriptors to those that are common
everywhere.  

For example, things that don't make sense (like "font=Helvetica" on a
text mode display) should just be ignored.  Things that ask for too
much (e.g. "position this at (0.314159, 0.271828)" on a system that
only allows widgets to be placed on a coarse grid) should be
approximated sensibly.

This way it should be relatively easy to write a bare bones display
engine, and then extra features could be gradually added to it over
time.

One question I'd like to hear opinions about:  if we're allowing the
user to create new specialized widgets, should we use an
object-oriented inheritance scheme, or do everything by delegation?
For example, I said I'd like to see a string selector being used by
the varselector that Thomas described.  But that could be done in two
ways:  either the varselector is a descendant of a string selector, or
it's a new component that contains a string selector.  Opinions?  (For
what it's worth, Delphi uses the inheritance system, and it works
pretty well, so that's where I'd lean.)

Duncan Murdoch

Please note, that the questions I ask are really meant as questions, and are not purely rhetorical.

I think there should be finer granularity than that.  We shouldn't use
Delphi's scheme of counting things in pixels (Delphi has problems when
you change fonts, or change screen resolutions), but some sort of
device independent coordinates (e.g. the dialog coordinates run from 0
to 1 in each direction) would be better than assuming it's a grid.

I think assuming it's in a grid is not all that bad as a start. After all, if the widgets do look different in different projects, it's dangerous to specify even relative sizes. I admit, that the idea of rows and columns is somewhat inspired by Qt, which uses rows and columns for layouting, but I guess something like this is available in other toolkits, too?
Anyway, we might of course add some percentual width-attributes (kind of like it's done in HMTL-tables), which could be taken as a hint to the layouting-engine, thereby adding a little more flexibility.

- some sort of widget that lists available objects (the "varselector" in my
example)

I think we should start at a lower level (a widget that gives a list
of strings to select from), and then implement a list of available
objects as a string list widget that has been populated by the names
of available objects.

Well, this may be going a bit into details already, but do we really need this? Do you ever need to select strings from a list, that do not represent R-objects? Of course, if we really need this, that should not be much of a problem, and RKWard's implementation of a "varselector" acutally works much like that internally.

- a widget that can hold a (single) object (the "varslot"), and will

probably

make some specifications about what types of objects it can hold (like the
attribute type="numeric" in the example)
- maybe a separate widget that can hold one or more objects, but basically
acts the same (might instead simply use a more generalized "varslot")
- maybe a separate widget that can hold a single constant value (number or
string)
- a widget that can be used to select interactions between variables

selected

in a "varslot"

In the same way, we want the lower level components that make these up
to be available.

Do we?

- radio-buttons
- checkboxes

These are low level.

Ok, admitted.

- a widget representing a text/label not directly attached to any of the

other

widgets

No need to make this special now, it's just a low level label...

True, but I was actually trying to give a _complete_ list, i.e. this is all the widgets, I think we need (at least for a first draft).

- a widget represent a line or other separation used for layouting purposes

We often want boxes, so it might make sense for that to be the lowest
level, with one style being a box with only one side visible.

Sounds reasonable.

We also need buttons, and the ability to attach actions to user
actions.  (E.g. click on a button  or change the entry in a widget and
execute some R code). 

Do we? Of course the GUI-itself does need some buttons e.g. for executing R-code, but there should be no need to explicitely define those. They should simply be generated by the application, not stated in the "plugin".

I'm not sure how many of these we want, but
there could be a lot.  For example, Delphi allows 16 different kinds
of events to be triggered by a button:  clicks, mouse
move/push/release, context sensitive help popup, 3 for drag and drop
functions, 2 for "docking" functions, 2 for focus entering/leaving the
button, and 3 for key presses while the button is focussed.  Since we
don't want all of these from the beginning, but we might want some of
them later, I think we should make it easy to add additional events to
components.

I still believe, we're partially talking about different things. Whether the application wants to show a help-menu on a right-click somewhere or on a hover, whether something gets pasted into a field or typed manually etc. should entirely be the responsibility of the application, not be defined inside an XML-file to be shared across projects. That's what I mean when talking about "high" level - the XML-specification should really say nothing about what happens when you right-click on some button. It should allow you to state: "Ok, I need this standard-R-widget here that represents a numeric value. If it happens to provide the functionality for a context-help (by whichever means), display the text specified. If it happens to support a header-label, display that other text here. I don't care what it looks like, and I don't care, whether the value is read from a silly slider or some more serious control. Just put it there."

We should also have a tree view widget, and a free text entry widget.

It probably makes sense to have a widget for entering longer texts, but do we really need a separate tree-view? What else would you want to put in there, if not the available variables?

I'm not sure why this needs to generate R code.  Why not just have a
function to retrieve the values of all widgets that have values?

Umm, yes, exactly that. And that function would result in some R-code. Or are we talking about something different here?
Let me post again the section in my example:

<code>
   t.test ($x$, $y$, "$hypothesis$")
</code>

Here my "code-generation" is to simply replace everything inside $$ with the values in the GUI (I have two "varslots" with tagged "x" and "y", and a group of radio-buttons tagged "hypothesis").
I'm simply not sure, whether a simple search-and-replace like this is flexible enough.

PS: No need to CC me, I'm on the list (with a different mail-account)

The level isn't terribly critical -- we will need both, to describe
both fine grained as well as higher level control of widgets,
especially if there is to be any hope for crafting similar UIs.

While they can initially be hardcoded,  flex-coding the underlying
components will be preferred in the long run.

Ok, how about this for a compromise: Let's try to start out with as few and as complex/high level widgets as possible, and then slowly add more flexibility as the limitations become visible?

One other thing:  like XML, we should allow details to be put into the
widget description even if they are meaningless on some systems,
instead of restricting descriptors to those that are common
everywhere.

Yes, I totally agree.

For example, things that don't make sense (like "font=Helvetica" on a
text mode display) should just be ignored.  Things that ask for too
much (e.g. "position this at (0.314159, 0.271828)" on a system that
only allows widgets to be placed on a coarse grid) should be
approximated sensibly.

I personally would however vote against allowing attributes like font="Helvetica" at all. There really is no need to have different dialogs in the same app to use different fonts. The application may decide to use Helvetica for this and Courier for that, but for something to be shared across different applications, specifying fonts does not make much sense.

This way it should be relatively easy to write a bare bones display
engine, and then extra features could be gradually added to it over
time.

Here, I agree again. Chances are my app will stay on the lower end of layout-features...

One question I'd like to hear opinions about:  if we're allowing the
user to create new specialized widgets, should we use an
object-oriented inheritance scheme, or do everything by delegation?
For example, I said I'd like to see a string selector being used by
the varselector that Thomas described.  But that could be done in two
ways:  either the varselector is a descendant of a string selector, or
it's a new component that contains a string selector.  Opinions?  (For
what it's worth, Delphi uses the inheritance system, and it works
pretty well, so that's where I'd lean.)

Hmm. Now I really do think, we're talking about something different. In my framework a user would not want to and would not be able to derive from anything. The XML-files I'm proposing would be much like HTML in some ways. You can use this widget or that and potentially get a bit of scripting, but how would the user (i.e. the plugin-writer) be able to derive from anything? After all, in my case it's the app that somehow has to makes sense of the plugin, not the user writing the whole application, so the application would need to know beforehand, what widget A provides and what widget B can understand.
Perhaps you can provide a (rough) example of how and where this would be used?

Thomas

On Mon, 25 Nov 2002 21:09:40 +0100 (MET), you wrote in message
<permail-200211252009404294-friedtcb@ruhr-uni-bochum.de>:

I think we should start at a lower level (a widget that gives a list
of strings to select from), and then implement a list of available
objects as a string list widget that has been populated by the names
of available objects.

Well, this may be going a bit into details already, but do we really need this? Do you ever need to select strings from a list, that do not represent R-objects? 

The example I'm thinking of is a dialog box at the side of a graph,
where you can make changes to the way the graph is generated.  For
example, if you want to plot densities, you might have a set of
radiobuttons to choose which distribution, or you might prefer to have
a string list of their names.  The radiobuttons work well when there
are a small number of choices, the string list works better when
there's a long list.

We also need buttons, and the ability to attach actions to user
actions.  (E.g. click on a button  or change the entry in a widget and
execute some R code). 

Do we? Of course the GUI-itself does need some buttons e.g. for executing R-code, but there should be no need to explicitely define those. They should simply be generated by the application, not stated in the "plugin".

I don't know what you mean by this.  I think you're right, that we're
talking about different things.

I still believe, we're partially talking about different things. Whether the application wants to show a help-menu on a right-click somewhere or on a hover, whether something gets pasted into a field or typed manually etc. should entirely be the responsibility of the application, not be defined inside an XML-file to be shared across projects. That's what I mean when talking about "high" level - the XML-specification should really say nothing about what happens when you right-click on some button. It should allow you to state: "Ok, I need this standard-R-widget here that represents a numeric value. If it happens to provide the functionality for a context-help (by whichever means), display the text specified. If it happens to support a header-label, display that other text here. I don't care what it looks like, and I don't care, whether the value is read from a silly slider or some more serious control. Just put it there."

I agree with the second part, but I think we also want to allow the
GUI to generate events.

We should also have a tree view widget, and a free text entry widget.

It probably makes sense to have a widget for entering longer texts, but do we really need a separate tree-view? What else would you want to put in there, if not the available variables?

"Lists" in R are really trees.  It would be nice to be able to look at
them that way, expanding and collapsing the various branches.

I'm not sure why this needs to generate R code.  Why not just have a
function to retrieve the values of all widgets that have values?

Umm, yes, exactly that. And that function would result in some R-code. Or are we talking about something different here?
Let me post again the section in my example:

<code>
  t.test ($x$, $y$, "$hypothesis$")
</code>

The way I was thinking about things is that we'd have a high level
parser that would translate what you wrote above into some detailed
GUI representation (probably a dialog box with 3 labels beside 3 text
entry fields).  But there should be other ways to generate the GUI
components.

Duncan

The example I'm thinking of is a dialog box at the side of a graph,
where you can make changes to the way the graph is generated.

I admit, I had not spent too much thinking on interactive graphs, yet. That does indeed change some things.

For
example, if you want to plot densities, you might have a set of
radiobuttons to choose which distribution, or you might prefer to have
a string list of their names.  The radiobuttons work well when there
are a small number of choices, the string list works better when
there's a long list.

Ok, that makes sense.

I agree with the second part, but I think we also want to allow the
GUI to generate events.

I can now see, that for the above example, this makes a lot of sense. I'd want to keep thing as simple as possible though, and allow only a limited set of events. One such event might be something like a "submit", i.e. make R e.g. redraw the graph whenever you switch a certain option. What else would we need?

"Lists" in R are really trees.  It would be nice to be able to look at
them that way, expanding and collapsing the various branches.

Ok, but, but wouldn't it be good enough, if the "varselector" could simply display them that way? Do we need it in any other context (except from simply browsing objects, which IMHO would not need to be realized as a plugin)?

<code>
  t.test ($x$, $y$, "$hypothesis$")
</code>

The way I was thinking about things is that we'd have a high level
parser that would translate what you wrote above into some detailed
GUI representation (probably a dialog box with 3 labels beside 3 text
entry fields).  But there should be other ways to generate the GUI
components.

This time, we're not only talking about different things, but I can also explain in which respect ;-). The section I quoted is just a small part of the example XML-file. It is NOT about describing the layout or even about specifying what types of GUI-components there should be. There is another section (<layout></layout>) which defines which ("high-level") widgets should be placed where, what kind of values (e.g. numeric) they require, how they are labeled, whether it is mandatory to fill them... See the whole thing in the r-sig-gui-archives somewhere around two weeks ago.
The <code/>-section is only about, how R-code is to be "generated" from the selections made, and in this case means: Take the values of the widgets "x", "y", and "hypothesis" (two varslots and one radiobutton-group in this case) and insert them into a string as shown.
The resulting string is what gets sent to R, when the user presses (in my case) "Submit" (and also the (partially) completed command is shown while the user is making selections, so you can watch the command being put together).
So again, do you think, a simple search-and-replace will be good enough for most purposes, and if not, what should we go for?

Thomas

See the whole
thing in the r-sig-gui-archives somewhere around two weeks ago.

I might add, look at http://rkward.sourceforge.net/images/ttest_plugin.png , to see the dialog created from that file. It's a bit more than just three text-fields...

The section I quoted is just a small part of the example XML-file. 

Yes, sorry about that.  I did read your earlier post and still have a
copy of it, but I forgot the context.

I haven't really been talking about your whole plugin idea at all,
I've been concentrating on what you called the layout section---but as
you've pointed out, at a lower level.

Duncan Murdoch

I think at this point, we should not try to reinvent the wheel: the
mechanism used in Splus (although there are some part of the dialog boxes
implementation in Splus that I hate), and even better, in Matlab are good
example of powerful dialog boxes building. There is the possibility to
define a CallBack function for each user interaction with the dialog box.
Thus, the treatment is then passed to the calculation engine, and is done
natively (no need to duplicate a parser, if-then-else, and the like). In
Matlab, there is a possibility to build such an interactive graph with
control button that Duncan envisions.

However, as powerful is this callback mechanism, in my experience, it is not
easy to figure out how to construct even the simplest dialog box this way. I
am now used to do it, but not all my collaborators understand this approach
yet! Consequently, I am not opposed to an alternative way of managing the
dialog box that could be easier, like the simple replacement mechanism
proposed by Thomas. I believe that both should be available simultaneously
(one for simplicity, the other one for power).

Considering the layering mechanism, I think a similar approach should be
favoured:
- a simple, almost automatic layering mechanism based on a grid for quick
and easy building of simple dialog boxes,
- and a finer mechanism for more complex layering requirements.

Lukily enough, it seems both of you (Thomas and Duncan) are complementary in
this approach. So, let's use a AND, instead of a OR, here ;-)

Thomas

-----Message d'origine-----
De : r-sig-gui-admin@stat.math.ethz.ch
[mailto:r-sig-gui-admin@stat.math.ethz.ch]De la part de Thomas
Friedrichsmeier
Envoye : lundi 25 novembre 2002 22:42
A : r-sig-gui@stat.math.ethz.ch
Objet : Re: [R-gui] Another R-GUI

The example I'm thinking of is a dialog box at the side of a graph,
where you can make changes to the way the graph is generated.

I admit, I had not spent too much thinking on interactive graphs, yet. That
does indeed change some things.

For
example, if you want to plot densities, you might have a set of
radiobuttons to choose which distribution, or you might prefer to have
a string list of their names.  The radiobuttons work well when there
are a small number of choices, the string list works better when
there's a long list.

Ok, that makes sense.

I agree with the second part, but I think we also want to allow the
GUI to generate events.

I can now see, that for the above example, this makes a lot of sense. I'd
want to keep thing as simple as possible though, and allow only a limited
set of events. One such event might be something like a "submit", i.e. make
R e.g. redraw the graph whenever you switch a certain option. What else
would we need?

"Lists" in R are really trees.  It would be nice to be able to look at
them that way, expanding and collapsing the various branches.

Ok, but, but wouldn't it be good enough, if the "varselector" could simply
display them that way? Do we need it in any other context (except from
simply browsing objects, which IMHO would not need to be realized as a
plugin)?

<code>
  t.test ($x$, $y$, "$hypothesis$")
</code>

The way I was thinking about things is that we'd have a high level
parser that would translate what you wrote above into some detailed
GUI representation (probably a dialog box with 3 labels beside 3 text
entry fields).  But there should be other ways to generate the GUI
components.

This time, we're not only talking about different things, but I can also
explain in which respect ;-). The section I quoted is just a small part of
the example XML-file. It is NOT about describing the layout or even about
specifying what types of GUI-components there should be. There is another
section (<layout></layout>) which defines which ("high-level") widgets
should be placed where, what kind of values (e.g. numeric) they require, how
they are labeled, whether it is mandatory to fill them... See the whole
thing in the r-sig-gui-archives somewhere around two weeks ago.
The <code/>-section is only about, how R-code is to be "generated" from the
selections made, and in this case means: Take the values of the widgets "x",
"y", and "hypothesis" (two varslots and one radiobutton-group in this case)
and insert them into a string as shown.
The resulting string is what gets sent to R, when the user presses (in my
case) "Submit" (and also the (partially) completed command is shown while
the user is making selections, so you can watch the command being put
together).
So again, do you think, a simple search-and-replace will be good enough for
most purposes, and if not, what should we go for?

Thomas

_______________________________________________
R-SIG-GUI mailing list
R-SIG-GUI@stat.math.ethz.ch
http://www.stat.math.ethz.ch/mailman/listinfo/r-sig-gui

I'm not sure why this needs to generate R code.  Why not just have a
function to retrieve the values of all widgets that have values?

Umm, yes, exactly that. And that function would result in some R-code. Or
are we talking about something different here?
Let me post again the section in my example:

<code>
   t.test ($x$, $y$, "$hypothesis$")
</code>

Just to mention the very elegant way used by Splus: all features of the
dialog box are described in a data frame. The data frame is passed to
callback functions that can modify some of its features and return a
modified data frame. In turn, the GUI actualizes the dialog box according to
these modifications.

Just a mention also, of the tcltk package approach, where every single
interaction with the dialog box is translated somehow into a R command.

These are two extremes approaches. I must admit I favor the first one,
because:
1) for Sciviews, the GUI needs to remain as much independent of the
"calculation kernel" as possible (the same GUI allows to connect to
different "calculation kernels" like R, Splus, Matlab, Octave, Scilab,
Ox,...) and
2) there is a difficulty if the dialog box is managed directly by the
calculation kernel: since the dialog box is event-driven, the calculation
kernel must be ready to respond immediately at any time when the dialog box
is displayed (otherwise, when the user clicks somewhere, there could be a
sensitive delay before the program responds if it is processing something
else and this gives the impression that everything is locked). Consequently,
either it is not possible to trigger (long) calculations during the display
of dialog boxes, or the calculation kernel must be reworked to allow some
king of parallelism (not easy!).

Philippe