-----Original Message-----
From: r-sig-gui-bounces@stat.math.ethz.ch
[mailto:r-sig-gui-bounces@stat.math.ethz.ch] On Behalf Of
James.Callahan@CityofOrlando.net
Sent: Thursday, November 18, 2004 2:48 AM
To: r-sig-gui@stat.math.ethz.ch
Subject: [R-gui] Auto-GUI: Automated Building of GUIs for Objects
Developing a GUI for R is hard -- even at the conceptual
level (let alone
coding) -- because there is neither a unique path, nor a
unique destination.
First, There is no one definitive GUI toolkit in the
open-source community. Moreover, the type of person attracted
to R development -- sees 50 different ways of accomplishing
the task. The closest solution I have seen is someone on this
list developing an R interface to GUIs that provides a common
R interface to multiple GUI toolkits.
Second, it is not clear what the GUI destination is. Given a
clear idea of the destination, R developers find or develop
the tools they need.
On 17-Nov-04 Philippe Grosjean wrote:
2) Second case: I write an original analysis and I want to make it
available for oceanographers. Most of them do not want, and will
never
learn> > the S language. They obviously need a simple and easy GUI
on top of
function, because they want to run the analysis without
One thought I have been toying with is that of an "Auto-GUI"
tool that would look at an R object and attempt to build a
GUI for it. The analogy would be the "Auto-Form" tool in MS
Access (or the better implementations of the same idea in
Lotus Approach or even in dBASE III). The DBMS looks at the
table and mechanically builds a form. The user has requested
that Auto-GUI build an MS-Office style menu for an object.
Auto-GUI looks at the object, sees that it has a print method
and attaches the "print method" to "File-Print" option on the
faux-Office menu. Auto-GUI looks at the data structure and
provides a tabular view (spreadsheet like) view of the data
on one tab. Auto-GUI sees one or more plot methods and
provides separate tabs for various plots (some more complex
plots may be lazy loaded, the plot isn't drawn till the user
clicks on the tab). So far, this just more or less recreates
GNumeric or MS Excel. There should be a model tab. But, what
does a model look like in a GUI?
To me, this is one of the core GUI questions, what does a
model look like
in a GUI? R has a standard syntax for describing a model on
a command
line, but what does a model look like in a GUI? The now
classic MS Office GUI wraps a familiar menu around a visual
representation of an object -- a text document, a worksheet,
a graph, a project, a photo, a database table, a drawing, a
map etc.. How should we visualize models and other R objects?
What is a WYSIWYG representation of a model?
A visual representation of a model could be:
- a simplified (implicit, but not explicit matrix notation)
equation -- similar to the command line interface
- a matrix equation rendered in HTML with hotspot links to
visual representations of the objects represented by the
symbols in the equation
- a stylized version of a graph -- I'm looking at a GGobi
cloud of points and I grab a "plane" symbol I want fitted
through it. I twist the plane to indicate I want to allow curvature.
- a flowchart -- macroeconomic models are often depicted with
flowcharts.
- a tree with right hand (independent) variables converging
towards one or more tiers of left hand (dependent) variables.
I like the idea of a matrix equation rendered in HTML for
output. I am frightened by the thought of students learning
statistics as locations in a particular vendor's report. the
student learns to look in a particular location on the output
for a certain useful number. Which is fine till they switch
between stat packages such as switching between SPSS and SAS
or SAS and R. If students are going to remember by location,
then let them remember the location in the context of a
matrix equation. The Auto-GUI with an output screen
consisting of a matrix equation rendered in HTML is one
possibility, but it still might not be the best way to do it.
Suppose I have a graph of a histogram and then drag and drop
a bell-shape curve onto it -- what should happen?
Just some incomplete thoughts....
Jim Callahan
Management, Budget & Accounting
City of Orlando
(407) 246-3039 office
(407) 234-3744 cell phone
[[alternative HTML version deleted]]