headers
Mike Jenkins | 1 May 2009 03:46
Favicon

open_file question

I’m having trouble piecing together the correct syntax for the filter keyword of open file.

 

from enthought.traits.ui.file_dialog  import open_file

open_file(filter=’Text file (*.txt)|*.txt’)

 

…selects no files.

 

open_file(filter=[’Text file (*.txt)|*.txt’,])

 

…selects text files.

 

open_file(filter=[’Text file (*.txt)|*.txt’, ’Python (*.py)|*.py’])

 

…selects only text files, and…

 

open_file(filter=[’Python (*.py)|*.py’, ’Text file (*.txt)|*.txt’,])

 

…selects only Python files.

 

Can someone clue me how to apply multiple, logically or’ed filters?  (A pull-down selection among filters would be OK, too.)

 

Thanks much,

Mike

 

 


This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. 
_______________________________________________
Enthought-dev mailing list
Enthought-dev@...
https://mail.enthought.com/mailman/listinfo/enthought-dev
Permalink | Reply | 502 comments |
headers
Prabhu Ramachandran | 1 May 2009 09:09
Picon
Gravatar

Re: bbfreeze and VTK

Julien Lamy wrote:
> Your wild guess was right. I don't have a vtkCommonPython.py either. 
> However, there is a vtkCommonPython.pyc in the library.zip of the frozen 
> version, so I guess bbfreeze is doing something with the original DLL. I 
> do have the vtkCommonPython.pyd, and it is included in the frozen version.
> 
> I'll have a deeper look at bbfreeze and see if I can come up with something.

Try removing the vtkCommonPython.pyc file from the library.zip.

prabhu
Permalink | Reply | 1 comment |
headers
Prabhu Ramachandran | 1 May 2009 09:12
Picon
Gravatar

Re: [mv2] Request: modify Axes module

B. P. Thrane wrote:
> I've had a look at the Axes module in detail and it turns out that it is 
> built on vtkCubeAxesActor2D. The "2D" suffix didn't look good, so I had 
> a look around and it turns out there is another much more powerful VTK 
> actor available called vtkCubeAxesActor. I did a simple test by adding 
> the following lines to the tvtk example called tiny_mesh.py:
> 
> cam = tvtk.Camera()
> ax = tvtk.CubeAxesActor(camera=cam)
> renderer.add_actor(ax)
> 
> As this doesn't set the view correctly, the axes are displayed in front 
> of the view, but one can clearly see that this module behaves correctly 
> in 3D with perspective. It has a lot of features I've been missing, it 
> even rotates the labels and give better individual axis controls, at 
> least it seems, anyway just look at the traits available in the tvtk 
> object below!

I had completely forgotten about this axes class.  A long while ago this 
was ported from paraview to VTK but at that time since it was only 
available in VTK-cvs I did not wrap it.  I'll have to figure out which 
release has this available and wrap it suitably.  I have no idea when I 
will get around to it though.  Maybe next weekend.

regards,
prabhu
Permalink | Reply | 9 comments |
headers
Robert Kern | 1 May 2009 09:14
Gravatar

Re: bbfreeze and VTK

On Fri, May 1, 2009 at 02:09, Prabhu Ramachandran
<prabhu@...> wrote:
> Julien Lamy wrote:
>> Your wild guess was right. I don't have a vtkCommonPython.py either.
>> However, there is a vtkCommonPython.pyc in the library.zip of the frozen
>> version, so I guess bbfreeze is doing something with the original DLL. I
>> do have the vtkCommonPython.pyd, and it is included in the frozen version.
>>
>> I'll have a deeper look at bbfreeze and see if I can come up with something.
>
> Try removing the vtkCommonPython.pyc file from the library.zip.

I'm pretty sure it's supposed to be there. Like zipped eggs, there
needs to a pure Python module in there that redirects to the real DLL.
The problem is most likely that the non-extension DLL that
vtkCommonPython.pyd links to is missing.

--

-- 
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
Permalink | Reply | 0 comments |
headers
Prabhu Ramachandran | 1 May 2009 09:20
Picon
Gravatar

Re: [mayavi] expand object in tree view...

fred wrote:
> fred a écrit :
>> Prabhu Ramachandran a écrit :
>>> On 04/10/09 00:08, fred wrote:
>>>> Is possible to set an attribute to tell that I don't want a object in
>>>> the tree view to not be expanded, like in the snapshots for the
>>>> MaskPoints filter?
>>> No not currently.  One could expose a trait that returns True/False on 
>>> the can_auto_close method but this seems too specialized.
>> Ok, thanks.
> In fact, can you show me a simple example showing how to do that?
> 
> Let's start from contour.py exemple.
> Drag the VTK reader in ipython shell.
> 
> And now?
> 
> I see a lot of tno_* VTK reader attributes (so tno_can_auto_close())
> which require node as argument.
> 
> But how can I get the node related to the dragged object?

