windows.c has be revisited so many times, yet just now I've noticed
that we aren't deleting/unsetting a configuration value ever.
What has went strangely unnoticed is that subsurface_unset_conf()
needs RegDeleteValue instead of RegDeleteKey. "keys" in the Windows
registry are like folders which contain files (or "values").
So in this case we need to delete a "file" and not a "folder" using
RegDeleteValue().
This ended up being a problem with the new prefs.c logic, where there
is a check if a config value is the default value and then it will be
unset/deleted.
There was potential for a crash, where a NULL value can reach
pango_font_description_from_string() for the divelist font.
It also wasn't possible to change the divelist font back to the default font
(e.g. Sans 8), once a different font was selected.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We may not write config variables with UTF-8 characters so the wchar_t
conversation in subsurface_unset_conf() is not needed.
This patch also attempts to improve subsurface_get_conf_bool()
and subsurface_get_conf_int() or better consitentcy with the other OS
files. For both functions return -1 if config key is not found.
Previouosly there was a check for that in function get_from_registry().
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This patch addes body to the functions subsurface_get_conf_int()
and subsurface_set_conf_int().
It also makes some small changes:
- subsurface_get_conf_bool() now uses subsurface_get_conf_int()
- for retrieving DWORDS we would only need RegQueryValueEx,
thus the wchar_t conversations aren't really needed, unless
we start storing integers in keys with UTF-8 characters in the name.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This commit has gone through a few iterations and I trimmed it down to
what I consider the "conservative minimum" - so this only stores window
size, not window position. And in my mind that's the more relevant part,
anyway. Have your window manager position the window at a "smart" spot on
your screen...
Signed-off-by: Amit Chaudhuri <amit.k.chaudhuri@gmail.com>
Signed-off-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
windows.c:subsurface_gettext_domainpath():
- memory at pointer returned from g_win32_getlocale() should be released
main.c:setup_system_prefs()
- it seems all calls to <os_file>:system_default_filename()
return a pre-allocated buffer, therefore we don't need to call strdup()
on the result itself.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Mostly coding style and whitespace changes plus making lots of functions
static that have no need to be extern. This also helped find a bit of code
that is actually no longer used.
This should have absolutely no functional impact - all changes should be
purely cosmetic. But it removes a bunch of lines of code and makes the
rest easier to read.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
subsurface_launch_for_uri() requires unicode support, using
ShellExecuteW() and also the passed UTF-8 buffer has to be translated
to UTF-16 beforehand. Once the ShellExecuteW() is done we release
the UTF-16 allocation.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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>
