Elmo Mäntynen | 1 Sep 08:40
Picon
Picon
Favicon

Re: [EnvisagePlugins] About the views in the workbench being black


Evan Patterson wrote:
> Elmo Mäntynen wrote:
>> Evan Patterson wrote:
>>> Elmo Mäntynen wrote:
>>>> I hace the latest trunk of ETS and started to build a gui around the
>>>> workbench framework. It seems quite nice, but views have black as
>>>> background color by default somehow, which looks bad with the normal
>>>> grey, black and white, and I'm quite sure it obscures some text. Is
>>>> there an easy fix that I can do in my code?
>>>>
>>>> You should see what I mean by running the examples in EnvisagePlugins. I
>>>> tried to use qt4 also, but that doesn't seem to be supported. Might some
>>>> earlier release not have this problem?
>>>>
>>>> I'm a bit late with this as the code is supposed to be usable by
>>>> non-programmers next week :)
>>>>
>>>> Elmo
>>> What problems do you see when running the Envisage examples under Qt? It 
>>> is supported, and they *should* work.
>> I-ve attached the traceback of running the lorenz example with -toolkit
>> qt4. With my own app I had different 'importing wx after selecting qt4,
>> which now seems to be the EnthoughtDeveloperPlugin and FBIPlugin.
>>
>> Acmelab doesn't crash with qt4, but it looks weird (notice the several
>> About buttons), see a screen cap:
>> http://picasaweb.google.com/lh/photo/w-GxRL1IBnpHgufDhj8oDQ?authkey=Gv1sRgCLvSis77p7PkrQE&feat=directlink
>>
>> I have several packages installed which require wx2.6, so how to easily
(Continue reading)

Elmo Mäntynen | 1 Sep 08:45
Picon
Picon
Favicon

Re: How to best proxy a non-traits object?


Robert Kern wrote:
> On Sat, Aug 29, 2009 at 04:54, Elmo Mäntynen<elmo.mantynen <at> iki.fi> wrote:
>> That is interesting, but for now I would just like to easily created a
>> proxy without the error prone typing of the trait names multiple times.
>> I tried the following:
>>
>> **********
>> def fix_proxy(d, names):
>>    for name in names:
>>        def f(self):
>>            return getattr(self.source, name)
>>        d['_get_'+name] = f
> 
> What you are doing here is creating len(names) function objects.
> However, each one refers to the variable name "name". It does not bind
> to the value of "name" at the time of function object creation, but at
> the time of calling. That's why each one of these only refers to the
> last name. Try this instead:
> 
> def f(self, name=name):
>     ....
> 

Thanks. I had just recently read about this confusing feature. Maybe
this trial and error has taught me now properly :)
_______________________________________________
Enthought-Dev mailing list
Enthought-Dev <at> enthought.com
https://mail.enthought.com/mailman/listinfo/enthought-dev
(Continue reading)

Elmo Mäntynen | 1 Sep 09:54
Picon
Picon
Favicon

Re: Problem with DelegatesTo


bryce hendrix wrote:
> Robert Kern wrote:
>> On Mon, Aug 31, 2009 at 11:47, bryce hendrix<bhendrix <at> enthought.com> wrote:
>>   
>>> Elmo Mäntynen wrote:
>>>     
>>>> This is a simplified test which fails:
>>>> *********
>>>> from enthought.traits.api import Unicode, Instance, DelegatesTo, HasTraits
>>>>
>>>> class BasketProduct(HasTraits):
>>>>     name = Unicode
>>>>
>>>> class BasketEditor(HasTraits):
>>>>     selected_product = Instance(BasketProduct)
>>>>
>>>> class BasketEditorView(HasTraits):
>>>>     "The view for detailed editing of a product"
>>>>     editor = Instance(BasketEditor)
>>>>     selected_product = DelegatesTo('editor')
>>>>
>>>>     name = DelegatesTo('selected_product')
>>>>
>>>>
>>>> def test_instantiate_editor_view():
>>>>     BasketEditorView()
>>>> **********
>>>>
>>>> The error:
(Continue reading)

Elmo Mäntynen | 1 Sep 12:16
Picon
Picon
Favicon

Re: Problem with DelegatesTo


