Hi Peter,
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).
Yes I read the bluetooth part of it after the fact. tbh the whole exercise would probably need to be ux tested anyway, since a lot of these types of things can be quite cumbersom if not.
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.
Not much of a cost considering the UX gains you get to have. i.e. not having a seperate program you have to run in order to do things.
Also, to get the device to sync, you usually have to press the button on the device and that would require some prompting.
I see the button as the jumping off point. You press the button, the demon code is already running with bluez or similar and starting syncing up and boots up the fusefs as the results page. Would be cool if I could just open up my laptop, log in and press the physical device button to get access to my files.
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??).
Yeah, stick the timestamp into stroke-time attribute on the path, not ideal since it's out of spec for svg, but with svg on it's knees, it's time to add some custom specs anyway. Might be a fun addition to inkscape later on to add the whole draw forwards/backwards thing and an interesting saved-undo.
The part that concerns me is the pressure information, since we'd just have strokes and have no real format for saving powerstrokes as svg directly. We could convert things to powerstrokes, but there'd have to be a bit of code that could detect that they're not 'filled out' and do that work on load.
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 :)
That's the ticket. Just less interaction and more 'just pop the stuff up' and also less UI work on your side. I suppose you could just make a folder stick some files in it and pop up a nautilus window, but it's not as cool as the device recognision you'd get otherwise.
Thanks for taking the time to fill in a few details.
Best Regards, Martin Owens