Via email a user noted a bug when "Gramps -v" was used with Gtk not installed (and gi was).
When the "gi.require_version('Gtk', '3.0')" was added during Gramps 5.0.0 timeframe, a corresponding exception was not.
Follow-on from https://gramps-project.org/bugs/view.php?id=8981
This patch was applied in Debian (gramps 42 branch) due to warnings picked
up in the build log and from testing by running gramps from the command
line. I have rebased it on master, as it will probably be a while before the
warnings become errors.
Restores setting the stdout encoding to sys.getdefaultencoding() in a
way that works with Python3 (thanks to Jack O'Connor on stackoverflow)
and in a place that sets it for the loggers, too.
The problem is really that the paths get munged into strings in the
system codepage, losing or misinterpreting most Unicode. Python's os
module is smart enough to encode the unicode to the file system
encoding, but the bsddb module needs a little help.
Provide a new function, constfunc.get_env_var(name, default=None) to
cleanly import Unicode environment variables in Windows and use it in
place of all instances of foo = os.environ['BAR] or foo =
os.environ.get('BAR').
Os path functions are smart enough to convert unicode to the file system
encoding on their own, but Db functions aren't, so provide an _encode
function in gen.db.write.py and apply it where a path is being passed to
DBEnv.open().
Also convert paths from the UI to unicode from 'utf8' rather than
sysfilesystemencoding. The latter happens to be correct most of the time
on Linux and OSX but is wrong on Windows.
Unfortunately, no package on ubuntu for sdn...
Bug fixed on trunk, when sdn is present on the system.
Verified that sdn roundtrip works.
date_test now fails on 1789-13-4(French) recognized as invalid,
as it probably should -- I guess this one is a test bug.
svn: r23127
Merged from gramps40 the commits below and
verified there are no more instances of BatchTool
on trunk to change as well.
commit 657a57fb7de3c9804dfbff5b27f824ff79ead2ae
Author: Vassilii Khachaturov <vassilii@tarunz.org>
Date: Wed Aug 21 17:24:41 2013 +0000
6953: remove "undo history warning" under CLI
Port my fix from gramps34.
In addition, the Check tool now has a hardwired dependency
on ProgressMeter. Make a nullifying mock locally and
only set it to the real thing only under GUI.
Tested with impex.sh (further stages after check still fail,
see bug #6878).
git-svn-id: svn+ssh://svn.code.sf.net/p/gramps/code/branches/maintenance/gramps40@22899 4ae1f11a-8b86-4847-b8af-ab372f36d1fd
commit 064d9a7b36770857f7fd68b35ade6e8f3f52b81a
Author: Vassilii Khachaturov <vassilii@tarunz.org>
Date: Wed Aug 21 17:24:18 2013 +0000
action 'tool' CLI handler broken w/o DISPLAY
Preparing to port my fix for 6953: remove "undo history warning"
when the BatchTool run from cli (e.g., "check")
from gramps34, the ground state was worse in gramps40...
git-svn-id: svn+ssh://svn.code.sf.net/p/gramps/code/branches/maintenance/gramps40@22898 4ae1f11a-8b86-4847-b8af-ab372f36d1fd
svn: r22902
Only one base translation per locale. To set up a different locale
on any axis (locale, domain, directory, or languages) instantiate a
secondary locale by calling GrampsLocale() with the appropriate
arguments.
svn: r21968
As noted in the previous change, importing const into setup.py tried to initialize GrampsLocale and ResourcePath, which won't work. Since all we want is the VERSION string, move that to a new file, gramps/version.py
svn: r21614
