Skip to content

[R-gui] R GUI considerations (was: R, Wine, and multi-threadedness)

13 messages · Jeffrey J. Hallman, Jan de Leeuw, Byron Ellis +5 more

Original
Jeffrey J. Hallman
# 
If you're looking for a GUI toolkit that:

   1.  Is cross-platform,
   2.  Has a good collection of widgets that look good on all platforms, and
   3.  Is easy to work with from R

then it is hopeless.  There is no such toolkit.

As one poster mentioned, most of the better GUI toolkits are very
object-oriented, because that paradigm is a good fit for GUI programming. 
There are a few programming environments out there that do have nice GUI
abilities, but they all use base languages that are not very R-like, and so
the potential R GUI programmer is faced with having to use two very different
languages for his creation.  And even if that obstacle is surmounted, there
remains the difficulty of trying to package up his work in such a way as to
make it easily installed by others.  Things are always breaking in the
interfaces between R and whatever you're using.  Trying to keep it all running
and packaging it for deployment are thankless, gargantuan tasks.

There is a better way, and that is to give up on R.  Start over with
a better programming environment, one that is object oriented, as flexible and
dynamic as R, is cross platform, easy to program in, and has decent GUI
facilities already.  Then port the stuff in R that does statistical
programming, and you have the best of all worlds. 

The environment I am thinking about is VisualWorks Smalltalk, which is free
for noncommercial use.  As a language, Smalltalk is both simpler and more 
powerful than R, and the VM it runs on is much faster than the R interpreter.
It has superior garbage collection and the best IDE in the business.
Callouts to C are just as easy as they are in R, but would likely not be
needed as often due to the faster VM and much better programming facilities.
Interfaces to various databases are possible, and the most powerful web
toolkit (Seaside) is written in Smalltalk and runs under VisualWorks.

There are a couple of other Smalltalk environments around that could also be
considered.  Squeak is an open source cross-platform Smalltalk that is not as
fast as VisualWorks, but still must faster and more robust than the R
interpreter.  Smalltalk/X is another possibility, though it works only on
Windows and Unix. 

Think about it.  Once you have a basic math package that can handle matrix
programming and various mathematical functions, building the various
statistical modeling tools on top of them is not that hard.  What makes S and
R so much better than SAS is their programmability.  Smalltalk is like that,
only better.


Jeff Hallman
Jan de Leeuw
# 
Ah. Let the language wars begin. Although I agree that going with R
is basically a sad mistake

http://www.jstatsoft.org/index.php?vol=13

giving up on R/S is no longer an option, I hope. Too much investment
from the community. Reculer pour mieux sauter, indeed.
On Oct 19, 2005, at 3:43 PM, Jeffrey J. Hallman wrote:

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Peter Kleiweg
    

    

      
      #
    

  


  

          

      
      
      
    

        
My advice about VisualWorks Smalltalk: don't. It may work well 
on Windows. On Linux, it is a disaster. Nothing works the way it 
is supposed to on Linux. I have tried one application in 
VisualWorks: BottomFeeder. Dozens of versions and bug fixed. But 
there are no fixed for the incompatibility between the virtual 
machine and my Linux box. It can't display jpeg's. Windows keep 
jumping around the screen. It doesn't know about size of fonts, 
so on many parts of the interface, parts of text are missing. 
Standard key combinations, copy and paste, all work completely 
different from other Linux applications. You can't install the 
program in the Unix way. It saves its internal state in a binary 
form that gets being corrupted, and you have to make a clean 
install regularly, loosing all your old data.

