should we encourage use of the tcltk2 gui toolkit?
James Salsman
saying that they want to implement a GUI of some kind, but most of
them don't say which GUI toolkit they're planning to use. That is
kind of a big deal for me when I look at ranking, which is why I've
held off on numeric rankings for most of the projects so far. We
would really help students by steering them towards a GUI toolkit that
we know they will be able to use no matter what platform they end up
on.
Are there any drawbacks to use of tcltk2?
http://cran.r-project.org/web/packages/tcltk2/tcltk2.pdf It's
actively maintained, fully cross-platform and platform independent,
and has a powerful set of layout, font, graphics, and plot rendering
tools. I notice it is in the "TeachingDemos" package suggests, unlike
all the other GUI toolkits.
What are the other fully platform independent GUI toolkits to choose
from? And if known, what are their advantages and disadvantages?
One of the reasons I like Tk-based GUIs is because I am easily able to
use them on small screens -- e.g. http://talknicer.com/pronounce/ --
and while that's not a big deal for R, it is something to keep in mind
when we think about what toolkit would best serve the future needs of
our students.
The unsolicited HMM GUI proposal's student and I have been in
correspondence. He was able to run the examples from the tcltk2
package very quickly.
If other mentors who aren't familiar with Tk decide to use tcltk2, I'd
be happy to help with any co-mentoring kinds of questions about it.
Best regards,
James Salsman
Dirk Eddelbuettel
I have no dog in this fight but if I had, I'd pick John's gWidgets.
More modern, more modular, more versatile. tcltk (and tcltk2) are useful,
but dated. And IIRC tcltk2 still have some pieces that may not be fully
cross-platform.
Dirk
--
Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com
Brian G. Peterson
> What are the other fully platform independent GUI toolkits to choose
> from? And if known, what are their advantages and disadvantages?
I would assume you'd consider R Gtk, qt, and Java interfaces as
platform-independent toolkits? They can run on Windows/Mac/Linux, which
has got to be 99%+ of the desktop (GUI-capable) users of R. Arguably,
they are more modern and flexible frameworks than tcl/tk, though tcl/tk
will (almost?) 'always' be available with an R installation.
I'm more interested in avoiding lock-in to one specific front-end
framework (e.g. StatET, R Commander, rattle, RKward, to pick on a few in
no particular order).
The GUI API library used seems somewhat less important to me, as long as
it is multi-platform. For example, I don't worry to much about the
aesthetics or 'native' feel of a particular toolkit, as long as it gets
the job done. So I'd lean towards a strong preference for *any*
multi-platform library, and use the one most familiar to the mentor or
student (preferably both). I would tend to down-rate proposals that
require lock-in to something not portable.
Regards,
- Brian
Ian Fellows
James Salsman
My impulse at this point is to ignore the platform GUIs, and suggest
that all the R GUI projects should implement an HTTP server, e.g. on
some localhost port if localhost:80 isn't available. That way people
get the familiar look and feel of a web page in the browser they are
comfortable with, easily able to print, select/copy, and save from,
and which takes care of layout without any cross-platform aesthetic
issues. This approach also has substantial accessibility advantages.
I see it's already been done at the freely available
http://www.math.montana.edu/Rweb/Resources.html but that requires
Perl, netpbm, and ghostscript, but only on the server. Another
advantage to this approach is that you can put the resulting GUI on a
non-localhost server and offer it everywhere, even mobile devices and
closed tablets. As the Rweb demo shows, you can offer a complete R
environment this way (although I don't know if they can save/restore
workspaces.)
How do other mentors feel about using the web browser for a GUI toolkit?
On Sat, Apr 9, 2011 at 11:59 AM, Ian Fellows <ifel...@gmail.com> wrote:
>
>... tcl/tk is not installed by default on the mac, and requires the user to
> go to simon's att site to get the installer.
That's a serious problem I was unaware of. I use all three desktop
platforms regularly, but I almost never use GUIs with R, so please
bear with me here. I don't know what Simon's installer does, but I
have Tcl/tk installed separately on my Mac.
On Sat, Apr 9, 2011 at 11:10 AM, Dirk Eddelbuettel <e...@debian.org> wrote:
>
>... I'd pick John's gWidgets.
I looked at http://cran.r-project.org/web/packages/gWidgets/vignettes/gWidgets.pdf
which suggests that gWidgetsRGtk2 / RGtk2 is more complete, but
gWidgetsteltk / tcltk is easier to install for Windows users, and that
Java may be abandoned. Section 3.1 suggests that RGtk2 requires
downloads on Mac and Windows.
Does gWidgetsQt / qtbase run without additional installation three
desktop platforms? I can't even find qtbase in
http://cran.r-project.org/web/packages/ -- did it get renamed?
Brian G. Peterson
> On Sat, Apr 9, 2011 at 11:10 AM, Dirk Eddelbuettel<e...@debian.org> wrote:
>> >
>> >... I'd pick John's gWidgets.
> which suggests that gWidgetsRGtk2 / RGtk2 is more complete, but
> gWidgetsteltk / tcltk is easier to install for Windows users, and that
> Java may be abandoned. Section 3.1 suggests that RGtk2 requires
> downloads on Mac and Windows.
I think you may be missing the point. If a student codes to gWidgets,
the GUI may be delivered via *any* of the gWidgets back end
implementations: tcl/tk, GTK, qt, Java, or a web server, depending on
what is installed and available on the machine.
- Brian
Dirk Eddelbuettel
On 9 April 2011 at 13:14, James Salsman wrote:
| My impulse at this point is to ignore the platform GUIs, and suggest
| that all the R GUI projects should implement an HTTP server, e.g. on
Yes, a web interface is good to have.
gWidgets has gWidgetsWWW which works well with rApache, and possible also
with the internal web server.
| I looked at http://cran.r-project.org/web/packages/gWidgets/vignettes/gWidgets.pdf
| which suggests that gWidgetsRGtk2 / RGtk2 is more complete, but
| gWidgetsteltk / tcltk is easier to install for Windows users, and that
| Java may be abandoned. Section 3.1 suggests that RGtk2 requires
| downloads on Mac and Windows.
gWidgets abstracts the toolkit. As discussed not all toolkits are on all platforms.
gWidgets can fall back onto Tcl/Tk as well it never gives you less than R's tcltk.
| Does gWidgetsQt / qtbase run without additional installation three
| desktop platforms? I can't even find qtbase in
| http://cran.r-project.org/web/packages/ -- did it get renamed?
The Qt stuff is newer as has AFAIK not left r-forge.
The point is: gWidgets _as an abstraction layer_ is mature. Actual plugins
may always have particular platform issues.
And FWIW I mentored a student two years ago who already then whipped up a GUI
using gWidgets within days. It has only gotten better since.
But as I said earlier, no dog in this fight so I may as well stop my sales pitch.
James Salsman
>
> gWidgets has gWidgetsWWW which works well with rApache, and possible also
> with the internal web server.
I am convinced now!
I'm going to ask the unsolicited HMM GUI student if he can get
gWidgetsWWW working, and if so, I'll definitely try to mentor that
one.
Claudia Beleites
I suggest we take this discussion to another place where it is more
appropriate. Not only we need to get to a decision, but people not
involved with GSoC face the same problem.
=> I suggest we go on thinking and learning about suitable toolkits,
abstraction layers etc. on r-sig-gui
r-si...@r-project.org
Claudia