Well, the title pretty much says it all. I wrote the core-side backend for shared files listing handling. The implementation was rather similar to that of downloadlist handling, so relativly easy. Since we didn't have per-file upload-speed calculation (like we have for downloads), and we didn't even store total uploaded amounts for files (ed2k module stores credits, but those are per client, not per file), I introduced those API changes as well. Both ed2k and bt modules support the new features as well.
Needs some tuning still - I'm not happy with how the location is displayed - will probably drop that altogether - but at least the protocol-side backend is in place. Btw, something of interest - SharedFile object has member pointers to both PartData (in case of temp file) and MetaData (which contains extended file information). While we cannot transport pointers directly to the GUI, I realized that I can simply use the object ID's (unique for each object) for the same purpose - we'll transmit two ID's with SharedFile object, and the gui can request the objects behind those ID's separately (if they'r not already known by libcgcomm). libcgcomm, on the other hand, will detect such links, and replace the ID's with actual object pointers in the GUI-side API. Soon we'll see how well this idea works in practice.
One annoying bug that had been bothering me quite a while was that sometimes, GUI would just crash for no apparent reason, and JIT debugging didn't even kick in. After quite some tracking, I discovered libcgcomm sometimes got confused during parsing and broke - and all subsequent parsing attempts naturally failed as well. Further tracking revealed that there was an unhandled exception thrown from somewhere, and it was never caught until it reached Qt code (and Qt doesn't use exceptions internally, so it was never caught there either). But the exception wasn't due to protocol incompatibilities between libcgcomm and cmod_cgcomm - as it turned out, the actual issue was that the parsing buffer was reset only once, right before the parsing loop; so if during parsing, two or more packets were discovered, the parser broke, and that only happened when either core or gui were overloaded and were unable to process the data fast enough.
Learning from the above, I added quite a lot of exception handlers on both core and gui-side parsers, to avoid further crashes and provide human-readable errors (well, developer-readable, anyhow) when things go wrong.
I made a second attempt at the "Home" page (as we now seem to be calling it) layouting, but didn't come up with anything show-worthy sadly. That page is pretty much the most complex page of the GUI, since there isn't a well-established standard on how to do it (and frankly, we don't even know WHAT it should do specifically).
Madcat, ZzZz