Mind you, this is software developed by someone from 
VisualWorks, presenting this as the prize horse of what 
VisualWorks is capable of.

            

      
      
      
    

        
Squeak works much better on Linux than VisualWorks, but it still 
shares many disadvantages with VisualWorks. The main obstacle is 
its use of a virtual machine for everything. It is like working 
in a completely different environment, were none of the rules of 
your usual environment apply. You cannot use your favourite 
software to do your programming and organising. I write programs 
in Python, C, PostScript, R, and half a dozen other regularly, 
all from Emacs. If I want to program VisualWorks or Squeak, I 
have to do so from within VisualWorks or Squeak, with its own 
editor. I can use none of the tools I rely on for all my other 
tasks. And of course, something written in VisualWorks is 
completely useless in Squeak, and vice versa.

            

      
      
      
    

        
No. A program should respect the user's chose of platform. I 
write a program in Python with Tk. On Linux it looks and feels 
like a Linux program. On Windows, it looks and feels like a 
Windows program.

Why would you want a GUI for something like R in the first 
place? It is a programming language. That is its force. Nothing 
beats the command line. A GUI can never offer the same power, 
unless it offers the same openness as the OS it is running on. 
It has to incorporate an editor to do the programming. Except 
without the GUI, I can use any editor I like. I don't need a 
GUI. Linux running X and my favourite windows manager is all the 
GUI I need.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Byron Ellis
    

    

      
      #
    

  


  

      
And I so wanted to stay out of this particular discussion, I hope  
you're proud of what you've done. *cracks knuckles* Right, lets get  
to it then.

        
On Oct 19, 2005, at 3:43 PM, Jeffrey J. Hallman wrote:

        

            

      
      
      
    

        
There is in fact such a toolkit. I'll give you a hint, its name ends  
in "step" and its heavily used under a different name by a company  
named after a fruit. It works quite well from R, doesn't require  
another language and frankly the binding between it and R was  
actually pretty pleasant as these things go. By my count it took 2727  
lines of C and 411 lines of R to bind, a good half of which are  
technically unnecessary. Right now it probably doesn't run under  
Windows and Linux/BSD/Solaris/Your Favorite POSIX Compliant UNIX at  
the present time, but thats mostly because I don't care rather than  
because it can't.

            

      
      
      
    

        
This is only a problem because people seem to insist on using R's  
object system in a way that is not actually very compatible with R's.  
To misquote Robert at DSC, "their primary complaint about R is that  
its not Java." If you think about it for a moment, R's environment is  
actually quite well suited to GUI tasks because, well, because it has  
environments. Imagine drawing into a window (you're a plotting tool  
or something). Really, you're a function executing in an environment  
(oh ho!) that has access to certain system resources, in this case a  
canvas of a certain physical and logical dimension. Responding to  
events could take on a similar structure---you're really executing in  
an Event environment that has certain bound symbols. Obviously you  
get to keep your lexical environment so event handlers that need to  
share state can in the usual way. Its not particularly difficult and  
doesn't even need to involve objects in any real way, except as  
little stubby things with attributes you can modify or poll.

            

      
      
      
    

        
How is this different than releasing any piece of software?

            

      
      
      
    

        
Did you just use the words "cross platform" and "VisualWorks  
Smallktalk" in the same email? Have you ever used VisualWorks on  
something other than Win32? I'd rather use Squeak. At least then I  
know it'll have an equally childish interface on every platform.

            

      
      
      
    

        
Contrary to popular belief the speed of R's interpreter is rarely the  
limiting factor to R's speed. People treating R like C is typically  
the limiting factor. You have vector operations, USE THEM.

            

      
      
      
    

        
But not portable across Smalltalks. Whoops. Oh, and there's still a  
helluva lot of Fortran code out there that nobody wants to port.

            

      
      
      
    

        
Because I spend all my time writing web shopping carts in R?

            

      
      
      
    

        
As it happens, I've thought about it. At length. To the point of  
having images that actual test out the idea of implementing these  
libraries whilst my simulations run in the background (we can discuss  
the effects on my degree progress at a later date). Smalltalk has  
some very clever features. I'm a particular fan of the notion that  
"breakpoint" and "exception" aren't different things for example.  
Unfortunately its also turns out that these "basic math packages"  
are, in fact, quite difficult to do well especially when multiple  
platforms are involved. For example, it took GSL 5 years to get to a  
'1.0' release and its still using CBLAS, an even older piece of code,  
to do most of its vector and matrix operations.

