simple window example code fails to compile with gtk_3.22 (ubuntu 18.04)

$ go build -tags "gobject_2.56 glib_2.56 gdk_3.22 gdkpixbuf_2.36 gio_2.56 gtk_3.22" main.go
# github.com/pekim/gobbi/lib/gio
../../../go/pkg/mod/github.com/pekim/[email protected]/lib/gio/function-2.36.go:39:2: could not determine kind of name for C.g_networking_init

Using older versions works fine.

$ go build -tags "gobject_2.10 glib_2.48 gdk_3.4 gdkpixbuf_2.32 gio_2.32 gtk_3.18" main.go

Good job on the bindings 👍

There is no means of connecting signal handler functions to named signals in a builder description. This was initially mentioned in #9.

Use of gtk_builder_connect_signals_full is probably the way to go.
gotk3's approach in gotk3/gotk3#9 provides some inspiration.

Unlike gobbi's normally type-safe approach to connecting signal handlers this is probably going to have to connect the handler functions without regard to type-safety.

github.com/pekim/gobbi/lib/gio

../../go/src/github.com/pekim/gobbi/lib/gio/v-.go:1192:44: undefined: Converter
../../go/src/github.com/pekim/gobbi/lib/gio/v-.go:1197:43: undefined: Initable
../../go/src/github.com/pekim/gobbi/lib/gio/v-.go:1261:66: undefined: Converter
../../go/src/github.com/pekim/gobbi/lib/gio/v-.go:1280:58: undefined: PollableInputStream
../../go/src/github.com/pekim/gobbi/lib/gio/v-.go:1344:68: undefined: Converter
../../go/src/github.com/pekim/gobbi/lib/gio/v-.go:1363:60: undefined: PollableOutputStream
../../go/src/github.com/pekim/gobbi/lib/gio/v-.go:1461:41: undefined: MenuModel
../../go/src/github.com/pekim/gobbi/lib/gio/v-.go:4593:55: undefined: PollableInputStream
../../go/src/github.com/pekim/gobbi/lib/gio/v-.go:4675:57: undefined: PollableOutputStream
../../go/src/github.com/pekim/gobbi/lib/gio/v-.go:6429:51: undefined: ProxyResolver
../../go/src/github.com/pekim/gobbi/lib/gio/v-.go:6429:51: too many errors

NOt sure what I did wrong ...

Why do I get this error while compiling the "simple_window" example code in a new project module? Compiles fine when run inside gobbi/example/simple_window

$ go build -tags "gobject_2.56 glib_2.56 gdk_3.22 gdkpixbuf_2.36 gio_2.56 gtksource_3.24 gtk_3.22"
# github.com/pekim/gobbi/internal/generate
../../../go/pkg/mod/github.com/pekim/[email protected]/internal/generate/namespace-file-generate.go:21:6: file.NoFormat undefined (type *jen.File has no field or method NoFormat)

gtk_text_buffer_create_tag() is missing from the api. Is this unimplemented because of varargs?

Is there a list of applications built using gobbi? What application are you building?

Should be able to detect the installed package versions with e.g. pkg-config --modversion gtk+3.0

It appears that the "signal" callback function signatures have changed since the last time I played around with gobbi. There appears to be a redundant parameter targetObject introduced, which matches the "C" style non-object oriented API, but should not be necessary since the callbacks are passed to methods on the same targetObject.

For example in file lib/gtk/v-3.22.29.go

type WidgetSignalButtonPressEventCallback func(targetObject *Widget, event *gdk.EventButton) bool

func (recv *Widget) ConnectButtonPressEvent(callback WidgetSignalButtonPressEventCallback) int 

gtksource appears to be missing, while using gobbi via go modules.

cannot load github.com/pekim/gobbi/lib/gtksource: cannot find module providing package github.com/pekim/gobbi/lib/gtksource

The current generation code is unfortunately an unmaintainable mess. I had no idea when I started writing it how many parameter types and variations there were. Nor did I understand how many of the permutations would need to be handled. As a result I can't see a way to migrate the current code to a better place. I'd normally prefer to iteratively refactor code to improve it, but in this case I don't think that it's practical.

The generated code is also problematic in that it's very slow to build. This is mostly because of the extensive use of cgo. It's in every wrapping function, and there are many generated C functions for callbacks. This makes development of gobbi painful, with continuous rounds of code generation and slow builds.

It's difficult to move forward with the code as it is. Issues #16 and #17 are examples of cases where I struggle to work with the existing generation code.

I am looking at re-writing to use girepository for invocation of library functions.

Pros

• the generated functions that wrap library functions will be become simpler, and will not contain any cgo code
• the code that generates the wrapper functions will be simpler
• all cgo code will be in one or two internal packages
  • all of the complexity of the multitude of parameter types and variations will be in here
  • all of the marshalling of parameters between Go types and C types will be in here
  • all of code dealing with transfer of ownership will be in here
  • much of the code will be amenable to unit testing
• building will be much quicker

Cons

• there will be a small overhead on function calls
• unavailabilty of a library function (for example running an application on a system with older than required version of a library) will not be detected until it is first called

Initial work is proving promising. It will be at least several more weeks before it's in a reasonably useable state.

https://source.puri.sm/Librem5/libhandy

Would be nice if bindings to libhandy could be generated for gobbi.

why gtk.HeaderBarNew() is missing from godoc

Some Gtk functions take string parameters that can be null, such as the one below.

GtkWidget * gtk_frame_new (const gchar *label);

Creates a new GtkFrame, with optional label label . If label is NULL, the label is omitted.

In the above case we are unable to omit/disable the label widget, as we are unable to pass NULL to the C function.

Gobbi's implementation currently does'nt take into account the nullable string parameters.

func FrameNew(label string) *Frame {
	c_label := C.CString(label)
	defer C.free(unsafe.Pointer(c_label))

	retC := C.gtk_frame_new(c_label)
	retGo := FrameNewFromC(unsafe.Pointer(retC))

	return retGo
}

The Gotk3 library handles this correctly.

func FrameNew(label string) (*Frame, error) {
	var cstr *C.char
	if label != "" {
		cstr = C.CString(label)
		defer C.free(unsafe.Pointer(cstr))
	}
	c := C.gtk_frame_new((*C.gchar)(cstr))
	if c == nil {
		return nil, nilPtrErr
	}
	obj := glib.Take(unsafe.Pointer(c))
	return wrapFrame(obj), nil
}

The Gir files do indicate nullable parameters (nullable="1"). So code generation should be possible.

<parameter name="label"
           transfer-ownership="none"
           nullable="1"
           allow-none="1">
  <doc xml:space="preserve">the text to use as the label of the frame</doc>
  <type name="utf8" c:type="const gchar*"/>
</parameter>

Would appreciate if you could get this working and a possible workaround if possible until then :)

This is a wonderful project, thank you for investing time into working on this. I'm interested in learning more about GTK and expanding my knowledge so I was experimenting with this and other Go and C GTK software and in my tests I ran into the following error:

$ go run main.go 
# github.com/pekim/gobbi/lib/glib
../../pekim/gobbi/lib/glib/main_event_loop.go:55:10: undefined: SOURCE_REMOVE

I think this is a simple bug fix, I can submit the pull request to fix it if its not already done locally on your machine.

I notice that the binding generation in Gobbi is not incremental for newer versions of the Gtk library. I have not run the code generation tool myself, but it appears to be a lot of work to regenerate the same bindings over and over for different versions.

While going through the Gotk3 codebase, I found that their binding files are named *_since_<version>.go and only newer API's are found in the newer version file.

gtk_since_3_22.go
gtk_since_3_20.go

And the version selection during build is done using Inverted selection.

// +build gtk_3_6,!gtk_3_8,!gtk_3_10,!gtk_3_12,!gtk_3_14,!gtk_3_16,!gtk_3_18,!gtk_3_20

I understand that Gotk3 is manual bindings, but is there anything holding us back from going incremental and lessening the burden during binding generation.

I am confused as to how to extract the GtkWidget element held inside the GList returned by gtk_container_get_children(). Any help would be appreciated.