> 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
>
>
