~eliasnaur/gio#217: 
Some bug fixes and enhancements in gogio, gesture/clicks and editor

I just wanted to let you guys know I have made a bunch of changes/fixes that you might want to move upstream, I will list them in the order I made them:

  • https://github.com/p9c/gio now contains a fork of gio current up to yesterday, with two main changes:

    • gogio now has a 'nostrip' option which disables the -w -s ldflags, which might make debugging possible in the apk. I'm not sure if this is useful?

    • I discovered to my chagrin that my plans of implementing standard X11 select/middle click paste, known as the 'primary' buffer, required me to poke also at the app/internal/wm directory. I am not sure yet if the fix I made should be applied to the other platform button handling, as the X11 handling was definitely wrongly implemented.

      When I say wrongly implemented, I found by logging the mouse events that presses get a 'button' value but there is zero in the release. The upshot of this is that the whole pointer click handling cannot be used in its current state to work with anything more than that primary mouse button, you know, that one that some computers only have 'one' of. Where it previously ORs the button code and then NOT-ANDs it, resulting in press with button and unpress with no button, it now ORs both press and release and then resets the value to zero after dispatching the event.

As I am trying desperately hard to avoid doing too much on upstream stuff and work around it, an extended version of the layout/widget/material library can be found at https://github.com/p9c/gel - in there are pretty much all the things, but crammed into one package and using chained methods.

But changes of substance are also in there:

  • the editor has been updated to include several new features:

    • triple click selects the entire text (might be better to make that the line but I am not using multilines anytime soon). To do this I had to change the gesture package to properly handle the extra time for 3 clicks with the double click interval limit.

    • Using the xgb interface from burntsushi the editor when the editor selection changes the selection is copied to the primary buffer, if on X11, and when the middle button is clicked, the content of the primary buffer is pasted and left selected to make it visible if it was misplaced (later I guess to add drag-and-drop, which should move the whole selection around, on desktop, this is incorrect behavior on touch interfaces however.

      So there may be some kinks in mobile interfaces and with other platforms - I have just implemented it for X11 and since the dummy getprimary function returns an empty string, and the paste will then be ignored, though it will change the cursor, and perhaps. Ok, so it doesn't cancel if you drag, which probably should be added, or, perhaps instead the caret could appear where it will insert, as the wobbly accidental scroll thing tends to do (which could be at least partially alleviated by disabling scroll while hover and button down). And a big grabber for mobile from long touch, and canceled by typing (deleting selection of course).

There's a few more things to round it out but we were going to run with just giving nice big friendly copy paste clear buttons, the new selection thing is wonderful, and why I have put the energy into this, but for copying and pasting crypto keys and short notes the prior setup was acceptable.

I promise not to mention it again but there is also a set of tools for working with offscreen dimensions calculations by using macro recording then discarding after the dimensions are returned, that I have used to implement a scrollbar that at least when used with relatively short axis-height segments in the List is smooth and fast, though initial display does stall the paint for some tens of frames. I can't justify doing it now but I want to generalise the segment iterator to allow any widget to be in a cell aligned baseline, bottom or top, and of course to be able to reverse the order of both axes. I don't know if the cost of either interfaces or functions to enable this efficiently is there, my guess would be interfaces will be faster for the glyphs than making the glyphs into widgets.

I hope this is of some use as I am otherwise doing it for the parallelcoin wallet's GUI anyhow.

Status
REPORTED
Submitter
~stalker_loki
Assigned to
No-one
Submitted
22 days ago
Updated
22 days ago
Labels
No labels applied.