Assuming you manage to pull that off (see you in 2010!) I'm still not  
convinced it would work as most Smalltalks (Squeak especially) take  
on a self-contained nature, meaning that they Don't Play Well With  
Others. The only time *I* really use a GUI is when I'm preparing a  
presentation or a paper in which case I need to be table to talk to  
all manner of different pieces of software, something which is  
generally ignored Smalltalk. At least with the current R GUIs I can,  
you know, cut and paste. Sure, you can get Smalltalks to do this sort  
of thing too, VisualWorks can do a fair amount though how well varies  
widely with platform (hey! Just like R). Even better, the  
programmatic interfaces vary from platform to platform and Smalltalk  
to Smalltalk. I could continue, but I'm getting hungry---suffice it  
to say that Smalltalk isn't some sort of panacea despite being a very  
nice language, too much James Robertson for you.

So, you've got a lot of work (implementing a robust scientific  
library) ahead of you for dubious gains (a rich GUI, maybe a better  
programming language and a whole raft of new problems). It seems like  
the better idea would be to pull a Java and shameless hijack the  
interesting bits from Smalltalk rather than go the other direction.

Oh, and since you suggested googling yourself,

I gotta go with Alan Z on this one, a<-1 is ambiguous is the worst  
possible way, := would probably be a better choice. Looks less like  
the APL symbol, but who cares?

            

      
      
      
    

        

      
      
    

        
---
Byron Ellis (ellis at stat.harvard.edu)
"Oook" -- The Librarian

  
  


  


      

    

    

      
      

        


  

        

      James Wettenhall
    

    

      
      #
    

  


  

      
Hi Peter and everyone,

[Hmmm, didn't I say I was not really interested in spending time getting
into these discussions anymore?  Oh well, I can't help myself. ;-) ]

            

      
      
      
    

        
I think there are many people who would strongly disagree with your
suggestion that there is no point in developing GUIs for R.  But there is
also some ambiguity about what is meant by a GUI - an Interactive
Development Environment (IDE) for developers or a GUI for users who are
highly intelligent, but have no interest whatsoever in ever learning how
to use a command-line interface, whilst still wanting to access some of
the functionality in R/Bioconductor.

Some statisticians / numerical computing specialists work in isolation and
like to advertise that some of their work is very "applied" e.g. they are
working on a project which will save the world or cure cancer or whatever
[sorry for the exaggeration] but this is a natural way for them to market
the importance of their field of research and feel good about themselves.

On the otherhand, there are people like the bioinformatics group I work in
who are a very successful research group, partly because we don't work in
isolation.  Instead we collaborate very closely with scientists from other
fields (i.e. biomedical scientists), but there is an extreme danger here
of being used as a service group (like I.T. support) by the biomedical
scientists who don't appreciate how much work is involved in computer
programming, statistics etc.  So one solution is to use a language like R,
with the philosophy "users become developers", i.e. rather than having to
learn an intimidating hierarchy of 100's of classes in some object
oriented language [OK, I'm exaggerating here], the user can begin using R
quite gently (but still do some powerful statistical calculations) and
then gradually become more advanced.  Now some of the (extremely
intelligent) biologists we collaborate with are very fearful of getting
started in a command-line interface, so they keep asking us to do mundane
things for them which are not going to lead to any research publications
for us - i.e. we feel like we are just being used as I.T. support.  So by
providing a GUI to them, getting started in R is less intimidating for
them, so then we can hopefully spend less time doing mundane numerical
computing tasks for our collaborators and have more time to do our own
serious research.  And we can even publish our work on developing GUIs
which we have - just a short article in Bioinformatics OUP so far - and
John Fox has published a full-length article on Rcmdr in the Journal of
Statistical Software - great stuff!

Does that make sense?
James

  
  


  


      

    

    

      
      

        


  

        

      Philippe GROSJEAN
    

    

      
      #
    

  


  

      
Byron Ellis wrote:

            

      
      
      
    

        
Hey! I vote for a 'fortune' here!

            

      
      
      
    

        
Otherwise, the discussion is taking a bad turn again (did someone 
suggested to trow away R, and rewrite it completelly?). So, here a 
couple of "rules" we should consider:

1) We love R, and we are really convinced that it is a nice statistical 
environment and a good statistical programming tool.

2) We want to build a GUI *around an existing software developped as a 
CLI*. As such, we know it is not straigthforward. We have to find 
workarounds for bad R behaviours (that happen because it was *not* 
conceived with a GUI in mind). We should just suggest a limited amount 
of changes, when really needed, remembering a GUI is not a priority in R 
development.

