A user may want to download the drawing multiple times. And besides, after
switching back to the default icon theme, I couldn't find a decent icon
anyway.
Enable the delete button that's been hidden away so far. When clicked, we
suffix the cached json file with '.deleted'. This also causes a popup with an
undo button to appear (taken from Nautilus). When clicked, that button will
restore the drawing again.
This is really all just renaming anyway, because nothing ever gets deleted
here.
An extra filter is needed to skip Tuhi drawings that have been deleted in the
GUI - we don't want to add the drawings we just deleted again just because
Tuhi still keeps them in cache.
Tuhi caches the json data but has no guarantee about storage. So we cache the
json we get from Tuhi and store it in our settings dir through our Config
backend. Then we use those cached values to generate the SVG files.
This is saved for posterity in the new settings file, so we need a new Config
object (singleton is enough here).
For now, whenever the orientation changes, we just wipe our UI and re-generate
all SVG files. Much easier than messing with proper SVG rotation given that a
device should only ever change between rotations once.
Previously we only ever updated on the initial device assignments. Especially
when the device is offline while started, this means we never get the right
icon.
This broke device initialization in some cases (not sure why it worked until
today though). Where a device is in register mode but the ManufacturerData has
not yet updated to the 4-byte string (i.e. a device previously known
normally), the device would now always call listen(). The firmware - in
register mode - would start initializing the connection though and get
rejected, leaving us with a device that cannot be registered.
This reverts commit a061240b11.
No functional change, it just uses a dict now to pick the protocol class which
makes it *slightly* easier to read.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Instead of just doing a single log line, let's log this to a yaml file so we
have a permanent record of the interactions with the device for bug reports.
This was getting stacked - once on init and once whenever we actually made a
connecting, resulting in the signal never getting disconnected properly and
some races because we tried to sync twice.
The whole "listen()" vs "listening" vs "connected" etc. is a bit of a mess and
should be reworked for a proper fix to this. But for now this will do.
This may fix#124
Propagated whenever we start talking to the device (and then again when we
stop). The purpose of this signal is merely that a UI can show e.g. a progress
bar while we're talking to the device to ensure the user something is
happening.
Fixes#138
Virtually all the commands we have that don't have a specific opcode expect
0xb3. Since that's the general ACK command, we can default to that and make
everything else the exception.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Peter Hutterer