~rogpeppe


#117 widget/material: ProgressBarStyle can use non-normalized color 4 months ago

Comment by ~rogpeppe on ~eliasnaur/gio

Sure, combined with a StackOp.

I'm more thinking of widgets that are less abstract than ProgressBarStyle and render foreground graphics (e.g. text) on top of a background. In that case, you can't necessarily insert a StackOp around the drawing of the background, so using a transparent background could still be useful AFAICS.

#117 widget/material: ProgressBarStyle can use non-normalized color 4 months ago

Comment by ~rogpeppe on ~eliasnaur/gio

it's simpler and more robust to offer an OpacityOp that adjusts the opacity of subsequent drawing commands (treated as a layer).

But what if (for example) you wanted only the background of the widget to be transparent, rather than the whole thing? Does OpacityOp still work for that use case?

#117 widget/material: ProgressBarStyle can use non-normalized color 4 months ago

Comment by ~rogpeppe on ~eliasnaur/gio

What am I missing?

Yes, that approach is better. I took that from some code that wanted to set an absolute value of alpha, which is actually probably not a useful thing to do.

However, your multiplication will overflow (you need to use at least 16 bits for the intermediate result), and you'll want to do the same rescaling operation on c.A as you do on the other pixels.

Why wouldn't we want to allow transparent widgets?

#117 widget/material: ProgressBarStyle can use non-normalized color 4 months ago

Ticket created by ~rogpeppe on ~eliasnaur/gio

This may not be an issue in practice, but it looks wrong to me so I'm pointing it out.

In this code, are the following lines:

// Use a transparent equivalent of progress color.
backgroundColor := b.Color
backgroundColor.A = 100

The idea seems to be to make the configured colour transparent, but it has a couple of issues:

  • what if the configured colour is already transparent? This might make it less transparent, which is probably wrong.
  • RGBA colors should always contain pre-multiplied alpha values. If b.Color contains any color components that are more than 100, this result won't be correctly normalized.

Perhaps it should be using something like the following code instead?

func SetAlpha(c color.RGBA, a uint8) color.RGBA {
	if c.A == 0 {
		return c
	}
	c.R = mult(c.R, a, c.A)
	c.G = mult(c.G, a, c.A)
	c.B = mult(c.B, a, c.A)
	c.A = a
	return c
}

func mult(v, alpha, oldAlpha uint8) uint8 {
	nv := int(v) * int(alpha) / int(oldAlpha)
	if nv < 0 {
		return 0
	}
	if nv > 0xff {
		return 0xff
	}
	return uint8(nv)
}

#32 Sourcehut Pain Points 4 months ago

Comment by ~rogpeppe on ~eliasnaur/gio

