[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