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.
When we have the systray icon enabled, any window visibility event seems
to have WINDOW_STATE_ICONIFIED bit on. By checking both _ICONIFIED and
_WITHDRAWN the behaviour appears nicer.
The main HUD process can hang due to unhandled exceptions, which
occurred in two separate situations:
1. Table window is closed and HUD instance killed before auto-importer
knows about it
2. Sometimes the threading can jam
These changes attempt to counter the effect of race-conditions. The
dictionary key (table name) is properly tested at the beginning of
update/create block, *but* there are two short round-trips to database
before the key is used. While these occur, the HUD instance can vanish
and thus get its key removed from the dictionary.
Also, when Tables.Table() is created, it will be populated on-demand,
and have child attributes only when such are found from the system. The
new table code pulls in data from actual windows. Again, there is a
query involved and while it runs, the table may have vanished. This
ended up as an error in this call:
foo = gtk.gdk.window_foreign_new(table.number)
The object 'table' is valid (not None) but it has been populated only
after actual table window was killed. Therefore it may not have .number
attribute, which raised an AttributeError. Now the presence of
table.number attribute is tested before the object can be sent to
create_HUD().
The return value is for Glib/GTK event loop, so it should be after
try-finally sequence. The value needs to be returned every time and we
really like to have threads_enter()/threads_leave() to be invoked in
pairs.
Table attributes are pulled from database but the table window itself
may have disappeared. The search parameters no longer match because
there is no window title to match against, so some attributes are not
set at all.
The new table code is saner, cleaner and altogether nicer than the old
one. On linux, the routines finally use Xlib directly. Depend on
python-xlib bindings so we can use them.
Use the "Anonymous Cards" image from openclipart.org
(http://openclipart.org/media/files/Anonymous/12230)
This same image is used in other new FPDB icons, but the combinations
with looking-glass don't look good in systray. This icon is plain enough
to work properly even when scaled really small.
Mika Bostrom