Hello, This message is little off-topic in R-help. Sorry for that, but not all interested people are wired yet to r-sig-gui (http://www.stat.math.ethz.ch/mailman/listinfo/r-sig-gui). Thanks for your comprehension. A preview version of SciViews (a Graphical User Interface for R under Windows, http://www.sciviews.org) was released a few weeks ago. Since then, the Web site recorded several thousands of downloads. I would really appreciate your feedback: - What you like, - What you don't like, - Wich features you would like to get in the next release. I got already some comments. I will post a summary in a while in r-sig-gui. Best, Philippe Grosjean P.S.: we are working now mainly on features like a complete object explorer and "libraries" (that is, graphical menus in the form of graph galleries, electronic reference cards, assistants,...). ...........]<(({?<...............<?}))><............................... ) ) ) ) ) ( ( ( ( ( Dr. Philippe Grosjean ) ) ) ) ) ( ( ( ( ( LOV, UMR 7093 ) ) ) ) ) Station Zoologique ( ( ( ( ( Observatoire Oc?anologique ) ) ) ) ) BP 28 ( ( ( ( ( 06234 Villefranche sur mer cedex ) ) ) ) ) France ( ( ( ( ( ) ) ) ) ) tel: +33.4.93.76.38.18, fax: +33.4.93.76.38.34 ( ( ( ( ( ) ) ) ) ) e-mail: phgrosjean at sciviews.org ( ( ( ( ( SciViews project coordinator (http://www.sciviews.org) ) ) ) ) ) .......................................................................
Feedback about SciViews?
9 messages · Philippe GROSJEAN, Martin Maechler, Byron Ellis +5 more
"PhGr" == Philippe Grosjean <phgrosjean at sciviews.org>
on Tue, 29 Apr 2003 09:56:22 +0200 writes:
PhGr> Hello, This message is little off-topic in
PhGr> R-help. Sorry for that, but not all interested people
PhGr> are wired yet to r-sig-gui
PhGr> (http://www.stat.math.ethz.ch/mailman/listinfo/r-sig-gui). Thanks
PhGr> for your comprehension.
PhGr> A preview version of SciViews
PhGr> (a Graphical User Interface for R under Windows,
=============
PhGr> http://www.sciviews.org) was released a few weeks ago.
R for Windows already comes with a (simple) GUI.
Many of the R developers would rather think mostly about GUI
efforts that are platform INDEPENDENT, such as the standard Tcl/Tk
package (try "library(tcltk)" and the demos from "demo(package =
"tcltk")" in R), and the RGtk (http://www.omegahat.org/RGtk/) one.
For that reason, in the Bioconductor project (http://www.bioconductor.org),
the "tkWidgets" package has been developed (built on top of R's
standard "tcltk" package -- which from 1.7.0 on does not need
extra efforts for installation on Windows).
Excuse that this sounds a bit negative, but platform independence
is one of the strengths of R.
Martin Maechler <maechler at stat.math.ethz.ch> http://stat.ethz.ch/~maechler/
Seminar fuer Statistik, ETH-Zentrum LEO C16 Leonhardstr. 27
ETH (Federal Inst. Technology) 8092 Zurich SWITZERLAND
phone: x-41-1-632-3408 fax: ...-1228 <><
On Tue, 29 Apr 2003 11:31:44 +0200, you wrote:
R for Windows already comes with a (simple) GUI. Many of the R developers would rather think mostly about GUI efforts that are platform INDEPENDENT, such as the standard Tcl/Tk package (try "library(tcltk)" and the demos from "demo(package = "tcltk")" in R), and the RGtk (http://www.omegahat.org/RGtk/) one.
That's true, but as the Windows maintainer, I would *love* to have an alternative to Rgui. The Graphapp package that underlies it is not easy to work with. I think the best long term strategy is to have a clean division between the user interface aspects of R (which are necessarily platform dependent) and the underlying computing engine (which should be platform independent). It should be as easy to experiment with the user interface as it is to experiment with other aspects of statistical computing. TCL/TK is one way to realize this, but should not be the only one. Duncan Murdoch
On Tuesday, April 29, 2003, at 07:13 AM, Duncan Murdoch wrote:
On Tue, 29 Apr 2003 11:31:44 +0200, you wrote:
R for Windows already comes with a (simple) GUI. Many of the R developers would rather think mostly about GUI efforts that are platform INDEPENDENT, such as the standard Tcl/Tk package (try "library(tcltk)" and the demos from "demo(package = "tcltk")" in R), and the RGtk (http://www.omegahat.org/RGtk/) one.
That's true, but as the Windows maintainer, I would *love* to have an alternative to Rgui. The Graphapp package that underlies it is not easy to work with. I think the best long term strategy is to have a clean division between the user interface aspects of R (which are necessarily platform dependent) and the underlying computing engine (which should
Precisely. I would actually say that R is -not- platform independent in that it expects a certain type of GUI--- a shell process living on STDIN and STDOUT that talks to an out-of-process Window Server of some sort. Most of the work done in the Windows GUI is spent faking that environment to make R think its still running on a X Server somewhere and similar work was done for the Mac/Carbon port (obviously, Darwin R can happily use Apple's X server). REventLoop takes some steps as does the work on embedding, but its still safer to run the "GUI" stuff out-of-process and even then not foolproof. If you want true platform independence you really have to consider independence in terms of style of interaction as well as operating system. Some people really dig on ESS, some like to click things. Personally, I like my plots inline with my code. All should be able to first-class GUI citizens if they so desire.
be platform independent). It should be as easy to experiment with the user interface as it is to experiment with other aspects of statistical computing. TCL/TK is one way to realize this, but should not be the only one. Duncan Murdoch
_______________________________________________ R-SIG-GUI mailing list R-SIG-GUI at stat.math.ethz.ch https://www.stat.math.ethz.ch/mailman/listinfo/r-sig-gui
Byron Ellis (bellis at hsph.harvard.edu) "Oook" - The Librarian
1 day later
On Tue, 29 Apr 2003, Byron Ellis wrote:
On Tuesday, April 29, 2003, at 07:13 AM, Duncan Murdoch wrote:
I think the best long term strategy is to have a clean division between the user interface aspects of R (which are necessarily platform dependent) and the underlying computing engine (which should
Precisely. I would actually say that R is -not- platform independent in that it expects a certain type of GUI--- a shell process living on STDIN and STDOUT that talks to an out-of-process Window Server of some sort. Most of the work done in the Windows GUI is spent faking that environment to make R think its still running on a X Server somewhere and similar work was done for the Mac/Carbon port (obviously, Darwin R can happily use Apple's X server). REventLoop takes some steps as does the work on embedding, but its still safer to run the "GUI" stuff out-of-process and even then not foolproof.
At the risk of starting a religous war, isn't java the obvious choice for a platform independent GUI ? I know java suffered a lot from early over hypeing when it wasn't really ready, but in the last year or two I've seen some very impressive platform independent GUI's built with java. just my tuppence worth... Luke
Luke Whitaker wrote:
At the risk of starting a religous war, isn't java the obvious choice for a platform independent GUI ? I know java suffered a lot from early over hypeing when it wasn't really ready, but in the last year or two I've seen some very impressive platform independent GUI's built with java.
As long as it doesn't end up like Matlab's java gui. Last summer vacation our systems guys upgraded matlab to the latest version with the new gui. On the first day of term in September, 25 students sat down to a lab session, typed 'matlab' and the very hefty Sun machine to which they (and many other people round campus) were connected fell rapidly to its knees. I suggested to the systems guys that they hard-code the '-nojvm' option into the startup script, the other option being to tattoo the same option onto every matlab user's knuckles. I think they liked the latter, and offered to provide rusty needles. Yes, java GUIs are a great idea with the platform independence and the swing toolkit configurability (it looks like Windows! no, its Motif! no its CDE! a new skin every day) but on a multi-user machine its very easy to kill it. There are other cross-platform UI toolkits around that dont use Java. FLTK springs to mind: http://www.fltk.org/
just my tuppence worth...
I've probably thrown in halfpence. Baz
Luke Whitaker <luke at inpharmatica.co.uk> writes:
At the risk of starting a religous war, isn't java the obvious choice for a platform independent GUI ? I know java suffered a lot from early over hypeing when it wasn't really ready, but in the last year or two I've seen some very impressive platform independent GUI's built with java.
Not for R. One could argue for Python in the same light, as well. Or even Emacs :-) (yes, it can be done-up with GUI-like features). best, -tony
A.J. Rossini rossini at u.washington.edu http://software.biostat.washington.edu/ Biostatistics, U Washington and Fred Hutchinson Cancer Research Center FHCRC:Tu: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email UW : Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX CONFIDENTIALITY NOTICE: This e-mail message and any attachments ... {{dropped}}
On Wed, 30 Apr 2003 17:29:36 +0100 (BST), you wrote:
At the risk of starting a religous war, isn't java the obvious choice for a platform independent GUI ? I know java suffered a lot from early over hypeing when it wasn't really ready, but in the last year or two I've seen some very impressive platform independent GUI's built with java.
I think the issue is that it's hard now to write any GUI at all, because too much UI is in R itself. As we move towards a separation of UI and computation, it may well make sense to write a GUI in Java. Duncan Murdoch
At 5:29 PM +0100 4/30/03, Luke Whitaker wrote:
On Tue, 29 Apr 2003, Byron Ellis wrote:
On Tuesday, April 29, 2003, at 07:13 AM, Duncan Murdoch wrote:
> I think the best long term strategy is to have a clean division > between the user interface aspects of R (which are necessarily > platform dependent) and the underlying computing engine (which should
Precisely. I would actually say that R is -not- platform independent in that it expects a certain type of GUI--- a shell process living on STDIN and STDOUT that talks to an out-of-process Window Server of some sort. Most of the work done in the Windows GUI is spent faking that environment to make R think its still running on a X Server somewhere and similar work was done for the Mac/Carbon port (obviously, Darwin R can happily use Apple's X server). REventLoop takes some steps as does the work on embedding, but its still safer to run the "GUI" stuff out-of-process and even then not foolproof.
At the risk of starting a religous war, isn't java the obvious choice for a platform independent GUI ? I know java suffered a lot from early over hypeing when it wasn't really ready, but in the last year or two I've seen some very impressive platform independent GUI's built with java.
Not unless it's a whole lot better than Insightful's initial effort on Solaris. The GUI itself (i.e., how it operated, what menus were where, etc.) was fine, but it was completely useless for anyone sitting at a remote host, due to dreadful image quality and poor performance when displaying anywhere other than on the console of the machine on which SPlus was actually running. (maybe it was ok displayed on a remote host of the same architecture; I don't remember; but neither I nor any of the potential additional users was) -Don
just my tuppence worth... Luke
______________________________________________ R-help at stat.math.ethz.ch mailing list https://www.stat.math.ethz.ch/mailman/listinfo/r-help
-------------------------------------- Don MacQueen Environmental Protection Department Lawrence Livermore National Laboratory Livermore, CA, USA