RAqua

RAqua is really beginning to look good. There are some things
I don't like, though. Better have them out in the open. Some of
them are probably in line to be fixed anyway. I am adding a
little wish list.

Having input and output in different windows, or in different
sections of one window, is bad, because it breaks the
perceptual link between input and output. After a while, the user does
not know anymore which input produced which output, and
so on.

It was talking with Simon (Urbanek) that convinced  me to implement the 
console this way, but it can be changed in principle letting the user 
specify what he likes more.
BTW, I think the user always know what he has done because I copy input 
to the output before processing. If you look at the R Console Out, you 
should noticed that. I had in mind this and I think it is a good 
compromise. For example pipes based front end don't do this if I 
remember well.
But my goal is to let people choose what they prefer :)

Having buffered output makes this even worse. If my
program takes one hour and does 100 iterations, I want
it to write something to the terminal. Otherwise I dont even
know if it's running, and the link between my actions and
what I see gets even more lost. It's like submitting a
batch job to your local mainframe.

I absolutely agree. I have to solve this, but this is somewhat related 
to the eventloop. I'll try to fix on my own, but as soon as the 
REventLoop scheme is implemented in R it should disappear.

In case you have any hints to give this is what I actually do: I simply 
run and quit the eventloop each time 
(RunApplicationEventLoop/QuitAppEventLoop). This gives me very 
simplified code and let me to use all the standard handlers by apple. 
This also will allow me a rapid migration to Cocoa as soon as I 
understand how to mix objective C inside R.

Having a monolithic application is ultimately is mistake,
I think, although it may be a useful option. A large framework
with all of R, except for a small GUI application which can
be anywhere (not necessarily in /Applications, which I
treat like /usr, so  it only contains Apple provided stuff).
Other GUI's share the framework, including Terminal
and future GUI's written in RCocoa (I wish).

I agree on this point too but it will imply very hard work and it 
should be taken under big consideration.

But, let me say, I think that the high priority has to be given to 
RAqua at the moment, the target being R-1.8.0.
My reasoning is the usual one: many people used Carbon R and don't want 
to deal with term/x11 or whatever.
They simply want a double-clicking app that they find where they expect 
it to be, i.e. inside /Applications.

The choice of putting all inside /Applications is due to the fact that 
I want to leave the system untouched as much as possible with the idea 
that, for example, my Darwin/X11 R can live in /usr/bin without 
interfere.
But of course I can leave StartR inside App and move the rest outside.

The default working directory seems to be set to /,
which is obviously a bad idea.

yes, this is a configuration bug I'm going to fix.

The search stuff in R.help does not work (no doubt
an applet problem).

not sure, but I'll check thanks.

We need: a source code editor, either external and
linked to RAqua, or included. We need: R services
(Evaluate Command, Evaluate Expression, Search in
Manual from any Cocoa application).

An internal editor I can implement is just a text editor like the old 
in Carbon R.
But I'll also reimplement the AppleEvent facility. This let RAqua being 
AppleScriptable and allows also for interprocess communication as it 
was with Alpha and Carbon R

Good idea the services.

The menu items send R commands to the Console. I
think it would be OK to have them send commands to
a history window (perhaps marked as having
been send from a menu), but having them in the console
sort of makes using Menu commands look rather stupid
(it says: if you had known what you were doing, you would have
used the console in the first place).

or it can be: you wanted to to this, well here is the corresponding R 
Command.
But I agree it is lazyness.

It is known that there is a hidden API to access the Window
Manager from command-line applications. If we knew what
the commands were, we could use Terminal.app and we
could uses pipes, so I hope Apple will release this at some
point.

I would be pleased to have these ...argh
have you seen the recent sample code by apple on running carbon code 
from X11 apps?
They open some carbon dialogs from x11 app. But there is still the 
problem of event loop, you cannot have both (X11/Carbon) event loop 
running...or at least it is what I have understand.

Thanks for all this remark, they have been very useful.

stefano

p.s. do not make distinction between RAqua and RCocoa. The RAqua is 
intended to be an Aqua GUI for R which is now implemented using Carbon 
API but can be rewritten (I hope shortly) using Cocoa.

Ah .. what I mean by RCocoa is an R interface to Foundation and AppKit
(like Pyobjc). Just a gleam in my eye.

p.s. do not make distinction between RAqua and RCocoa. The RAqua is  
intended to be an Aqua GUI for R which is now implemented using Carbon  
API but can be rewritten (I hope shortly) using Cocoa.

===
Jan de Leeuw; Professor and Chair, UCLA Department of Statistics;
Editor: Journal of Multivariate Analysis, Journal of Statistical  
Software
US mail: 9432 Boelter Hall, Box 951554, Los Angeles, CA 90095-1554
phone (310)-825-9550;  fax (310)-206-5658;  email: deleeuw@stat.ucla.edu
homepage: http://gifi.stat.ucla.edu
   
------------------------------------------------------------------------ 
-------------------------
           No matter where you go, there you are. --- Buckaroo Banzai
                    http://gifi.stat.ucla.edu/sounds/nomatter.au