One other pain point that I just encountered (technically not sourcehut's fault, but still a pain): the Go documentation website pkg.go.dev doesn't know about sourcehut so methods and types in the documentation don't link to the source code. This is a feature I usually use all the time when browsing documentation.

#114 example/glfw: build failure: "Package gl was not found in the pkg-config search path." 4 months ago

Ticket created by ~rogpeppe on ~eliasnaur/gio

I'm running on Ubuntu 18.04 (no Wayland) and I installed the dependencies mentioned by the top level documentation (apt install libwayland-dev libx11-dev libx11-xcb-dev libxkbcommon-x11-dev libgles2-mesa-dev libegl1-mesa-dev). The other examples seem to work OK, but I cannot run examples/glfw. It fails to build with this error:

% cd glfw
% go run .
go: downloading github.com/go-gl/glfw v0.0.0-20190409004039-e6da0acd62b1
go: downloading github.com/go-gl/gl v0.0.0-20190320180904-bf2b1f2f34d7
go: downloading github.com/go-gl/glfw/v3.3/glfw v0.0.0-20191125211704-12ad95a8df72
# pkg-config --cflags  -- gl gl
Package gl was not found in the pkg-config search path.
Perhaps you should add the directory containing `gl.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gl' found
Package gl was not found in the pkg-config search path.
Perhaps you should add the directory containing `gl.pc'
to the PKG_CONFIG_PATH environment variable
No package 'gl' found
pkg-config: exit status 1

I suspect I need to install some other dependency, but I'm not sure what. It would be good if the package doc comment in the example explained something about what the example is demonstrating and what system dependencies are required.

#113 add links to documentation from home page 4 months ago

Ticket created by ~rogpeppe on ~eliasnaur/gio

The gioui home page does not seem to link anywhere to developer docs about how to actually use gioui. If I go to pkg.go.dev and search for "gioui", I find the module, but it has many sub-packages so it's hard to know where to start. It would be great to have a very brief outline of some good places to start reading the docs for an overview where to start reading the reference documentation, and a pointer to any tutorial-tyle docs (if they exist).

An white-paper-style overview doc for the basic rendering model would be super useful.

FWIW I came here wondering "how can I display an animated bitmap image with gioui" and I'm still not sure where to start. I guess the only thing to do it trawl through the examples looking for one that seems similar, but that doesn't seem right somehow.

#20 consider another binary name 1 year, 16 days ago

Comment by ~rogpeppe on ~eliasnaur/gio

One plea: please at least consider a slightly longer name. The command name space is global, and there are many thousands names there already (I've got ~6000 commands in my path currently). When I see three-character command names, I know that I'll see them in a year and have no idea what that command is doing; likewise if I'm trying to remember the name, a name like "ago" isn't going to be easy to remember. Given that most people have command-line completion, I doubt there's a real need for a short name. Starting the name with "go" will at least make the completion suggestions decent for those that can't remember the specific command name.

"gomobile" didn't seem too long to me (is gio much different from the immediate-mode version of that command in fact?). Given that, perhaps "gobuildapp"? Or "gogui"?

#20 consider another binary name 1 year, 16 days ago

Comment by ~rogpeppe on ~eliasnaur/gio

Not only is gio taken as a command name, it is also used as a command when you open any file from the command line. The xdg-open command uses the xdf-mime script, which contains the following shell function:

info_gnome()
{
    if gio help info 2>/dev/null 1>&2; then
        DEBUG 1 "Running gio info \"$1\""
        gio info "$1" 2> /dev/null | grep standard::content-type | cut -d' ' -f4
    elif gvfs-info --help 2>/dev/null 1>&2; then
        DEBUG 1 "Running gvfs-info \"$1\""
        gvfs-info "$1" 2> /dev/null | grep standard::content-type | cut -d' ' -f4
    elif gnomevfs-info --help 2>/dev/null 1>&2; then
        DEBUG 1 "Running gnomevfs-info \"$1\""
        gnomevfs-info --slow-mime "$1" 2> /dev/null | grep "^MIME" | cut -d ":" -f 2 | sed s/"^ "//
    fi

    if [ $? -eq 0 ]; then
        exit_success
    else
        exit_failure_operation_failed
    fi
}

If you have the wrong gio in your path, then the script just succeeds silently and the wrong application is opened. So installing the Go gio command breaks opening files from the command line under Ubuntu Linux.

As an alternative name, how about go-gio ? Fundamentally, the command builds Go graphics programs, so the "go" prefix seems like it might be appropriate to me.

#2 document system dependencies better 1 year, 5 months ago

Ticket created by ~rogpeppe on ~eliasnaur/gio

The "quick start" docs say:

For Linux you need Wayland and the wayland-client, wayland-egl, wayland-cursor, and xkbcommon development packages.

It would be nice if this documented exactly the commands to run to install these dependencies under at least one common Linux variety, such as Ubuntu.

Just running:

sudo apt install wayland-client  wayland-egl wayland-cursor xkbcommon

fails for me with "Unable to locate package wayland-client" etc.

I'm not even sure whether I'm able to use gio on stock Ubuntu 16.04 which I'm currently running.