Opening URI addresses from Subsurface does not work on Windows using
the latest GTK bundle from the Gnome website. The reason lies in GIO
and GLib and how it obtains assigned applications for protocols and MIME
types.
While gtk_show_uri() should be viable for both linux.c and macos.c,
in windows.c ShellExecute() is used, which provides proper support
for the URI calls.
subsurface_launch_for_uri() returns TRUE on success.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
.. and add the usual logic to not save the default values.
This also simplifies the initial system-specific setup of both of these:
since we have defaults for all the preferences that get set up at
startup, we can just initialize those defaults to the system-specific
fonts then and there.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The old code (on purpose) didn't try to differentiate "nonexisting
boolean configuration" with "existing boolean configuration set to
false", which is problematic if we optimize the saving to not save
default preferences at all.
Which this does.
So in addition to the logic to know about default preferences, this has
to change the interfaces for the PREF_BOOL reading code so that you can
tell the difference between "no value" and "false".
And since the previous calling convention was an abomination of doing
pointer casting and having case-statements for the config types, change
that while at it. Both from a usage perspective *and* from a back-end
perspective it is actually much simpler to just have different functions
for the string vs boolean config read/write versions. The OSX versions
in particular end up being one-liners.
(The GConf library is a nightmare, and doesn't seem to have any way to
know whether a boolean value exists or not, so you have to read it as a
GConfVal and then turn it into a gboolean rather than just get the "oh,
it didn't exist" as an error value).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
.. and rename the badly named 'output_units/input_units' variables.
We used to have this confusing thing where we had two different units
(input vs output) that *look* like they are mirror images, but in fact
"output_units" was the user units, and "input_units" are the XML parsing
units.
So this renames them to be clearer. "output_units" is now just "units"
(it's the units a user would ever see), and "input_units" is now
"xml_parsing_units" and set by the XML file parsers to reflect the units
of the parsed file.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In the device selector when downloading from a divecomputer add the drive
name that we have been looking for (so far that's only "UEMISSDA") to the
drive letter - this should make it easier for people to figure out why
there is a drive letter offered as an option.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
subsurface_fill_device_list() now goes trough the list of registry
entries in the SERIALCOMM key and adds all present values (such as
COM1, COM2) to a GtkListStore. Once done the function compares
all logic drive label to a static list of known DC labels,
such a 'UEMISSDA', which is the only present one at the moment
and adds any matching drive letters (e.g. C:\, H:\) to the list store
as well.
If no serial ports were added or no matching logical drives were found
the function simply adds a default entry named "COM1".
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
We try to identify devices that are connected and their matching device
names (and mount paths in the case of the Uemis Zurich). Those are
presented as a drop down menu to choose from. The user can still override
this by simply entering a different device / path name.
On Windows this is not functional. How do I find out which drive letter
corresponds to the USB device named "UEMISSDA"? Similarly we need code
that finds serial ports that are present. For now we once again default
to COM3 (so this isn't a step back, but of course it's far from what we
want).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
linux.c, macos.c, windows.c now contain
subsurface_os_feature_available() that can accept an enum type
os_feature_t defined in dive.h.
The function can be useful to check if a specific global feature
is available on a certain OS version.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
So far we only looked in the a local subdirectory, but once Subsurface has
been installed, we don't need to change the search path for translation
files anymore.
Fixes#2
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This commit adds an install-cross-windows target to the Makefile that
creates a staging directory for us under packaging/windows that contains
the required .mo files. This currently fails for the Norwegian translation
because of the no_NO.UTF-8 vs nb issue - right now we just use the first
component of our own localization filename to find the matching Windows
localization and that fails.
The subsurface.nsi file is updated accordingly and this now appears to
create working installers with sane paths for the localization files.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is mostly a quick hack to be able to test localization under Windows.
It seems to work fine under Windows 7
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The MacOSX applications bundle needs to be told where to bind the
text domain from.
Also copy the gettext .mo files in the install-macosx target.
[Dirk Hohndel: minor change in main(): move the path declaration to
the beginning of the function]
Signed-off-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Before setting a new font we try to free the existing font. Sadly if no
config value is set for the default font, we assign a string literal.
Which of course means that subsurface dumps core when trying to free it.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
windows.c:
Windows's registry (which is technically a filesystem) uses UTF-16
for its "keys". This forces us to convert each of our UTF-8 (GLib, GTK)
configuration entries if we want to store special characters. To do that
we use the RegQueryValueExW() and do some conversation around
the function call itself.
The opposite happens when we require a UTF-16 value to be read from the
registry and converted to UTF-8 in subsurface_set_conf().
An addition to this patch is a somehow expandable buffer in
windows.c: subsurface_get_conf(). We increase the size of the buffer
in chunks of 64 bytes, until RegQueryValueExW() is able to write to it
(as suggested by the WINAPI documentation).
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For unicode command line characters Windows uses UTF-16, while Glib
and GTK use UTF-8. To solve that we retrieve the command line
via __wgetmainargs() and use g_utf16_to_utf8() to convert each argument.
The used method should support wildcards passed as arguments
(e.g. *.xml).
Two new, OS abstracted functions appear in linux.c (NOP), macos.c (NOP),
windows.c:
subsurface_command_line_init(...)
subsurface_command_line_exit(...)
which are being called in main()
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Several potential problems.
- we could end up dereferencing exiting_filename when it was NULL
- we could free the default_filename by mistake -
subsurface_default_filename always needs to return a copy of it
- closing the existing file before opening a new one repopulated the
existing_filename with the default filename - preventing the opened
file to become the new existing filename
Also, make existing filename a const char * and make file_open have the
same sensible default folder behavior as the other file related functions.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The default file name is OS specific and tries to follow the customs on
each of the OSs. It can be configured through the preferences dialog.
On MacOS we get a strange warning which appears to be a well documented
Gtk bug on MacOS.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
flushing the entire registry is not required on windows. simply
closing the registry key when done would suffice.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
On Linux and MacOS the subsurface_close_conf() doesn't really close the
config file (it flushes writes on MacOS), but on Windows it does
actually close the registry hkey.
Which is bad, if you change the settings multiple times - we assume that
the config file is open the whole time.
So add a "subsurface_flush_conf()" function, and call *that* when
changing configuration parameters. And call the close function only at
the very end.
Alternatively, maybe we should just open the config file separately
every time. I don't much care, maybe somebody else does.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Move the About and Preferences menu item to the App menu.
Switch the accelerator key to be Meta (i.e., Command) instead of Control
This required a bit of restructuring of the code, but it's all for a good
cause.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
To do this a few things needed to move into the os specific files, but the
overall change is fairly small and the difference on the Mac is amazing.
Subsurface now becomes a Mac app with Mac toolbar and useful default
fonts.
Changed the CFBundleIdentifier to be the reverse DNS of the subsurface
site (sadly, 'torvalds' is not yet a TLD).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
So far we hard coded /dev/ttyUSB0 - which is a good starting point in
Linux but not so useful on Windows or MacOS. This was now moved into one
of our OS helper functions with (somewhat) reasonable defaults.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is based on an older patch by Lubomir I. Ivanov <neolit123@gmail.com>
which no longer applies due to the refactoring of the registry setting
code.
It takes care of all of the casts between actual C types and the Windows
specific types that the Windows API functions expect. It also adds some
comments to the overloading of "value" in our subsurface_set_conf function.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Now that I can test Windows binaries again, the bugs were rather easy to
spot. Because of the different flow of the opening, writing and closing of
the registry key my first attempt got things wrong - we simply always
create the key with all access rights; if it exists Windows will just open
it for us. The second bug was a cut'n'paste error.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This should make the Makefile much more robust when cross compiling.
The windows.c code is now compile tested but not functionally tested.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds tested code for Linux and Mac OS, implementing the api that
Linus suggested.
The Windows code was moved into its own file, but hasn't even been compile
tested, yet.
In order to have just one interface to set or get a preference value we
encode TRUE as (void *) 1 and FALSE as NULL. This works consistently on
all platforms and regardless of whether we have 32 or 64 bit.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
