On Tue, Feb 27, 2018 at 06:51:19PM -0500, Martin Owens wrote:
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.
following up from that, I started with the fuse code this morning, just to get a grasp on how things could work. And I almost immediately ran into a bunch of UX issues that make me question the fuse FS approach again.
First, for a device to sync with a host, it needs to be 'registered' first. This includes holding the button down for 6+ seconds until the LED starts blinking, then pressing the button to confirm once the daemon has connected. The tuhi daemon has the required DBus signals so a client can time this correctly and show the required notifications. But in an FS we're pretty much limited to having a README.txt that spells out what you need to do. Less than ideal...
Second, a device may only sync when the button is pressed. While we can dbus-activate the tuhi daemon on the first FS access, we cannot communicate this to the user beyond having a README.txt.
Third, the registration process is a bit whacky and if a user syncs the device with a different application (like the Android app), the device needs to be re-registered because its UUID will change. Again, something we have signals for in the DBus API but not something easy to handle in an FS.
Fourth, this obviously only works when bluetooth is on. If it's off, we need to ask the user what they want to do.
You can get around these by using the org.freedesktop.Notifications API but I'm not sure how useful that's going to be.
Then there is the subject of permanent storage: the device deletes drawings immediately after sync. the tuhi daemon will delete old drawings on restart, so the only ones guaranteed to be available are the ones drawing in the last session. This make background sync risky, the files need to be fetched, converted and saved somewhere in a normal file system for permanence.
Now the fuse fs is little more than a passthrough from the real directory where everything sits, except that it has a terrible UI :)
so yeah, not convinced the fuse approach is a good one for this particular device. as it looks like, we'll need a fair bit of UI around it anyway.
Cheers, Peter
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