[R-gui] Re: R-SIG-GUI digest, Vol 1 #3 - 9 msgs

[Mark Myatt]

List,

Sorry for jumping in the middle of a discussion. I have been in the
field for some time and have only just got back.

Philippe Grosjean, I think, wrote:

>>For the graphical toolkit, it is certainly time to get a clearer idea of
>>which one is the most suitable among Tcl/Tk (+ Tix), Gtk, QT, wxWindows,...
>>As far as I know, Peter Dalgaard (with many others) develops Tcl/tk; Duncan
>>Temple Lang works on Gtk/Gnome. There are already available libraries
>>(including the base R library 'tcltk'). Dan Putler and Zed Shaw recently
>>choose Swing. Is this correct? Any suggestions from specialists are
>>welcome.

My tendency would be to explore how far we can go with Tcl/Tk since the
availability of the tcltk library allows for a good division of labour.
We could have two development efforts:

        1. One team develops the GUI. This I envisage as a sort of IDE
        with a syntax highlighting editor, output window, and an object
        inspector but others might have better ideas. I have already
        gone part of the way with this (syntax highlighting editor,
        output window, customisable menus) in Tcl/Tk but do not have
        time at present to do much more. I suppose this could be done in
        something other than Tcl/Tk. The advantage of Tcl/Tk is that it
        is open, interpreted, and not too difficult to write.

        2. A second team develops tcltk wrappers to R functions to do
        something like an 'SPSS-like' gui. These functions are called by
        the GUI.

One problem is that cross-platform implementation might be tricky since
(possibly parading my ignorance) Windows platforms do not support named
pipes making inter-process communication a lot more tricky than it needs
to be. This might be immensely tricky with Tcl/Tk ... I just don't know.

An alternative might be to take one of the open source IDEs ... there
are loads of these and modify it to meet our needs.

>>Personnally, I develop SciViews under Windows, using OCXes (most are free
>>or
>>shipped with Microsoft Visual Studio, but one is commercial -ActiveBar-).
>>This is not portable at all. This is not open source at all. But I choose
>>it
>>for all the functionnalities I got (and indeed, I started the project many
>>years ago, when many oher graphical toolkits like Gtk or Qt were in their
>>infancy). I consider the current windows implementation of SciViews as a
>>prototype to test various GUI architectures. I would definitely be happy to
>>get rid of all these M$ D-Com, ActiveX and OCXes, but I need:
>>- An advanced text editor with synthax highlighting, "codetips",
>>"auto-completion lists", etc... and I got the free CodeMax with CodeSense
>>(http://www.ticz.com/homes/users/nlewis/HTML/Software_Development/CodeSense/
>>Download/download.htm#uguide) which is wonderful.

I think that the ScITE editor offers similar functionality in an open
source bundle. I think we need to be clear about what we mean by 'free'.
I think this has to mean something like the GPL. You can do all of this
stuff by overloading a standard Tcl/Tk text-widget.

>>- An integrated and context-sensitive menus/toolbars/docking windows
>>system,... and I found ActiveBar
>>(http://www.datadynamics.com/activebar/default.htm) very easy to use and
>>configure.

I think most toolkits (qt, gtk, motif, tk) can do this.

>>- A spreadsheet,... and I got Formula One (shipped with the free version of
>>Borland Delphi) which is very nice.

I seldom use the data-browser in R mostly because I do most data-entry /
management outside of R. I am not sure how important a spreadsheet is.

>>- A decent rich text editor with embedded graphs, etc... and I find the
>>standard richedit.ocx suitable.

I suppose this could be done with HTML or XML.

>>- A html browser,... and the Internet Explorer ocx is performing well
>>(arrghl).

More of these than you can shake a stick at ... Mozilla is popular ...
>From what I am told, Mozilla / Penzilla with XUL good do the entire GUI
thing from within the browser.

>>Yes, I know! You want to kill me now! Perhaps, an alternative would be to
>>convince me that I will find similar features in other graphical toolkits?

The problem with all this is that it is very much Windows based and I
think we should address UNIX (and derivatives such as Linux, MacOS X)
systems as well. This means we are restricted to cross-platform tools
and have to choose the best available.

The other thing that nags me is that we should try and make the UI as
light as possible. I can imagine a situation where the size of the UI
(including support libraries) comes to several times the size of the R
engine and has a huge processing overhead. Let us avoid bloat.

Well, just my tuppence.

Mark


--
Mark Myatt