Some tasks for the mayavi2 sprint

https://svn.enthought.com/enthought/wiki/MayaviSprint2008

And now I got to go to sleep...

Gaël

[chaco2] contour_line_plot issue

Hi,

I get an issue with the following example (with chaco from branch and 
from trunk).

If plot object is _created_ with red color, there is no problem.

However, if the plot object is created with a colormap as color
and after changed to the red color, I get this traceback:
Traceback (most recent call last):
   File "./a.py", line 70, in <module>
     demo_main(PlotFrame, size=(950,650), title="Some contour plots")
   File

"/usr/local/lib/python2.5/site-packages/enthought.enable2-2.0.5.dev_r19266-py2.5.egg/enthought/enable2/example_support.py", 
line 38, in demo_main
     frame = demo_class(None, size=size, title=title)
   File

"/usr/local/lib/python2.5/site-packages/enthought.enable2-2.0.5.dev_r19266-py2.5.egg/enthought/enable2/example_support.py", 
line 15, in __init__
     self.enable_win = self._create_window()
   File "./a.py", line 53, in _create_window
     q.colors = 'red'
   File

"/usr/local/lib/python2.5/site-packages/enthought.traits-2.0.4.dev_r18169-py2.5-linux-i686.egg/enthought/traits/trait_handlers.py", 
line 177, in error
     raise TraitError, ( object, name, self.info(), value )
enthought.traits.trait_errors.TraitError: The 'colors' trait of a 

[chaco2] label color for Legend...

Hi,

How can I access the label color for the Legend trait ?

I have read the legend.py source code, tried to find out it with ipython
and completion, but unsuccessfully.

TIA.

Cheers,

--

-- 
Fred

Re: [chaco2] label color for Legend...

On Jul 1, 2008, at 9:21 AM, fred wrote:

> Hi,
> How can I access the label color for the Legend trait ?
> I have read the legend.py source code, tried to find out it with  
> ipython
> and completion, but unsuccessfully.

Hi Fred,

Unfortunately right now we don't directly expose that as an option.   
However, you can set it by accessing a "private" attribute of the  
Legend:

     legend._cached_labels[0].color = "green"

The Legend._cached_labels attribute is a list of Label instances (from  
label.py), and you can set attribute things  
like .color, .bgcolor, .border_width (if you want a single label in  
the legend to have a border), etc.  Below is an image with the results  
of running the following lines on simple_line.py:

         legend._cached_labels[0].color = "green"
         legend._cached_labels[0].bgcolor = "pink"
         legend._cached_labels[0].border_width = 2
         legend._cached_labels[0].margin = 2

One thing to note is that the legend only populates/updates is  
_cached_labels list when do_layout() has been called on it.  So if you  
just created the legend, set its .plots or whatever, and you want to  

Re: [chaco2] label color for Legend...

Peter Wang a écrit :

> One thing to note is that the legend only populates/updates is 
> _cached_labels list when do_layout() has been called on it.  So if you 
> just created the legend, set its .plots or whatever, and you want to 
> modify label properties, you have to force a layout call first by doing 
> legend.do_layout().
Thanks a lot, Peter.

Do you plan to change this (ie set it as an option) or do I have to keep 
this hack in my code ?

Cheers,

--

-- 
Fred

MayaVi and Composite Data Sources

Hi there,

We're currently using TVTK very happily for displaying
vtkCompositeDataSet objects.  (Subclasses, rather.)  It all seems to
be working great -- and we're doing some good scientific visualization
with it.

I was wondering if there was any hope of enabling composite data
sources in MayaVi.  From looking at the source it looks like MayaVi
requires a VTKDataSource, which in turn requires an object of type
vtkDataSet.  vtkCompositeDataSet and vtkDataSet both inherit from
vtkDataObject, but unfortunately the method of interaction is slightly
different -- for instance, vtkCompositeDataSet::GetDataSet requires a
vtkCompositeDataSetIterator, as the vtkCompositeDataSet does not
itself possess array objects, and the pipeline for all of the mapping
filters requires setting the executive to be a
vtkCompositeDataPipeline.  These are all surmountable in the TVTK
code, but I guess I don't quite know how to take a manually-generated,
non-vtkDataSet object and put that into MayaVi to enable the full set
of tools that MayaVi provides.

