The icon image quality degradation described in the previous changeset is
actually a result of loading by pixbuf, regardless of whether we then draw on
it or not. Interestingly, if the initial load is done by name, then subsequent
loads by pixbuf maintain the higher quality. In any case, in order to minimize
the quality impact, only load the image by pixbuf when actaully doing the
drawing. And the entire thing is still optional -- if download_progress_bar is
not set, the icon is only ever loaded by name.
--HG--
extra : rebase_source : 21233543a2e668bacdd43af1055c99d3e4b8e8e8
On some window manager / panel combinations, drawing on the icon degrades its
quality; make the drawing optional.
--HG--
extra : amend_source : 689f688dc46159cf240773bd9ec39fc02ea1dcbc
The old (gpodder 2) trayicon.py (which was removed in
a198ecc400) had the functionality of showing a
download progress bar on the tray icon itself. The new Gtk status icon
extension did not copy over this functionlity. This changeset ports that
functionality over, and is heavily based on that original code.
--HG--
extra : amend_source : b6cd3349db7f54b8e30b86b9d514073cb80a15fd
This was removed in 34b54e94b8, since it was no
longer used. However, in the next changset we will start using it again.
Although we're about to use it from the extension, it makes a certain amount of
sense to add it back into draw rather than into the extension, since it uses
some other functions from draw, and is also generic in the sense that it could
conceivably be used elsewhere.
--HG--
extra : rebase_source : ef7edc382dfcd2537c2b3b08ded9cf103d13c41b
I'm finally migrating from gpodder 2 to 3, and when starting up gpodder3
after running the migration, I ran into the following uncaught exception
(which aborted gpodder):
TypeError: coercing to Unicode: need string or buffer, NoneType found
The 'Episode details', or shownotes, could be displayed but not
hidden. Further, the menu item and the context sensitive menu gave
inconsistent behavior when multiple episodes were selected. And
I've removed the 'Episode details' context sensitive menu from the
'Progress' notebook page since this displays the shownotes on the
hidden 'Podcasts' notebook page.
The unix_get_active_interfaces() function only partially works on
FreeBSD. Wireless interfaces do not have a status of "active", but
rather "associated".
steps to reproduce:
0) have update setting on "download immediately"
1) when a new episode starts downloading
2) pause and then resume the download
3) manually update the podcast
result: a duplicate download task gets added/queued, can lead to corrupt
downloads.
there are other circumstances that can trigger the bug, but this one is
simplest/most reliable to reproduce.
while i can't claim to understand all of the download-handling code,
this seems (more) correct, and fixes the problem.
note: if the code looks confusing, the git diff patch just came out
weird -- compare the "before" and "after" files manually..
default GTK 'gravity' setting seems slightly buggy on win32, and
'static' gravity avoids the problem. this should also work well
(better?) on other platforms, but it's untested, so..
it seems a 'configure-event' is sent before each 'window-state-event'
when the window is maximized, so the code is checking the stale value of
cfg.maximized, and saves the new position when it shouldn't.
it may be this only happens on win32, but the new code should work
correctly everywhere.
