the "Retry" button thing we had previously didn't really seem all that
good in practice, as there's no way (??) to determine if the OS actually
_did_ pop up some kind of prompt for the user (as OS X does).
since hotkeys won't work if hook registration fails, displaying an
error immediately seems to be the best option... and still much better
then what used to happen where the app would just silently fail to start
quite simply, i don't speak anything other then english. the source
code i originally got from Xunkar also had some english strings that
had not been translated either, so everything other then english was
somewhat out of date to begin with.
i very strongly feel that it's bad form to provide an option for
choosing an alternate language within the app when the alternate
language translations are out of date and are just plain missing some
strings in places.
if at some point in the future someone wants to finish one or more of
these translations so they are once again in sync, we can then
re-enable the language selection.
it's unfortunate, but i feel this is the best decision for now.
the AWT FileDialog provides laughably bad "support" for setting
file filters (the type which the user can select from a dropdown).
oh well, semi-non-native looking file open/save dialogs are here to stay
previously icons got their raw pixel data serialized to a massive
int array type structure in xml. now we serialize the entire ImageIcon
object to a base64 string, which is still quite a long string, but
fits nicely on one line instead of making the resulting xml feel hugely
bloated.
kind of a hacky implementation, but it works.
ideally i would like to not depend on JNativeHook at all if global
hotkeys are disabled and provide some sort of "dual" event processing
using both the built in Swing key press events and the native key press
events, using input from whichever is appropriate based on the user
settings.
however, JNativeHook and Swing use different key codes. it would be
possible to write some code to translate between the two, but i don't
have a bunch of different keyboards and OS installs to test this
properly and feel that the odds of me writing some key code translation
function that doesn't work 100% of the time is a bit too high.
so, we just use JNativeHook for global and non-global and test for
window focus depending on which is enabled. this has the unfortunate
consequence of requiring that the key event hook registration was
successful regardless of if the user wants to use global or non-global
hotkeys. kind of annoying, but can't be helped for now!
i need to test this more on Windows/Linux to ensure it works fine there
too, but i think it should be fine.
getting native OS file dialogs is _probably_ most important on OS X
as the Swing JFileChooser version lacks the favourites column which
a lot of users will end up feeling somewhat lost without.
this change is in prep for some serialization changes i will be doing
in the very near future. i will need access to the underlying Image
object and the Icon interface doesn't include that so i would need to
cast at some point to ImageIcon anyway.
basically, save it under ~/.llanfair always.
the reason being is that under certain deployments it's entirely
possible the current directory where the JAR is located _might_ not be
writeable by the application. but the user's home directory should
always be writeable.
the only reason i'm bothering with doing something semi-drastic like
changing the entire indentation style from spaces to tabs is because
i prefer tabs, but more importantly, since all my editors are configured
to use tabs, i will likely accidentally introduce tab indenting
somewhere without realizing it and then everything would end up being
inconsistent. would rather just solve this problem right now. :)
just some "standardization" (debatable i guess) to the source directory
layout and resources directory.
removal of the dependancy on Sidekick-1.2 jar is mainly because Xunkar
does not have the source for this particular version of the library and
the current version on Github does not have some of the stuff that we
need for for this version (not even in an updated form, looks like he
did a fair bit of cleaning out of stuff he no longer needed). i would
rather _not_ depend on jars where no source / future support is possible
so i included decompiled sources for this library so future bugfixing
and modification is a bit easier moving forward. can decide if we want
to move to the latest version of Sidekick at a later time.
Gered