[logicalshift]

Well, my main side project is the same as it's been for the last couple of years, an animation/vector editing tool written in Rust: https://github.com/logicalshift/flowbetween

It's sort of starting to make the transition between a pile of ideas and an actually useful tool at the moment. The whole idea is to be a vector editing application that works more like a bitmap tool when it comes to painting, so there's a flood-fill tool and a way to build up paths just by drawing on the canvas rather than having to manually mess around with control points.

The way I built the UI is unique too I think. Choices for UI librarys for Rust were quite limited when I started so I built it to be easy to move to different libraries. I don't think there's any other UI library in existence that is as seamless for switching between platforms (or which can turn from a native app to a web app with a compiler flag without resorting to something like Electron)

[chrismorgan]

I suspect that https://github.com/hecrj/iced would now be another UI library that’s as seamless for switching between platforms. Flutter might qualify too (or might not).

[logicalshift]

I’ve been keeping an eye on the various UI libraries when they come up: right now it seems to take me around a month to add a new one so I’m waiting for one to get traction.

Something else that’s a problem is that as a drawing app, FlowBetween wants to be able to get access to data from a digitizer: pen pressure and tilt in particular. A lot of UI libraries don’t think to pass that through from the operating system, or have an awkward API (browser support is also very spotty for this)

[chrismorgan]

Yeah, lack of support for different input media has been a real pain point for me—most of the developers of these things have mice only, and don’t stop to bother about touch or pen input. I use a Surface Book which has mouse, touch and pen, and I like to use all three forms at various times.

If you’re trying to do touch and pen on non-web platforms, things tend to be very messy if you want to handle all three types of pointers optimally.

But browser support spotty? I find the pointers events API a marvellous abstraction over platform differences, doing the right thing automatically for >99% of cases, and making the remaining cases possible. The only thing I feel it actually lacks is standardised gesture support for touch. I wrote a simple pressure-capable drawing app a couple of years back in the very early days of pressure-sensitivity (back when Edge was the only browser on Windows that supported it, so I targeted Edge only until other browsers got it), and I found it a refreshingly straightforward system to work with. And since then, everyone implements things like tilt and pressure.

So I’m curious to hear what you’re quibbling over, as someone that’s been using this stuff in anger more recently than I.

[logicalshift]

I suspect some of my experience is now out of date, as it's now spread out over quite some time. The most recent issue I had to deal with was Chrome: when drawing the canvas at high-res it was being a bit slow at blitting some bitmaps and so was running at 30fps. Something is tied to the framerate with the pointer events implementation and so the events also lagged behind, which made drawing on the canvas quite difficult as the display was 250-500ms behind the user. Eventually 'fixed' by turning the resolution down, but it was a real pain finding what part of the application had got behind (FlowBetween being designed not to lag but to catch up when the display can't keep up). That's quite a subtle one and the pointer events lagging is easily mistaken for the frame rate lagging.

Other browsers don't do this, but they've had a few other issues: what I remember in particular - some only support pressure information using the touch API, and some seemed to support pressure information on different APIs on different platforms, so both pointer events and touch events were needed.

All of these are maturity issues rather than real problems with the API, though and I haven't re-checked some of the older issues recently - that Chrome issue was still happening back in January so might still be around, but the others I last encountered over a year ago so may have been fixed by now.

[chrismorgan]

If you haven’t been using it, make sure to use PointerEvent.getCoalescedEvents where available, which unlinks the events from the display frame rate. Anything using pointer events for drawing should use it. (But remember that events can come in at any speed, e.g. a 240fps pen should coalesce four events per 60fps frame—so make sure you can cope with lots of events.)

I believe that the pointer events API is in current browsers now uniformly superior in functionality to the touch events API which it obsoletes.

[Jemaclus]

Wow, this is cool. What was the inspiration for this? Why Rust?

[logicalshift]

I like to draw, and I suppose my frustrations with other animation packages that I’ve tried were the main inspiration. It’s quite nice to have something that combines two hobbies into one.

When I started I picked Rust because I’d been learning it and wanted to try using it on a more substantial project. I’m very happy with it as a choice of language: it definitely has a difficult learning curve especially with the way borrowing looks similar to references in a garbage-collected languages but works very differently. However, it’s a very expressive language: something about it makes it very easy to write code quickly that’s still very easy to follow later on.

[Jemaclus]

Awesome. I dabbled with Rust several years ago, but have been thinking about diving back into it... Do you have any recommendations about where to start?

[logicalshift]

The official Rust Programming Language book is excellent and was all I really needed to learn the language. I had a small project to work on that I didn't mind rewriting after my first attempt (my build server is a NUC and I wanted to write some software flash the LEDs on the front to indicate build state)

I suspect everyone goes through a phase of hating borrowing when learning Rust: it's helpful to know that it's something that eventually 'clicks' and really stops being an issue. It didn't exist when I was learning, but 'Learning Rust with Entirely Too Many Linked Lists' looks like it would have helped a lot.

[Jemaclus]

Thanks! I'll check that out...