>From glancing at the 2.8 code in vtk_data_source.py, I'm not entirely
sure how to go about adding support in.  Has anybody ever experimented
with this?

Thanks!

-Matt

HasTraits beginner question

How do I specify that a trait must be explicitly initialized?

I'm sure I'm missing something pretty simple that I'd add to the
following definition to force the "name" attribute to be defined at
instantiaion of the Person class.

class Person(HasTraits):
    name = String

What I'd like is that this works:
p = Person(name='Bob')

But that this raises an exception:
p = Person()

Of course, I could override __init__, but it seems that there must be a
simpler way. I couldn't find anything in the Traits User's Manual.

-Andrew

Re: HasTraits beginner question

On Tue, Jul 1, 2008 at 17:30, Andrew Straw <strawman@...> wrote:
> How do I specify that a trait must be explicitly initialized?
>
> I'm sure I'm missing something pretty simple that I'd add to the
> following definition to force the "name" attribute to be defined at
> instantiaion of the Person class.
>
> class Person(HasTraits):
>    name = String
>
> What I'd like is that this works:
> p = Person(name='Bob')
>
> But that this raises an exception:
> p = Person()
>
> Of course, I could override __init__, but it seems that there must be a
> simpler way. I couldn't find anything in the Traits User's Manual.

__init__ is the way to go (even if we had another way, in my opinion).
If you are going to require something be set in the constructor, it is
best to make it a positional parameter anyways. It offsets the user's
annoyance at not having a sensible default with a nicer syntax.

--

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."

Re: Preference pages with and without envisage

Gael Varoquaux wrote:
> Mlab uses tvtk and tvtk scenes, but not always the tvtk scene plugin, as
> it can work without envisage.
> 
> Due both to historical reasons and archetictural reasons, we have a
> difference preference entry for scene color whether it is with mlab or
> with the envisage scene plugin. The historical reasons are that mlab used
> a different preference system than tvtk.plugin so as not to rely on
> envisage. This problem is gone as enthought.preferences have been
> factored out of envisage. The architectural reason is that if envisage
> and the mayavi plugin are loaded, mlab uses the mayavi plugin, and thus
> the scene plugin, however if envisage is not present, mlab instanciates
> by itself the scenes.

I'd prefer it if there were only one default color that mlab and the 
mayavi2 app use rather than two separate ones.

cheers,
prabhu

Re: Scrollable Groups

On Fri, Jun 20, 2008 at 4:42 PM, Alexander Michael
<lxander.m@...> wrote:
> I've discovered a problem with my patch that occurs when there is an
> InstanceEditor in the scrollable group (tested on WinXP with WX).
> Clicking into a field within the instance editor causes the scrolled
> panel to snap back to the origin. [I've attached a second example that
> illustrates the the problem. After launching it (with my patch
> installed), scroll down and try to click into a field.] I've been
> digging around in the WX Backend but couldn't find anything helpful so
> I am bringing this up on the list-- any suggestions what kind of event
> is being thrown and where it might be coming from?

I've fixed this problem which resulted from the ScrollChildIntoView
method of wx.lib.scrolledpanel.ScrolledPanel not accounting for
multiply nested subpanels (as occurs with the Instance editor) when
determining if and how to scroll the control with focus into view.
I've attached an updated patch and replaced the patch file in the
ticket (<https://svn.enthought.com/enthought/ticket/1467>) as well. It
would be great to see this applied to the trunk, thanks!

Alex

Index: helper.py
===================================================================
--- helper.py	(revision 19349)
+++ helper.py	(working copy)
@@ -24,6 +24,8 @@
 #-------------------------------------------------------------------------------