Hi Martin,
thanks for your reply, I realised I was a bit scant on details. First, a basic technical detail: the device is a bluetooth LE device and needs to be explicitly synced, it doesn't stay connected. Any data that is synced off the device is deleted by the firmware, thus local buffering is needed anyway. This buffering is currently handled by the Tuhi daemon, but it's not a permanent storage solution (we automatically delete old drawings).
On Tue, Feb 27, 2018 at 08:28:06AM -0500, Martin Owens wrote:
Hi Peter,
This is an exciting addition.
The way I would think about this problem is "what operating systems do you want to target", if the target is predominately Linux, then the most super-amazing intergration would be a fuse-fs user space mount.
only Linux, because on other platforms Wacom provides applications to extract the data anyway. There is no need for a daemon on other platforms.
IMO a fuse-fs would be overkill. The data is already synced and buffered, simply saving this to a preconfigured folder seems sufficient and gets you 99% of the way there. The fuse FS would only get you the look of a USB stick, at the cost of wrapping everything into a fake fs.
Also, to get the device to sync, you usually have to press the button on the device and that would require some prompting.
You plug the device in and it pops up just like a regular usb stick, but with it's own wacom icon and relivant name. Inside you can offer up raw or converted file formats, it's up to you how complex you want to go. Although offering svg files directly would be double rainbow amazing tbh.
Offering SVG files is trivial, we already do so in our debugging tools (minus things like pressure handling, not sure how do do that). But I just offering SVG means we're losing some of the capabilities: the data we get from the device however can also include stroke timestamps and per-point pressure. The Wacom Android app has a slider where you can replay the drawing and export a partial one. This would be possible with the raw data but not with an SVG unless we shove it into magic attributes somewhere (how??).
That way Inkscape would be able to open up the files as is, no special arrangements. The best part is that the files would work with many-many programs and you get a many-to-many win-win. I highly recommend this. (some good references for fuse mounts can be found in the google docs fs, the android adb fs, the media-fs for phones etc)
We're planning to have an application that provides SVG export etc. as standalone anyway. This can take over the user prompting and (background?) sync anyway, so the files will be available somewhere, ready for the taking :)
Cheers, Peter
It doesn't sound like you're targeting MacOSX or Windows considering you're using DBus. So I hope this is the way you're going to go with it.
Best Regards, Martin Owens
On Wed, 2018-02-21 at 11:38 +1000, Peter Hutterer wrote:
Benjamin Tissoires and I have been working on a project called Tuhi that communicates with the wacom smartpad devices and pulls the data off them.
https://github.com/tuhiproject/tuhi/
Devices working so far are the Bamboo Spark, Slate and the Intuos Pro Paper. Smartpad devices aren't traditional graphics tablets [1] but instead have a paper notepad on top of a sensor with a special pen. You draw on the paper, the sensor registers the drawings and stores it in a custom vector- based format in the device. Later, you connect the device over bluetooth to the host and fetch the drawings from the firmware.
This is the bit that tuhi does, and it exposes the drawings as a simple json-based vector format overa session DBus API. To interact, you basically connect to the dbus daemon, tell it to listen to the device and then get notified about new drawings. Then you can fetch the drawings one-by- one as needed.
Tuhi only has a commandline client for debugging and we don't intend to ship that client, it's for debugging only. Eventually, we may have a standalone application similar to Wacom's Inkspace (yeah, confusing, isn't it?). This app would be a gallery-style application that displays the drawings and exports them to the desired formats. That's a fairly straightforward process.
But right now what we're interested in is whether inkscape has interest in a plugin-style implementation that talks to the tuhi daemon. Or whether there are use-cases where the standalone application is insufficient and some tighter integration is needed. Or other use-case you can think of that we haven't yet.
Any comments appreciated!
Cheers, Peter
[1] the intuos pro paper is when you plug it in, let's ignore that for now
Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel