[kepler-dev] VergilPreferences and [Bug 2343] - add welcome screen for release 1.0
Christopher Brooks
cxh at eecs.berkeley.edu
Thu Feb 9 11:35:04 PST 2006
I think we need a preferences system that is simple,
but let's keeping going with VergilPreferences.
We would need something really basic to handle the "expert" overall
parameter for use in ptolemy.gui.GraphicalMessageHandler.
We can't use MoML in ptolemy.gui.
I'll rename ptolemy.vergil.VergilPreferences to
ptolemy.actor.gui.PtolemyPreferences and proceed.
_Christopher
Edward writes:
--------
I think the "please don't show..." could be handled even with the
current preferences mechanism... Configuration has a static field that
lists all the configuration that have been created (in principle, there
could be more than one). We could provide
a static method to access this list. This access would have to
happen after the Configuration is created, of course.
To access the configuration from a random place, if you have a NamedObj,
then you can call Configuration.findEffigy(). This is a static method.
Then call Effigy.toplevel(). The result will always be the configuration.
However, we need to be careful about creating dependencies on GUI
infrastructure.
...
Edward
At 08:27 AM 2/9/2006, you wrote:
>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 file
s
> > > 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, withou
t
> > > 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 setti
ngs
> > > 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) rat
her
> > > 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 val
ue.
> > * 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 caugh
t
> > * 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, b
ut
> > 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 stora
ge
> > > > 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
> > > ---------------------------------------------
------------
Edward A. Lee
Professor, Chair of the EE Division, Associate Chair of EECS
231 Cory Hall, UC Berkeley, Berkeley, CA 94720
phone: 510-642-0253 or 510-642-0455, fax: 510-642-2845
eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
--------
More information about the Kepler-dev
mailing list