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 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.
Mika Bostrom