Skip to content

idea (PR#7345)

11 messages · dan@bolser.co.uk, Uwe Ligges, Dan Bolser +6 more

Original
dan@bolser.co.uk
# 
Full_Name: Dan B
Version: 2
OS: Fedora 2
Submission from: (NULL) (80.6.127.185)




It would be great if something like

currentPlot <- edit(par)

allowed dynamic changes to the 'currentPlot', which I am using as some kind of
'magic' keyword in the above context. i.e. the value of 'currentPlot' is
actually an alias for whatever the current graphical object is. 

calling the above command would open the edit pannel for the par options
relevant to whatever the currentPlot object was. 

The changes made to par would trigger an automatic redraw of the plot, to allow
dynamic editing. After the changes were made and edit closed, a copy of the
edited par could be taken to allow the settings to be automatically applied in
the future.

Dynamic editing of all object variables could be supported through this
mechanism to allow a very flexible overall control of graphical objects.
Uwe Ligges
#
dan@bolser.co.uk wrote:

            

      
      
      
    

        

      
      
    

        
Nice idea. Do you have any schedule for which R release R-core can 
include your contribution? Do you get it ready for R-2.1.0?
In particlular, I'm very interested in the way you are going to include 
this feature for non-screen devices such as postscript()...

Uwe Ligges

  
  


  


      

    

    

      
      

        


  

        

      Dan Bolser
    

    

      
      #
    

  


  

      
On Fri, 5 Nov 2004, Uwe Ligges wrote:

        

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        
Please point me at the release schedule ;)



I am fairly sure you were attacking my comments with a snide email - if
that isn't the case - I am very sorry. Please note that I am not currently 
able to make a significant contribution to R, and please ignore the rest
of this email.

If you are being snide, however, ...


Naturally doing this is totally beyond me, but as an end user it is my
prerogative to suggest such things. In fact any good software product
should be bombarded with suggestions on how it could be improved. 

Hopefully my 'idea' isn't too far removed from the practicalities of
software development (given the underlying design of R). For example I
could say something like 'make R read my mind and do what I want...'.
If my idea is of the same magnitude of impossibility, I apologise,
however, the request still stands because, as an end user, I can imagine
this style of working fitting in with the way I experience using R.

I see the developer idea to make 'dynamic graphics for the computer game
generation'. I think my idea is easier to implement, but has the same
overall outcome.

I really don't understand the negative and condescending culture that seems
to pervade R-dev. OK, so I am running round like a headless chicken,
complaining all over the place, doing thing in an inappropriate way and
generally annoying people all over, but I am not a troll. I genuinely like
R and I genuinely wish it could be better in certain ways, and (perhaps
vainly) I believe I can help by making my opinion known. I just don't get
the 'shut-up and f*** off' attitude. 

Ah well .. perhaps I am just being over sensitive. Again, apologies all
round if that is the case.

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On Fri, 5 Nov 2004 13:51:07 +0000 (GMT), Dan Bolser
<dmb@mrc-dunn.cam.ac.uk> wrote :

            

      
      
      
    

        
I think you misunderstood the comment.  You're right that making good
suggestions is valuable.  However, R is an open source project:
nothing gets done unless someone volunteers to do it (or contributes
lots of money to pay someone to do it; that hasn't happened much yet,
though it has happened).

This means that big things only get done by their proponents.  Nobody
has time to devote to someone else's idea that will take weeks to
develop, unless it looks like a really interesting problem to solve.
A number of us happily implement small suggestions, but we just don't
have time to work on everything that would be good in R.  Luckily R
has a very active development community (see the hundreds of packages
on CRAN), so an amazing number of things get done.

            

      
      
      
    

        
Email is no good for sending or receiving nuances of meaning.  It's
very easy for someone to read a suggested improvement as a demand for
service, and that would be totally inappropriate in an open source
project.  It's also very easy for someone to read a "do it yourself"
response as negative and condescending.   Both of these may be correct
readings in some cases, but not in all:  and you'll save a lot of
energy by just ignoring the bits you don't like.

            

      
      
      
    

        
Duncan Murdoch

  
  


  


      

    

    

      
      

        


  

        

      Martin Maechler
    

    

      
      #
    

  


  

      
DanB> I really don't understand the negative and condescending
DanB> culture that seems to pervade R-dev.

It's pervading in replies to *Bug reports* about non-bugs!!
I thought you had read in the mean time what R bug reports
should be and that the things you have been posting as bug
reports were posted **WRONGLY**.

PLEASE:  
  1) All these suggestions were perfectly fit to be posted to R-devel
  2) All of them were completely NOT fit to be sent as bug reports

Martin

  
  


  


      

    

    

      
      

        
      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
hadley wickham <h.wickham@gmail.com> writes:

            

      
      
      
    

        
There is (or maybe the whole b***ing mechanism), but some of us have
other things to attend to too, so things tend to sink into the mud... 

I had a look at the time, but it was unclear to me whether the
modified forms would entail messing with the Jitterbug sources. We're
already using a locally hacked version of a system that is no longer
supported by its author, and I'm unhappy about adding further hacks to
it.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Hadley Wickham
    

    

      
      #
    

  


  

      
Some parts would probably require modifications to jitterbug, but the
majority of changes are cosmetic.  I'd be happy help out making the
changes, but I suspect it would take you just as long to explain the
system to me as it would to do it.

Hadley

  
  


  


      

    

    

      
      

        


  

        

      Byron Ellis
    

    

      
      #
    

  


  

      
On Nov 5, 2004, at 5:06 AM, Uwe Ligges wrote:

        

            

      
      
      
    

        
*snip*

            

      
      
      
    

        
The most obvious, and by far most difficult route, would be to make 
graphics devices first class citizens (IIRC Duncan TL has brought this 
up elsewhere) wherein you would aDev <- edit(aDev). That brings things 
to the device level (what you want) and a static device could act 
accordingly (i.e. not invoke a redraw). Obviously the most difficult as 
it would be a massive upheaval of base graphics (I suppose all of this 
could all be grouped under a category of "event-based streams," 
graphics events, XML SAX events, file events--aka connections, etc. 
Doesn't CL or Scheme have something along those lines?). But, as 
mentioned in the thread, pretty speculative but you never can tell what 
someone might hunker down and implement :-)

            

      
      
      
    

        

      
      
    

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

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
On Fri, 5 Nov 2004 14:01:01 -0800, Byron Ellis

        
<ellis@stat.harvard.edu> wrote:

        

            

      
      
      
    

        
Take a look at grid.  I think it's more likely something like this
would be built on top of grid than on top of base graphics.

Or, if you want to try it:

Take a look at grid.  I think you'll find it a lot easier starting
there than starting with base graphics.

Duncan Murdoch

  
  


  


      

    

    
1 day later

    

      
      

        


  

        

      Paul Murrell
    

    

      
      #
    

  


  

      
Hi

        
Duncan Murdoch wrote:

            

      
      
      
    

        
Grid provides graphical objects to work with and there are a couple of 
ways to create a GUI front-end.

See, for example, RGrace (http://www.hppi.troitsk.ru/Kondrin/rgrace.htm)

Paul