At the moment there's no support for other color spaces, but I imagine adding linear at least is reasonable.

In the meantime, you try converting your image into sRGB. If it's in linear format then see https://git.sr.ht/~eliasnaur/gio/tree/28c206fc78c7/internal/f32color/rgba.go#L28 how to convert it. It's a private package, but you can copy what you need.

• Egon

On Tue, Jul 19, 2022 at 9:18 PM Javier Hernandez Fuertes outgoing@sr.ht wrote:

Hello,

 I am trying GIO and it is a very interesting and impressive

project, but I am having a little issue when drawing images, they are shown 'darker' than the actual images are. I work with astronomical images and the lost is important. Is it related with working with a SRGB color space? Is there an option to use other color space?

 Sorry if the questions do not make sense, but I am newbie in the

subject. Thank you very much,

-- Javier Hernández Ingeniero de Bases de Datos Centro de Estudios de Física del Cosmos de Aragón (ceFca) http://www.cefca.es Plza San Juan Nº 1, Planta 2ª E-44001 Teruel (Spain) Phone: +34 978 221266 Ext.1105 Fax: +34 978 611801

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/436

I do agree with ~egonelbre, it's a useful feature but not frequently required and creating a separate repository where may be infrequent but useful and helpful gio widgets resides.

I think it has only come up a few times for me and, similarly, I've needed chamfered boxes. But, I don't think it makes sense to include all possible button variations in the core. Although, it might make sense to create a repository of "extra drawing primitives".

~egonelbre Huh, well I do feel like an idiot now. I'm not sure how I got that discontinuity in there, as I vetted this gradient when I generated it by writing it to an image and I didn't see it there. However, it's now clear that this is my problem somewhere. Thank you for taking a look!

The gradient definition looks wrong: https://go.dev/play/p/CK8hWEGAip4

From the values it already looks like a discontinuity:

{R: 0xf7, G: 0x82, B: 0x49, A: 0xff},
{R: 0xac, G: 0x16, B: 0x46, A: 0xff}, // <-- this is the first wrong color
{R: 0xfc, G: 0xa3, B: 0x59, A: 0xff},

• Egon

On Sat, May 21, 2022 at 12:59 AM ~whereswaldon outgoing@sr.ht wrote:

This simple gio program paints a gradient as 40 vertical rectangles, each with a unique color. However, it displays with a pattern of rectangles that assume the wrong color.

I've verified that the color data being fed to paint.ColorOp is definitely not the same for every 10th rectangle, so I don't know why this is happening.

Here is a screenshot. The discontinuity should be obvious. :D

This isn't a super high-priority issue, but I'm very confused. I hope eventually someone can help me make sense of this.

-- View on the web: https://todo.sr.ht/~eliasnaur/gio/416

For pixel-art or images based on measurements (e.g. spectrogram), it can be useful to use nearest-neighbor scaling instead of linear.

A proposal to add make it possible to change image scaling mode. One possible api:

img := paint.NewImageOp(img)
img.Filter(paint.FilterNearest)
img.Add(gtx.Ops)

Of course the API could be also implemented in other ways.

You can add them into a github gist or post them to some image sharing site. It's also useful to link to the source of the code, as it's quite often that people make mistakes when using the library. e.g. in this case there could be a mistake with regards to using unit.Px instead of unit.Sp. Although both disregard the image dpi.

sourcehut is rather minimalistic and mainly sticks to plaintext, with some markdown support.

An alternative approach would be to always use the cursor specified for the clip area that grabbed the cursor. This would avoid extra API.

Currently pointer.InputOp specifies Grab to prioritize input, however there's no way to specify a cursor for it.

As an example https://github.com/egonelbre/expgio/blob/973e0ace9c958c649a5cacd7b7aa4517b21de1a0/debug/drag/main.go shows a case where an area starts dragging another box. However, there's no way to specify the "pointer.CursorGrabbing" for that case. It would be possible to add some sort of overlay, however it might be nicer to have an additional GrabCursor in https://pkg.go.dev/gioui.org/io/pointer#InputOp, where pointer.DefaultCursor preserves the current behavior.

This would probably need to be also exposed as an argument on gesture.Drag.

~inkeliz which tool are you exactly using? I don't see materialdesign/icons showing up using goda weight.

Are you using a tool that examines the binary or a tool that examines the packages?