Splitting drawings via GUI

[stelzch]

This is a WIP feature implementation, but I would like to hear your thoughts anyway.

What this is for

The original Wacom Inkspace app has a "split drawing" feature, it is really useful if you forgot to press that only button the device has and now are left with two drawings overlayed. This PR adds a dialog to Tuhi where the user can select a split position via slider:

Open Questions

Timestamp as ID

AFAIK, a drawing is uniquely defined through its UNIX timestamp in seconds. In this working implementation, if the user splits a drawing, the part that is split off gets assigned timestamp + 1, since assigning it the current timestamp would mess up the display order. However, if the user decides to split the first part again, a collision occurs. This might not happen very often, but I would suggest changing the Identifier from timestamp to either timestamp + some sort of hash or add precision (e.g. milliseconds) to avoid problems of that kind altogether. Any thoughts?

Drawing rendering

The PR also contains code to render a drawing from its json_data into a Gtk.DrawingArea with cairo. It is more responsive to changes than the current "exported SVG" approach, however I have not benchmarked its performance. Would it make sense to replace the rendering drawings in the DrawingPerspective with it?

[whot]

As a first gut reaction, I'd say multiply the timestamps by 10000 for the display order and then give the split-off-part the count of strokes in the drawing. So where you split up a drawing at the 50th stroke, the resulting file would have the timestamp 12345.0050, multiplied (if that's even needed...) it'll sort just fine. 10k strokes should be good enough for everyone, right?
tbh, I can't remember if we have actual ms in the stroke data but if we do we can use that too.

As for Tuhi itself - we have barely any time to work on it, so you've just put in more work than me or @bentiss have in the last 6-12m :) I'd be all-to-happy to hand the project over to someone who actually uses it and has some interest in it working.

I barely remember the decisions we made regarding rendering but often enough the answer is: whatever was easy to implement and worked well enough :) The SVG approach was effectively a one-liner and the advantage is that we don't need to worry about differences between the exported SVG and the rendering we show. For any sort of manual rendering we need to match line widths, etc. That's all I can think of here as arguments.

[stelzch]

Thanks for the quick and thoughtful reply.

I just found out that since the drawings are loaded with this glob expression

return [Drawing.from_json(f) for f in configdir.glob('*.json')]

it is actually possible to use floating point numbers as timestamps and tuhi loads them without problems. As you suggested, the splt timestamp is now calculated by old_timestamp + num_strokes * 1e-5 (extra 90k strokes for good measure)

[jiucenglou]

This feature is very useful ! Will this feature be merged soon ?