I've noticed that when Gio draws the window decorations, the buttons in the title bar are included in the tab order for keyboard focus: After cycling through the widgets in the content of the window, pressing tab goes to the minimize, maximize, and close buttons before returning to the regular widgets.

@whereswaldon suggested: I think we'd just need a way to mark a given gesture.Click and/or widget.Clickable as ineligible for keyboard focus, and we could then use that in the implementation of widget.Decorations

OK. In that case, I suppose we should wait for the dust to settle from that transition.

Andy

On Thursday, December 14, 2023 1:21:29 PM PST, ~whereswaldon wrote:

I believe we're considering unifying the clipboard API with the transfer API as well. It would enable some nice things like handling typed clipboard contents other than text (images, etc...) and would make it possible to handle drag-n-drop and clipboard in a uniform way. You'd likely still need to explicitly request a paste (read the clipboard), but the content could come to you in the same format as other data transfer mechanisms. This new clipboard functionality seems like it fits that paradigm too.

Yes, that would probably work.

I had assumed that the API would be similar to the clipboard API, because they are often thought of together, and the underlying implementation is similar (at least on X11). But they wouldn't have to be the same.

Andy

On Thursday, December 14, 2023 7:16:03 AM PST, ~whereswaldon wrote:

I don't think that transfer.DataEvent has enough information; it would need to include the mouse location for the middle-click if we would use it. (With middle-click paste, the text is inserted where the middle button was clicked, not at the current insertion point.)

In my brief experiment just now, the middle-click moves the insertion point prior to the insertion. That would be easy to implement without modifying the data event. We could just cause the cursor to move on middle click. Or am I missing something?

We should probably wait to work on the implementation till the event system overhaul is done.

I don't think that transfer.DataEvent has enough information; it would need to include the mouse location for the middle-click if we would use it. (With middle-click paste, the text is inserted where the middle button was clicked, not at the current insertion point.)

Andy

On Wednesday, December 13, 2023 7:17:58 AM PST, ~eliasnaur wrote:

If you've going to take a stab at it please keep in mind that the event system is probably getting an overhaul soon: https://todo.sr.ht/~eliasnaur/gio/550. I haven't thought deeply about the issue itself, but it seems to me that it can be implemented by triggering a transfer.DataEvent when the user middle-presses; widget.Editor listens for DataEvents through transfer.TargetFilter at every frame so it should receive events even when it hasn't explicitly asked for them.

I don't really know what I'd be getting into with this low-level GUI plumbing, but I suppose I could try.

I assume one of the first steps would be adding "primary selection" support to gioui.org/io/clipboard. One option would be to add a boolean field to each struct type in that package, indicating whether it applies to the primary selection instead of the clipboard. Maybe it could be called Primary.

On platforms without support for the primary selection, the ops relating to it would just do nothing. A ReadOp would never produce an event there.

Andy

On Tuesday, December 12, 2023 11:41:04 AM PST, ~whereswaldon wrote:

There's a challenge here in that the behavior isn't coherent cross-platform. Windows and macOS desktop users will not expect this to happen. To get this to work in Gio, we'd need to:

• start notifying the OS of any text selected so that this special clipboard could be updated on supported platforms (maybe this could reuse the existing IME events)
• develop platform-specific code for reading this special clipboard (I suppose this could return nothing on windows/mac/etc so that it doesn't do unexpected things on those platforms)
• add some mechanism for text editing widgets to receive from this special clipboard on middle-click if there isn't some other handler in place for the middle-click interaction

It's certainly doable. Are you interested in working on it? We'd be happy to offer guidance on how to approach it.

On X11 and Wayland, you can usually select text with the mouse, and then click the middle mouse button to paste it. This doesn't seem to work in Gio apps. Are there plans to implement it?

I've pulled my stroke package out into its own GitHub repository now, under the same dual license as Gio. (https://github.com/andybalholm/stroke)

I had been hoping to finish up a few things before sharing it, but I got busy. So here it is as it is now.

One thing to watch out for is that the semantics of MiterLimit are not the same as in gioui.org/x/stroke. I followed the PostScript/PDF semantics, where MiterLimit is ignored unless the join type is set to MiterJoin. And it always falls back to BevelJoin if the MiterLimit is exceeded. The API of gioui.org/x/stroke allows specifying miter joins that fall back to round joins if the miter limit is exceeded. If you want to keep that option, we'll need to add another field to Options—maybe it could be called MiterFallback, and you could set it to RoundJoin if you want that behavior.

Other than that, I think that using it as a backend for Gio's stroking is mostly a matter of translating between Gio's representations of paths and [][]stroke.Segment. A stroke.Segment is a single cubic Bezier curve segment. A []stroke.Segment is a connected contour. A [][]stroke.Segment is a complete path, with multiple contours.

All segments are represented as cubic Beziers because that is the most general form, and linear and quadratic segments can easily and losslessly be converted to cubic.

Andy

On 3/14/22 1:40 AM, ~eliasnaur wrote:

You were mentioned in ~eliasnaur/gio#379 by ~eliasnaur.

github.com/andybalholm/giopdf/stroke is 3x faster than our stroke implementation according to

https://todo.sr.ht/~eliasnaur/gio/331/comment#event-138998

this issue tracks replacing our implementation as described in

https://todo.sr.ht/~eliasnaur/gio/331/comment#event-139258

Gentle ping, ~andybalholm. I believe a better stroke implementation would help the community alot, see for example most recent issue latest issue https://todo.sr.ht/~eliasnaur/gio/313. If you don't have the time to implement a Gio replacement that uses your package, please let us know, perhaps with a few sentences describing the work required so someone else may take over.

Please also let us know if you're willing to release your version under UNLICENSE.

I'll be glad to. But I'd like to avoid needing to maintain two copies of the same code (one in core and one in gio-x). Since most of the code in my package is toolkit-independent, it might be best to factor that out into a separate module, with no dependencies but the Go standard library, and put only the Gio-specific parts in gio core and gio-x.

Andy

I'm still running into this kind of artifacts pretty often.

Since debugging code is twice as hard as writing it in the first place, I decided to try writing my own path-stroking library. It turns out to be three times as fast as gioui.org/x/stroke, with less than half the code. (The 3x measurement benchmarks producing an ops list, but not rendering it to a backend. If rendering is included, execution time is dominated by CGO calls.)

The code is part of my WIP PDF rendering library at github.com/andybalholm/giopdf/stroke.

If that's the intended behavior, I can work with it, but it should probably be documented. (I don't see that it's documented in gonum/plot either.)

Andy