3) The S language is a strong force in R. Don't try to hide it under 
more sexy dialog boxes or other kinds of GUIs: expose R code (for 
instance, show R code constructed after selections done in that dialog 
box)... and give an opportunity to edit and reexecute that code to 
stimulate first experiments with the S language.

4) What is the language that is working an all platforms R runs, is 
perfectly compatible with R, and is always available once R is 
installed? Well, R itself (i.e., the S language), of course! So, to make 
sure your GUI code is most usable by the R community, write as much GUI 
code as you can in S language... and if you think you can write 
everything in you XXX language, think again, and you will realize that a 
large part of that code can actually be written directly in R as well.

5) There are new and better graphical widgets and languages appearing 
regularly in the computer world. The best ones for making a GUI today 
may be obsolete rapidly in the future. On the contrary, we all hope a 
longer life for R. Thus, write your GUI code in R as much as possible in 
a way it is independent from a particular GUI toolkit and interfacing 
language. I say, as much as possible, because this is a very diffcult 
task, given the specificities of each toolkit and language.

6) Write your code with reusability in mind; Reusability in your own 
GUI, but also, for sharing code between GUI projects. Remember writing a 
GUI for R is a very long and complex task, and you can hardly do it 
alone. Working all together, sharing code and ideas, would greatly 
improve our output.

I think if you disagree with these "rules", you'r wasting your time. You 
are then better to log off from R-SIG-GUI, even uninstall R if you are 
so angry,... and enjoy life instead of wasting time fighting against the 
$%*?&#! behaviour of R in your GUI.

Best,

Philippe Grosjean

  
  


  


      

    

    

      
      

        


  

        

      Peter Kleiweg
    

    

      
      #
    

  


  

      
James Wettenhall schreef op de 20e dag van de wijnmaand van het jaar 2005:

[...]

            

      
      
      
    

        
To me, it does not make sense. When I have to work with 
something like Word, I am intimidated by lots of buttons with 
cryptic icons, with menus and submenus I can't make heads or 
tails of, the program doing weird things with my text I don't 
understand. A simple, friendly prompt is much more inviting. 
Give me a well-organised documentation, and let me do my thing.

A GUI fits in a big-is-better marketing strategy. The more 
intimidating a GUI looks, the better. As a user, I always feel a 
prisoner of such monstrosities. Hundreds of options, but I 
cannot find the ones I actually need, with no possibility to use 
other software tools as auxiliaries.

I find, the biggest problems with operating on large and complex 
sets of data (like you do in R), are things like digitisation of 
the data, preparation, transformation, selection. You usually 
have to do quite some work on the data before you have something 
R can handle. This preparation is best done with the tools you 
feel comfortable with, a simple editor, shell scripts, Perl, 
make, etc. Once you have your data prepared, invoking another 
command through the command line is a small step. You can go 
forward and backward, doing data preparation and processing the 
prepared data with something like R, iteratively. Look at GRASS 
as an excellent example.

