Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New UserPreferencesManager implementation #1126

Merged
merged 13 commits into from Apr 9, 2016
Merged

New UserPreferencesManager implementation #1126

merged 13 commits into from Apr 9, 2016

Conversation

rhwood
Copy link
Contributor

@rhwood rhwood commented Apr 8, 2016

  • Addresses both DefaultUserMessagePreferences does not save open windows at application quit. #1110 and issues with Use RowSorter in RosterTable. #1103.
  • Provides groundwork for migrating from a "User Preferences" manager to a "User Interface" state manager (what is the difference, in a clear and succinct non-technical language between a "User Preferences" and a user's preferences? -- based on the XML schema and change history, historically there wasn't one).
  • The UserPreferencesManager API does not change at this point, but the storage behind it is made more amiable to later API changes (to support, for example, expanded table sorting and filtering capabilities introduced in Java 1.6).
  • Uses a new storage format that lays the ground work for being able to ensure some UI state is per-computer, while other UI state is shared among all computers using a given profile (which supports Encapsulated or Per-node Profiles #69).
  • Replaces the user of Boolean with boolean within the Shutdown manager API, which breaks binary compatibility, but does not require any further code changes.
  • Needs more testing, both for errant dialogs while quitting JMRI, and for settings that are not retained.

rhwood added 12 commits April 3, 2016 21:09
Since NamedBeans, JavaBeans, and all code using properties in the
UserPreferencesManager all use Strings to identify properties, only use
Strings here as well.
Also use constants for fired property changes.
This allows UI preferences to be stored and updated as needed instead
of only once in a shutdown hook.
This implementation uses the same preferences/configuration storage
mechanism as the explicit preferences do.
- Allow other parts of JMRI to be aware of a shutdown in progress.
- Fix FindBugs warnings.
- Use boolean instead of Boolean to indicate shutdown failure.
- Close open windows with a WindowClosing event instead of an immediate
dispose().
Do not ask a user if its okay to shutdown after shutdown has started.
Since some tests of other code explicitly call out the old manager
(instead of only using the API that UI managers implement):
- trap settings in old manager within the new manager, instead of only
at file read time
- allow test implementations to override showMessage to prevent tests
from waiting on user input
@bobjacobsen
Copy link
Member

(AppVeyor 1st-time failure was in AppVeyor's init itself, not the JMRI part - restarted)

@bobjacobsen
Copy link
Member

Similar AppVeyor fail on 2nd try. The AppVeyor build queues are now closed, so perhaps they're working on something. Will leave this alone for a bit & then restart the test.

@rhwood rhwood merged commit 08ab1d2 into JMRI:master Apr 9, 2016
@rhwood rhwood added this to the 4.3.5 milestone Apr 9, 2016
rhwood added a commit to JMRI/website that referenced this pull request Apr 9, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants