Based on the commit log comments, I'm gonna guess it's still a work in
progress.  :)


On Wed, Mar 31, 2021 at 10:45 AM Sebastien Binet <s@sbinet.org> wrote:
>
> hi there,
>
> I know this has been discussed already but I was looking for Type1
> bibliography and stumbled upon this port of HarfBuzz to (seemingly)
> a pure-Go package:
>
> - https://github.com/benoitkugler/textlayout/blob/main/harfbuzz/harfbuzz.go
>

> Note: protonmail's interface doesn't quite incorporate support for mailing list
> replies, sorry to larry for emails direct to his address.

:)  No worries.

On Tue, Dec 29, 2020 at 4:27 AM Loki Verloren
<stalker.loki@protonmail.ch> wrote:
> One thing that has occurred to me this morning as I am working through the process
> of finding the code that is causing problems is that as they are implemented in most
> versions, the event handlers for press, click and release are function calls.
>
> Maybe they could be changed into a channel instead of function call `chan func()`
> so they are sent to one buffered handler that runs the event callbacks
> asynchronously by default, processing them first in first out as a channel queue

Good questions.  First off, I'd agree that starting a goroutine in
widget layout code is probably a bad idea.

In general, you want to remember that your layout code could run 0
times per second, or 60+ times per second, and code accordingly.  Both
situations require care.

If your layout code isn't called at all (maybe your app is iconified),
will your app crash or hang?  If it's called at 60 Hz, will it crash /
hang / fork a gazillion goroutines?  If a cat takes a nap on the
keyboard (causing a redraw per keystroke if a text field has focus),
will your app be okay?

If you call a function, how long will it take?  Can it hang?  Does it

I see this has already been applied, but I still want to ask: What's
the motivation behind this patch?  To me, trying to dink around with
the order or spacing of imports is wasted effort.  What value do we
get from trying to carefully curate that?  It seems like actively
rejecting or working against the uniformity brought by
gofmt/goimports.

-- L

On Thu, Dec 17, 2020 at 2:56 AM Elias Naur <mail@eliasnaur.com> wrote:
>
> Thanks, applied.

[ I sent this yesterday, but it bounced because it was HTML from
gmail, and I didn't notice till now. ]

Vim on macOS (aka MacVim), Windows, and Linux all support stand-alone
GUI windows that do not need a terminal.  MacVim calls theirs "mvim";
the other two call it "gvim".  ("gvim", as such, actually does work on
a Mac, but I think you have to compile it yourself and use X11, and
few people do that.)  I think they all support synchronous usage,
where you start it and it doesn't return until the user quits.  I know
MacVim does because I use it every day.

If this is just a project for yourself, that's probably all you need.
Other folks of course like other editors, in which case Your (or
Their) Mileage May Vary.

I'm not sure how Elias feels about this now / in general, but in the
past he accepted patches from me that didn't have working code for all
architectures, as long as each architecture had a compilable stub, so
that client code would at least compile across all platforms, even if
the functionality wasn't actually implemented.  This also gives people
that *do* have those architectures available a head start on where and
how to implement the new feature.

-- Larry

On Mon, Oct 26, 2020 at 11:28 AM Josiah Niedrauer <josiah@jniedrauer.com> wrote:
>
> I recently hacked in key release events so I could write games using gio. I
> have access to X11, wayland, and Windows, but I have no MacOS devices to

(I haven't looked at Chris's code.)

How would the Spy know which events were processed and which not?
What if you wrap a Spy around a Spy (around a Spy, around a Spy ...)?

Let's try not to reinvent the Javascript event model, if possible
(bubbling and cancelling and whatnot), which seems very complex.  (If
that's *not* possible, let's try to learn from it and/or other
toolkits' event models.)

I seem to recall (it's been a little while) that In my own code, I
have an ugly hack for this sort of thing for keystrokes, where
basically I mark keys I've consumed/processes as such, and then ignore
already-processed keys at the top of every event processing loop.

[ Repost, replying to the list too this time. ]

Here's the bit of the pastebin that I think you meant:

    usualLayout := layout.W.Layout(gtx, func(gtx layout.Context)
layout.Dimensions {
        return layout.UniformInset(unit.Dp(8)).Layout(gtx,
material.Editor(th, input, "").Layout)
    })
    if !isNumeric {
        bg := Background{
            Color:  color.RGBA{A: 0xff, R: 255, G: 0, B: 0},
            Radius: unit.Dp(0),
        }

All of what Chris says below is true.

Thanks, Chris!

Signed-off-by: Larry Clapp <larry@theclapp.org>

On Fri, Sep 25, 2020 at 10:34 AM ~whereswaldon <whereswaldon@git.sr.ht> wrote:
>
> I've been bugging Larry off and on about this feature for months now,
> and I offered to attempt to synthesize the feedback that Elias provided
> on the last iteration myself. Larry accepted my offer, and here we are.
> The last version of the patch is here:
> https://lists.sr.ht/~eliasnaur/gio-
> patches/%3C20200720130808.48510-1-larry%40theclapp.org%3E#%3CC4QW8FQ0ZFZC.1RVWXDLW3QZGD@testmac%3E

Please use ModAlt on Macs.  On my Mac, in Gmail on Chrome, Pages, and
Evernote, for example, Ctrl-Left & Ctrl-Right are
move-to-start-/end-of-line, respectively.  (As is Cmd-Left & -Right,
so you can't use ModShortcut.)  Thanks.

Also: Thanks for this!  Been missing this functionality a lot!

-- Larry

On Tue, Sep 15, 2020 at 9:03 AM Jack Mordaunt <jackmordaunt@gmail.com> wrote:
>
> >From 276298f20ac87c8bdea5126ba6ea0deecee4e396 Mon Sep 17 00:00:00 2001
> From: Jack Mordaunt <jackmordaunt@gmail.com>
> Date: Tue, 15 Sep 2020 20:49:30 +0800