You want all the preprocessing done in a GUI? I don't see how 
that is possible in a way that makes sense. How do you tell the 
GUI what your raw data looks like? How do you tell it to prepare 
the data for processing by R? Does the user have to learn the 
GUI's own scripting language and filters?

If you want users to be productive, you have to give them 
something they can easily incorporate within the tools they use 
on a daily basis. No big applications with everything locked in, 
but a set of programs or commands that do specific tasks, with 
an easy to understand input and output. You need something that 
works in an open environment, so the user can use existing 
skills. With a GUI that does "everything", the user has to learn 
from scratch all the things that make "everything" happen.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Thomas Friedrichsmeier
    

    

      
      #
    

  


  

          

      
      
      
    

        
Maybe you're just seeking this discussion for the fun of it. In this case, I 
won't stop you. If not, do you really think it is going anywhere?
You don't want/need a GUI? Fine. Don't use one, and don't write one. Do some 
others feel the need for a GUI? Yes, they do. Could there be at least some 
reason for that? Well, it's not like you can just "start using R", even if 
you do have the statistical background, and even if you do have basic 
programming knowledge. Is a bloated GUI less intimidating to some than a 
command-line? Yes. Do all GUIs necessarily make extra sure to hide you from 
everything going on behind the scenes, so you will be kept locked in, and 
helpless for ever? No. Should everybody be forced to use a GUI? No. Does 
anybody advocate otherwise? Not as far as I can see.
I don't think there's anything more to be said on this topic.

Regards
Thomas Friedrichsmeier

  
  


  


      

    

    

      
      

        


  

        

      James Wettenhall
    

    

      
      #
    

  


  

      
Hi again,

        
Peter Kleiweg wrote:

            

      
      
      
    

        
I feel the same way.  But a typical member of the target audience for my
GUIs is certainly not someone like you or me (although occasionally I put
features into a GUI which can protect me against making some of the
mistakes I typically make at the command-line).  A typical member of my
target audience is someone who is highly intelligent, but has never heard
of a command-line interface, and would find it quite intimidating.  I'm
certainly not claiming that you are one of those people, but if you like,
I can introduce you to plenty of people like that.

            

      
      
      
    

        
I disagree.  I don't try to compete with the intimidating commercial GUIs.
My academic-style GUIs don't look and feel as professional as commercial
GUIs, but I give the user a choice.  Do you want to pay $5,000 per user
per year for commercial software to analyze your data, or do you want to
try using Bioconductor's command-line interface yourself (an idea they
will very quickly shy away from), or do you want someone else to analyze
your data for you or do you want access to the latest high-quality
statistical methods in Bioconductor via our GUI without paying any money
for a commercial license and without having to be intimidated by the
command-line interface?

