Re: [Rd] GUI hooks in R [Was: assignInNamespace and new bindings]

From: Thomas Friedrichsmeier <thomas.friedrichsmeier_at_ruhr-uni-bochum.de>
Date: Wed, 01 Jun 2011 19:50:01 +0200

On Wednesday 01 June 2011, Simon Urbanek wrote:
> I suppose, yes, it's possible, but I see somewhat of an asymmetry if done
> that way : GUIs are like plug-ins in that there is a set of functions they
> have to implement to work properly. In the current state this is done
> using the C-level hooks, but they are incomplete in that some of the
> required hooks are not available on all platforms. However, if you
> introduce an additional layer of R function hooks, there will be two sets
> of competing ways for the GUI so register and some of them are simply not
> feasible on the R level (console handling, for example, which is why we
> have C-level hooks).

Well we already have both, at least in some parts. See e.g. options() "pager" and "editor" (which have dupes on the C level, some of which are not crossplatform,  again), and "browser" (which is a likely candidate for GUIcustomization,  and does not have a C equivalent). Possibly options("error"), too, and perhaps some others.

Options on the R level have some obvious advantages, e.g. it is not quite as impossible to change the function signature at a later point of time. Also keep in mind that GUIs will almost certainly comprise some R code, but do not necessarily have to have C code. Think tcltk or RGtk based UIs, for instance. Why shouldn't these have an easy way to customize select.list(), for instance. Finally, having this in options() will allow power-users to utilize selected GUI elements, whereever they like (or to disable their GUIs graphical dialogs for some features).

Also, I can give you a bunch more UI functions that I would like to be able to customize cross-platform. From the top of my head: - Yes / no / cancel questions (graphical only on Windows, currently, but why not let the hosting GUI decide?)

- readline()
- Progress bars
- Adding menus (several GUIs bring their own functions for this, but there is 
no standard API. Thus packages have a hard time integrating with more than just one GUI.)

Do you seriously want to have a C API for all of these?

> It also makes the GUI unnecessary messy, since they
> will need to provide both C code and R code, where the R code essentially
> just points to C code, practically replicating what the C-level hooks
> would do (just more complicated as it requires embedded symbol
> registrations etc.).

Personally, I find that easier than even setting the C pointers cross-platform (because the way to set these is platform specific).  

> Currently I'm more inclined to make the hooks cross-platform (maybe
> conditional on the GUI type set to "custom" or something like that). But
> if someone wants to devise some nice way of customizing parts using R
> callback, I won't oppose it.

Well, if that stands *real* chances of being included, I will happily make a start (and take the discussion to R-SIG-GUI).

> If you have issues with stdout buffer before the pipe, use can use
> setvbuf() to disable buffering.

Well, actually I capture the stdout in a separate process (RKWard uses two processes, anyway). Perhaps moving all output capturing to one process might fix my interleaving issues without the need to mess with system[2](). I'll give that a try.  

> Cautiously I would argue you have to the moment you're outside R,
> essentially since the built-in graphics devices are not guaranteed to work
> when embedded. In practice, I think if you write a GUI, you have to
> provide a GD - that is the only reasonable way you can seamlessly
> incorporate R graphics into your GUI.

Not on Windows and X11, at least. Try RKWard on one of these platforms, and see if you can find any seams. Then check your dev.list() to see the underlying devices.

Admittedly, we do not have support for the Quartz device, yet, and this may be harder than Windows and X11, but I'm still optimistic.  

> That said, there is a precedent for graphics hooks. The problem I see is
> the same that became apparent with grid last time we added hooks - there
> are potentially multiple ways to get to the same C level point, and they
> are either easily forgotten, or even hard to enumerate. For example,
> dev.set() is not the only way to activate a device - it can be activated
> from the menu and other means via selectDevice() which is at C level, so
> there is no R code involved at all, thus setting a hook on dev.set() is
> will work only in a subset of cases and thus you cannot expect
> consistency in your GUI.

Well, in our particular use case, we can query the window manager for everything else we need to know. But of course there are several more usecases,  where adding hooks at the R level would not be good enough (one would be multi-device plot history feature).

However, *if* such hooks are going to be integrated into base R, then it _think_, it should be no problem to root these hooks at the C level, rather than the R level.

> (Note: none of my comments are specific to RKWard, since it is not even
> available for OS X so I don't know anything about it)

Well, I can't blame you for not trying it, since compilation on the Mac does take ages, and we don't promise the result is any useful, ATM. We simply don't have a developer with a Mac in the project. But most of the time, you *can* compile RKWard on Mac OS X, and it is known to work at least some of the time.

Regards
Thomas



R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Received on Wed 01 Jun 2011 - 17:53:03 GMT

This quarter's messages: by month, or sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

All messages

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Wed 01 Jun 2011 - 21:00:14 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive