Hi Brad,

I believe I've found your problem. See the comment inline below.

> package windowexample
>
> import (
> "fmt"
> "image"
> "image/color"
> "log"
> "os"
>
> "gioui.org/app"

On Thu, Apr 3, 2025 at 3:11 AM Brad Beveridge <brad.beveridge@gmail.com> wrote:
>
> Thanks for the tips!  One really weird thing about moving area.Pop()
> to the end of the function - the drag area is now accurate, but the
> dragging is no longer smooth.  The 'window' jitters around and
> generally appears to only move about half the distance it should.
> I've looked over the Slider code and I seem to be doing similar
> operations in the same order, so I must be doing something subtle.

Dragging has some subtlety for sure. The jitter you're experiencing
comes from the fact that your drag area is itself moving every frame,
so the "origin" of the motion is constantly changing. It can be really
tricky to compensate for this. One strategy might be to just define a
single global drag area at a level of abstraction above the window,

A couple of thoughts inline in your code. Definitely seems like you're
on the right track.

Cheers,
Chris

On Wed, Apr 2, 2025 at 3:22 AM Brad Beveridge <brad.beveridge@gmail.com> wrote:
>
> Thanks for the pointers.   Here's my little proof of concept.  The
> code that calls it places a button inside the 'window'.  I've stolen
> heavily from what I can find surfing the Gio code.  If you have time,
> I'd appreciate any review comments.
>
> Thanks!

On Mon, Mar 31, 2025 at 12:05 AM Brad Beveridge
<brad.beveridge@gmail.com> wrote:
>
> Hello!
> I would like to use a floating window layout, similar to the way that ImGui's floating windows work.  It feels like I should be able to combine op.Offset and some adjustment to the constraints of the context, but I'm struggling a little to get all the concepts together.
> Does such a floating window already exist?  If not, I'd appreciate and pointers of where to look to figure it out.

I don't think anyone has built this, but conceptually you can do it.
Record the contents of each "window" in a macro, with the contents
given a fake gtx.Constraints defined by whatever window size you want.
Then use op.Offset to place the origin of each window before replaying
its macro.

Cheers,

On Thu, Jan 30, 2025 at 8:28 AM Elias Naur <mail@eliasnaur.com> wrote:
>
> On Wed Jan 22, 2025 at 4:51 PM CET, ~whereswaldon wrote:
> > From: Chris Waldon <christopher.waldon.dev@gmail.com>
> >
>
> Thanks. A question below.
>
> > This commit allows inserting runs of style info into an editor/selectable with the new
> > AddRuns() method, and to a label via a new parameter in LayoutDetailed().
> > Runs will automatically adjust to edits (within an editor) in the following way:
> >
> > - if an edit occurs within a run, the run will expand/contract to keep the
> >   new contents inside itself.

On Thu, Jan 30, 2025 at 7:15 AM Elias Naur <mail@eliasnaur.com> wrote:
>
> On Mon Dec 23, 2024 at 2:37 AM CET, ~whereswaldon wrote:
> > From: Chris Waldon <christopher.waldon.dev@gmail.com>
> >
> > This commit fixes a bug in which ReadRuneAt would return EOF
> > *and* valid data when the cursor was sufficiently near the
> > end of the available data.
> >
> > Signed-off-by: Chris Waldon <christopher.waldon.dev@gmail.com>
> > ---
> >  widget/text.go | 4 ++++
> >  1 file changed, 4 insertions(+)
> >

On Thu, Jan 30, 2025 at 8:24 AM Elias Naur <mail@eliasnaur.com> wrote:
>
> On Sun Dec 22, 2024 at 8:50 PM CET, ~whereswaldon wrote:
> > From: Chris Waldon <christopher.waldon.dev@gmail.com>
> >
>
> Thank you very much for working on this. The parts look good to me, with a few comments
> below. My main gripe is the slice-of-runs API and the implied complexity.

Thanks for the review! Seems like there are a few high-level topics we
need to resolve:

- Should the shaper require pre-flattened runs?
- Should runs be expressed in relative or absolute rune positions?

> Thanks for doing this. FWIW, I'm weakly against tracking user-generated
> files in the repository gitignore. Should IDE files be added there as well?
> I find it better to just add them to my local (yet project-global) gitignore
> configuration.

That's fair; I've switched to this approach and dropped the ignorefile.

Cheers,
Chris

Thank you, merged with a tweak.

Cheers,
Chris

On Sat, Jan 25, 2025 at 9:11 AM zjzhang <zhangzj33@gmail.com> wrote:
>
> Text Shaper set the last empty line height to ascent+decent
> of the paragraph break glyph which causes the last visual empty
> line to have a smaller line height. This commit tries to fix it
> by setting the line height using the line height from the last line.
>
> References: https://todo.sr.ht/~eliasnaur/gio/629
> Signed-off-by: zjzhang <zhangzj33@gmail.com>

Hi Reto,

> Not sure if this was intentional, but you added a go.work file into
> the example repo (https://git.sr.ht/~eliasnaur/gio-example/) with
>
> commit cc20163cce554b5cbbc4b2cf0d988604af7de373
> Author: Chris Waldon <christopher.waldon.dev@gmail.com>
> Date:   Tue Jan 14 11:00:23 2025 -0500

:facepalm: It was not intentional. Thank you very much for bringing it
to my attention. I have removed it, added work files to the gitignore,
and tagged v0.8.1.

Thank you,