pekim / gobbi

gobbi is a set of generated Go bindings for gtk et al.

This project is no longer actively developed. For a promising set of generated gtk bindings, take a look at https://github.com/diamondburned/gotk4.

gobbi

gobject bindings

gobbi is a set of generated Go bindings for gobject based libraries. There are bindings, with varying degrees of completeness, for gtk, gdk, gdkpixbuf, gio, gobject, and glib.

The intention is to provide the bindings required for writing gtk applications. So the focus is on supporting functions in the higher level libraries such as gtk, gdk, gdkpixbuf and gio. Much of the functionality provided by the lower level libraries, such as glib and gobject, is adequately supported in Go core packages.

example use

package main

import (
	"github.com/pekim/gobbi/lib/gtk"
	"os"
	"runtime"
)

func init() {
	runtime.LockOSThread()
}

func main() {
	gtk.Init(os.Args)

	window := gtk.WindowNew(gtk.GTK_WINDOW_TOPLEVEL)
	window.SetTitle("A window title")
	window.SetDefaultSize(300, 300)

	window.Widget().ConnectDestroy(func(_ *gtk.Widget) {
		gtk.MainQuit()
	})
	window.Widget().ShowAll()

	gtk.Main()
}

go get github.com/pekim/gobbi
go run -tags "glib_2.48 gdk_3.4 gdkpixbuf_2.32 gio_2.32 gtk_3.18" gobbi-simple.go

documentation

https://pekim.github.io/gobbi/

At a minimum it's probably a good idea to read at least the Getting started and Application lifecycle pages.

code generation

The code that implements most of the APIs is generated from the GObject Introspection (gir) XML files in the internal/gir-files directory. The generation code is in the internal/generate package.

All of the generated API code, and a very small number of manually maintained files, is in the subdirectories of the lib directory.

status

The library should be perfectly servicable and complete enough to build most applications.

Some simple example applications have been created, and may be found in the example directory. It is possible that for more complex applications some necessary apis may be missing.

The API is reasonably stable, although some changes are certainly possible.

The generation code is rather messy in some areas, and needs tidying up. The generated code is simple, and fairly readable.

gotk3

gotk3 is a more mature library than gobbi. It might be a safer choice than gobbi for those who are cautious. However gobbi should work just as well in most cases.

gobbi supports a larger number of apis than gotk3. However gotk3 supports some apis that gobbi does not, and vice versa.

gobbi is more type safe in some areas, notably the callbacks connected to signals.

gobbi's Issues

godoc missing api gtk.HeaderBarNew()

why gtk.HeaderBarNew() is missing from godoc

main_event_loop.go:55:10: undefined: SOURCE_REMOVE when running "Custom Drawing" Example Code

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.

Feature request: libhandy support

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

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

go modules: missing gtksource

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

callback function signatures changed

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 

Use girepository to invoke library functions

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.

showcase applications built using gobbi

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

could not determine kind of name for C.g_networking_init

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 👍

missing api gtk_text_buffer_create_tag()

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

Support connecting signals for a Builder

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.

Incompatible with gobject 2.62.4

lib/glib/v-.go:308:46: could not determine kind of name for C.G_KEY_FILE_DESKTOP_KEY_FULLNAME
lib/glib/v-.go:309:52: could not determine kind of name for C.G_KEY_FILE_DESKTOP_KEY_GETTEXT_DOMAIN
lib/glib/v-.go:310:46: could not determine kind of name for C.G_KEY_FILE_DESKTOP_KEY_KEYWORDS

How to extract element from GList

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.

Can not run go get github.com/pekim/gobbi/lib/gtk

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 ...

code generation error

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)

redundant code generation

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.

Use pkg-config to automatically generate build tags

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

nullable string parameters

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 :)