~eliasnaur/gio

6 4

GIO is not referenced in awesome GO

Details
Message ID
<76479c39-0236-bc29-4a80-f924bd63d441@meessen.net>
DKIM signature
pass
Download raw message
Hello,

I just noticed that GIO is not referenced in the awesome GO module list 
[1]. Is there a reason for that ?

[1] https://github.com/avelino/awesome-go#gui


-- 
Bien cordialement,
Ch.Meessen
Details
Message ID
<CAFcc3FSNfm8P_mjscwQpgOmmL6bBha9j5woEdJLWtnGaHsvQYg@mail.gmail.com>
In-Reply-To
<76479c39-0236-bc29-4a80-f924bd63d441@meessen.net> (view parent)
DKIM signature
pass
Download raw message
Hi Christophe,

> I just noticed that GIO is not referenced in the awesome GO module list
> [1]. Is there a reason for that ?
>
> [1] https://github.com/avelino/awesome-go#gui

Alas, we've tried: https://github.com/avelino/awesome-go/pull/3508

Ultimately, we have two obstacles:

- We need to address a bunch of linter errors related to godoc
- Our test coverage doesn't meet their arbitrary 80% threshold. In
many cases, this is because packages don't make a ton of sense to
test. For example, the `gioui.org/widget/material` package is largely
a bunch of visuals. That's fundamentally difficult to test in a
valuable way.

You can see our current test coverage here:

?       gioui.org/app    [no test files]
?       gioui.org/app/internal/log    [no test files]
?       gioui.org/app/internal/wm    [no test files]
?       gioui.org/app/internal/xkb    [no test files]
?       gioui.org/app/permission    [no test files]
?       gioui.org/app/permission/bluetooth    [no test files]
?       gioui.org/app/permission/camera    [no test files]
?       gioui.org/app/permission/networkstate    [no test files]
?       gioui.org/app/permission/storage    [no test files]
ok      gioui.org/f32    (cached)    coverage: 49.4% of statements
?       gioui.org/font/gofont    [no test files]
ok      gioui.org/font/opentype    (cached)    coverage: 74.5% of statements
ok      gioui.org/gesture    (cached)    coverage: 20.0% of statements
?       gioui.org/gpu    [no test files]
ok      gioui.org/gpu/headless    (cached)    coverage: 81.9% of statements
?       gioui.org/gpu/internal/convertshaders    [no test files]
?       gioui.org/gpu/internal/d3d11    [no test files]
?       gioui.org/gpu/internal/driver    [no test files]
?       gioui.org/gpu/internal/opengl    [no test files]
ok      gioui.org/gpu/internal/rendertest    (cached)    coverage: [no
statements]
?       gioui.org/internal/byteslice    [no test files]
?       gioui.org/internal/egl    [no test files]
ok      gioui.org/internal/f32color    (cached)    coverage: 50.0% of statements
ok      gioui.org/internal/fling    (cached)    coverage: 47.2% of statements
?       gioui.org/internal/gl    [no test files]
?       gioui.org/internal/opconst    [no test files]
?       gioui.org/internal/ops    [no test files]
?       gioui.org/internal/scene    [no test files]
?       gioui.org/internal/srgb    [no test files]
?       gioui.org/internal/stroke    [no test files]
?       gioui.org/io/clipboard    [no test files]
?       gioui.org/io/event    [no test files]
?       gioui.org/io/key    [no test files]
?       gioui.org/io/pointer    [no test files]
?       gioui.org/io/profile    [no test files]
ok      gioui.org/io/router    (cached)    coverage: 86.9% of statements
?       gioui.org/io/system    [no test files]
ok      gioui.org/layout    (cached)    coverage: 74.2% of statements
?       gioui.org/op    [no test files]
ok      gioui.org/op/clip    (cached)    coverage: 9.0% of statements
?       gioui.org/op/paint    [no test files]
ok      gioui.org/text    (cached)    coverage: 47.5% of statements
?       gioui.org/unit    [no test files]
ok      gioui.org/widget    (cached)    coverage: 74.1% of statements
?       gioui.org/widget/material    [no test files]

I think maybe we could fix the linter concerns they have and see what
they think regarding coverage in our case as a path forward, but I
haven't had time to try. If you're interested in helping to push this
forward, the help would be appreciated.

Cheers,
Chris Waldon
Details
Message ID
<9cGenf-ZbHhJB2QioL96agKmX3PWLfARAzzEpSBWnp6ENTKT4Ldy3OVQMKkDxt0gtcZxIYrYXWiE0_FsoYvBTBu5jNmJGUZZAb0sIZ3ZMSM=@protonmail.ch>
In-Reply-To
<CAFcc3FSNfm8P_mjscwQpgOmmL6bBha9j5woEdJLWtnGaHsvQYg@mail.gmail.com> (view parent)
DKIM signature
pass
Download raw message
Testing widgets would require a simulation of user input, which probably means also creating
a macro recording to create standard interactions, and could be done with offscreen 

