Re: Envisage, appropiate use of plugins, extensions and services

G'day,

Christiaan Putter wrote:
> So thus far in Envisage I have:
> 
> A workbench application with a finance plugin.
> A DataProvider interface with implementations  for 2 different sources.
> A FinanceDB class that handles storing the data locally.
> 
> ** This is where I hit my first problem:  I figured providing the
> IDataProvider implementations as services was the best way to go.  But
> how to register them?  It seems the only way to do this was within the
> plugin itself.
> 
> So in my finance plugin I have:
> 
> #### Services provided by this plugin #####################################
> 
>     def yahoo_factory(self, protocol, properties):
>         from dataprovider.yahoo import YahooDataProvider
>         return YahooDataProvider()
> 
>     def mt_factory(self, protocol, properties):
>         from dataprovider.mt import MTProvider
>         return MTProvider()
> 
>     yahoo_id = self.application.register_service('lgraphs.finance.api.IDataProvider',
> yahoo_factory)
>     mt_id = self.application.register_service('lgraphs.finance.api.IDataProvider',
> mt_factory)

Re: object-oriented access to scene actors

On 01/27/09 09:03, Eric Carlson wrote:
> On a completely separate level, I can not help but feel strongly that the tvtk/mayavi/mlab framework
might work very well as the basis for a 3d drawing package. Most recently, I used the framework to extract
pieces from a 3ds model, merge, save as stl, then open, transform, clip multiple times, merge with some
other meshes, resave as stl, import into cam package, output gcode, which was CNC milled to create a
pinewood derby car. Beyond the modeling, I also think the framework would work well for ECM2 and PyCam.

Sounds very interesting.  Thanks for the compliments.  I think VTK 
itself isn't too well suited to the scene graph like model that seems 
often better for a 3D drawing package since VTK does not have such an 
architecture underneath.  The problem being scaling to larger and larger 
number of actors.  However, it does let you do a lot of stuff and works 
brilliantly for scientific data so this is an interesting use for VTK.

> BTW, after figuring out how to use the VTK 3ds importer, I had a difficult time extracting the names of the
pieces. Dice3DS was a very useful package for my project.

Ah, OK. VTK's 3DS importer just injects a whole bunch of actors 
directly, a bit of a pain but can be worked around again thanks to 
Python.  I haven't had occasion to play with 3DS files so it is good to 
know Dice3DS is a good package to have for this kind of work.

cheers,
prabhu

newbie question...

Hi all,

What am I doing doing wrong in the following cme?

TIA.

Cheers,

--

-- 
Fred

_______________________________________________
Enthought-dev mailing list
Enthought-dev@...
https://mail.enthought.com/mailman/listinfo/enthought-dev

Re: newbie question...

On Mon, Feb 2, 2009 at 10:28, fred <fredmfp@...> wrote:
> Hi all,
>
> What am I doing doing wrong in the following cme?

#### Not strictly necessary, but good practice:
class A(HasTraits):
    colormaps = List()

    def _colormaps_default(self):
        return color_map_name_dict.keys()

class B(HasTraits):

    a = Instance(A, ())

    colormap = String('jet')

#### In Items, these dotted names are not quite the same as those in
#### on_trait_change decorators. Because there is a context with
#### multiple objects (usually the edited object and the handler, but
#### possibly others), you need to start with the name in the context.
    view = View(Item('colormap',
                     editor=EnumEditor(name='object.a.colormaps')))

--

-- 
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

chaco recenter a plot after using the pan tool

_______________________________________________
Enthought-dev mailing list
Enthought-dev@...
https://mail.enthought.com/mailman/listinfo/enthought-dev

Re: chaco recenter a plot after using the pan tool

On Mon, Feb 2, 2009 at 11:00, Chris Colbert <sccolbert@...> wrote:
>  I have a plotting application that allows the user to change the index
> range over which the function is calculated. If the plot hasn't yet been
> panned, then the plot updates the index scale when the range is altered.
> However, once the plot is panned (or zoomed) the data still updates, but the
> scale range remains the same (as it should). But I want a way to bind a
> 'refit' command to a button so as to redraw the plot as if it were just
> created (refit the value and index scales to fit all of the data).
>
> So far, the only way I have been able to do this is to instantiate the plot
> object anew sending the current parameters to the constructor. This works,
> but it causes a bug with the zoom tool where it wont zoom in as far as
> normal, and the range-zoom selection will only work intermittantly.
>
> I have tried invalidate_and_redraw() but to no avail.
>
> Is there a built in method that accomplishes this?

In the default configuration of the pan and zoom tools, pressing Esc
will do this.

--

-- 
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."
  -- Umberto Eco

Re: chaco recenter a plot after using the pan tool

_______________________________________________
Enthought-dev mailing list
Enthought-dev@...
https://mail.enthought.com/mailman/listinfo/enthought-dev

Re: chaco recenter a plot after using the pan tool

On Feb 2, 2009, at 11:13 AM, Chris Colbert wrote:

> esc moves the plot back to its origin, but doesn't rescale the axes  
> to include the new data.
>
> For example: suppose i have exp(x) for x = 0..10.   and i plot it. I  
> give the user a spin box to control the range of x.
> Now the user changes the range to x=-3..13. If i haven't yet used  
> the pan or zoom tool, the x and y axis automatically rescale to show  
> ('fit') the new data on the screen.
>
> Once I pan the plot (or zoom), the axes no longer rescale and the  
> only way I have found to fit the new data is via reinstantiation. Is  
> the method that is being called to rescale the axes prior to panning  
> or zooming available for use?
>
> Chris

That's odd... pressing Esc should set both sets of bounds (the  
DataRange objects that the X and Y LinearMappers reference) to be  
"auto".  This should definitely take into account new data.  You can  
try manually setting them: index_mapper.range.set_bounds("auto",  
"auto") and value_mapper.range.set_bounds("auto", "auto").

-Peter

Re: newbie question...

Robert Kern a écrit :

> #### Not strictly necessary, but good practice:
> class A(HasTraits):
>     colormaps = List()
> 
>     def _colormaps_default(self):
>         return color_map_name_dict.keys()
Robert, do you mean that using the _trait_default() method is "better"
than using the __init__ method?

Or using the __init__ method is a sledgehammer approach in this case?

> class B(HasTraits):
> 
>     a = Instance(A, ())
> 
>     colormap = String('jet')
> 
> #### In Items, these dotted names are not quite the same as those in
> #### on_trait_change decorators. Because there is a context with
> #### multiple objects (usually the edited object and the handler, but
> #### possibly others), you need to start with the name in the context.
>     view = View(Item('colormap',
>                      editor=EnumEditor(name='object.a.colormaps')))
Thanks a lot for the solution _and_ explanation!

Cheers,

--

-- 
Fred

Re: newbie question...

On Mon, Feb 2, 2009 at 12:09, fred <fredmfp <at> gmail.com> wrote:
> Robert Kern a écrit :
>
>> #### Not strictly necessary, but good practice:
>> class A(HasTraits):
>>     colormaps = List()
>>
>>     def _colormaps_default(self):
>>         return color_map_name_dict.keys()
> Robert, do you mean that using the _trait_default() method is "better"
> than using the __init__ method?
>
> Or using the __init__ method is a sledgehammer approach in this case?

1) I just like the _trait_default()s if one can use them.
2) You should declare the trait regardless.
3) You would need to call super(A, self).__init__(**traits)

--

-- 
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."
  -- Umberto Eco

_______________________________________________
Enthought-dev mailing list
Enthought-dev <at> mail.enthought.com
https://mail.enthought.com/mailman/listinfo/enthought-dev