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

From: Thomas Friedrichsmeier <>
Date: Wed, 01 Jun 2011 22:52:32 +0200

On Wednesday 01 June 2011, Simon Urbanek wrote:
> This is a whole different story. So far I have been talking about embedding
> GUIs which use Read/WriteConsole and that is also what the original
> question was about. Obviously you can add toolkit packages, but I don't
> consider those GUIs in the discussed sense.

To the degree that we were talking about RKWard: No, this is not, what the original question was about. But I would be very reluctant about trying to distinguish between different types of GUIs. IMO, GUIs are pieces of software that do GUI stuff.

True, some sets of features go hand in hand. E.g. it seems unlikely, that a GUI will want to provide custom history()-handling, without using Read/WriteConsole on the C level. But many other features could be interesting to a much wider range of use-cases. Why not make it easily possible to write a mini-GUI package, which simply moves some user interaction (yes/no questions, selection from lists, readline()) from the console to graphical dialogs. This does not in any way require embedding, conceptually.  

> My argument was that we should
> clean up the embedding GUIs facilities first by making them consistent
> across platforms. Those should not need to require separate R code.

Very much agreed about making these facilities consistent across platforms. But again, the second point can also be looked at from the other side: Writing a "slim" GUI package should not need to require separate C code.

> > Think tcltk or RGtk based UIs, for instance.
> Those are fairly special in that there are embedding GUIs available as
> examples (although I'm not sure how functional). However you may not have
> meant that aspect of it so the above applies.

No, I meant, you can write GUI functionality entirely in R using these packages, as they already wrap all the C.

> > 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).
> Agreed, but this is a separate question and consideration.

True. But I think it may be possible to enable this within a single solution.

> Not all, see above. However, menus are an interesting example - it can't be
> quite a vanilla customization, because the implementation of the menu
> backend is heavily dependent on what embedding GUI is running R, so it is
> not really a customization as there may not be any choices (e.g., you
> can't use JGR's menu functions in the Mac GUI)

No, but still the GUI can provide functions, whether or not it is an embedding one. Think Rcmdr, which does not embed, but does provide menus, which third party packages may want to add to.  

> A while ago I was proposing a different approach when working on iWidgets -
> there would be a global GUI object that would be used for UI functions so
> they can dispatch on it. Then methods could be written for the various GUI
> object classes implementing different GUIs and behaviors so the R-side
> code would be very simple - just calling generics - whereas the actual
> implementation of those methods could be in any package that is providing
> the current GUI. This would leverage method dispatch as the natural
> selection of behavior. I still like this the best - you could even have
> packages that specialize other GUIs and create subclasses etc. Also now we
> actually have the object system supporting GUI-style semantics (reference)
> in R... Again, this is not for user-side customization but to link UI
> provides with R's UI functions.

Well, on the outcome side, that's not too far from what I have in mind. Let the GUI provide a set of R functions to call for various tasks. I could certainly get along with such a solution, although admittedly, I fail to see the practical point, here. To me, easy user-side customization (starting from scratch or from any particular GUIs defaults) would easily trump the ability to sub-class GUIs.

> Quartz is fairly nice in that you can provide additional back-ends fairly
> quickly - see R_ext/QuartzDevice.h - so you could embed it directly into
> your GUI. (But then I suppose the Mac support is too far away from reality
> for this to be relevant ;))

Well, that's good to know. Practical Mac support is roughly one Mac posession away.


> This is OT so feel free to reply in
> private if you wish -- but why don't you abstract out the interface so
> that you can use native toolkits (like RStudio does - that's one thing
> they did well)?

Two short points:
- The abstraction is there. KDE *can* be compiled natively on Mac (but that's not much less heavy than the X11 variant). We don't recommend this option for RKWard, ATM, because we still lack a solution for the Quartz device (see above), and because I never found the time to test it at all. - Abstracting KDE away from 50.000+ lines of code, much of which *is* precisely about the interface? Yeah, good one. But see, I don't even wish to do away with it. Yes, it is quite a heavy dependency, esp. on the Mac. But it also provides a whole lot of really good features, which are central to RKWard. Trust me, I have taken the time to evaluate my options. mailing list
Received on Wed 01 Jun 2011 - 20:59:12 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 - 23:40:15 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.

list of date sections of archive