non-painting operations. I have mentioned before the question about whether ops and events can
be serialized, and as I understand it, they can't. This also makes testing more complicated.

Having dug quite deep into a lot of the parts mentioned below, I am entirely unsurprised that
there is so many linter errors. 


There is numerous places, for example, where the keyword 'len' is used as a variable. I don't
even understand why that compiles, but the linter sure screams about it.

This is an extension of the widget/material/layout packages that I wrote, which most notably 

implements a pre-render dimensions calculation that I used to implement a (smoothest of all
I have seen yet) scrollbar, and several miscellaneous enhancements that need this prerender
step.

https://github.com/p9c/gel

It also yes mostly implements a DSL for building Gio GUIs including the run loop itself.
The most difficult part and it's not quite perfect as it is only smooth with relatively uniform
list elements, *but* it can display a list over 20,000 elements largely labels and some icons,
it takes about half a second to calculate and after that it's painting faster than my display,
and it also has pagedown/up that is pixel exact. 


It doesn't behave well if the size of the list elements varies too widely because my reverse-
engineering of the position is probably not quite right, and you can see in such cases the 

scrollbar and view jump backwards sometimes like the coordinate conversion has got an off-
by-one bug but I just have so far worked around it with what I put in the listelements.

I would love to contribute but I am extremely opinionated as anyone could see by reading the 

code in that repo. I am of the opinion that layout, material and widget packages should be merged,
maybe not quite as I have but perhaps to loosen the coupling a little, it's a little tight. But
I really could not make my stuff work without putting everything into one package.

Sorry to take so long to show it to the community but I have been very busy and/or out of order.

I hope that I can in some way contribute, of course everyone is free to copy, adapt and improve
my work, that's the whole reason I made it.

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Tuesday, April 13th, 2021 at 14:19, Chris Waldon <christopher.waldon.dev@gmail.com> wrote:

> Hi Christophe,
> 

> > I just noticed that GIO is not referenced in the awesome GO module list
> > 

> > [1]. Is there a reason for that ?
> > 

> > [1] https://github.com/avelino/awesome-go#gui
> 

> Alas, we've tried: https://github.com/avelino/awesome-go/pull/3508
> 

> Ultimately, we have two obstacles:
> 

> -   We need to address a bunch of linter errors related to godoc
> -   Our test coverage doesn't meet their arbitrary 80% threshold. In
>     

>     many cases, this is because packages don't make a ton of sense to
>     

>     test. For example, the `gioui.org/widget/material` package is largely
>     

>     a bunch of visuals. That's fundamentally difficult to test in a
>     

>     valuable way.
>     

>     You can see our current test coverage here:
>     

>     ? gioui.org/app [no test files]
>     

>     ? gioui.org/app/internal/log [no test files]
>     

>     ? gioui.org/app/internal/wm [no test files]
>     

>     ? gioui.org/app/internal/xkb [no test files]
>     

>     ? gioui.org/app/permission [no test files]
>     

>     ? gioui.org/app/permission/bluetooth [no test files]
>     

>     ? gioui.org/app/permission/camera [no test files]
>     

>     ? gioui.org/app/permission/networkstate [no test files]
>     

>     ? gioui.org/app/permission/storage [no test files]
>     

>     ok gioui.org/f32 (cached) coverage: 49.4% of statements
>     

>     ? gioui.org/font/gofont [no test files]
>     

>     ok gioui.org/font/opentype (cached) coverage: 74.5% of statements
>     

>     ok gioui.org/gesture (cached) coverage: 20.0% of statements
>     

>     ? gioui.org/gpu [no test files]
>     

>     ok gioui.org/gpu/headless (cached) coverage: 81.9% of statements
>     

>     ? gioui.org/gpu/internal/convertshaders [no test files]
>     

>     ? gioui.org/gpu/internal/d3d11 [no test files]
>     

>     ? gioui.org/gpu/internal/driver [no test files]
>     

>     ? gioui.org/gpu/internal/opengl [no test files]
>     

>     ok gioui.org/gpu/internal/rendertest (cached) coverage: [no
>     

>     statements]
>     

>     ? gioui.org/internal/byteslice [no test files]
>     

>     ? gioui.org/internal/egl [no test files]
>     

>     ok gioui.org/internal/f32color (cached) coverage: 50.0% of statements
>     

