[R-gui] Re: R-SIG-GUI digest, Vol 1 #18 - 5 msgs

[thomas.friedrichsmeier@ruhr-uni-bochum.de]

> Well, it's not like the interface has been a whole lot of programming,
> so if there are better ways we should be open towards them (the
> thinking effort has not been quite vanishing though...). I'm more
> worried that we'd be missing some opportunities for using preexisting
> code (we don't need to rewrite the text widget or tkTable!) and end up
> with poor solutions to problems that have already been solved better
> by others.

By all means no! I'm not voting to write a replacement for the Tcl 
text-widget. Some frontends will however chose QTextEdit/QLineEdit or 
whatever instead. I think it's pretty obvious that we won't agree on 
a common existent toolkit and definitely we will not agree on a newly 
designed one either - and that's not a problem. I'm proposing 
something like a wrapper around the Tcl text-widget, not a 
replacement for it. This wrapper will however be abstract enough, so 
that a tcl/tk approach can use the tcl-widget, a qt-approach can use 
some qt-widget providing roughly the same functionality, a delphi 
approach a delphi one, and a browser-based interface might use some 
HTML form-elements.

> I'm not all that happy with the idea of encoding menu structures in
> external files either. I really do think that you need a handle on
> (say) the system menubar, so that a function can say "Please add these
> items to the toplevel menu", etc. However, there is not necessarily a
> contradiction between the two - the R side can edit the XML
> description and ask the GUI shell to reload it; it just feels a bit
> clunky.

And you will still have that handle on the menubar. You can still put 
in whatever you like that is specific to your application. And you 
can still have a function to say "please add this to the menu at a 
specific place". The "location"-thing does not have to be more than a 
hint to be used if the application does not even know about a plugin. 
Imagine you load a plugin from the internet. You could then call 
something like load.plugin ("filename") and if your application 
adheres to something like a common standard of a menu-hierarchy, it 
will be placed appropriately without any need to specify (or even 
know) where it should go. If your application choses to use a 
completely different menu-structure, it will probably provide a 
function like load.plugin ("filename", some.place.identifier) which 
will place it there.
I think it will make very much sense to agree on a rudimentary common 
menu-structure, but nobody prevents you 
from for example providing an additional map saying which plugin 
should be placed where. Nobody can prevent you from doing so, and 
doing so will not get any harder - you will not have to edit any XML 
for that, you'll simply ignore some sections of the XML. So, the 
"location"-thing will then be useless to you, but it won't do you any 
harm, either. We will lose the advantage of having a similar core 
structure across applications, but this is definitely no regression 
from using individual solutions in the first place.

Thomas