headers
Dave Peterson | 1 Jul 21:01

Re: Enthought Edition Package for Linux

Hi Gundala,

We don't yet have a build of Python Enthought Edition (aka Enthon) 
publicly available for RHEL 4.   We're not far from it, but our 
priority, for various customer reasons, is getting Python 2.5 Windows 
out.   The form of the release, when we get to it, will likely be done 
as eggs -- which means the tools likely won't be usable by things 
outside of Python.

-- Dave

Gundala Viswanath wrote:
> Thanks for your reply. I am using Red Hat Enterprise 4.
> I had a lot of trouble installing mainly SciPy, MatPlotLib, and
> other scientific packages.
>
> Enthought seem to be the one I am looking for. It has everything there.
>
> --
> Gundala
>
> On 7/1/07, Gael Varoquaux <gael.varoquaux@...> wrote:
>   
>> On Sun, Jul 01, 2007 at 01:59:06AM +0800, Gundala Viswanath wrote:
>>     
>>> The Enthought Edition is truly incredible. I want to re-place my original
>>> Python in my Linux box with Enthought Edition. This really save me trouble
>>> installing all those packages on my own.
>>>       
>> I don't rally see why you would need the enthought python distribution
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Peterson | 1 Jul 21:16

Re: Traits design question.... custom editors with toolkit selection?

David C. Morrill wrote:
> Well, I'm glad you realized  the problem before you completed all of the 
> refactoring :-)
>
> I saw your previous note about refactoring all of the dependencies out 
> of the wx editor code, and I was wondering either:
>
> a) how you were going to do it, or
> b) were you unaware that you were about to break a lot of code?
>
> Apparently the answer was  (b). :-)
>   

I certainly hope not.  I'm removing the editors from traits.ui as well 
as traits.ui.wx, and all references to them in various api.py's, etc.  
In order to do it, I'm punting on making the editors have different 
toolkit implementations and just going for a wx version.   Hopefully I'm 
doing it right!   I wouldn't mind you reviewing the SVN check-ins and 
letting me know if something is wrong. :-)   This could be done for the 
chaco (chaco_1.9) PlotEditor since I've already checked that in.

> I never claimed that the current toolkit design was the best possible 
> approach, but it was the best I could come up with at the time. But its 
> main weakness is extensibility.
>   

Never meant to imply you did claim it!  Just asking for confirmation / 
help on how to extend it if it was possible.

> BTW, just so you understand the current 'design' a little better: the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Brennan Williams | 2 Jul 02:34
Gravatar

Re: [traits] creating tabbed list..

fred wrote:
> Brennan Williams a écrit :
>> Fred, can you attach the whole piece of code again?
>>
>>   
> No problem, Brennan.
>
>> Also, I wonder if you create a large number of tabs (e.g. 200) where 
>> there is an easy way of scrolling left/right through the tabs?
>> In your app, how many tabs would you typically create?
>>   
> Oh, far less.
> For my real-world app, around 5, only.
>
> Can you try it and let me know if you get the same issue ?
>
under Windows (XP, Python 2.4 and ETS from 2-3 weeks ago, i.e. stable), 
tabs created ok, number of tabs increments, displayed tab is now blank 
(rather than the previous address)
>
> Cheers,
>
> ------------------------------------------------------------------------
>
> #! /usr/bin/env python
>
> from enthought.traits.api import *
> from enthought.traits.ui.api import *
>
> class DisplayData(HasTraits):
(Continue reading)

Permalink | Reply | 4 comments |
headers
fred | 2 Jul 09:12
Picon

Re: [traits] creating tabbed list..

Brennan Williams a écrit :
> under Windows (XP, Python 2.4 and ETS from 2-3 weeks ago, i.e. stable), 
> tabs created ok, number of tabs increments, displayed tab is now blank 
> (rather than the previous address)
>   
Hi,

"displayed tab" is blank until you select one.

Anyway, it should be better if it was updated automatically,
without clicking on it, because the "displayed tab" is the last created
in this case.

Don't know how to do that.

And under linux, can you get it a try ?

Cheers,

--

-- 
http://scipy.org/FredericPetit
Permalink | Reply | 3 comments |
headers
Martin Chilvers | 2 Jul 10:33
Picon

Re: [Envisage] Controling the persistence of editors

Hi Gael,

> I would like my editors not to be persistent. What I mean by this, is
> that I would like that if I open several editors during a session, and
> close the app without closing the editors, next time I open the app, the
> editors are no longer there. How can I do that (I have absolutely no clue
> where to look) ?

I'm pretty sure that this behaviour is fixed in Envisage 2.0... However, when 
we refactored the workbench for PyFace 3.0 and Envisage 3.0 we made this very 
easy to do... I'm writing docs at the moment (hard to believe for some, I 
know), so the new release (which will be minimal, but well-tested!) will be out 
RSN...

Martin
Permalink | Reply | 5 comments |
headers
Gael Varoquaux | 2 Jul 10:41
Favicon
Gravatar

Re: [Envisage] Controling the persistence of editors

Hi Martin,

