headers
Prabhu Ramachandran | 1 Sep 10:16
Picon
Gravatar

Re: [mv2] behavior of surface module (contours enabled) and multiscalars variable...

>>>>> "Fred" == fred  <fredmfp@...> writes:

    Fred> Prabhu Ramachandran a écrit :
    >> Fred, I think I've finally fixed this in SVN in the
    >> enthought.branches/enthought.mayavi_2.0 branch.  Can you please
    >> test and let me know if it works for you?  Thanks.  Sorry for
    >> taking so long to fix this.
    >> 
    Fred> Hmm, may be I'm confused with the different thread about
    Fred> issues with Surface module issues...

    Fred> BTW, my last post was related to the following issue, in
    Fred> concern with the Surface module (alone this time, without
    Fred> any filter): if you change scalars, title colorbar is well
    Fred> updated, data range is well updated, but not the data
    Fred> itself, displayed by the Surface module.

Ahh, this was a tricky one since it is really a VTK bug, IMO.
Basically, the vtkDataSetMapper does not update its output if the
input point_data changes.  I've worked around the problem by creating
a new mapper each time.  I'll also post to the vtk developer list to
see what the problem.  Please check SVN and let me know if there are
problems.

Thanks.

cheers,
prabhu
(Continue reading)

Permalink | Reply | 1 comment |
headers
fred | 1 Sep 10:28
Picon

Re: [mv2] behavior of surface module (contours enabled) and multiscalars variable...

Prabhu Ramachandran a écrit :
> Ahh, this was a tricky one since it is really a VTK bug, IMO.
> Basically, the vtkDataSetMapper does not update its output if the
> input point_data changes.  I've worked around the problem by creating
> a new mapper each time.  I'll also post to the vtk developer list to
> see what the problem.  Please check SVN and let me know if there are
> problems.
>   
This does work fine this time ;-)

Thanks a lot.

Cheers,

--

-- 
http://scipy.org/FredericPetit
Permalink | Reply | 0 comments |
headers
Prabhu Ramachandran | 1 Sep 10:35
Picon
Gravatar

Re: traits - ui.dispose and exiting an application

>>>>> "DM" == David C Morrill <dmorrill@...> writes:

    > Gael Varoquaux wrote:
[...]
    >> I have been having the same hesitations with pylab figures and
    >> finally decided that a figure was an object, and that an editor
    >> was just a representation of that object, just like the
    >> InstanceEditor is a representation of a HasTraits object that
    >> uses its traits to represent it.
    >> 
    >> I can alway access the object in my callbacks. Something like
    >> 
    >> SceneWrapper(HasTraits):
    >> 
    >> scene = Instance(Scene, (), editor=TVTKSceneEditor)
    >> 
    >> background = Delegate('scene')
    >> 
    >> off_screen_rendering = True
    >> 
    >> seems to make sense.

I was thinking of something along those lines too.  In addition to
that I was thought this would be handy:

 scene = Instance(SceneWrapper, (),
                  actors='my_actors', widgets='my_widgets')

where my_actors and widgets are List traits on the object where the
user would add/remove actors and widgets and SceneWrapper would listen
(Continue reading)

Permalink | Reply | 2 comments |
headers
Gael Varoquaux | 1 Sep 11:02
Favicon
Gravatar

Re: traits - ui.dispose and exiting an application

On Sat, Sep 01, 2007 at 02:05:28PM +0530, Prabhu Ramachandran wrote:
> I was thinking of something along those lines too.  In addition to
> that I was thought this would be handy:

>  scene = Instance(SceneWrapper, (),
>                   actors='my_actors', widgets='my_widgets')

It took me a while to see how you would implement this. I must say I am
not to excited about this syntax. To me actors and widgets are properties
of the editor, or of the SceneWrapper instance, but not of the Traits.
They should be passed along like:

    scene = Instance(SceneWrapper, (),
		    editor=SceneEditor( actors='my_actors',
					widgets='my_widgets'))

to do something similar to:

    class A(HasTraits):
	a = Str('b')
	b = Event(editor=ButtonEditor(_label='a'))
	view=View('a', 'b')

or like:

    scene = Instance(SceneWrapper, (),
			{'actors'=[...], 'widgets'=[...]})

The reason I am not to excited about the use of traits metadata is that
it is not to standard for this kind of use. I don't feel it is an
(Continue reading)

Permalink | Reply | 1 comment |
headers
Prabhu Ramachandran | 1 Sep 13:07
Picon
Gravatar

Re: traits - ui.dispose and exiting an application

>>>>> "Gael" == Gael Varoquaux <gael.varoquaux@...> writes:

    Gael> On Sat, Sep 01, 2007 at 02:05:28PM +0530, Prabhu
    Gael> Ramachandran wrote:
    >> I was thinking of something along those lines too.  In addition
    >> to that I was thought this would be handy:

    >> scene = Instance(SceneWrapper, (), actors='my_actors',
    >> widgets='my_widgets')

    Gael> It took me a while to see how you would implement this. I
    Gael> must say I am not to excited about this syntax. To me actors
    Gael> and widgets are properties of the editor, or of the
    Gael> SceneWrapper instance, but not of the Traits.  They should
    Gael> be passed along like:

    Gael>     scene = Instance(SceneWrapper, (), editor=SceneEditor(
    Gael> actors='my_actors', widgets='my_widgets'))
    Gael> to do something similar to:

Fair enough.  I was only outlining the ideas and not the specifics of
the syntax. :-)

    Gael> or like:

    Gael>     scene = Instance(SceneWrapper, (), {'actors'=[...],
    Gael> 'widgets'=[...]})

This is no good since a user can't just add/delete to the list
dynamically.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ondrej Certik | 1 Sep 18:38
Picon
Gravatar

debian package for the mayavi2 and traits

Hi,

as I promised at the SciPy2007 conference, I can create the Debian
packages for mayavi2 and traits and get them to Debian (and Ubuntu).

If you are interested, could you please do a release? As a tar.gz. I
am the maintainer of the python-scipy package now, so I should be able
to fix things fast. If I run into any problems, I'll ask you.

If you are unable to do a release as a tar.gz, then I need to create a
short script, how to generate such a tar.gz, either from svn, or egg,
or whatever you have.

Ondrej
Permalink | Reply | 49 comments |
headers
Prabhu Ramachandran | 1 Sep 20:59
Picon
Gravatar

Re: Threshold patch...

>>>>> "Fred" == fred  <fredmfp@...> writes:

    Fred> As previously discussed with Prabhu a few weeks ago, I wrote
    Fred> a patch for the Threshold filter.

    Fred> This new Threshold filter let you choose what kind of data
    Fred> you want to threshold: data cells or data points, via a Enum
    Fred> traits.

Thanks Fred.  I've updated threshold.py to work with on both point and
cells based on your patch but implemented quite differently.  Please
check the source to see what I've done different.  Thanks again for
the patch and patience. :-)

I've also added an option to disable the automatic resetting of the
thresholds.

cheers,
prabhu
Permalink | Reply | 8 comments |
headers
Prabhu Ramachandran | 1 Sep 20:56
Picon
Gravatar

Re: [MayaVi-users] Threshold filter with timeseries

>>>>> "Luis" == Luis Armendariz <luis@...> writes:

    Luis> It seems that in Mayavi, the lower and upper thresholds
    Luis> reset to a different range when stepping through a
    Luis> timeseries, which is quite annoying.  I realize that this
    Luis> happens because the range of values changes from step to
    Luis> step, but it'd still be nice to have the option of stepping
    Luis> through a fixed threshold range.

    Luis> I've added two checkboxes to the Threshold class so I can
    Luis> control which of the upper/lower thresholds to fix. Mostly,

I've incorporated this and a feature that Fred asked for (thresholding
on cells and points) into the Threshold filter please check it and let
me know if it works OK.  Many thanks for the patch.

regards,
prabhu
Permalink | Reply | 0 comments |
headers
Prabhu Ramachandran | 1 Sep 21:33
Picon
Gravatar

Re: debian package for the mayavi2 and traits

Hey Ondrej,

>>>>> "Ondrej" == Ondrej Certik <ondrej@...> writes:

    Ondrej> Hi, as I promised at the SciPy2007 conference, I can
    Ondrej> create the Debian packages for mayavi2 and traits and get
    Ondrej> them to Debian (and Ubuntu).

That is absolutely awesome news!  Thanks so much!

    Ondrej> If you are interested, could you please do a release? As a
    Ondrej> tar.gz. I am the maintainer of the python-scipy package
    Ondrej> now, so I should be able to fix things fast. If I run into
    Ondrej> any problems, I'll ask you.

Terrific.  We have an ETS-2.5 (ETS == Enthought Tool Suite) release
but AFAIK, the release manager, Dave Peterson, is away on vacation for
couple of weeks.  ETS 2.5 was the first release of ETS in the form of
eggs and while things work there are some bugs.

I am fixing several bugs in mayavi and tvtk on the branches.  In a
week I'll hopefully fix most of the critical bugs.  Then I will be
ready for an ETS 2.6 release.  In the meanwhile perhaps it may be a
good idea to get things going with the 2.5 release.

    Ondrej> If you are unable to do a release as a tar.gz, then I need
    Ondrej> to create a short script, how to generate such a tar.gz,
    Ondrej> either from svn, or egg, or whatever you have.

The source packages for ETS-2.5 are already available here:
(Continue reading)

Permalink | Reply | 43 comments |
headers
Ondrej Certik | 1 Sep 22:26
Picon
Gravatar

Re: debian package for the mayavi2 and traits

> The source packages for ETS-2.5 are already available here:
>
>  http://code.enthought.com/enstaller/eggs/source

Perfect, those tar.gz are fine. Are you versioning all of them at
once, with ETS-2.5, ETS-2.6, ...? What I would like to do is to create
a separate package for all components, that are necessary and treat
them as separate packages.
I'll start with traits, see how it goes and then try other.

> To install mayavi2 from this you can simply do this:
>
>  $ easy_install -f http://code.enthought.com/enstaller/eggs/source \
>    enthought.mayavi
>
> Provided that you have easy_install setup properly**.

Yes, but as you said, no automatic downloading is suitable. But I'll
just take those tar.gz and use them, in the same standard way as all
the other debian packages.

Do you need to name the packages "enthought.traits"? Why not just
"traits"? The Debian source package will be just "traits" and the
binary "python-traits", so I will have to rename it anyway. It would
be easier, if your tarball was already named correctly. The other
option is just to release a gigantic enthought package, that will
contain all of the subpackages.

I'll have to rename traits.ui.wx to traits-ui-wx. So this together
with "traits" will be the 2 traits packages, is that ok?
(Continue reading)

Permalink | Reply | 37 comments |

Gmane