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
...
This reverts commit 78d3da0c4e17ce356905c3b745d9773eb458988e.
Because while eliminating the call to System#exit does mean that
JavaFX's LauncherImpl can properly report errors and stack traces, it
also means that Bitsquare never shuts down (probably due to non-daemon
threads). When System#exit is removed (or replaced with Platform#exit),
closing the Bitsquare window (or clicking Exit from the system tray menu)
results in the application no longer being able to function at the UI
level (because the JavaFX toolkit has essentially been shut down), but
the process does not exit either.
So in the meantime, this change is being reverted, and we just have to
deal with not getting stack traces at the command line when uncaught
exceptions bubble up through the #start method (specifically, exceptions
that occur before the UncaughtExceptionHandler has had a chance to be
set).
A solution to this could be to provide a custom subclass of JavaFX's own
Application class that implements a template #start / #doStart methods
trying and catching anything that is raised from #doStart and printing
the stack trace on its own.
Calling System#exit short-circuits normal error reporting, meaning that
when an exception is called within the scope of executing the
Application's #start method, the message
Exception in Application start method
is printed to the console, but without a stack trace. Removing the
System#exit call allows JavaFX's LauncherImpl to continue processing the
exception, ultimately printing out the stack trace as expected.
