On Fri Dec 6, 2019 at 12:34 PM Gregory Pomerantz wrote:
> On 12/6/19 11:38 AM, Elias Naur wrote:
> > The trick is to realize that the order of Rigid/Flex calls and the order
> > of the FlexChildren in Flex.Layout don't have to match. In your example,
> > you should Rigid the widget with the highest priority first:
> 
> I was just working on updating the heart rate monitor app to add a 
> stopwatch widget and improve the layout (including adding new layouts 
> for horizontal screens). A common pattern seems to be to have a Flex 
> with a number of Rigid children and one or more Flex children taking up 
> remaining space (basically pushing any other items to the edge of the 
> layout area but still leaving enough space for them to get drawn).
> 
> Could it be possible to always automatically treat Flex children as a 

On Fri Dec 6, 2019 at 10:01 AM Larry Clapp wrote:
> I'd like some help on layout.
> 
> I'd like an editor widget at the bottom of the window, that starts at
> one line when it's empty, and grows in height up to 25% of the window.
> 
> I'd like a list to fill the remaining space.  The list is
> "ScrollToEnd: true", in case that matters.  So it's similar to a TTY
> in that respect: you add stuff to it, which goes in at the bottom, and
> everything above it scrolls up.
> 
> I've tried two Flex children with 75% and 25%, but that gives the
> editor widget at the bottom 25% of the space even when it's empty.
> 

On Thu Dec 5, 2019 at 8:59 AM Larry Clapp wrote:
> Editor.DeleteBackward
> Editor.DeleteForward
> Editor.MoveLeft
> Editor.MoveRight
> Editor.MoveTop
> Editor.MoveBottom
> Editor.Insert
> 
> Move the Editor.command method up above all the functions it calls.
> 
> Signed-off-by: Larry Clapp <larry@theclapp.org>
> ---
>  widget/buffer.go | 12 ++++++-

On Wed Dec 4, 2019 at 10:17 PM Larry Clapp wrote:
> Signed-off-by: Larry Clapp <larry@theclapp.org>
> ---
>  widget/buffer.go | 12 ++++++++++++
>  widget/editor.go | 23 +++++++++++++++++++++++
>  2 files changed, 35 insertions(+)
> 
> Since v1: Added Editor.Insert.
> 
> diff --git a/widget/editor.go b/widget/editor.go
> index ef282c7..4358217 100644
> --- a/widget/editor.go
> +++ b/widget/editor.go
> @@ -613,6 +618,24 @@ func (e *Editor) scrollToCaret() {

On Wed Dec 4, 2019 at 6:42 PM  wrote:
> >> I need to pass a build tag `-tags sqlite` to the build so I can build sqlite access into my app. It
> >> doesn't seem gogio take that info and therefore I can't access my DB from my mobile.
> >> I guess there must be more stuff to it (like CGO) but I don't know about that.
> 
> It seems I did something wrong passing my GOFLAGS.
> Checking the source code, I saw that you pass `os.Environ()` to the cmd.Env ( https://git.sr.ht/~eliasnaur/gio/tree/master/cmd/gogio/androidbuild.go#L192 )
> So I tried again with `GOFLAGS="-tags=sqlite" gogio -target android .` and it worked.
> 
> Now I'm facing another issue as I can't write on the fs of android by creating a sqlite database.
> Do I need to ask Android permissions for that?
> 
> ```
> 12-04 17:43:12.288 23150 23182 I gio     : sqlite:///data/user/0/com.tuxago.mempack/files/mempack/mempack.sqlite

On Wed Dec 4, 2019 at 8:01 AM Tanguy ⧓ Herrmann wrote:
> I just read that this email.
> I'm impressed you even remember this exchange. And I'm happy I've played the devil's advocate, because, I clearly prefer a little Java and a lot of Go than just Java without Go at all.
> And if the result of that exchange helped to move towards Gio, I'm even happier.
> 
> I finally started to play with it, and if it's not the kind of patterns I'm used to, I still enjoy it better than to deal with any of those enterprise-y Java patterns.
> And for now, the tooling is excellent. Between pure go CLI and gogio for specific platform building, it's very easy to test locally and deploy + test on mobile.
> 
> So again, thanks for your dedication to this topic and bringing pure Go UI to mobile dev without boilerplate.
> 

Thank you! If you're not already aware, Gregory Pomerantz is doing some
great work to enable integration with the Android SDK, permissions and
external apps. For example, see the December newsletter for a

	gdlv ported to Gio

gdlv, the GUI frontend to the Go debugger recently gained support for Gio in
addition to the existing Shiny backend. Alessandro Arzilli did the work, and
let me know that the Gio backend is now the default on macOS.

	https://github.com/aarzilli/gdlv


	Keyboard modifiers and mouse buttons

The work on gdlv lead to several features and fixes to Gio itself.

Package io/key gained support for the Ctrl, Command (macOS), Alt and Super (PC)

On Wed Dec 4, 2019 at 6:09 AM  wrote:
> 
> I need to pass a build tag `-tags sqlite`  to the build so I can build sqlite access into my app. It doesn't seem gogio take that info and therefore I can't access my DB from my mobile.
> I guess there must be more stuff to it (like CGO) but I don't know about that.
> 

That's just an oversight, and -tags should be easy to add to the `gogio`
command. Would you be interested in submitting a patch? I'm just about
the send out the December newsletter with instructions on cloning and
sending patches with a web-based workflow.

-- elias

On Tue Dec 3, 2019 at 9:25 AM Péter Szilágyi wrote:
> Hey Elias,
> 
> Thanks for the review comments. I kind of knew they are coming, just
> didn't have a good place to rationalize/discuss them (would be nice if
> sourcehut provided a means to add comment / questions outside of the
> patch commit description). I replied below, but the crux of my
> question revolves around making all the helper methods internal. I do
> understand the desire, but that entails the internal fields being
> converted to public. I can do that id that's what you want, but I'm
> not sure. Please advise.
> 
> > The users of Mul(tiply) must then switch the order if they need to.
> Hmmm, fair enough, maybe I'll then extend the comment a bit to

On Sun Dec 1, 2019 at 6:06 PM Péter Szilágyi wrote:
> Currently Gio has a simplistic transformation operation implemented
> that's essentially an offset vector. This is enough for many layout
> tasks, but falls short when animations come into the picture (e.g.
> spinner).
> 
> This CL replaces the current transform op with one base on affine
> transformation matrices, thus enabling advanced operations such as
> scaling, rotation and shearing.
> 
> Since it's expected that most UIs will not use (or use in very limited
> portions) the advanced transforms, the CL also special cases the offset
> use case, so both calculations and serializations using only translation
> will take optimized coda paths. This is handled under the hood.