There's a meson issue where loading i18n produces a warning about missing
gettext but then proceeds to fail with confusing error messages where the i18n
module is used, see https://github.com/mesonbuild/meson/issues/6165
Work around this by explicitly checking for gettext after loading i18n.
Fixes#270
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This one hooks into the correct portal APIs, hopefully fixing the issue with
the Flatpak version not saving files correctly.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
pack_end, introduced in 29761204a9 means they
align to the bottom of the window. Where there aren't enough drawings to fill
the window, everything is bottom aligned. Hack around this by adding an empty
label to the bottom that expands to the maximum available size and stop
expanding the rest. This new label thus pushes everything up to the top
position.
Fixes 29761204a9
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The first drawings we load are from disk. If we sync a drawing from the device
with a different key (i.e. created in a different month), the new flowbox for
that drawing was appended to the list and in last place. This caused
out-of-order sorting (though a restart of Tuhi would fix it).
So simply change the behavior to sort by oldest timestamp first and pack_end()
for all of them. If we pack all our flowboxes with pack_end, they are
effectively in reverse order, i.e. last one added is first in the list.
Fixes#244
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We're already running the meson test through pytest anyway and pytest is more
powerful than unittest. So let's switch, it's just a search/replace away.
Plus, this way the approach to dynamically create the tests based on the test
logs in the user's home directory is a lot saner.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We're already running the meson test through pytest anyway and pytest is more
powerfull than unittest. So let's switch, it's just a search/replace away.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
f5ea08f171 added this effective requirement for
the Spark and older generations, so let's make sure the test passes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the device name is longer than one reply, the registration will crash.
This adds support for a variable number of replies until the reply ends
with `0x0a`.
This is a workaround for registering problems with Spark.
The registration hangs at "Connecting to device...".
Internally the `GENERAL_ERROR` occurs, which is expected
when registering a Spark device, but this should also
raise an AuthorizeException, but it instead reaches the
handler as DeviceError.
It is currently unclear why the `GENERAL_ERROR` passes to
this handler, so this catches any `GENERAL_ERROR` while
registering a Spark device.
This isn't needed. We need python but if we can run meson we can rely on
python being available anyway. And we don't actually use the python header
files here.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The whole purpose of Tuhi is to save the files after downloading and the
flatpak sandbox quietly dropped any file we saved in the target directory.
We could use xdg-download or something as allowed directory but let's open up
home itself since we don't want to limit where the files can be saved.
Fixes#230
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
It's confusing to users because they don't get any indication that it's the
development package we need, not the normal python package.
This requires bumping meson's minimum version to 0.50 but hey, we can live
with that.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Any args that we don't handle in live mode directly (none right now) should be
passed through to the tuhi server.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This only modifies the XDG directories to point to the ones flatpak uses.
Makes it easier to switch back and forth.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Handling SIGINT in the freshly-started server leads to a race condition:
on Ctrl+C, Tuhi is killed before tuhi-live can call StopLive, leaving the
device in live mode. On the next start of tuhi-live nothing works because the
device will complain about invalid state.
Simplest solution here is to ignore SIGINT in the Tuhi instance and instead
rely on python's multiprocessing module to take us down when the main process
exits.
Fixes#206
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
There's just no point to that and if the tablet is currently in live mode, it
refuses the GET_WIDTH request anyway.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If for some reason the device is still in live mode from an earlier
invocation, stop live mode first before we attempt to start a new one.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Peter Hutterer