headers
Martin Spacek | 1 Nov 21:11

Tooltips to identify plotted objects in mayavi

I have a bunch of datapoints I'm plotting in 3D with mlab.points3d(). I also
have a bunch of ellipsoids (ParametricSurface objects) interspersed among the
plotted data, enveloping some of the points. Each ellipsoid has an associated
ID, and I'd like to be able to display that ID in a tooltip when hovering over
the ellipsoid with the mouse.

Is there a simple way to do this?

I find the whole enthought/mayavi/VTK/TVTK/Traits/Envisage/wx combination a big
confusing jumble, and I have no clear idea of where to begin, nor can I find
any tips in the mayavi documentation or this mailing list. I have some
scattered ideas:

When I print out my scene.interactor, I notice it has a MouseMoveEvent
vtkObserver, which might be useful. Or, maybe I should catch a wx mouse
movement event, grab the mouse's x and y coords in wx, use those to
somehow do a hit test on the vtk stuff underlying it
(maybe scene.picker.pick_world(x, y)?), and somehow check if there's an
ellipsoid under the returned coordinate. Or simply find the nearest one.

Thanks for any help you can offer,

Martin
Permalink | Reply | 5 comments |
headers
Lic. José M. Rodriguez Bacallao | 2 Nov 04:56
Picon

Re: about application object

thanks for the answer. A question (and a suggestion too): why not to
make the application singleton object available from a simple import
off the Application class and get a class instance attribute for this
singleton, for example:

from enthought.envisage.api import Application

application_singleton = Application.app

On Sat, Oct 31, 2009 at 4:33 PM, Robert Kern <rkern <at> enthought.com> wrote:
> On Sat, Oct 31, 2009 at 14:22, Lic. José M. Rodriguez Bacallao
> <jmrbcu <at> gmail.com> wrote:
>> hi folks, I need to get the application object from inside a service
>> object to lookup some other services, is there any way to achieve that
>> without passing the application object from the plugin
>> (plugin.application) in the service creation time to the service
>> object, say, in the constructor?
>
> You should pass the application object from the plugin to the services
> that need it. Alternately, you should obtain the other services that
> it needs at construction time and just configure it with those from
> the start.
>
> --
> 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
(Continue reading)

Permalink | Reply | 18 comments |
headers
Robert Kern | 2 Nov 05:08
Gravatar

Re: about application object

On Sun, Nov 1, 2009 at 22:56, Lic. José M. Rodriguez Bacallao
<jmrbcu <at> gmail.com> wrote:
> thanks for the answer. A question (and a suggestion too): why not to
> make the application singleton object available from a simple import
> off the Application class and get a class instance attribute for this
> singleton, for example:
>
> from enthought.envisage.api import Application
>
> application_singleton = Application.app

1) It's much, much better design to write your services not require an
Envisage Application wherever possible. It makes things much easier to
test.

2) Even if the services do need to reference the Application, it's
best to avoid singletons in any case. We used to have a
get_application() function to return a singleton Application, but
we've moved away from that. Application is no longer a singleton.

--

-- 
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> enthought.com
(Continue reading)

Permalink | Reply | 17 comments |
headers
Lic. José M. Rodriguez Bacallao | 2 Nov 06:21
Picon

Re: about application object

I am designing many services based on another services, for example a
service that need another service to work, so the second service need
to lookup the first service and this (the lookup of a service) is only
achievable through the application object, as an example: I have a
DicomReader service that read just read dicom files from a dir, cd,
dicom server (Q/R) and a visualization service that visualize those
dicom files. When I need to visualize those files I need to lookup the
DicomReader service to read those files first so I need to have the
application object at hand. Is this a bad design?

On Sun, Nov 1, 2009 at 11:08 PM, Robert Kern <rkern <at> enthought.com> wrote:
> On Sun, Nov 1, 2009 at 22:56, Lic. José M. Rodriguez Bacallao
> <jmrbcu <at> gmail.com> wrote:
>> thanks for the answer. A question (and a suggestion too): why not to
>> make the application singleton object available from a simple import
>> off the Application class and get a class instance attribute for this
>> singleton, for example:
>>
>> from enthought.envisage.api import Application
>>
>> application_singleton = Application.app
>
> 1) It's much, much better design to write your services not require an
> Envisage Application wherever possible. It makes things much easier to
> test.
>
> 2) Even if the services do need to reference the Application, it's
> best to avoid singletons in any case. We used to have a
> get_application() function to return a singleton Application, but
> we've moved away from that. Application is no longer a singleton.
(Continue reading)

Permalink | Reply | 16 comments |
headers
Robert Kern | 2 Nov 06:24
Gravatar

Re: about application object

On Mon, Nov 2, 2009 at 00:21, Lic. José M. Rodriguez Bacallao
<jmrbcu <at> gmail.com> wrote:
> I am designing many services based on another services, for example a
> service that need another service to work, so the second service need
> to lookup the first service and this (the lookup of a service) is only
> achievable through the application object, as an example: I have a
> DicomReader service that read just read dicom files from a dir, cd,
> dicom server (Q/R) and a visualization service that visualize those
> dicom files. When I need to visualize those files I need to lookup the
> DicomReader service to read those files first so I need to have the
> application object at hand. Is this a bad design?

Like I recommended before, do the lookups in the start() method of the
plugin that constructs the services. Configure the services with
references to the other services that they need.

--

-- 
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> enthought.com
https://mail.enthought.com/mailman/listinfo/enthought-dev
Permalink | Reply | 15 comments |
headers
Lic. José M. Rodriguez Bacallao | 2 Nov 06:38
Picon

Re: about application object

so, I will need to lookup the service I need as dependence and the
service I need to configure and the configure it, is this correct?

example:

# plugin start override
def start():
    reader = self.application.get_service('imagis.dicom.reader.DicomReader')
    visualizer =
self.application.get_service('imagis.dicom.visualizer.Visualizer)
    visualizer.reader = reader

PS: sorry for my english, it's not so good.

On Mon, Nov 2, 2009 at 12:24 AM, Robert Kern <rkern <at> enthought.com> wrote:
> On Mon, Nov 2, 2009 at 00:21, Lic. José M. Rodriguez Bacallao
> <jmrbcu <at> gmail.com> wrote:
>> I am designing many services based on another services, for example a
>> service that need another service to work, so the second service need
>> to lookup the first service and this (the lookup of a service) is only
>> achievable through the application object, as an example: I have a
>> DicomReader service that read just read dicom files from a dir, cd,
>> dicom server (Q/R) and a visualization service that visualize those
>> dicom files. When I need to visualize those files I need to lookup the
>> DicomReader service to read those files first so I need to have the
>> application object at hand. Is this a bad design?
>
> Like I recommended before, do the lookups in the start() method of the
> plugin that constructs the services. Configure the services with
> references to the other services that they need.
(Continue reading)

Permalink | Reply | 14 comments |
headers
Robert Kern | 2 Nov 06:48
Gravatar

Re: about application object

On Mon, Nov 2, 2009 at 00:38, Lic. José M. Rodriguez Bacallao
<jmrbcu <at> gmail.com> wrote:
> so, I will need to lookup the service I need as dependence and the
> service I need to configure and the configure it, is this correct?
>
> example:
>
> # plugin start override
> def start():
>    reader = self.application.get_service('imagis.dicom.reader.DicomReader')
>    visualizer =
> self.application.get_service('imagis.dicom.visualizer.Visualizer)
>    visualizer.reader = reader

That would work. However, you may want to do this in the plugin that
instantiates the Visualizer:

def start(self):
    reader = self.application.get_service('imagis.dicom.reader.DicomReader')
    visualizer = Visualizer(reader=reader)

--

-- 
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
(Continue reading)

Permalink | Reply | 13 comments |
headers
Lic. José M. Rodriguez Bacallao | 2 Nov 06:54
Picon

Re: about application object

yes but, Visualizer is a service, how to contribute a service in the
start method of a plugin?

On Mon, Nov 2, 2009 at 12:48 AM, Robert Kern <rkern <at> enthought.com> wrote:
> On Mon, Nov 2, 2009 at 00:38, Lic. José M. Rodriguez Bacallao
> <jmrbcu <at> gmail.com> wrote:
>> so, I will need to lookup the service I need as dependence and the
>> service I need to configure and the configure it, is this correct?
>>
>> example:
>>
>> # plugin start override
>> def start():
>>    reader = self.application.get_service('imagis.dicom.reader.DicomReader')
>>    visualizer =
>> self.application.get_service('imagis.dicom.visualizer.Visualizer)
>>    visualizer.reader = reader
>
> That would work. However, you may want to do this in the plugin that
> instantiates the Visualizer:
>
> def start(self):
>    reader = self.application.get_service('imagis.dicom.reader.DicomReader')
>    visualizer = Visualizer(reader=reader)
>
> --
> 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
(Continue reading)

Permalink | Reply | 9 comments |
headers
Robert Kern | 2 Nov 06:59
Gravatar

Re: about application object

On Mon, Nov 2, 2009 at 00:54, Lic. José M. Rodriguez Bacallao
<jmrbcu <at> gmail.com> wrote:
> yes but, Visualizer is a service, how to contribute a service in the
> start method of a plugin?

self.application.register_service()

If you are using service_offers instead of registering services
directly, just do the in the factory function instead.

--

-- 
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> enthought.com
https://mail.enthought.com/mailman/listinfo/enthought-dev
Permalink | Reply | 8 comments |
headers
Lic. José M. Rodriguez Bacallao | 2 Nov 07:03
Picon

Re: about application object

yes, I'm using the service_offer way for registering my services, I
don't understand what U mean with: "just do the in the factory
function instead."

On Mon, Nov 2, 2009 at 12:59 AM, Robert Kern <rkern <at> enthought.com> wrote:
> On Mon, Nov 2, 2009 at 00:54, Lic. José M. Rodriguez Bacallao
> <jmrbcu <at> gmail.com> wrote:
>> yes but, Visualizer is a service, how to contribute a service in the
>> start method of a plugin?
>
> self.application.register_service()
>
> If you are using service_offers instead of registering services
> directly, just do the in the factory function instead.
>
> --
> 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> enthought.com
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>

--

-- 
Lic. José M. Rodriguez Bacallao
(Continue reading)

Permalink | Reply | 7 comments |

Gmane