This file was produced by adding a `-v` flag following the `-deploy`
flag in `package/windows.bat`. The creation of the file is reported by
javapackager as follows:
Config files are saved to
C:\Users\CBEAMS~1.WIN\AppData\Local\Temp\fxbundler5661616451276716144\windows.
Use them to customize package.
Subsequent commits will customize this file, primarily for the purpose
of avoid the dreaded 'missing dll' errors mentioned originally in
d16c274 and detailed at https://bitbucket.org/shemnon/javafx-gradle/issue/43.
This change allows users to place a bitsquare.properties file within
a `.bitsquare` directory under their home directory. This makes it
possible to specify property values (such as
node.useManualPortForwarding=true) that will survive cleaning the
application data dir (e.g. with `--clean=true` flag as introduced
in #291).
The precedence of this new "homeDirProperties" property source is lower
than the "appDirProperties" property source.
This means that if a user has a `bitsquare.properties` file both in his
home directory and in his application data directory, both files will be
processed, but for any properties that exist in both files, the property
specified in the application data directory file will take precedence.
This arrangement allows users to customize settings on an app-by-app
basis, which is especially useful in local testing scenarios where more
than one Bitsquare instance is running.
Prior to this change, the "clean flag" was named `user.data.clean.dir`,
but in fact it cleaned the *app* data dir, not the *user* data dir.
This is the difference betwen deleting
~/Library/Application Support (the "user data dir")
vs.
~/Library/Application Support/Bitsquare (the "app data dir")
The name of this flag has been updated to `--app.data.dir.clean` to
reflect the fact that it cleans the latter vs. the former.
The processing of this flag has also been updated. It's default value
(false) is now assigned during the creation of the default properties
source in BitsquareEnvironment, and instead of reading and handling the
flag directly in the BitsquareEnvironment constructor, we now handle
cleaning in BitsquareApp#initAppDir, where logic for handling the
creation of the directory already exists.
See #291
Overview of major changes:
- Introduce top-level `viewfx` package for general-purpose MVVM-style
infrastructure classes. Note that this package naming will likely
change, especially if and when we extract it to a physically-separate
library.
- Introduce View and Model class hierarchies that capture the various
lifecycle and model management concerns throughout the existing
Bitsquare application (see `viewfx.view` and `viewfx.model` packages)
- Introduce @FxmlView and FxmlViewLoader to support declarative,
convention-over-configuration support for FXML-based views.
Eventually, this approach will allow for seamless mixing of FXML- and
non-FXML based view implementations within the same application.
- Introduce a type-safe approach to intra-view navigation: eliminate
the Navigation.Item enum in favor of navigating directly from one
view to another using *View class literals. This change is closely
tied to the @FxmlView approach described above.
Many additional smaller changes are included as well; see individual
commits for details.
* cbeams: (75 commits)
Rename viewfx.view.support.guice.{Guice=>Injector}ViewFactory
Use instanceof checks on views instead of class equality
Add CachingViewLoaderTests
Revert "Remove System#exit call from BitsquareApp#stop"
Change signature of ViewLoader#load to accept Class
Complete implementation and testing of @FxmlView support
Remove System#exit call from BitsquareApp#stop
fix checkArgument
Use irc instead of fiat classes
Remove hardcoded path from ViewLoaderTests
Fix conditional logic in AccountView#activate
Polish AccountSettingsView
Introduce @FxmlView, replace Navigation.Item
Begin refactoring Navigation
Rename enum gui.{Navigation#Item => FxmlView}
Introduce viewfx.view.support.CachingViewLoader
Extract ViewLoader interface and introduce FxmlViewLoader
Fix broken tests and app exceptions due to ViewLoader changes
Bind ViewFactory interface to GuiceViewFactory impl
Move i.b.gui.ViewLoader.java => viewfx.view.support.ViewLoader
...
