From andy_liaw at merck.com  Thu Oct 20 16:48:37 2005
From: andy_liaw at merck.com (Liaw, Andy)
Date: Thu, 20 Oct 2005 10:48:37 -0400
Subject: [Rd] [R-gui]      R GUI considerations
Message-ID: <39B6DDB9048D0F4DAD42CB26AAFF0AFAFED513@usctmx1106.merck.com>

> From: Philippe Grosjean
> 
> Duncan,
> 
> I agree totally with you on all points, now that we clarified our 
> respective ideas. I am afraid I probably agree also with your last 
> point, from a theoretical point-of-view ("I still think we need more 
> glue and am working on that while we continue to experiment with the 
> design of GUIs for the next 5 years rather than the immediate 
> needs.").
> 
> I say, from a theoretical point-of-view, because in practice I am not 
> sure all these people waiting for GUIs, like in the projects I cited 
> before, will appreciate we just continue to play in the sandbox for 
> another 5 years!!! They want their GUI delivered... in the 
> next years, 
> or in the next six months, or even closer if possible!

Er, how about yesterday?  (Sorry, couldn't resist...)

Andy

 
> So, a mix between the theoretical approach and the practical 
> needs tells 
> me that it is perhaps time to shorten a little bit the 
> sandbox phase and 
> to move forward right now.
> 
> Best,
> 
> Philippe
> 
> ..............................................<?}))><........
>   ) ) ) ) )
> ( ( ( ( (    Prof. Philippe Grosjean
>   ) ) ) ) )
> ( ( ( ( (    Numerical Ecology of Aquatic Systems
>   ) ) ) ) )   Mons-Hainaut University, Pentagone (3D08)
> ( ( ( ( (    Academie Universitaire Wallonie-Bruxelles
>   ) ) ) ) )   8, av du Champ de Mars, 7000 Mons, Belgium
> ( ( ( ( (
>   ) ) ) ) )   phone: + 32.65.37.34.97, fax: + 32.65.37.30.54
> ( ( ( ( (    email: Philippe.Grosjean at umh.ac.be
>   ) ) ) ) )
> ( ( ( ( (    web:   http://www.umh.ac.be/~econum
>   ) ) ) ) )          http://www.sciviews.org
> ( ( ( ( (
> ..............................................................
> 
> Duncan Temple Lang wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > 
> > Hi Philippe.
> > 
> >  I am sorry that you are upset by what I wrote.
> > I did not intend to cause offense.  And I was
> > not considering you as "just a professor only interested
> > by the results of your students".  However,
> > the discussion has unfortunately degenerated to that
> > common denominator for several people, either implicitly
> > or explicitly and I believe it is important to make
> > certain that the real issues are identified and discussed
> > by being precise about what it is that is being discussed.
> > 
> > I most certainly do thing a "polymorphic" GUI
> > that mixes different components is feasible.
> > Indeed,  I have been working on the integration
> > in general terms for many years and have developed
> > a general infrastructure for integrating such tools
> > in various settings.  What we are discussing is
> > the software architecture for constructing this
> > distinctly focused GUIs.
> > 
> > I think experiments in GUI design are terrific and
> > we need them.  I applaud SciViews for this.
> > And JGR, etc. too. But they don't necessarily
> > allow others to experiment as they are not
> > customizable. Just as users don't necessarily
> > want to learn R to do statistics, R programmers
> > don't necessarily want to learn Java or C++
> > and the specifics of an application like
> > SciViews or JGR to try out small changes.
> > That is why I have long argued that we use
> > the existing common interest that we all have
> > which is R and that we allow people
> > to reuse components of SciViews, etc.
> > 
> > If these are integrated into R so that people can
> > really modify them and construct different GUIS
> > from their elements, that would be terrific.
> > In the meantime, the ability to easily and conveniently
> > do experiments in R does warrant discussing a software
> > architecture that facilitates that and so involves
> > bindings to toolkits, both modern ones and convenient ones.
> > 
> >  Anyway, apologies again for the misunderstanding. I was
> > not considering you in that narrow fashion that came
> > across in my mail.
> > 
> >  Enough said for the moment. All these experiments are good,
> > collaboration is good. The obvious place to do it in my book
> > is in the R language or else have some good glue between the
> > systems.  As much work as I have done on GUIs in the S language
> > in  the last 13 years, I still think we need more glue and
> > am working on that while we continue to experiment with the
> > design of GUIs for the next 5 years rather than the immediate needs.
> > 
> > 
> >  Thanks,
> >   D
> > 
> > 
> > 
> > Philippe Grosjean wrote:
> > 
> >>Duncan,
> >>
> >>Could you, please, stop considering me as just a professor in
> >>biostatistics only interested by the results of my students 
> and nothing
> >>else. Do you need a couple of evidences that I am working with other
> >>people, other applications, and that they require totally different
> >>GUIs? Here they are:
> >>
> >>1) I am the instigator and main programmer of ZooImage
> >>(http://www.sciviews.org/zooimage/), an Open Source system combining
> >>ImageJ and R (mainly) to provide a complete numerical image analysis
> >>system for automating zooplankton samples processing. In the R side,
> >>image measurements gathered by ImageJ are analyzed with the 
> powerfull
> >>machine learning algorithms implemented in R (like random forest,
> >>bundling, ...). After analysis of several samples, they 
> usually form a
> >>space or time series to be analyzed by respective tools, still in R.
> >>Targetted users are biological oceanographers... most of them are
> >>reluctant to "programming" in R (i.e., to write and edit 
> little scripts
> >>to run the analyses), and the others are more accustomished 
> to Matlab.
> >>
> >>2) I participate to the development of FLR 
> (http://flr-project.org/), a
> >>framework for modelling fisheries entirely written with S4 
> objects. The
> >>project is now used in several fisheries evaluation programs, and we
> >>face some problems with modellers and advisors telling they 
> don't want
> >>to have to "learn R" for running their models. Quite different
> >>application and targetted users.
> >>
> >>3) One of the future contracts I mentioned earlier in this 
> post is with
> >>IFREMER, to make a flexible reporting system mixing the report()
> >>functions of SciViews and Rpad to end up with dynamically 
> recalculable
> >>HTML reports (hopefully web-based solution), for instance for weekly
> >>reports on the survey of water quality along the French 
> coast. Again, a
> >>very different application and GUI.
> >>
> >>4) Another contract consists in making an artificial human noise,
> >>analysing results from more than 200 artificial odor receptors. The
> >>people there agree for using R as the "calculation engine", 
> but want a
> >>really simple point and click interface for their analyses, 
> and all the
> >>machinery completely hidden.
> >>
> >>That said, if you consider a polymorphic R GUI that mixes 
> together the
> >>different paradigms (menu&dialog boxes, spreadsheet, notebook-like
> >>interactive documents, ...) is not something possible to 
> do, it is your
> >>problem. My own experience, *including the various 
> different situations
> >>cited here above* make me feel that it is something 
> possible. I don't
> >>want to kill all R GUIs projects in favor of a single one, 
> but I affirm
> >>that we should work in a more collaborative way.
> >>
> >>Best regards,
> >>
> >>Philippe
> >>
> >>..............................................<?}))><........
> >> ) ) ) ) )
> >>( ( ( ( (    Prof. Philippe Grosjean
> >> ) ) ) ) )
> >>( ( ( ( (    Numerical Ecology of Aquatic Systems
> >> ) ) ) ) )   Mons-Hainaut University, Pentagone (3D08)
> >>( ( ( ( (    Academie Universitaire Wallonie-Bruxelles
> >> ) ) ) ) )   8, av du Champ de Mars, 7000 Mons, Belgium
> >>( ( ( ( (
> >> ) ) ) ) )   phone: + 32.65.37.34.97, fax: + 32.65.37.30.54
> >>( ( ( ( (    email: Philippe.Grosjean at umh.ac.be
> >> ) ) ) ) )
> >>( ( ( ( (    web:   http://www.umh.ac.be/~econum
> >> ) ) ) ) )          http://www.sciviews.org
> >>( ( ( ( (
> >>..............................................................
> >>
> >>Duncan Temple Lang wrote:
> >>
> >>
> >>
> >>Philippe Grosjean wrote:
> >>
> >>
> >>>>>Hello Marc and the others (and the User!2006 organizing 
> commitee),
> >>>>>
> >>>>>I answer to Marc's email, because I think it is the most 
> constructive
> >>>>>one. I am a little bit dissapointed that the discussion 
> about R GUIs,
> >>>>>whatever the initial subject, inevitably shifts to an endless
> >>>>>discussion about which graphical toolkit to use, and whether one
> >>>>>should interface it directly, or by means of an 
> intermediary language
> >>>>>perhaps more suitable for handling widgets events.
> >>>>>
> >>>>>Should I recall that this thread is *not* about which graphical
> >>>>>toolkit to use, but is trying to trigger a discussion on 
> how could we
> >>>>>work together to avoid duplication in coding for R GUIs, 
> and perhaps,
> >>>>>join in a common project. Something totally different!
> >>>>>
> >>
> >>
> >>
> >>I think all of us will agree that we have limited resources
> >>and should collaborate where possible.
> >>However, to do this, we must have a common set of interests
> >>that form a reason to collaborate.
> >>Your earlier mail mentioned the link
> >>(http://www.sciviews.org/_rgui/rgui/GUIs.html)
> >>to the different types of GUIs you were considering, be it
> >>a Web-based, or notebook style, or whatever.
> >>
> >>I really think that you have to think about things from 
> other peoples'
> >>perspectives and realize that many of us are not 
> considering "the GUI"
> >>as you are. You seem to have an audience in mind which
> >>  a) need access to a broad range of R functions
> >>  b) are averse to the command line.
> >>It appears you have students in mind, probably non-statisticians
> >>in an introductory class.  That is great. And your approach is
> >>perfectly reasonable to address that need.
> >>
> >>However, others of us have very different goals.
> >>Some of us want specialized GUIs, e.g. GeneGGobi, interfaces
> >>to specific functionality (e.g. random forests), ....
> >>Others of us have been buidling tools for interactive 
> documents, much
> >>like a Web browser embedded in R with complex composite widgets
> >>embedded within the document to have dynamic, interactive documents.
> >>These are very different audiences, and accordingly very different
> >>GUIs.  They require not customization of a general GUI, but
> >>an ability to construct entirely new GUIs.
> >>
> >>Where we can really collaborate is in the development of
> >>GUI components that can be used from within R to construct
> >>these different GUIs.
> >>
> >>I really encourage you to try to consider what other people
> >>are thinking and hopefully this will help us get past the
> >>discussions of specific toolkits, etc.  I think they have
> >>originated from beliefs that we are all talking about variations
> >>of the same student-oriented GUI. In fact, we are talking about
> >>much richer forms of pedagogy and interface.
> >>
> >> D.
> >>
> >>
> >>
> >>
> >>
> >>
> >>>>>I know people that already play the game of 
> collaboration: those I am
> >>>>>working with to bring bridges between their projects and 
> SciViews-R.
> >>>>>There is another person working on general improvements of R for
> >>>>>GUIs: Duncan Murdoch, but this is about RGui.exe, thus 
> for Windows only.
> >>>>>
> >>>>>I support the proposition of Marc Schwartz to dedicate a 
> session in
> >>>>>User!2006 to this subject... but I would like to precise this: it
> >>>>>should be stated clearly that the GUI session would 
> *not* be about
> >>>>>discussing which graphical widgets to use, and *not* on the
> >>>>>presentation of yet another new R GUI project. That 
> session should be
> >>>>>clearly focused on:
> >>>>>- actual examples of use of R GUIs, and the benefit 
> their bring in
> >>>>>practice,
> >>>>>- propositions for developping a common and reusable API 
> for R GUIs
> >>>>>(preferrably written in R to be independent of 
> particular graphical
> >>>>>widgets -I started such a thing in svDialogs, and I 
> think that Simon
> >>>>>Urbanek's Iwidgets is similar in philosophy-),
> >>>>>- bringing bridges between existing R GUI projects,
> >>>>>- identifying cross-platform opportunities.
> >>>>>That session should be followed by an extensive 
> discussion (why not
> >>>>>around a drink, or a good meal?), between interested people. The
> >>>>>discussion should be best focused on:
> >>>>>
> >>>>>1) How and who will install tools for collaborative work on those
> >>>>>common R GUI pieces of code (a CVS or SVN for 
> instance)... we already
> >>>>>have a web site and the R-SIG-GUI, even if these tools 
> are currently
> >>>>>under-used.
> >>>>>
> >>>>>2) How and who will sketch documents summarizing our goals. Of
> >>>>>course, these documents should be editable by everybody. So,
> >>>>>something like a WiKi sounds good here.
> >>>>>
> >>>>>3) In a near future, we will begin to add code in the 
> "common R GUI
> >>>>>tools", of course. This should be pieces of code 
> extracted from the
> >>>>>various R GUI projects. So, we have to draw an initial 
> list of these
> >>>>>pieces of code and who will provide them.
> >>>>>
> >>>>>I CC: this mail directly to the User!2006 organizing committee,
> >>>>>because it is a direct call asking for such a session. 
> Regarding the
> >>>>>organizer,  I wouldn't propose names... someone from the R
> >>>>>developer's team, or a key person in R GUIs topics...
> >>>>>Best,
> >>>>>
> >>>>>Philippe Grosjean
> >>>>>
> >>>>>..............................................<?}))><........
> >>>>> ) ) ) ) )
> >>>>>( ( ( ( (    Prof. Philippe Grosjean
> >>>>> ) ) ) ) )
> >>>>>( ( ( ( (    Numerical Ecology of Aquatic Systems
> >>>>> ) ) ) ) )   Mons-Hainaut University, Pentagone (3D08)
> >>>>>( ( ( ( (    Academie Universitaire Wallonie-Bruxelles
> >>>>> ) ) ) ) )   8, av du Champ de Mars, 7000 Mons, Belgium
> >>>>>( ( ( ( (
> >>>>> ) ) ) ) )   phone: + 32.65.37.34.97, fax: + 32.65.37.30.54
> >>>>>( ( ( ( (    email: Philippe.Grosjean at umh.ac.be
> >>>>> ) ) ) ) )
> >>>>>( ( ( ( (    web:   http://www.umh.ac.be/~econum
> >>>>> ) ) ) ) )          http://www.sciviews.org
> >>>>>( ( ( ( (
> >>>>>..............................................................
> >>>>>
> >>>>>Marc Schwartz wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>>Greetings all,
> >>>>>>
> >>>>>>While recognizing that "this is easier said, than 
> done", is there any
> >>>>>>logic in suggesting that for those who might be interested, a
> >>>>>>specific R
> >>>>>>GUI session of sorts be added to the UseR! 2006 meeting 
> schedule?
> >>>>>>
> >>>>>>Since some quorum of interested GUI users may be 
> planning to attend the
> >>>>>>meeting or may be motivated to do so, it may be an 
> opportunity to:
> >>>>>>
> >>>>>>1. Leverage face to face interaction and visualize 
> possible options
> >>>>>>
> >>>>>>2. Define areas of commonality
> >>>>>>
> >>>>>>3. Bring some level of focus to targeted segments of 
> the user base that
> >>>>>>would utilize a GUI and for whom there may be differing 
> functional
> >>>>>>requirements.
> >>>>>>
> >>>>>>4. Identify cross-platform opportunities and technologies
> >>>>>>
> >>>>>>5. See further notes below...
> >>>>>>
> >>>>>>
> >>>>>>Some of the preliminary work could no doubt be done in 
> advance to
> >>>>>>better
> >>>>>>prepare and structure discussion.
> >>>>>>
> >>>>>>This could be done as a "breakout" session or if there 
> is sufficient
> >>>>>>interest (and facility/funding issues can be resolved) 
> perhaps a group
> >>>>>>session held the day before or perhaps the day after the main
> >>>>>>conference
> >>>>>>program.
> >>>>>>
> >>>>>>If there is a core group that is interested in pursuing this, an
> >>>>>>announcement could be made to the respective R e-mail 
> lists (r-help,
> >>>>>>r-devel, r-sig-gui, etc.) whereby, with the sufficient 
> lead time as we
> >>>>>>have, the requisite activities could be put in place to 
> orchestrate the
> >>>>>>session, define specific desired outcomes and identify 
> individuals
> >>>>>>willing to spend their time to coordinate and make this venture
> >>>>>>successful (however success would be defined).
> >>>>>>
> >>>>>>There is no business or financial motivation here for a 
> GUI. If there
> >>>>>>was and a for profit company decided that there would 
> be a significant
> >>>>>>return on investment, they would spend the money, hire 
> the resources,
> >>>>>>define a team leader and put forth a single development 
> spec for a GUI
> >>>>>>project based upon their own market research. It would 
> be done in a
> >>>>>>relatively authoritarian fashion and if you didn't 
> agree, you would be
> >>>>>>asked to find a job elsewhere.
> >>>>>>
> >>>>>>Here, you would need to solicit voluntary resources, 
> reconcile the
> >>>>>>expected differences of opinion on the spectrum of 
> matters that would
> >>>>>>have to be addressed and define some common framework 
> for operating,
> >>>>>>perhaps based upon targeted user segments.
> >>>>>>
> >>>>>>This subject, as mentioned, has come up on the lists previously,
> >>>>>>with no
> >>>>>>common resolution, resulting of course in the 
> individual activities
> >>>>>>that
> >>>>>>have emerged.
> >>>>>>
> >>>>>>Is there a group of motivated useRs out there, who have 
> the time,
> >>>>>>energy, and skills and are willing to work within the 
> framework of a
> >>>>>>design and development "team" environment, where a quid 
> pro quo for
> >>>>>>moving forward could evolve from the User! 2006 meeting?
> >>>>>>Is there an individual, who would need to emerge from 
> that group, who
> >>>>>>has the respect and requisite skills to drive a 
> consensus of opinion
> >>>>>>and
> >>>>>>keep a team focused and moving in the proper direction?
> >>>>>>
> >>>>>>If so, that might be a step in the direction of 
> evolving a GUI that
> >>>>>>might make sense for some yet to be defined range of 
> useRs, who would
> >>>>>>not otherwise utilize the CLI or might need to evolve 
> in that direction
> >>>>>>over time.
> >>>>>>
> >>>>>>If not, then the status quo continues...
> >>>>>>
> >>>>>>There are some 300 Linux distributions out there and 
> multiple X based
> >>>>>>GUIs, which have evolved for reasons as varied as those 
> behind the
> >>>>>>available R GUIs and more. Yet there are a select few base Linux
> >>>>>>distributions and largely two GUIs that have garnered 
> any significant
> >>>>>>market share. Perhaps, over time, lacking any 
> coordinated activity, a
> >>>>>>similar situation will evolve here, if the predicate 
> that a broad
> >>>>>>demand
> >>>>>>for a R GUI is valid.
> >>>>>>
> >>>>>>If the predicate is false, then this process is perhaps 
> rightly done by
> >>>>>>individuals meeting narrowly focused, local requirements.
> >>>>>>
> >>>>>>I should note, that I am not prospective GUI user, but 
> a happy ESS
> >>>>>>user.
> >>>>>>I simply thought that I would try to provoke some 
> discussion on this
> >>>>>>point, since I jumped into this thread earlier in the week.
> >>>>>>
> >>>>>>Best regards,
> >>>>>>
> >>>>>>Marc Schwartz
> >>>>>>
> >>>>>>______________________________________________
> >>>>>>R-devel at r-project.org mailing list
> >>>>>>https://stat.ethz.ch/mailman/listinfo/r-devel
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>_______________________________________________
> >>>>>R-SIG-GUI mailing list
> >>>>>R-SIG-GUI at stat.math.ethz.ch
> >>>>>https://stat.ethz.ch/mailman/listinfo/r-sig-gui
> >>
> >>
> >>
> >>--
> >>Duncan Temple Lang                duncan at wald.ucdavis.edu
> >>Department of Statistics          work:  (530) 752-4782
> >>371 Kerr Hall                     fax:   (530) 752-7099
> >>One Shields Ave.
> >>University of California at Davis
> >>Davis, CA 95616, USA
> >>
> >>>
> > 
> > - --
> > Duncan Temple Lang                duncan at wald.ucdavis.edu
> > Department of Statistics          work:  (530) 752-4782
> > 371 Kerr Hall                     fax:   (530) 752-7099
> > One Shields Ave.
> > University of California at Davis
> > Davis, CA 95616, USA
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.2 (Darwin)
> > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> > 
> > iD8DBQFDU+ta9p/Jzwa2QP4RAnppAJ9dv+LRlZttkmI8epiPrkU3aUsNjgCeIhGD
> > 5bD+9bu3xIy6Oioy3a63JNo=
> > =s0yj
> > -----END PGP SIGNATURE-----
> > 
> > _______________________________________________
> > R-SIG-GUI mailing list
> > R-SIG-GUI at stat.math.ethz.ch
> > https://stat.ethz.ch/mailman/listinfo/r-sig-gui
> > 
> >
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
>



[Rd] [R-gui] R GUI considerations
Liaw, Andy