In case someone needs to connect to a DB engine in non-standard port,
defining the TCP port is required. This is a rare corner case which
should only arise when a given DB host runs multiple versions of the
same DB engine.
However, the support is relatively straightforward to implement and it
shouldn't conflict with any other options.
If any stat in HUD had manually specified number of decimal places, the
entire hand processing stopped when the first such stat was encountered.
Now really do the decimal place formatting as it was supposed to work.
Also, for future reference: tuples are immutable - you can't overwrite
any tuple member. Hence the need for new routine, __stat_override()
It makes very little sense to do a format string for nothing but zeroes
in case of unknown values. Simply return a set of 'NA' strings in place
of usual stats. This makes the error cases consistent throughout
Stats.py
The values that are displayed in the HUD box included the '%' symbol if
these values were percentages. This clutters the HUD for those who don't
need such extra characters.
This patch removes the trailing '%' from result[1]. The default
formatting for HUD values is '%3.1f' and if decimal places need to be
changed, the code for those is now simpler. A user who wishes to show a
percent symbol after any given stat value, can edit HUD_config.xml and
assign such stats the hudsuffix="%" attribute.
This patch also changes the way the tooltip strings are constructed.
Instead of appending the percent symbol to generated string, the '%' is
now generated in place by the format-string stanza '%%'.
When fpdb is built, the prebuilt .mo files from locale/$LANG/$TYPE/ are
now automatically copied to target directory. For debian builds this
means that all locales are placed in $INSTROOT/usr/share/locale and
should be instantly usable for inclusion.
It makes very little sense to do a format string for nothing but zeroes
in case of unknown values. Simply return a set of 'NA' strings in place
of usual stats. This makes the error cases consistent throughout
Stats.py
The values that are displayed in the HUD box included the '%' symbol if
these values were percentages. This clutters the HUD for those who don't
need such extra characters.
This patch removes the trailing '%' from result[1]. The default
formatting for HUD values is '%3.1f' and if decimal places need to be
changed, the code for those is now simpler. A user who wishes to show a
percent symbol after any given stat value, can edit HUD_config.xml and
assign such stats the hudsuffix="%" attribute.
This patch also changes the way the tooltip strings are constructed.
Instead of appending the percent symbol to generated string, the '%' is
now generated in place by the format-string stanza '%%'.
This fixes the FPDB main window visibility with window managers that use
workspaces instead of virtual desktop(s). On such a system the
application receives WINDOW_STATE_ICONIFIED event when the workspace is
switched. This hides the window.
It wouldn't be too big a problem if the window wouldn't occasionally get
stuck in a "hide-me-loop", where any attempt to unhide/present the
window again triggers the hide routine. The two state events, _ICONIFIED
and _WITHDRAWN are not the same or even mutually exclusive. As such the
old event mask test simply did not cover all the possibilities.
Also, the property 'visible' does not necessarily match reality. It can
be set to true for iconified windows, and false to a visible window. So
a better solution is to not rely on the property, but just track the
wanted visibility state in our own code.
After this simple refactoring, the application window finally seems to
behave properly. [Also, widget.present() automatically calls .show(), so
we can kill one redundant operation.]
Changelog bump for new snapshot, and executable script renames that were
done for win32 setups.
(cherry picked from commit a5a507ece7)
Signed-off-by: steffen123 <steffen@schaumburger.info>
* Deal with .pyw file extensions, because distutils doesn't
* Remove unnecessary win32-only build files from fpdb/*
* Tweak .desktop file for better menu integration
* Assume that build happens with python2.6
The values for pdata[p]['position'] come from DerivedStats.py, where the
value was explicitly cast to a string. This way it should work again and
use the cleaner code from sqlcoder instead.
The value in pdata[p]['position'] is a string. Change the 'pos'
dictionary keys to strings, and to prevent potential breakage on other
databases, always enforce that the looked up key is first converted to
string.
This change is needed to skip a nasty behaviour: if the string triggered
a decoding error, it will trigger one *AGAIN* if the string is printed
to console. By writing directly to sys.stderr we skip the
locale/conversion issues and get the troublesome string directly in a
file where it is stored as a raw sequence of octets.
This encoder is used to handle input from HH conversion, which needs to
end up as UTF-8 in the database. Switch the open-coded routine from
Database.py to this common routine so all encodings now take place in
the same file.
This change is needed to skip a nasty behaviour: if the string triggered
a decoding error, it will trigger one *AGAIN* if the string is printed
to console. By writing directly to sys.stderr we skip the
locale/conversion issues and get the troublesome string directly in a
file where it is stored as a raw sequence of octets.
This encoder is used to handle input from HH conversion, which needs to
end up as UTF-8 in the database. Switch the open-coded routine from
Database.py to this common routine so all encodings now take place in
the same file.
It seems that running encoder.encode() on a latin1/latin9 string results
in, yes a bloody UnicodeDecodeError. Decode error on .encode()...
Really. This way the modification from non-unicode string to real
unicode appears to work better.
The strings (names) as stored in database should always be UTF-8;
whatever the display locale is, we then need to convert from the storage
encoding to session encoding. When making database queries with players
names in them, the names must be reconverted to UTF-8.
It seems that running encoder.encode() on a latin1/latin9 string results
in, yes a bloody UnicodeDecodeError. Decode error on .encode()...
Really. This way the modification from non-unicode string to real
unicode appears to work better.
The strings (names) as stored in database should always be UTF-8;
whatever the display locale is, we then need to convert from the storage
encoding to session encoding. When making database queries with players
names in them, the names must be reconverted to UTF-8.
If the system (display) locale is UTF-8, there is no need to encode to
either direction. In fact, running the .encode() routine appears to
mangle a valid UTF-8 string to a worse condition, effectively breaking
it.
The names are stored in UTF-8, so simply converting the name from UTF-8
to Configuration.LOCALE_ENCODING before putting the string in tooltip is
enough. Neat.
The names are stored in UTF-8, so simply converting the name from UTF-8
to Configuration.LOCALE_ENCODING before putting the string in tooltip is
enough. Neat.
The names are stored in UTF-8, so simply converting the name from UTF-8
to Configuration.LOCALE_ENCODING before putting the string in tooltip is
enough. Neat.
The names should be always in UTF-8 encoding. At least for PostgreSQL
the encdoding of the database comes from the time of running 'initdb'
(which is different from 'createdb') and if the encoding was selected or
set to something else at that time, the following error will occur:
File ".../pyfpdb/Database.py", line 1630, in <lambda>
self.pcache = LambdaDict(lambda key:self.insertPlayer(key, siteid))
File ".../pyfpdb/Database.py", line 1661, in insertPlayer
c.execute (q, (site_id, _name))
File "/usr/lib/python2.5/encodings/iso8859_15.py", line 12, in encode
return codecs.charmap_encode(input,errors,encoding_table)
UnicodeEncodeError: 'charmap' codec can't encode character u'\u2122' in
position 10: character maps to <undefined>
This happens because 'name' is a regular string as opposed to a valid
unicode object. By forcing the string to unicode and encoding it in
UTF-8 the error goes away. In my case the database encoding was
ISO-8859-15 (latin9) but any other "wrong" encoding would trigger the
same problem.
This is a relatively common problem in python.
The names should be always in UTF-8 encoding. At least for PostgreSQL
the encdoding of the database comes from the time of running 'initdb'
(which is different from 'createdb') and if the encoding was selected or
set to something else at that time, the following error will occur:
File ".../pyfpdb/Database.py", line 1630, in <lambda>
self.pcache = LambdaDict(lambda key:self.insertPlayer(key, siteid))
File ".../pyfpdb/Database.py", line 1661, in insertPlayer
c.execute (q, (site_id, _name))
File "/usr/lib/python2.5/encodings/iso8859_15.py", line 12, in encode
return codecs.charmap_encode(input,errors,encoding_table)
UnicodeEncodeError: 'charmap' codec can't encode character u'\u2122' in
position 10: character maps to <undefined>
This happens because 'name' is a regular string as opposed to a valid
unicode object. By forcing the string to unicode and encoding it in
UTF-8 the error goes away. In my case the database encoding was
ISO-8859-15 (latin9) but any other "wrong" encoding would trigger the
same problem.
This is a relatively common problem in python.
Mika Bostrom