When we first started distributing our GUIs, we were unsure whether we
would get more requests for new buttons / new features or more requests
for a less-intimidating set of menus/buttons, or possibly a "novice mode"
where lots of default values are used automatically without asking the
user, so that the data analysis workflow feels simpler.  Almost all
requests have been for more features, rather than complaints from people
who are intimidated or overwhelmed by too many choices.  But nevertheless,
I still think it is a good idea to have a "novice mode" in a GUI, with
less menu items, less buttons, less dialogs, with the understanding that a
number of default values are decided upon automatically without
consultation with the user.

            

      
      
      
    

        
Understood.  But as I said, you are not a typical member of the target
audience my GUIs are written for.  Neither am I.

            

      
      
      
    

        
Certainly most of the email questions we get from strangers about using
our GUIs are about how to get started e.g. rather than using a standard
raw data format which our GUI knows how to read, they have tried to
preprocess the files themselves in Excel or equivalent (unnecessarily), so
then we have to tell them "Please read our input-file-format
documentation!  Please don't mess with the standard raw data formats!" 
Then once they get started with the analysis, they are generally very
happy.  And we can try to improve our requried-input-file-format
documentation after getting their feedback.

            

      
      
      
    

        
Again, it sounds like we are talk about a different class of users /
target audience.  My users certainly wouldn't know how to write a shell
script or use Perl or make.  But they do want to be able to analyze their
own data, and try different normalization methods and see the effects
graphically, rather than just sending off their data to a statistician.

            

      
      
      
    

        
That's why we like writing GUIs for R, rather than just encouraging people
to use proprietary commercial GUIs.  If they use a commercial GUI, and
they want something a little different from what the commercial GUI can
do, there is often very little we can do for them.  But with an R GUI, you
can provide a way for the user to dump out an .RData file or equivalent,
so that if they need something which the GUI currently cannot do, then the
statistician can do some command-line operations on their .RData file and
send them back some graphs to put into their PowerPoint slides or an
updated .RData file they can continue using in the GUI or whatever.  I've
certainly done this for some users and they have been very pleased with
the results.  For other users, I have actually added new buttons / menu
items to the GUI very quickly in response to their requests for features
not currently available.

            

      
      
      
    

        
No, the user is not expected to learn any scripting language.  I think it
would be very difficult to write a general GUI for all types of data
analysis in R.  But we are focusing on very specific classes of data, e.g.
gene expression microarray data, where most people are using some very
well-known, well-documented raw data formats.  Gradually the developer can
add support for more raw data formats to the GUI, but sometimes the
developer receives a request for supporting a data format which is so
obscure that it is not worth the GUI developer's time to implement it so
we can just say "Sorry, you'll have to collaborate with a statistician who
can do your analysis at the command-line, unless you want to learn the
command-line interface yourself."

            

      
      
      
    

        
I have no objection to software developers writing Visual Basic macros for
Excel or webservers with familiar-looking HTML forms if that's what they
want.  But in our case, we want them to use something closely related to
the tools that WE use on a daily basis (not just what THEY use), because
if they develop a need for a customization - something out of the
ordinary, it is going to be much easier for us to fulfill their special
request using a command-line analysis if they are using R (either directly
at the command-line interface or via a GUI), than if they are using an
expensive proprietary commercial system.  And just to clarify, I'm not
talking about things like Microsoft Office which they would have anyway,
I'm talking about scientists deciding whether to spend thousands of
dollars on commercial software for very specific types of data analysis
starting with well-documented raw data formats or whether to use our free
software instead.

            

      
      
      
    

        
I certainly don't think talking about at GUI for R that does "everything"
is realistic, and I have never considered doing that.  I'm happy to admit
that my GUIs have limitations in terms of what the users can do by
point-and-click, but for the advanced user (or for a collaborating
statistician who can take .RData files saved from their GUI analysis),
there are ways of switching from GUI analysis to command-line analysis
when really necessary, so in a way, an R-GUI _can_ do "everything", but it
just can't do everything in a user-friendly way, and doesn't want to try
to do that, because that would mean a completely intimidating collection
of menus and buttons (which is how some people feel about Microsoft
Office).

We may have to agree to disagree about some things, but I hope this has
made my point of view a little clearer.

Best wishes,
James

  
  


  


      

    

    

      
      

        


  

        

      Peter Kleiweg
    

    

      
      #
    

  


  

      
James Wettenhall schreef op de 21e dag van de wijnmaand van het jaar 2005:

            

      
      
      
    

        
Actually, your elaborate response makes much sense to me. I 
understand now that it is not just about replacing the command 
line with a GUI. It is not like LaTeX versus Word (i.e. good 
versus bad), but about organising and streamlining tasks, doing 
"higher level" things. At least, that is what I think it is.

This is a topic I have been struggling with for quite some time. 
For years, I have been working on software for dialectometrics 
and cartography. At the beginning, just for doing research at 
our institute. But soon, it developed into something people from 
other institutes can use. A large set of command line programs, 
manual pages, an R interface, and quite an extensive tutorial 
with example material.

