XDG_DATA_DIR in flatpak is $HOME/.var/app/org.freedesktop.Tuhi/data/tuhi
vs $HOOME/.local/share/tuhi for normal runs.
Which means switching between flatpak and normal means we lose the UUID and
the stored drawings.
The tuhigui.ini settings file where we store the orientation of the device is
now the same config directory tuhi dumps its data in.
The svgs are in an svg subdirectory, just to make them easier to find.
As a <builddir>/tuhi and <builddir>/tuhi.devel version. The latter runs
in-tree, the former is the one to be installed.
This is this type of script for a number of reasons. The quickest integration would
be to just use multiprocessing and call into the python module instead of
running other generated scripts. But that doesn't work, GLib doesn't like that
much (the GTK UI crashes). See
https://jameswestby.net/weblog/tech/14-caution-python-multiprocessing-and-glib-dont-mix.html
Another option would be to have a single thread because with GObjects we don't
need to care, right? Except that we do because the DBus bindings use sync
calls and that hangs when we have the server in the same process in a single
thread. Fixing the bindings is a bit more involved.
So meanwhile, let's just go for a script that executes the right targets as
separate processes and let the kernel take care of 'threading', that's what
it's there for after all.
If we want to integrate this with TuhiGui, we can't have multiple mainloops.
And there's nothing with Tuhi that needs it anyway, it's all about how it is
being called. Which means we can just move this to the main method.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Drop the user-visible separation, make everything just Tuhi. Directory
structure remains largely separate (tuhi vs tuhigui) except for the po files
which are in the top-level directory because convention.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is a plain subtree merge without any changes to the tuhigui tree itself.
As we'll keep the distinction between the DBus server and the GTK UI, the
directory layout will reflect that.
No-one but Arch packages Tuhi at the moment, so let's assume it's not
running/installed, install it and start it up together with TuhiGui and voila,
everything just works as it should be.
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.
Peter Hutterer