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

[Thomas Friedrichsmeier]

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.

Regards
Thomas

---------------- OT below this line ----------------

> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <https://stat.ethz.ch/pipermail/r-devel/attachments/20110601/40bb3bed/attachment.bin>