Thanks for the response Dan If I hear you correctly about sticking with the higher level GUI framework that is the most flexible, then gWidgets comes out as the most likely candidate.
There is one more thing I thought about. Has there been any work done on a meta-GUI, i.e. a gui for building gui-s? For example for the ggenericwidget() function which looks like it will end up as the workhorse of any graphically driven system. I tried fgui(ggenericwidget) but what one actuallty needs is a way to interactively work out the 'lst' agument and choose the appropriate way to obtain the arguments (e.g some though radio buttons, some by loading files, some are R objects in the workspace etc.) as well as some generec options what to with the output (e.g. assign to functin or object, save or plot). Do you think there will be interest in building a GUI for ggenericwidget/ regards Christiaan On 23 November 2011 10:01, Dan Putler <dan.put...@sauder.ubc.ca> wrote: > Hi Christiaan, > > This is (as you probably expect) an "it depends" question for at least two > reasons. One thing that complicates everything is the underlying widget > toolkit that is being used. The goal of gWidgets is to be agnostic with > respect to the underlying GUI toolkit, but seems to have the most > functionality under GTK2 (via the RGTK package), while both fgui and rpanel > use Tcl/Tk (via the tcltk package). gWidgets will work with Tcl/Tk and the > tcltk package, but you may want to make sure you can get the functionality > you want from gWidgets when using Tcl/Tk. Mixing GTK2 and Tcl/Tk in even a > loosely coupled setup seems like asking for trouble (and the installation > process for novice Mac users could be really trying). The second question > is how tightly integrated do you want all the various dialogs you create to > be? If they are very loose, you may well be OK using a number of different > high level R GUI "frameworks". However, I can see where maintenance of the > system you develop could be a real headache, particularly if you want the > components to be tightly integrated. The upshot, if you can base everything > on using the R tcltk package as the foundation, then what you are proposing > is probably do-able, but by mixing and matching higher level R GUI > frameworks you may be trading-off short-term implementation gains for > long-term maintenance headaches. Personally, in this situation I would > stick with the higher level GUI framework that is the most flexible, even > it it is not the easiest for creating "quick and dirty" user dialog boxes. > > Dan > > > On 11/22/2011 11:31 PM, christiaan pauw wrote: > >> Hi Everybody >> >> I have to make a gui for a collection of my functions in order to make >> it easier for my colleagues (who are very code-shy and function strictly in >> a point and click environment). >> >> I have trawled the web for documentation and have come to the >> preliminary conclusion that I am going to use the gWidgets package for this >> task but fgui and rpanel seems to make some aspects easy to implement. >> >> Is it feasible to use gWidgets, fgui as well as rpanel in >> one implementation or should one stick to one of these and do everything >> with the one gui package? >> >> regards >> Christiaan >> >> [[alternative HTML version deleted]] >> >> ______________________________**_________________ >> R-SIG-GUI mailing list >> R-SIG-GUI@r-project.org >> https://stat.ethz.ch/mailman/**listinfo/r-sig-gui<https://stat.ethz.ch/mailman/listinfo/r-sig-gui> >> > > ______________________________**_________________ > R-SIG-GUI mailing list > R-SIG-GUI@r-project.org > https://stat.ethz.ch/mailman/**listinfo/r-sig-gui<https://stat.ethz.ch/mailman/listinfo/r-sig-gui> > [[alternative HTML version deleted]] _______________________________________________ R-SIG-GUI mailing list R-SIG-GUI@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-gui
