curious: what does the traits software development plan looks like?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

curious: what does the traits software development plan looks like?

_jelle_
I'm very curious to have more of an idea of what the traits ( & dependencies )
software development plan looks like. I'm a complete traits fanboi, but the
fast paced development at enthought makes it hard to understand how the
 different components relate . traits & traitsui is evident, but it requires
 a more thorough understanding how pyface, apptools, etsdevtools,
 envisageplugins, envisage, enable, chaco blockcanvas & mayavi and enaml
  relate. I think I have a reasonable idea now but my point is that the global
  project is sold short because of lack of proper communication of how these
  modules relate.

A related question to that is, the traits development plan.
For instance, I understand technically the significance of enaml, but its
important for developers to know for instance 1) if enaml will eventually
 follow up traitsui to provide a traits gui backend 2) if Enthought would
  advise to build your application views on enaml rather than traitsui and
  pyface for example.

IMHO its a bad thing that the "authoritative" roadmap [1] stems from the days
of traits 2.1 apparently. In other words; its hard 1) to point other developers
 to a page that explains why traits is the bees knees
2) a development plan might add to an (even more) cohesive community and
informs potential users. Honestly, this amazing project needs some TLC when it
 comes to promoting it ;)


[1] https://svn.enthought.com/enthought/wiki/Traits-2_1


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: curious: what does the traits software development plan looks like?

Jonathan March
Hi Jelle,

I appreciate and share your concern that the Enthought Tools should be more visible and accessible. You raise many good questions; I'll try to touch on a few of the easier ones, but some are longer discussions. 

* We are in the process of completely reworking our website; this includes clearing out or updating obsolete material. This is crucial, but with limited resources, it will have to happen in stages. And the EPD-related parts come first, in part because there are many more EPD users than ETS users. 

* Your point is very well taken about the usefulness of a simple public document that describes the inter-relationship between the ETS packages. Thanks for the nudge on this.

* Yes, we recommend that developers use enaml rather than traitsui whenever feasible. This is what we are doing in our own new consulting work. For legacy apps, or those which require UI components not yet supported by enaml (a list which is shrinking rapidly!), traitsui may still be more practical for the moment.

* Enaml is already well integrated with Traits at a low level. We would love to build high-level tools that allow a Traits model to map effortlessly to an enaml view (a la TraitsUI). So far we have not had strong enough customer demand to justify the effort, but I do expect that we will get there. Needless to say, pull requests are always welcome :)

Best,
Jonathan 


On Thu, Feb 7, 2013 at 7:43 AM, jelle <[hidden email]> wrote:
I'm very curious to have more of an idea of what the traits ( & dependencies )
software development plan looks like. I'm a complete traits fanboi, but the
fast paced development at enthought makes it hard to understand how the
 different components relate . traits & traitsui is evident, but it requires
 a more thorough understanding how pyface, apptools, etsdevtools,
 envisageplugins, envisage, enable, chaco blockcanvas & mayavi and enaml
  relate. I think I have a reasonable idea now but my point is that the global
  project is sold short because of lack of proper communication of how these
  modules relate.

A related question to that is, the traits development plan.
For instance, I understand technically the significance of enaml, but its
important for developers to know for instance 1) if enaml will eventually
 follow up traitsui to provide a traits gui backend 2) if Enthought would
  advise to build your application views on enaml rather than traitsui and
  pyface for example.

IMHO its a bad thing that the "authoritative" roadmap [1] stems from the days
of traits 2.1 apparently. In other words; its hard 1) to point other developers
 to a page that explains why traits is the bees knees
2) a development plan might add to an (even more) cohesive community and
informs potential users. Honestly, this amazing project needs some TLC when it
 comes to promoting it ;)


[1] https://svn.enthought.com/enthought/wiki/Traits-2_1


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: curious: what does the traits software development plan looks like?

Satrajit Ghosh
dear jonathan

thank you for this update. here is another related question. are there any plans in your current roadmap for python 3 support? a number of our related projects are python 3 compatible and we would like to be there as well. we don't use all aspects of traits and are evaluating whether it makes sense for our project to move to something like traitlets (from the ipython folks) in the near term.

cheers,

satra


On Thu, Feb 7, 2013 at 5:17 PM, Jonathan March <[hidden email]> wrote:
Hi Jelle,

I appreciate and share your concern that the Enthought Tools should be more visible and accessible. You raise many good questions; I'll try to touch on a few of the easier ones, but some are longer discussions. 

* We are in the process of completely reworking our website; this includes clearing out or updating obsolete material. This is crucial, but with limited resources, it will have to happen in stages. And the EPD-related parts come first, in part because there are many more EPD users than ETS users. 

* Your point is very well taken about the usefulness of a simple public document that describes the inter-relationship between the ETS packages. Thanks for the nudge on this.

* Yes, we recommend that developers use enaml rather than traitsui whenever feasible. This is what we are doing in our own new consulting work. For legacy apps, or those which require UI components not yet supported by enaml (a list which is shrinking rapidly!), traitsui may still be more practical for the moment.

* Enaml is already well integrated with Traits at a low level. We would love to build high-level tools that allow a Traits model to map effortlessly to an enaml view (a la TraitsUI). So far we have not had strong enough customer demand to justify the effort, but I do expect that we will get there. Needless to say, pull requests are always welcome :)

Best,
Jonathan 


On Thu, Feb 7, 2013 at 7:43 AM, jelle <[hidden email]> wrote:
I'm very curious to have more of an idea of what the traits ( & dependencies )
software development plan looks like. I'm a complete traits fanboi, but the
fast paced development at enthought makes it hard to understand how the
 different components relate . traits & traitsui is evident, but it requires
 a more thorough understanding how pyface, apptools, etsdevtools,
 envisageplugins, envisage, enable, chaco blockcanvas & mayavi and enaml
  relate. I think I have a reasonable idea now but my point is that the global
  project is sold short because of lack of proper communication of how these
  modules relate.

A related question to that is, the traits development plan.
For instance, I understand technically the significance of enaml, but its
important for developers to know for instance 1) if enaml will eventually
 follow up traitsui to provide a traits gui backend 2) if Enthought would
  advise to build your application views on enaml rather than traitsui and
  pyface for example.

IMHO its a bad thing that the "authoritative" roadmap [1] stems from the days
of traits 2.1 apparently. In other words; its hard 1) to point other developers
 to a page that explains why traits is the bees knees
2) a development plan might add to an (even more) cohesive community and
informs potential users. Honestly, this amazing project needs some TLC when it
 comes to promoting it ;)


[1] https://svn.enthought.com/enthought/wiki/Traits-2_1


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev


_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev



_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev