[R-gui] [Rd] R GUI considerations
Philippe Grosjean
phgrosjean at sciviews.org
Mon Oct 17 19:50:40 CEST 2005
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:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFDU9h19p/Jzwa2QP4RAmYjAJ992GZhsa2XXu+RgC2ma7WlnmfvJQCeK1AS
> nf7SVZeZsoS4Q9gaigI6U8c=
> =r1zP
> -----END PGP SIGNATURE-----
>
>
More information about the R-SIG-GUI
mailing list