Elmo Mäntynen wrote:
> 
> bryce hendrix wrote:
>> Robert Kern wrote:
>>> On Mon, Aug 31, 2009 at 11:47, bryce hendrix<bhendrix <at> enthought.com> wrote:
>>>   
>>>> Elmo Mäntynen wrote:
>>>>     
>>>>> This is a simplified test which fails:
>>>>> *********
>>>>> from enthought.traits.api import Unicode, Instance, DelegatesTo, HasTraits
>>>>>
>>>>> class BasketProduct(HasTraits):
>>>>>     name = Unicode
>>>>>
>>>>> class BasketEditor(HasTraits):
>>>>>     selected_product = Instance(BasketProduct)
>>>>>
>>>>> class BasketEditorView(HasTraits):
>>>>>     "The view for detailed editing of a product"
>>>>>     editor = Instance(BasketEditor)
>>>>>     selected_product = DelegatesTo('editor')
>>>>>
>>>>>     name = DelegatesTo('selected_product')
>>>>>
>>>>>
>>>>> def test_instantiate_editor_view():
>>>>>     BasketEditorView()
>>>>> **********
(Continue reading)

markus.proeller | 1 Sep 14:44
Favicon

adding colorbar and title to MPL figure


Hello,

I have a question concerning the example project from http://code.enthought.com/projects/traits/docs/html/tutorials/traits_ui_scientific_app.html with the camera and control panel at the bottom of the page.
How could there be a colorbar and a title be included for the MPL figure?

Thanks,

Markus
_______________________________________________
Enthought-Dev mailing list
Enthought-Dev@...
https://mail.enthought.com/mailman/listinfo/enthought-dev
Robert Kern | 1 Sep 19:31
Gravatar

Re: adding colorbar and title to MPL figure

On Tue, Sep 1, 2009 at 07:44, <markus.proeller@...> wrote:
>
> Hello,
>
> I have a question concerning the example project from
> http://code.enthought.com/projects/traits/docs/html/tutorials/traits_ui_scientific_app.html
> with the camera and control panel at the bottom of the page.
> How could there be a colorbar and a title be included for the MPL figure?

In the image_show() function, self.figure is a matplotlib Figure. Use its API.

http://matplotlib.sourceforge.net/api/figure_api.html#matplotlib.figure.Figure

--

-- 
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
Darren Dale | 1 Sep 20:42
Picon
Gravatar

wx specific code in Traits

While converting to relative imports, I ran across the following in wy
svn checkout of Traits/enthought/traits/ui/extras/edit_column.py:

from enthought.pyface.ui.wx.grid.edit_renderer \
    import EditRenderer

I'm not sure how it should be handled, maybe just moved into TraitsBackendWX?

Darren
Robert Kern | 1 Sep 20:48
Gravatar

Re: wx specific code in Traits

On Tue, Sep 1, 2009 at 13:42, Darren Dale<dsdale24 <at> gmail.com> wrote:
> While converting to relative imports, I ran across the following in wy
> svn checkout of Traits/enthought/traits/ui/extras/edit_column.py:
>
> from enthought.pyface.ui.wx.grid.edit_renderer \
>    import EditRenderer
>
> I'm not sure how it should be handled, maybe just moved into TraitsBackendWX?

Basically, everything in extras/ is platform- and backend-specific.
Leave it be for now. Moving it to TraitsBackendWX is more involved
than just moving the files.

--

-- 
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
bryce hendrix | 1 Sep 21:25

Re: wx specific code in Traits

Darren Dale wrote:
> While converting to relative imports, I ran across the following in wy
> svn checkout of Traits/enthought/traits/ui/extras/edit_column.py:
>
> from enthought.pyface.ui.wx.grid.edit_renderer \
>     import EditRenderer
>
> I'm not sure how it should be handled, maybe just moved into TraitsBackendWX?
>
>   

Funny you should mention that file- just an hour ago I removed its 
import from the api.py file in the same dir. I also hunted through most 
of ETS for where it is imported and fixed those imports. We might be 
able to move it to BlockCanvas, or remove it altogether, unless someone 
outside of Enthought has been using it.

Bryce
Peter Wang | 2 Sep 01:23

Re: ets 3.3.0

On Aug 31, 2009, at 4:35 AM, william ratcliff wrote:

> I was trying to easy_install ets 3.3.0 (running on windows vista,  
> python 2.5) and ran into some bugs.  Here's what happened:

Hey William,

I have updated SVN of Chaco to no longer build or use the  
_speedups.cpp module, so your build error should go away.  Would it be  
possible for you to grab Chaco from SVN and install that?

Thanks,
Peter

Gmane