subsurface/main.c

222 lines
4.9 KiB
C
Raw Normal View History

/* main.c */
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#include <locale.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <time.h>
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
#include <libintl.h>
#include <glib/gi18n.h>
#include "dive.h"
#include "divelist.h"
#include "libdivecomputer.h"
#include "version.h"
struct preferences prefs;
struct preferences default_prefs = {
.units = SI_UNITS,
.visible_cols = { TRUE, FALSE, },
.pp_graphs = {
.po2 = FALSE,
.pn2 = FALSE,
.phe = FALSE,
.po2_threshold = 1.6,
.pn2_threshold = 4.0,
.phe_threshold = 13.0,
},
.mod = FALSE,
.mod_ppO2 = 1.6,
.ead = FALSE,
.profile_dc_ceiling = TRUE,
.profile_red_ceiling = FALSE,
.profile_calc_ceiling = FALSE,
.calc_ceiling_3m_incr = FALSE,
.gflow = 30,
.gfhigh = 75,
.font_size = 14.0,
.show_invalid = FALSE,
Merge branch 'Qt' After the 3.1 release it is time to shift the focus on the Qt effort - and the best way to do this is to merge the changes in the Qt branch into master. Linus was extremely nice and did a merge for me. I decided to do my own merge instead (which by accident actually based on a different version of the Qt branch) and then used his merge to double check what I was doing. I resolved a few things differently but overall what we did was very much the same (and I say this with pride since Linus is a professional git merger) Here's his merge commit message: This is a rough and tumble merge of the Qt branch into 'master', trying to sort out the conflicts as best as I could. There were two major kinds of conflicts: - the Makefile changes, in particular the split of the single Makefile into Rules.mk and Configure.mk, along with the obvious Qt build changes themselves. Those changes conflicted with some of the updates done in mainline wrt "release" targets and some helper macros ($(NAME) etc). Resolved by largely taking the Qt branch versions, and then editing in the most obvious parts of the Makefile updates from mainline. NOTE! The script/get_version shell script was made to just fail silently on not finding a git repository, which avoided having to take some particularly ugly Makefile changes. - Various random updates in mainline to support things like dive tags. The conflicts were mainly to the gtk GUI parts, which obviously looked different afterwards. I fixed things up to look like the newer code, but since the gtk files themselves are actually dead in the Qt branch, this is largely irrelevant. NOTE! This does *NOT* introduce the equivalent Qt functionality. The fields are there in the code now, but there's no Qt UI for the whole dive tag stuff etc. This seems to compile for me (although I have to force "QMAKE=qmake-qt4" on f19), and results in a Linux binary that seems to work, but it is otherwise largely untested. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2013-05-18 05:01:41 +00:00
#ifdef USE_GTK_UI
.map_provider = OSM_GPS_MAP_SOURCE_VIRTUAL_EARTH_HYBRID,
#endif
};
/* random helper functions, used here or elsewhere */
static int sortfn(const void *_a, const void *_b)
{
const struct dive *a = *(void **)_a;
const struct dive *b = *(void **)_b;
if (a->when < b->when)
return -1;
if (a->when > b->when)
return 1;
return 0;
}
void sort_table(struct dive_table *table)
{
qsort(table->dives, table->nr, sizeof(struct dive *), sortfn);
}
const char *weekday(int wday)
{
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
static const char wday_array[7][7] = {
/*++GETTEXT: these are three letter days - we allow up to six code bytes */
N_("Sun"), N_("Mon"), N_("Tue"), N_("Wed"), N_("Thu"), N_("Fri"), N_("Sat")
};
return _(wday_array[wday]);
}
const char *monthname(int mon)
{
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
static const char month_array[12][7] = {
/*++GETTEXT: these are three letter months - we allow up to six code bytes*/
N_("Jan"), N_("Feb"), N_("Mar"), N_("Apr"), N_("May"), N_("Jun"),
N_("Jul"), N_("Aug"), N_("Sep"), N_("Oct"), N_("Nov"), N_("Dec"),
};
return _(month_array[mon]);
}
/*
* track whether we switched to importing dives
*/
static gboolean imported = FALSE;
static void parse_argument(const char *arg)
{
const char *p = arg+1;
do {
switch (*p) {
case 'v':
verbose++;
continue;
case '-':
/* long options with -- */
if (strcmp(arg,"--import") == 0) {
/* mark the dives so far as the base,
* everything after is imported */
process_dives(FALSE, FALSE);
imported = TRUE;
return;
}
if (strcmp(arg, "--version") == 0) {
printf("Subsurface v%s, ", VERSION_STRING);
printf("built with libdivecomputer v%s\n", dc_version(NULL));
exit(0);
}
/* fallthrough */
case 'p':
/* ignore process serial number argument when run as native macosx app */
if (strncmp(arg, "-psn_", 5) == 0) {
return;
}
/* fallthrough */
default:
fprintf(stderr, "Bad argument '%s'\n", arg);
exit(1);
}
} while (*++p);
}
void renumber_dives(int nr)
{
int i;
for (i = 0; i < dive_table.nr; i++) {
struct dive *dive = dive_table.dives[i];
dive->number = nr + i;
}
mark_divelist_changed(TRUE);
}
/*
* Under a POSIX setup, the locale string should have a format
* like [language[_territory][.codeset][@modifier]].
*
* So search for the underscore, and see if the "territory" is
* US, and turn on imperial units by default.
*
* I guess Burma and Liberia should trigger this too. I'm too
* lazy to look up the territory names, though.
*/
static void setup_system_prefs(void)
{
const char *env;
default_prefs.divelist_font = strdup(system_divelist_default_font);
default_prefs.default_filename = system_default_filename();
env = getenv("LC_MEASUREMENT");
if (!env)
env = getenv("LC_ALL");
if (!env)
env = getenv("LANG");
if (!env)
return;
env = strchr(env, '_');
if (!env)
return;
env++;
if (strncmp(env, "US", 2))
return;
default_prefs.units = IMPERIAL_units;
}
int main(int argc, char **argv)
{
int i;
gboolean no_filenames = TRUE;
const char *path;
char *error_message = NULL;
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
/* set up l18n - the search directory needs to change
* so that it uses the correct system directory when
* subsurface isn't run from the local directory */
path = subsurface_gettext_domainpath(argv[0]);
setlocale(LC_ALL, "");
bindtextdomain("subsurface", path);
Conversion to gettext to allow localization This is just the first step - convert the string literals, try to catch all the places where this isn't possible and the program needs to convert string constants at runtime (those are the N_ macros). Add a very rough first German localization so I can at least test what I have done. Seriously, I have never used a localized OS, so I am certain that I have many of the 'standard' translations wrong. Someone please take over :-) Major issues with this: - right now it hardcodes the search path for the message catalog to be ./locale - that's of course bogus, but it works well while doing initial testing. Once the tooling support is there we just should use the OS default. - even though de_DE defaults to ISO-8859-15 (or ISO-8859-1 - the internets can't seem to agree) I went with UTF-8 as that is what Gtk appears to want to use internally. ISO-8859-15 encoded .mo files create funny looking artefacts instead of Umlaute. - no support at all in the Makefile - I was hoping someone with more experience in how to best set this up would contribute a good set of Makefile rules - likely this will help fix the first issue in that it will also install the .mo file(s) in the correct place(s) For now simply run msgfmt -c -o subsurface.mo deutsch.po to create the subsurface.mo file and then move it to ./locale/de_DE.UTF-8/LC_MESSAGES/subsurface.mo If you make changes to the sources and need to add new strings to be translated, this is what seems to work (again, should be tooled through the Makefile): xgettext -o subsurface-new.pot -s -k_ -kN_ --add-comments="++GETTEXT" *.c msgmerge -s -U po/deutsch.po subsurface-new.pot If you do this PLEASE do one commit that just has the new msgid as changes in line numbers create a TON of diff-noise. Do changes to translations in a SEPARATE commit. - no testing at all on Windows or Mac It builds on Windows :-) Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2012-10-11 00:42:59 +00:00
bind_textdomain_codeset("subsurface", "utf-8");
textdomain("subsurface");
setup_system_prefs();
prefs = default_prefs;
subsurface_command_line_init(&argc, &argv);
parse_xml_init();
init_ui(&argc, &argv);
for (i = 1; i < argc; i++) {
const char *a = argv[i];
if (a[0] == '-') {
parse_argument(a);
continue;
}
set_filename(NULL, TRUE);
parse_file(a, &error_message);
if (no_filenames)
{
set_filename(a, TRUE);
no_filenames = FALSE;
}
}
if (no_filenames) {
const char *filename = prefs.default_filename;
parse_file(filename, NULL);
/* don't report errors - this file may not exist, but make
sure we remember this as the filename in use */
set_filename(filename, FALSE);
}
process_dives(imported, FALSE);
parse_xml_exit();
subsurface_command_line_exit(&argc, &argv);
init_qt_ui(&argc, &argv, error_message); /* qt bit delayed until dives are parsed */
run_ui();
exit_ui();
return 0;
}