>     ok gioui.org/internal/fling (cached) coverage: 47.2% of statements
>     

>     ? gioui.org/internal/gl [no test files]
>     

>     ? gioui.org/internal/opconst [no test files]
>     

>     ? gioui.org/internal/ops [no test files]
>     

>     ? gioui.org/internal/scene [no test files]
>     

>     ? gioui.org/internal/srgb [no test files]
>     

>     ? gioui.org/internal/stroke [no test files]
>     

>     ? gioui.org/io/clipboard [no test files]
>     

>     ? gioui.org/io/event [no test files]
>     

>     ? gioui.org/io/key [no test files]
>     

>     ? gioui.org/io/pointer [no test files]
>     

>     ? gioui.org/io/profile [no test files]
>     

>     ok gioui.org/io/router (cached) coverage: 86.9% of statements
>     

>     ? gioui.org/io/system [no test files]
>     

>     ok gioui.org/layout (cached) coverage: 74.2% of statements
>     

>     ? gioui.org/op [no test files]
>     

>     ok gioui.org/op/clip (cached) coverage: 9.0% of statements
>     

>     ? gioui.org/op/paint [no test files]
>     

>     ok gioui.org/text (cached) coverage: 47.5% of statements
>     

>     ? gioui.org/unit [no test files]
>     

>     ok gioui.org/widget (cached) coverage: 74.1% of statements
>     

>     ? gioui.org/widget/material [no test files]
>     

>     I think maybe we could fix the linter concerns they have and see what
>     

>     they think regarding coverage in our case as a path forward, but I
>     

>     haven't had time to try. If you're interested in helping to push this
>     

>     forward, the help would be appreciated.
>     

>     Cheers,
>     

>     Chris Waldon
Alessandro Arzilli
Details
Message ID
<20210413150111.p7rafpfkjaywukgv@kra>
In-Reply-To
<9cGenf-ZbHhJB2QioL96agKmX3PWLfARAzzEpSBWnp6ENTKT4Ldy3OVQMKkDxt0gtcZxIYrYXWiE0_FsoYvBTBu5jNmJGUZZAb0sIZ3ZMSM=@protonmail.ch> (view parent)
DKIM signature
pass
Download raw message
On Tue, Apr 13, 2021 at 02:55:17PM +0000, Loki Verloren wrote:
> There is numerous places, for example, where the keyword 'len' is used as a variable. I don't
> even understand why that compiles, but the linter sure screams about it.

Because len is a predeclare identifier, not a keyword and redefining it is
legal as well as an acceptable choice.

https://play.golang.org/p/fJWORZ8_d-6

Every time I read the output of a linter I'm reminded why I hate them.
Details
Message ID
<xI2Y2A79JteBedVWmetC-wYH8M83i0oiL9S009nR98H_OrQH5HJ9havxFAYpMRSnuk_uPfJ0xdEXDlDVp1wlBtXKoC82NmjzkFca6kbc8KY=@protonmail.ch>
In-Reply-To
<20210413150111.p7rafpfkjaywukgv@kra> (view parent)
DKIM signature
pass
Download raw message
Just because it's legal, doesn't make it good or wise. You can break the line after the func
keyword too, but why would you? Distinctive names are important, for readability. 


I should not be depending on the syntax highlighter to tell me whether 'true' is a variable 

or a value.

I'm sure if Rob Pike was to Go as Linus is to Linux, that half the linter rules would be
enforced in compilation long ago and almost nobody would write linters. Only a lot of 

experience trying to make sense of other people's code will teach you why certain linting 

rules exist, because the compiler will let you do it, even though it makes the code cryptic.

'cryptic' is not something you can judge without artificial intelligence, or a human with deep
study of the matter. Even after 4 years learning how to write Go code, I still learn new reasons
to write one way and not another, ones that nobody has written anything about.

Easy to write is often hard to read and even harder to debug. Go's concurrency system and interfaces
amplify the complexity of tracing bugs, as it is, so, to me, adding things like using these legal
but ambiguous names for variables should be considered a crime against who inherits your codebase.

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Tuesday, April 13th, 2021 at 17:01, Alessandro Arzilli <alessandro.arzilli@gmail.com> wrote:

> On Tue, Apr 13, 2021 at 02:55:17PM +0000, Loki Verloren wrote:
> 

> > There is numerous places, for example, where the keyword 'len' is used as a variable. I don't
> > 

> > even understand why that compiles, but the linter sure screams about it.
> 

> Because len is a predeclare identifier, not a keyword and redefining it is
> 

> legal as well as an acceptable choice.
> 

> https://play.golang.org/p/fJWORZ8_d-6
> 

