we don't need the same-ish check twice, we can just pop our non-list into a
list an go from there.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This requires adjusting the svg conversion in kete as well, afaict the 1000
range there was chosen because it's (almost) the midpoint of the Bamboo series
with 2048 pressure grades. So let's use half of 0x10000 instead, which is
approximately 0x8000 as the crow flies.
Fixes#142
This is using opacity of 0% to hide them - this way the space stays allocated
and showing it doesn't rearrange things. Using visiblity here causes
everything to shift around on reveal.
The default size of the drawings is a bit small now, good for an overview but
not for identifying which drawing to use now. Add a zoom slider for that.
This requires adjusting the svg conversion in kete as well, afaict the 1000
range there was chosen because it's (almost) the midpoint of the Bamboo series
with 2048 pressure grades. So let's use half of 0x10000 instead, which is
approximately 0x8000 as the crow flies.
Fixes#142
Some randome color off the google colour picker that's supposed to look more
like a real paper color. This also means we set the general background white
now to give it a better contrast.
On startup and before we connected to a tablet, let's display a missing tablet
icon. Taken from the tablet icon, combined with the X from one of the network
icons in the Adwaita theme.
Once we get a sync notification, we just hide that one and done.
This broke at some point, let's fix it again by moving to the drawing and
calling refresh() from there - no need for the DrawingPerspective to call into
the drawing here.
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>
Peter Hutterer