[Rd] [R-gui] R GUI considerations
Philippe Grosjean
phgrosjean at sciviews.org
Mon Oct 17 20:45:17 CEST 2005
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!
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
>
>
More information about the R-devel
mailing list