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>
We have a dbus property for this so let's just use that as a backend for our
live property instead of emulating our own on top of it.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
0xb3 is the generic error code (or success, where applicable). Let's handle
those by default so that the rest of the messages only have to care about
replies with message-specific opcodes.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a new main() there so we have a single entry point for the gui instead of
a complex script that needs to be called. That start up script should really
just be the minimum bits possible.
It's still not perfect because we won't work without the gresources and they
require that the pkgdatadir is set. But at least it moves all the logic out of
the startup script.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
We have implied inclusion orders here, specifically with gi. This works as
long as the files are included in the right order from other files but its not
generic enough - we really do need the gi.require_version() bit
everywhere to avoid issues.
Of course, once we do this flake8 complains about everything so let's
reshuffle things in an order it's happy with. This seems to be local modules
first, then ... whatever except when not?
application.py is excluded from this patch because it's about to get changed
in the next one and I'm too lazy to separate those out.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This sets up the config dir, loggers, etc. for us. Fixes regressions
introduced a while ago when Tuhi.run() was removed and then more obvious
breakage now that we require the Config path to be set up.
Fixes#206
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Since most of the signals are propagated by the bindings we largely just need
to hook up simple methods to log what is happening.
One nasty hack: we import some of the bits into the kete namespace so
tuhi-live continues to work. This can be fixed up in a follow-up commit.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The first argument in any signal is the object that emits it, so we don't have
to add it again.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Both of the signals here are connect to the device, not Tuhi. The only reason
this worked was because the signal sent by the dbus bindings had the device
twice in the arguments and 'tuhi' was actually the device.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This is used by the GUI and by kete and it's just an abstraction of the
handling anyway with little actual logic. Let's make this sharable.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This conflicts with trying to register the device on authentication errors and
making re-registration unreliable. Tuhi would keep connecting to the device
while holding the button down, so we'd get another failed connection and a
disconnect from the device. The Register signal would come in and get lost
somehow.
Fixes#195
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Check those modules that aren't part of the python installation and bail out
of meson where they're missing. This is technically wrong because we don't
need them at build-time and only at run-time but pragmatically sensible
because we waste too much time dealing with those bugs.
Fixes#200
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
flathub requires us to use specific versions, so let's do that here too so
we're consistent in testing.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Niclas Hoyer