> Every time I read the output of a linter I'm reminded why I hate them.
Alessandro Arzilli
Details
Message ID
<20210413174827.fzupiivrxk5hfahm@kra>
In-Reply-To
<xI2Y2A79JteBedVWmetC-wYH8M83i0oiL9S009nR98H_OrQH5HJ9havxFAYpMRSnuk_uPfJ0xdEXDlDVp1wlBtXKoC82NmjzkFca6kbc8KY=@protonmail.ch> (view parent)
DKIM signature
pass
Download raw message
On Tue, Apr 13, 2021 at 03:41:22PM +0000, Loki Verloren wrote:
> Just because it's legal, doesn't make it good or wise. You can break the line after the func
> keyword too, but why would you? Distinctive names are important, for readability. 
> 
> 
> I should not be depending on the syntax highlighter to tell me whether 'true' is a variable 
> 
> or a value.
> 
> I'm sure if Rob Pike was to Go as Linus is to Linux, that half the linter rules would be
> enforced in compilation long ago and almost nobody would write linters. Only a lot of 
> 
> experience trying to make sense of other people's code will teach you why certain linting 
> 
> rules exist, because the compiler will let you do it, even though it makes the code cryptic.

I do have some experience reading other people's code. In principle you are
not wrong if people actually wrote code that redefines the true identifier
linters would be invaluable. If the ruleset of linters was better they would
be good. But in reality 99% of linters output is irrelevant nitpicking about
made up problems.
It has gotten better though, 20 years ago they were *really* bad.
Details
Message ID
<6ad96fe33c9affe4e0ea2d525680875f@evereska.org>
In-Reply-To
<xI2Y2A79JteBedVWmetC-wYH8M83i0oiL9S009nR98H_OrQH5HJ9havxFAYpMRSnuk_uPfJ0xdEXDlDVp1wlBtXKoC82NmjzkFca6kbc8KY=@protonmail.ch> (view parent)
DKIM signature
pass
Download raw message
I haven't read through the whole codebase of Gio, but as a pragmatist, I tried to get if redefining len was 
so rare.

$ grep -E "[[:space:]]len[[:space:]]" -r /usr/local/go/src | wc -l
425

Maybe not the most frequent, but still exists in the Go codebase, and written by Rob Pike, Robert Griesemer, 
Brad Fitzpatrick, Russ Cox, and others from the Go Team. And code from 2020, not some old code
that ought to be rewritten.

I'd say that as long as it is explicit enough and the scope of that variable is short, it is ok.
And that's why I'm not so fond of linters. I had linters at work a few months ago, and because of that,
I had to write convoluted code to avoid the lint, because we didn't want to cancel the lint warning for this
line. Made the code less readable to me.

So linting to get some errors not handled caught, ok. But for styling, the lint can't really be
human in understanding readability.


April 13, 2021 5:41 PM, "Loki Verloren" <stalker.loki@protonmail.ch> wrote:

> Just because it's legal, doesn't make it good or wise. You can break the line after the func
> keyword too, but why would you? Distinctive names are important, for readability. 
> 
> I should not be depending on the syntax highlighter to tell me whether 'true' is a variable 
> 
> or a value.
> 
> I'm sure if Rob Pike was to Go as Linus is to Linux, that half the linter rules would be
> enforced in compilation long ago and almost nobody would write linters. Only a lot of 
> 
> experience trying to make sense of other people's code will teach you why certain linting 
> 
> rules exist, because the compiler will let you do it, even though it makes the code cryptic.
> 
> 'cryptic' is not something you can judge without artificial intelligence, or a human with deep
> study of the matter. Even after 4 years learning how to write Go code, I still learn new reasons
> to write one way and not another, ones that nobody has written anything about.
> 
> Easy to write is often hard to read and even harder to debug. Go's concurrency system and
> interfaces
> amplify the complexity of tracing bugs, as it is, so, to me, adding things like using these legal
> but ambiguous names for variables should be considered a crime against who inherits your codebase.
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> 
> On Tuesday, April 13th, 2021 at 17:01, Alessandro Arzilli <alessandro.arzilli@gmail.com> wrote:
> 
>> On Tue, Apr 13, 2021 at 02:55:17PM +0000, Loki Verloren wrote:
>> 
>> There is numerous places, for example, where the keyword 'len' is used as a variable. I don't
>> 
>> even understand why that compiles, but the linter sure screams about it.
>> 
>> Because len is a predeclare identifier, not a keyword and redefining it is
>> 
>> legal as well as an acceptable choice.
>> 
>> https://play.golang.org/p/fJWORZ8_d-6
>> 
>> Every time I read the output of a linter I'm reminded why I hate them.
Reply to thread Export thread (mbox)