[R-SIG-Mac] Re: RAqua
jago at mclink.it
Wed Jul 2 20:15:37 MEST 2003
On Mercoledì, lug 2, 2003, at 18:43 Europe/Rome, Jan de Leeuw wrote:
> 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
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
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
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
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.
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.
More information about the R-SIG-Mac