My employer urged me to add some sort of GUI. It would make more 
people willing to try using the software. I resisted the idea of 
a GUI. For one thing, I work on Linux but the GUI should be used 
on Windows. (Java is too bothersome. Smalltalk too clumsy. And I 
didn't know about Python yet.) But the main problem was: I had 
no idea what a GUI should look like, what it was supposed to do. 
It took me quite some time, working with my own software, before 
I was able to look at it from a distance. The software is just a 
toolkit. I didn't want a Graphical Toolkit. What I wanted was 
something like a Graphical Project Manager, something task 
oriented, with and interactive help system that guides the user 
through the work.

It is still fresh. I haven't had any responses on people using 
the GUI, so I don't know yet if this is what people helps. What 
I still think as one of the biggest obstacles for using my 
software is not cured by the GUI. You still need to select and 
prepare the data. If you want maps, you have to provide map 
data, in a format the software understands.

This GUI I built is quite specific. It assumes a quite narrow 
purpose (though parts of the software can be used independently 
for quite other purposes): you start with a set of dialect data, 
you do some calculations on that data to make estimates of 
differences between dialects, and you visualise these dialect 
differences on a geographic map.

I still don't see anything like that for R. A general GUI for R? 
What are the "higher level task" you use R for? It only makes 
sense to me if you want to use R in a specific field, such as in 
Bioconductor. You build a GUI to that specific higher level 
application of R.

Or does anyone want to transform R into something like a 
spreadsheet program? There are people making a GUI for LaTeX to 
make it look like Word, a WYSIWYG, but to me that seems like a 
very silly thing to do.

For those interested, here is my software:

    http://www.let.rug.nl/~kleiweg/L04/

And the GUI is here:

    http://www.let.rug.nl/~kleiweg/L04/pyL04/

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Kasper Daniel Hansen
    

    

      
      #
    

  


  

      
On Oct 21, 2005, at 8:53 AM, Peter Kleiweg wrote:

        

            

      
      
      
    

        
For the applications James have in mind, the data format is basically  
standardized. From a certain level you might think of every  
observation residing in a separate file (in one out of a couple of  
different file formats), so all the user has to do is choose "file  
format" and basically label every file with eg.  
"control"/"treatment". This is somewhat simplifying of course, but  
basically the data input step is much more simple than in "general"  
cases.

            

      
      
      
    

        
Yes, and this is exactly what James have been doing.

            

      
      
      
    

        
Agreed, although I am humble enough to know that there might be sense  
in doing so from a certain perspective which I am not aware of.

Kasper

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Philippe GROSJEAN
    

    

      
      #
    

  


  

      
... A couple of screenshots of your GUI would help those who don't have 
time to download and install your software to visualize what you did.
Best,

Philippe Grosjean

..............................................<?}))><........
  ) ) ) ) )
( ( ( ( (    Prof. Philippe Grosjean
  ) ) ) ) )
( ( ( ( (    Numerical Ecology of Aquatic Systems
  ) ) ) ) )   Mons-Hainaut University, Pentagone (3D08)
( ( ( ( (    Academie Universitaire Wallonie-Bruxelles
  ) ) ) ) )   8, av du Champ de Mars, 7000 Mons, Belgium
( ( ( ( (
  ) ) ) ) )   phone: + 32.65.37.34.97, fax: + 32.65.37.30.54
( ( ( ( (    email: Philippe.Grosjean at umh.ac.be
  ) ) ) ) )
( ( ( ( (    web:   http://www.umh.ac.be/~econum
  ) ) ) ) )          http://www.sciviews.org
( ( ( ( (
..............................................................

        
Peter Kleiweg wrote:

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Peter Kleiweg
    

    

      
      #
    

  


  

      
Philippe Grosjean schreef op de 22e dag van de wijnmaand van het jaar 2005:

            

      
      
      
    

        
I did today:

http://www.let.rug.nl/~kleiweg/L04/pyL04/