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 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.
Since we deal with minimize/expose/show/hide routines ourselves, we
don't want these signals passed any further.
NOTE: if no return type is specified, it is automatically None which
usually is translated to False. That might trigger some weird behaviour,
up to and including rare and hard to reproduce GTK crashes.
PostgreSQL does automatic argument conversion/formatting when dealing
with timestamps. This simplification allows the session stats to be
generated with PostgreSQL as db backend.
Modified:
* Mucked.py
When running from outside source tree, the image containing mucked
cards' faces could not be loaded. Provide an extra path to load from.
Affected files:
* Configuration.py
* Database.py
* HandHistoryConverter.py
* fpdb_import.py
and setup.py to a lesser extent.
Logging requires a configuration file when initialising the class. If we
are executing from outside the source tree, this file is not present.
Catch config parser's error and try to provide the logging config file
from debian package path.
Update symlink target to match python-support from latest Debian and the
oncoming Ubuntu versions.
Modified files:
* Configuration.py
* HUD_config.xml.example
* HUD_main.py
Instead of tweaking aggregation settings directly in code, make the
values configurable through HUD_config.xml; use the newly created
<hud_ui> element for this. Retain coding convention and key-value
names as they are.
By default the hud positions a little box on top-left corner of each
table. Make the text in this box user-modifiable without touching the
source.
Most likely useful for active users and those who play with smaller
tables. On shrunk table the default box may cover some of the players'
cards.
By default the hud positions a little box on top-left corner of each
table. Make the text in this box user-modifiable without touching the
source.
Most likely useful for active users and those who play with smaller
tables. On shrunk table the default box may cover some of the players'
cards.
Conflicts:
pyfpdb/Database.py
Resolve by reverting to sqlcoder's version; it uses the nice insert in
fillDefaultData for each case now and having the DB backends separate
might be good for the foreseeable future.
Database.py : fillDefaultData()
Remove manual 'id' from INSERT command. In database schema,
TourneyTypes.id is a primary key and thus autoincrement. In postgres,
autoincrements are implemented as sequences - inserting a value
"manually" bypasses the sequence generation, which resulted in a
remarkably weird error.
Namely, upon the first hand to import, the insert fails due to primary
key violation. The default value from an unused sequence is 1, but a
row with such an id already exists.
The solution is to create the single row of default data values with
unspecified TourneyTypes.id, hence allowing postgres to generate the
correct id from the sequence. This way the import works again.
Database.py : fillDefaultData()
Sql-coder had fixed the default data insert, and in the process changed
the default type ID. Since his works in general case, I can remove my
modifications.
* Database.py : fillDefaultData()
PostgreSQL has a rather annoying (mis)feature when dealing with boolean
data types: raw 1/0 input as integer is not automatically cast to
boolean values. Instead, one must use one of several other ways of
signifying true/false.
http://www.postgresql.org/docs/8.4/static/datatype-boolean.html
documents the available and understood formatting.
Fix by special-casing PostgreSQL and making all boolean values fed as
strings, '1' for true and '0' for false.
PostgreSQL does not have an UNSIGNED specifier in its language.
Mysql's "TINYINT UNSIGNED" is postgreSQL's "SMALLINT" which is a bit
inconvenient but apart from annoying, not a problem.
Mika Bostrom