issue with apptools.preferences

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

issue with apptools.preferences

_jelle_
When I'm adapting from the apptools example [1] to my application, something
that's worrying is that when the PreferencesManager is used as an attribute
that changed values do not get written to disk. A little eery since there are no
real differences and I cannot trace this difference in behavior.
The example, however, works perfectly.

Any suggestions why this isn't working as expected?

Thanks!

[1] https://github.com/enthought/apptools/blob/master/
examples/preferences/preferences_manager.py

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

Re: issue with apptools.preferences

_jelle_
Is is fair to say that the issues Prabhu mentions [1] are still valid?
apptools.preferences seems unnessecarily complex ( the traits duplication
 _is_ a nuisance and counter intuitive ), and I agree its awkard that the
PreferencesHelper doesn't sync traits by default.
This does cripple the usefulness of the preference package imho.

Cheers!

-jelle

[1] http://article.gmane.org/gmane.comp.python.enthought.devel/14331/match=preferences

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

Re: issue with apptools.preferences

_jelle_
mystery solved: the PreferencesManager view was a modal view
which is why the OK/Cancel did not show up, and hence preferences
were not updated.

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

Re: issue with apptools.preferences

Jonathan March
In reply to this post by _jelle_
On Wed, Aug 8, 2012 at 12:35 PM, Jelle Feringa <[hidden email]> wrote:
Is is fair to say that the issues Prabhu mentions [1] are still valid?
apptools.preferences seems unnessecarily complex ( the traits duplication
 _is_ a nuisance and counter intuitive ), and I agree its awkard that the
PreferencesHelper doesn't sync traits by default.
This does cripple the usefulness of the preference package imho.


FYI, a cleaner preferences system is on our to-do list, but AFAIK is not imminent.

 
Cheers!

-jelle

[1] http://article.gmane.org/gmane.comp.python.enthought.devel/14331/match=preferences

_______________________________________________
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: issue with apptools.preferences

_jelle_
Good to hear Jonathan. Its a stinky corner in an impressive code base.
I thought I solved it with setting the modality to live in the
PreferencesManager view but alas...

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

Re: issue with apptools.preferences

Martin Chilvers
Hi Jelle,

On 08/08/2012 20:45, Jelle Feringa wrote:
> Good to hear Jonathan. Its a stinky corner in an impressive code base.
> I thought I solved it with setting the modality to live in the
> PreferencesManager view but alas...

The preferences API definitely needs a second look to simplify it and to
improve the integration with traits. The helper parts are confusing
that's for *sure* - but there is always going to be some weirdness when
trying to specify types when some preferences formats e.g .ini files do
not preserve type information.

Having said that, the APIs do seem a little complex until you realise that:-

a) the API was lifted from Eclipse and is very powerful. It allows
(amongst other things) preferences to be integrated from pretty much
anywhere and from any point in the preference node tree (i.e. part of
the preferences namespace could be stored in a .ini file, some in, say,
LDAP, some remotely etc.). It also allows you to configure multiple
preferences scopes to handle precedence etc. We may have missed things
as 'pythonic' or 'traitsonic' as we could have, but the APIs themselves
have been successul in Java-land ;^)

b) the API follows a common pattern for naming hierarchies so that many
developers will recognise quickly.

IMHO the main problem is that the code is really a 'framework' for a
preferences system, and so it feels like you have to do too much. On
Quickblocks we added an implementation called 'ApplicationPreferences'
which just configures the system in a common pattern where we have
preferences scopes like:- command-line, user, system. I've attached the
code and tests in case it comes in handy.

In essence the API would be used as follows:-

preferences = ApplicationPreferences(
     default_preferences_filename = '/some/path/to/default.ini',
     user_preferences_filename    = '/somt/path/to/user.ini'
)

and then to get preferences:-

bgcolor = preferences.get('acme.foo.bgcolor')

and to set:-

preferences.set('acme.foo.gbcolor', 'blue')

Of course, I'm always open to suggestions for how the above example can
be simplified and the intent made clearer.

Martin


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

application_preferences.py (6K) Download Attachment
application_preferences_test_case.py (3K) Download Attachment
argument_parser.py (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: issue with apptools.preferences

Martin Chilvers
In reply to this post by Jonathan March
G'day,

On 08/08/2012 20:09, Jonathan March wrote:

> On Wed, Aug 8, 2012 at 12:35 PM, Jelle Feringa <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Is is fair to say that the issues Prabhu mentions [1] are still valid?
>     apptools.preferences seems unnessecarily complex ( the traits
>     duplication
>       _is_ a nuisance and counter intuitive ), and I agree its awkard
>     that the
>     PreferencesHelper doesn't sync traits by default.
>     This does cripple the usefulness of the preference package imho.
>
>
> FYI, a cleaner preferences system is on our to-do list, but AFAIK is not
> imminent.

So I just went and took a look the APIs for the preferences stuff and
the core seems pretty darn tight to me and I'd be interested in seeing
the design for a replacement of that level. We didn't make the APIs up -
we used prior art from at least two successful projects.

Having said that, the layer that integrates with traits and the helpers
is indeed a 'stinky corner!', but IMHO we really only need to re-work
that layer of the code - the rest is solid, commented, documented and
tested.

Martin

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