Proposal: Change type of ResponseType & Co. to suitable golang primitive

[MJacred]

Problem

• e.g. adding button to dialog using func (dialog *Dialog) AddButton(buttonText string, responseId int) Widgetter
• want to pass a gtk.ResponseType
• expected: takes parameter
• actual: type error -> gtk.ResponseType is of type C.gint, not int

example

// this should work (but not on my machine: see note further below)
func (m *Something) Something() {
	// …
	m.dialog.AddButton("something", gtk.ResponseAccept) // where dialog is of type gtk.Dialog
	// …
}

// this does not work (see further below for more info)
func (m *Something) Something(response gtk.ResponseType) {
	// …
	m.dialog.AddButton("something", response) // where dialog is of type gtk.Dialog
	// …
}

the former is currently marked as an error in my environment (probably because it's not completely set up yet): cannot use gtk.ResponseAccept (constant unknown with invalid type) as int value in argument to m.dialog.AddButton. All cgo constants from gotk4 trigger this error, though only the first case is listed in the errors list

the latter causes the following error message:

cannot use response (variable of type gtk.ResponseType) as int value in argument to m.dialog.AddButtoncompiler[IncompatibleAssign](https://pkg.go.dev/golang.org/x/tools/internal/typesinternal#IncompatibleAssign)

Proposal

• change type of gtk.ResponseType & Co. to a golang primitive
• should have no downside: at least gtk.ResponseType is not used internally at all, only ever as int
• undesirable alternative: change parameter type in respective funcs to gtk.ResponseType -> horrible downside: no custom types possible, so let's not go there

[diamondburned]

There actually is a downside: a lot of weird constants in GIR utilize the fact that a gint is always 32-bit to do some cursed bitting, and using Go's int breaks that, because they're 64-bit. I've tried using int before.

The real issue here is GIR using gint for ResponseType instead of being its own enum type afaict.

[MJacred]

Hm… cursed

How about convenience funcs similar to func gobool(b C.cairo_bool_t) bool, but exported so that API users can access them?

[diamondburned]

Eh, that's more trouble than it's worth. I think it's probably better to hard-code a special rule where all parameters with the name responseId with type int will have a type gtk.ResponseType instead.

[MJacred]

Hm… while it can be somewhat annoying to not be able to create custom response types in more complex dialogs, one can design around it I guess

side note: I updated the issue description with a concrete example to showcase the exact issue/use case of the cannot use response (variable of type gtk.ResponseType) as int value error.
And included a separate error constant unknown with invalid type, which is probably due to my current setup

[diamondburned]

the former is currently marked as an error in my environment (probably because it's not completely set up yet): cannot use gtk.ResponseAccept (constant unknown with invalid type) as int value in argument to m.dialog.AddButton. All cgo constants from gotk4 trigger this error, though only the first case is listed in the errors list

Does this happen during development or build? It should build fine even with this error.

the latter causes the following error message:

cannot use response (variable of type gtk.ResponseType) as int value in argument to m.dialog.AddButtoncompiler[IncompatibleAssign](https://pkg.go.dev/golang.org/x/tools/internal/typesinternal#IncompatibleAssign)

Just cast it to int: int(response). You'll have to do the same for gtk.Response* constants too.

[MJacred]

Does this happen during development or build? It should build fine even with this error.

That was during development. A build shows an error which sounds more sensible:

vendor/github.com/diamondburned/gotk4/pkg/core/glib/paramspec.go:60:13: could not determine kind of name for C.g_param_spec_is_valid_name

That's why the IDE cannot find the type.
I need to upgrade my system first.

---

Just cast it to int: int(response). You'll have to do the same for gtk.Response* constants too.

Indeed… I thought I would need a more complex solution due to it involving cgo. Seems both errors have the same root cause, will close the issue.
Thank you!