Envisage 3.0 definitaly looks very interesting and seems to adress my
main issues with envisage. When do you expect it will be out ? What
dependancies will it have ?

I am a bit reluctant to depend on envisage 3.0 as I know there is a long
QA cycle before a new version of the ETS can be left to propagate out in
the wild (I don't really consider 2.0 to be ready for use by Mr Joe
Scientist). Fernando and I hope to start in a few months some new
scientific applications based on envisage and traits, and I am in talks
with QME-dev's developper to port his app on traits+envisage, so I don't
want to put back the work on ezvisage, which we plan to use as a
front-end to envisage.

> I'm pretty sure that this behaviour is fixed in Envisage 2.0

I am using 2.0, directly from enthought.branches.

Cheers,

Gaël
Permalink | Reply | 4 comments |
headers
Martin Chilvers | 2 Jul 10:48
Picon

Which parts of PyFace are obsolete?!?

G'day,

As part of Phil's work on Qt4-ifying PyFace, it would be nice to know if there 
are any bits of the package that we no longer need...

I'll start the ball rolling....

1) enthought.pyface.viewer (the entire package)

AFAIK this package may still be used in one place (the preference dialog), but 
that should be refactored anyway. This package only existed because when we 
started copying Eclipse, I thought it would also make sense to copy JFace. The 
idea being that since we didn't have a dedicated team to build an entire widget 
set up-front, if we had one to copy then when we needed a new one we had 
something to base it on, and the package had some chance of looking like a 
coherent whole instead of a bunch of widgets written by a bunch of different 
developers.... Anyhoo, it turns out that many people found the JFace APIs hard 
to use... so we scrapped that plan...

2) enthought.pyface.new_dialog.py

I'm not sure if this is still used anywhere... If it is, it should be moved out 
of here anyway as it introduces a nasty circular dependency with enthought.naming.

3) enthought.pyface.expandable_panel.py
                     expandable_header.py

This was the fancy 'Visio'/'Outlook' style expandable panel... I'm not sure if 
we ended up using it anywhere...
(Continue reading)

Permalink | Reply | 11 comments |
headers
Martin Chilvers | 2 Jul 11:02
Picon

Re: [Envisage] Controling the persistence of editors

Hi Gael,

> Envisage 3.0 definitaly looks very interesting and seems to adress my
> main issues with envisage. When do you expect it will be out ? What
> dependancies will it have ?

The basic Envisage 3.0 package depends on:-

         "enthought.traits>=3.0",
         "enthought.util"

The workbench plugin requires:-

         "enthought.envisage>=3.0a1",
         "enthought.io",
         "enthought.pyface>=3.0",

> I am a bit reluctant to depend on envisage 3.0 as I know there is a long
> QA cycle before a new version of the ETS can be left to propagate out in
> the wild (I don't really consider 2.0 to be ready for use by Mr Joe
> Scientist).

I agree about 2.0! However, Envisage 3.0 is hopefully easy to use 
out-of-the-box, and is also, hopefully in a position to be more agile. The code 
was written using TDD and so a) it should be pretty stable from day one and b) 
we have more confidence that we can fix bugs and add new features much faster 
than we could with 2.0... (fingers crossed!)...

> Fernando and I hope to start in a few months some new
> scientific applications based on envisage and traits, and I am in talks
(Continue reading)

Permalink | Reply | 3 comments |
headers
Gael Varoquaux | 2 Jul 11:06
Favicon
Gravatar

Re: [Envisage] Controling the persistence of editors

Hi Martin,

All this sounds pretty nice. I what shape is traits 3.0 ? What is the
status of standard plugins with envisage 3.0 (python_shell, resource,
text_editor) ?

And a question that would be more directed to the enthought people, when
to you target a ETS 3.0 release ?

Gaël
Permalink | Reply | 2 comments |
headers
Martin Chilvers | 2 Jul 11:19
Picon

Re: [Envisage] Controling the persistence of editors

Hi Gail,

> All this sounds pretty nice.

In theory yes - lets hope the theory lives up to the practise...

> I what shape is traits 3.0 ?

We've been using it for a few months now and it seems pretty solid. There are 
still a couple of API tweaks I'd like to see for adaptation etc, but the rest 
of it looks excedllent. Having interfaces is great, delegation works now, and 
the new decorator syntax for trait change handlers works very nicely!

> What is the
> status of standard plugins with envisage 3.0 (python_shell, resource,
> text_editor) ?

The very first release will not include any of the above. It will include the 
base framework itself, the core plugin and the workbench plugin. Like I said 
the hope is that it is of sufficient quality that we can add other things very 
quickly (the python shell and text editor plugins for example will be a doddle 
and then can be placed high on the priority list of things to do next!)...

As for resources, the current resource plugin is up for a refactor. One of the 
main problems with it is that it was intended as a place to attach integration 
information (adapters etc) for different aspects of an applicaton to specific 
types of data, but sadly:-

a) The resource type itself wasn't extensible so that other plugins couldn't 
add new aspects...
(Continue reading)

Permalink | Reply | 0 comments |

Gmane