You will need to override the tno_can_auto_close method in a subclass 
and return True/False depending on what you want.  I think you could 
monkey patch this.  You typically won't need to get the node related to 
the dragged object -- see core/base.py for example.

prabhu
Permalink | Reply | 5 comments |
headers
Prabhu Ramachandran | 1 May 2009 09:22
Picon
Gravatar

Re: [mayavi] keyboard/mouse interaction...

fred wrote:
> Prabhu Ramachandran a écrit :
> 
>> Keep track of a KeyPressEvent (check on the exact name), get the 
>> KeyCode/KeySym (check again), then toggle a flag in your code, then 
>> track the mousewheel by either adding the observer after the 'w' is 
>> toggled on or keeping it all the time and toggling off.
> Half fixed.
> 
> This was the straightforward part (adding the observer).
> 
> The less straightforward one is to remove or abort the previous
> (initial) callbacks for MouseWheelBackwardEvent & MouseWheelForwardEvent
> and added again/start them when I finished to play with my resising
> glyphs tool. :-(

When you call add_observer, it returns an index corresponding to the 
callback attached.  To remove the callback you can do something like so 
(untested):

  x = obj.add_observer('SomeEvent', cbk)
  obj.remove_observer(x)

prabhu
Permalink | Reply | 18 comments |
headers
Prabhu Ramachandran | 1 May 2009 09:29
Picon
Gravatar

Re: [mayavi] CME crash

fred wrote:
> Hi,
> 
> What am I doing wrong with this simplified CME?
> 
> I only want to test adding new engines (without any source, yes).
> 
> 
> It crashes when I press on "new scene" button.

Works on the mac.  You may want to avoid deleting the first scene you 
create.  That might be the source of the problem.  I also think this is 
cleaner:

  49    def _current_tab_default(self):
  50         return self.tabs_list[0]
  51
  52     def _tabs_list_default(self):
  53         return [DisplayTab()]

rather than what you had originally.

prabhu
Permalink | Reply | 0 comments |
headers
Prabhu Ramachandran | 1 May 2009 09:31
Picon
Gravatar

Re: Bumping up numpy requirement for Mayavi

Gael Varoquaux wrote:
>> You do more R&D when you aren't updating things on a daily/monthly 
>> basis.  If not you end up doing R&D on various software upgrade issues.
> 
> Well, yes and no. I get frustrate when I see people around me busy
> implement code that exists in recent releases of foobar, just because
> they do not want to depend on it. But that's another debate.

The statement is true when you are working on something that is 
available as open source not otherwise.

>> I think it is reasonable but I would prefer we supported 1.04.  One 
>> solution would be to simply save it as a gzipped string. In fact if you 
>> used enthought.persistence.state_pickler to save a dict containing the 
>> arrays it will do it for you automatically.
> 
> Is this going to be cross platform (I am thinking of issues eg related to
> endianness)? From looking at the code I see that it uses ndarray.dumps. I
> don't know if this is portable.

I don't know but thought that it should be endian-neutral but am not sure.

prabhu
Permalink | Reply | 1 comment |
headers
Prabhu Ramachandran | 1 May 2009 09:38
Picon
Gravatar

Re: New documentation

Gael Varoquaux wrote:
> I have just done a big commit that rewamps the documentation, the
> documentation-building and part of the packaging.
> 
> The main added feature is a gallery of examples, with some images. Also
> the docs have recieved a lot of minor improvements, both linked to the
> addition of the examples, and not. The documentation generation is now
> more automatic, and thus checked in generated code has been removed.

Excellent!  I just got everything built on my mac and it looks terrific. 
  Thanks for all the work on this!

> A close eye has been kept on the size of the docs and the final sdist.
> With many minor improvement (removing generated, unecessary and
> duplicated files), the size of the sdist is down to 8.3M.

Hmm, but the html.zip that is checked in is still at 13MB?

cheers,
prabhu
Permalink | Reply | 8 comments |
headers
Gael Varoquaux | 1 May 2009 09:43
Favicon
Gravatar

Re: New documentation

On Fri, May 01, 2009 at 01:08:38PM +0530, Prabhu Ramachandran wrote:
> > A close eye has been kept on the size of the docs and the final sdist.
> > With many minor improvement (removing generated, unecessary and
> > duplicated files), the size of the sdist is down to 8.3M.

> Hmm, but the html.zip that is checked in is still at 13MB?

Yes. I can't check in the file: I get a timeout on the SVN. This is
really a pain, because it means I can't update the website either.

Peter, (or anybody else) any chance changing some settings on apache (eg
timeout) will improve the situation?

Cheers,

Gaël
Permalink | Reply | 7 comments |

Gmane