[kepler-dev] VergilPreferences and [Bug 2343] - add welcome screen for release 1.0
Christopher Brooks
cxh at eecs.berkeley.edu
Thu Feb 9 08:27:39 PST 2006
Hi Edward,
I'm hacking up the Welcome window and would like to have a way
the window so it has a "Please don't show me this dialog again"
checkbox and I have some questions about VergilPreferences.
- vergil.VergilPreferences should probably be renamed to
PtolemyPreferences and moved to ptolemy.actor.gui so that the
actor.gui.WelcomeWindow class can get at it and ptolemy.actor.gui does
not depend on vergil.
In fact, getting a preference is a fairly basic task, so this
should go in some non-gui base class. If we use plain old java
properties, then perhaps we could have a preferences class in
ptolemy.util? I'd like to be able to get at preferences without
requiring moml.
Another preference I'd like to see is a way for the user to adjust
how much detail the GraphicalMessageHandler window initially shows.
GraphicalMessageHandler is in ptolemy.gui and only imports
ptolemy.util, so MoML is not available.
- We need a way to access a global property when we don't have a
container. In general, I think the Kepler developers are confused
about how we should get a Configuration from anywhere in the code.
So, we need a preferenceValue(String preferenceValue) that
does not require a context or container and gets the value of
the global preference.
Comments?
I've included some email below that has further details
_Christopher
> To: Matthew Brooke <brooke at nceas.ucsb.edu>
> cc: eal at eecs.berkeley.edu
> From: "Christopher Brooks" <cxh at eecs.berkeley.edu>
> Subject: Re: [Bug 2343] - add welcome screen for release 1.0
> In-reply-to: Your message of Fri, 20 Jan 2006 16:28:29 -0800.
> <43D1802D.3000607 at nceas.ucsb.edu>
> Date: Sat, 21 Jan 2006 18:07:54 -0800
> Sender: cxh at carson.EECS.Berkeley.EDU
>
> I've taken the liberty of ccing Edward here.
>
> Matthew Brook writes:
>
> > Christopher:
> >
> > > Perhaps Edward's preferences manager
> > > (ptolemy.vergil.VergilPreferences) can be used?
> >
> > When i started the SVG icon stuff, I needed to access properties files
> > from various parts of the code, and spent a lot of time trying to use
> > ptII's existing configuration.xml, to no avail. I finally figured it
> > just wasn't 'available' for enough of the codebase at runtime, without
> > hard-coding paths in order to re-load it (or maybe I'm just too
> > dumb...).
>
> Right this is a problem in general. It is not always easy to get
> at the configuration, you usually need a model that was read in.
>
> > So - I went ahead and used java's built-in
> > resourcebundle/properties classes for storing prefs. This is
> > overkill/inappropriate in some places (for example, many of the settings
> > are not localizable, so do not really need resourcebundle files), but it
> > works marvelously. I guess in the meantime, Edward created the
> > VergilPreferences thing, which I haven't looked at - so now we have a
> > proliferation on our hands... :-(
> >
> > Anyway - I have put all the ui-related settings in *.properties files in
> > configs/ptolemy/configs/kepler/, and they all have names like:
> > ui****.properties. The 'main' one is uiSettings.properties.
> >
> > Up to now, these only contain application settings (ie read-only) rather
> > than user settings - so we still need to create a user-settings file for
> > these read/write props. Is that what VergilPreferences currently does?
> > if it's ultra-simple to use, and easy to get a reference to the props
> > class (say via a static method somewhere) let's use it! If not, then
> > let's use POJ!
> >
> > m
>
> Right, VergilPreferences saves its perferences in
> ~/.ptolemyII/VergilPreferences.xml
> or c:/Documents and Settings/username/ptolemyII/VergilPreferences.xml
>
> I think it is fine to have the ui read only settings in
> configs/ptolemy/configs/kepler
>
> The primary entry point in VergilPreferences is:
>
> /** Check to see whether a preference of the specified name is
> * defined in the specified context, and if it is, return it's value.
> * Note that if there is an error in the expression for the preference,
> * then this method will return null and report the error to standard out.
> * This is done because we assume the error will normally be caught
> * before this method is called.
> * @param context The context for the preference.
> * @param preferenceName The name of the preference.
> * @return The value of the preference, or null if it is not set.
> */
> public static Token preferenceValue(NamedObj context, String preferenceName
> ) {
>
> I'm not sure what the context would be for the "Show this dialog at
> startup". This is sort of a global context.
>
> Perhaps we should extend VergilPreferences to provide a default global
> context with a static accessor? Also, it would be nice to have
> a static method that returns a String:
> public static String preferenceValueAsString(String preferenceName);
>
> Also, I don't see how I add a new preference? (Edward?)
>
> I'm not particularly wedded to using .xml for the global preferences, but
> using xml makes sense in this context, where we are setting things
> like Relation size, Link bend radius and Show Parameters, and we want
> these things to be inherited and overridden in the model hierarchy.
>
> However, there is quite a bit of appeal to using Plain Old Java (POJ)
> properties, like what we do with ptII/lib/ptII.properties, which
> is created by configure and contains POJ properties that
> are merged in by VergilApplication. POJ properties do not
> require MoMLParser, so they are more useful for codegen runtime
> and other small footprint programs.
>
> BTW - Perhaps we should use ptII/lib/ptII.properties for global
> properties and first load ptII/lib/ptII.properties and then load
> ~/.ptolemyII/ptII.properties (if it exists) so we can override these
> properties.
>
> Anyway, seems like we have lots of properties systems, we should
> hash something out and use it.
>
> 1) We could extend VergilPreferences:
> - static accessor without a context
> - static accessor that returns a String
> - static setter of new Properties (with automagic save?)
>
>
> 2) Hack up ptII.properties
> - configure sets properties, but we need to make it easy for
> users to override
> - static setter of new Properties (with automagic save?)
>
> 3) Hack up the Kepler properties system
> - Make it useful in Ptolemy only
>
> Comments?
>
> _Christopher
>
> >
> >
> > bugzilla-daemon at ecoinformatics.org wrote:
> > > http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2343
> > >
> > >
> > >
> > >
> > >
> > > ------- Additional Comments From cxh at eecs.berkeley.edu 2006-01-20 14:51 --
> --
> > ---
> > > I can take this bug, but I'm not sure how it is different from
> > > http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2343
> > > Maybe these should be merged in to one bug?
> > >
> > > I've often thought it would be great to have a "Don't show me this window a
> ga
> > in"
> > > checkbox, but what has stopped me was that we need persistent storage
> > > of the user's choice. Perhaps Edward's preferences manager
> > > (ptolemy.vergil.VergilPreferences)
> > > can be used?
> > >
> >
> > --
> >
> > ---------------------------------------------
> > Matthew Brooke, Ph.D.
> > Marine Sciences Research Building, Room #3407
> > University of California
> > Santa Barbara, CA 93106-6150
> > ph: (805) 893-7108 fx: 805-893-8062
> > brooke at nceas.ucsb.edu
> > ---------------------------------------------
More information about the Kepler-dev
mailing list