ggobi / cranvas Goto Github PK

I'm wondering if there is any way to avoid conflicts of function names with other packages. For example, I want to use the name visible in cranvas, but this name is also used in the gWidgets package, so it will be masked when gWidgets is loaded.

I know one possible solution to to import gWidgets and use gWidgets::function_name to avoid this package being explicitly loaded, or explicitly import the functions we need in the NAMESPACE. But currently the decision on the GUI is still unclear (whether to build a GUI in cranvas, or which toolkit do we use), so I just put gWidgets in the Suggests field.

Or we come up with another fancy name...

Sorry, I couldn't find a simpler example - this plot is about 1/3 whitespace on my computer.

library(cranvas)
data(crimes)
crimes$State <- tolower(crimes$State)
names(crimes) <- c("state", "abbr", "population", "violent", "murder", "rape", "robbery", "assault", "property", "burglary", "larceny", "cartheft", "nines")

crimes[, 4:12] <- crimes[, 4:12] / crimes$population
qcrimes <- qdata(crimes)
qscatter(qcrimes, population, log10(robbery))

library(cranvas)
data(crimes)
qcrimes <- qdata(crimes)
qparallel(data = qcrimes)

brush(qcrimes, "color") <- "red"
brush(qcrimes, "size") <- 5

Brush rectangle is still yellow.

to make the boxes more striking

Error in function (layer, event) : attempt to apply non-function

Anybody know what spawns this error?

multiple selection via the text box does not work; no idea how to fix it

to make this selector fancier, we may consider scrolling the droplist to the selected elements when brushing on a plot

Does it makes sense never to do anything from a single mouse click? Then that action is reserved for changing window focus.

hover: show the closest point

persistent brushing

e.g. we may want to change the colors of the selected objects

I'm not a particularly big fan of Emacs, but Emacs with ESS is really handy for writing roxygen documentation. For example, you do not need to type the prefix ##' for every single line (it will be automatically generated); you can generate a doc template for a function quickly; wrap long lines into shorter ones...

Currently I see there are long lines in the doc, which could be problematic for roxygen (this is a defect in roxygen I've been complaining about). Ideally you should not write too long in a single line, otherwise roxygen will fail.

I do not know if you (Iowans) are interested in trying Emacs. I believe it can save a huge amount of time in writing R docs.

in qboxplot()

all of you said yes, but I'm pretty sure things are going to be rather messy soon... as someone began to realize it...

we are using different systems, and have different settings for R; e.g. roxygen might break a line with different widths so you can see

this is a line in doc

under Linux R, but

this is a 
line in doc

under Mac R. It does not make much sense to solve these "conflicts" in GIT. There are other changes which are essentially not real changes at all. See, for example, 85db9d5

again, my opinion is to maintain the real source code, and ignore the "byproducts" (Rd files); to include them could be good to single developers, but could also be pain to collaboration.

If you have any calls to library() or require() in your code, please declare the dependent packages in the DESCRIPTION file of the package. Make it clear whether a package belongs to the category Depends, Imports, Suggests or Enhances. Refer to the manual "Writing R Extensions" for details.

The only situation in which we need require() is that we do not absolutely need a package to run cranvas, but if that package exists, our functionality might be improved. Such code is usually written like if (require('stringr')) {...}; and the package name needs to be listed in the field Suggests or Enhances in the DESCRIPTION file.

If the package you need has been listed in the Depends field, you don't need to load it again in your code, since library(cranvas) will load the dependent packages automatically.

The alpha blending on qscatter now kicks out the error:

Error in rgb(col[1, ], col[2, ], col[3, ], col[4, ]) :
alpha level 1.63934, not in [0,1]

and points disappear.

If a variable has NA's then qtime will not plot anything.

The initial point size is too small.

The limits to alpha blending need to be set so that the points and lines don't disappear. I think the scale is exponential, because it gets transparent quickly, but I didn't check the code.

Can anybody fix this warning message?

* installing *source* package ‘cranvas’ ...
** R
** data
** inst
** preparing package for lazy loading
Loading required package: qtbase
Loading required package: qtpaint
Loading required package: plumbr
Loading required package: plyr
Warning in .checkFieldsInMethod(def, fieldNames, allMethods) :
  Local assignment to field name will not change the field:
    dest[[col]] <- data_proj[, col]
 Did you mean to use "<<-"? ( in method "step" for class "Tourr")

since the function qmap() in qtpaint has been renamed to qvmap(), we can use the name qmap in cranvas now.

they are too crowded at the moment

currently I only considered the bar plot for a factor variable; if we also consider continuous variables, there will be extra burden in programming since brushing should work differently, axis labels should be different, ...

do it like this:

library(qtpaint); library(qtbase)
x0 = qscene()
obj = Qt$QObject() # keep this in scope somewhere
x0$setParent(obj)
x1 = qlayer(x0)
x2 = qplotView(scene = x0)
qconnect(x1, 'destroyed', function(x) print('hi...'))

whoever has any important files under this directory should take them out: https://github.com/ggobi/cranvas/tree/master/files

we are going to remove this directory soon

you can use git checkout to get them back, anyway

The link_var function needs a couple more pieces:

1. A mechanism for going back to 1-1 linking, eg

    attr(Remi, "Link")$linkvar = NULL

2. A check on the variable chosen, to make sure that it is categorical. A continuous variable cannot be used for linking, not easily, you'd have to have some sort of neighborhood brush.
3. I just set a variable and then tried to change that variable, but it didn't change the variable for the brushing. The attr was changed to reflect the new one but it was still linking by the previous variable.

because qdrawSegment() will scale as the canvas size changes, which will make the ticks ugly... (too long/short)

just a note here (low priority...)

this is tedious: event$key() == Qt$Qt$Key_A

wish: key() == 'A'

it does not work at the moment; need to figure out how to avoid the infinite recursion

di said it did not make sense to draw the labels, say, from 0 to 1 when these numbers are not essentially meaningful

Changing the order of variables leave the variable labels behind

i.e. move the calculation part into cranvas, or split productplots into two modules (one for calculation, and one for plotting)

productplots depends on ggplot2, which again depends on other packages; this dependency chain is too long for cranvas

use record_selector(vars, data)

then the GUI should respond to changes in .brushed as well rather than the current one-way propagation

this should be put on a nonlinear scale like the scatterplot - it takes too long holding the - key down before the lines clearly become transparent. using the pollen data example.

when do you plan to release plumbr?

it can make the installation of cranvas a tiny bit easier

Needs to suggest gWidgetsQt rather than gWidgetsRGtk2

add an option to scale the data "globally" rather than per axis, e.g. (all.x - global.min)/(global.max - global.min)

rather than doing this inside qparallel(), qmosaic(), qhist(), ...

we have two choices when the user passes a data frame rather than a mutaframe to the plotting functions:

1. stop: stopifnot(is.mutaframe(data))
2. coerce internally: data = qdata(data) and possibly issue a warning message

I'm in favor of 2, because in this case, the only feature that is lost is linking. All the other features are still available (brushing, key stroke interactions, ...). Actually linking will also be possible if we put the coerced data in the returned object.

histogram works fine with this code:

require(cranvas)
require(ggplot2)
data(tennis)
qtennis <- qdata(tennis)

qhist(Matches, qtennis, horizontal = FALSE)

but if parallel coordinate plot is called first hist can't find qhist_split_column:

require(cranvas)
require(ggplot2)
data(tennis)
qtennis <- qdata(tennis)

qparallel(vars=c(3,4,7,8,9,10,13,14,15,17), qtennis)
qhist(Matches, qtennis, horizontal = FALSE)
Error in switch(j, .brushed = qupdate(layer.brush), .color = qupdate(layer.main), :
EXPR must be a length 1 vector
Error in get(i, x, inherits = FALSE) :
object 'qhist_split_column' not found
Error in get(i, x, inherits = FALSE) :
object 'qhist_split_column' not found

qhist_split_column shouldn't be necessary for a basic histogram, anyway.

Can we input the desired plot size as an argument to each plot function?

the little GUI record_selector()

in the near future, we will change qdata() to something like this:

qdata(flea, color = species, fill = species, size = head, palette = 'auto')

then use the scales package to generate the real colors/sizes, e.g. use dscale to create qualitative colors, or area_pal to create point sizes...

the data will have a new attribute so it will be easy to create a legend layer from it; we can also change the color palette or the color variable on the fly (via command line at the moment)

R-exts 1.3.2

long time ago I surrendered to Michael (and Hadley?) and designed the current qmutaframe(), which I never thought was elegant. I don't like the idea to directly augment the original data by extra columns .colors, .brushed, ... The only reason I saw to do so was that users might want to play with these additional columns. This is not persuasive in my eyes.

What I want is a mutalist with components

  $data: the original data frame
  $color
  $visible: can hide or show certain rows
  $brushed: whether or not brushed
  $other variables corresponding to rows

Based on such a data structure, we can write higher-level interactive graphics functions, such as visible and visible<- to control the visibility of graphical elements, and brushed, brushed<- to control brushing, brush_attr/brush_attr<-, ... These function are designed to provide a consistent logic to do interactive graphics, rather than manipulating the raw data objects such as data$.brushed.

To be continued...

Right mouse button resizes brush for scatterplot, density, parallel (not the area plots).

When mouse is clicked the closest corner should be detected and resize larger of smaller the rectangle by shifting this point with the mouse movement.

1. ordering of input parameters: some functions have the data set as the first argument, others have the variables. we need to decide which we want to do.
2. is the argument "title" or "main"
3. Are we allowing xlab, ylab for everything?
4. Some functions have variable names in " ", others just the name no quotes

brushing not done yet

btw, the brushing on y ~ x is odd; should fix it (brushing side-by-side boxplots is OK)