g_get_user_runtime_dir, used in func GetUserRuntimeDir() not available on my Debian 6 amd64

[asida]

after resolve GOPATH issue I've ended up with error:

cd /home/asida/go-gtk/src/glib pkg-config --cflags glib-2.0 gobject-2.0 pkg-config --libs glib-2.0 gobject-2.0 /usr/local/go/pkg/tool/linux_amd64/cgo -objdir $WORK/glib/_obj/ -- -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I $WORK/glib/_obj/ glib.go

glib

error: 'g_get_user_runtime_dir' undeclared (first use in this function) error: (Each undeclared identifier is reported only once make: *\ [install] Error 2

seems that fn g_get_user_runtime_dir' used in GetUserRuntimeDir is newer function, not available for my Debian version ??

A.

[bytting]

You are using debian stable?

[asida]

YEP stable with older GTK, after resolve glib by remarking particular row in source I've ended up with GtkComboBoxText error ;-(

I'm just curious why source contains comments that it should work even with older GTK...

[bytting]

I haven't been working that much with the code but it seems to me that a lot of functions used in go-gtk requires version 2.18, so if you don't have at least version 2.18 its probably going to be problems.

[asida]

squeeze stable has 2.20, so I have...

[bytting]

It seems the g_get_user_runtime_dir came in version 2.28 http://developer.gnome.org/glib/2.30/glib-Miscellaneous-Utility-Functions.html#g-get-user-runtime-dir

[asida]

I've disabled all ComboBox code in gtk.go and all packages compiled fine on my Debian 6. So I went into code and made changes to gtk.go and gtk.go.h....seems combobox for GTK2.20 - 2.23 is not implemented at all, just empty wrappers,.. I am I right ? also seems that GTK 2.24+ heavilly changed in ComboBox code and behaviour so it seems that mattn gets a bit lost here with his "wrap all" strategy....

This particular CxGo code mashup: C._gtk_combo_box_text_insert_text(COMBO_BOX_TEXT(v), gint(position), gstring(ptr)) IMHO, ISN'T definitelly good practice, code pattern, nor usefull ;-( it remains me C#.NET coding practices...nobody later can read WTF it means....

I think that this is quite better: C._gtk_combo_box_text_insert_text(v.GWidget, gint(position), gstring(ptr)) expecially when GTK has GTK_COMBO_BOX() and GTK_COMBO_BOX_TEXT macros

• one might remove some of _gtk.... wrappers as direct call is possible and there is no reason to wrap since it is internal implementation invisible to Go users

any comments to my desperate code research ?

[bytting]

About the macros, you can't type v.GWidget instead of COMBO_BOX_TEXT(v) You would have to type C.toGtkComboBoxText(v.GWidget) Thats why I made the macros. They make the code less verbose and makes it a lot more readable. Note that cgo doesn't make C preprocessor macros available in go so you basically have to make a C wrapper just to get to them, and thats when it starts to get ugly. Still, there may be better ways to go about things. I'm all ears.

About the empty wrappers I don't know. I never liked them either but I figured they had to be there to make things compile, even if they are not in use. But I may be wrong assuming that.

[asida]

corebob,

I've finally compiled tabby with go-gtk,... BTW nice, working example....but 6MB binary size,... probably because of lib static link in go.... I have some ideas to talk about....but lets finish my macros story for now ...

I've remarked COMBO_BOX_TEXT() and C.toGComboBoxText both and I changed all wrapper fn's _gtk_combo_boxtext..... to accept C.GTkWidget only (instead of newer ComboBoxText type) for all versions of GTK. This seems to be more native to GTK. Conversion from GtkWidget to GTK 2.24 ComboBoxText is made in C code in gtk_combo_boxtext..... call where I can use native GTK macros GTK_COMBO_BOX_TEXT for 2.24 and GTK_COMBO_BOX for 2.20 or just GtkWidget for older. This is easier to read code instead of hard mixing Go and C calls IMHO.....

but back to my silly idea,...6MB is damn horrible, unacceptable huge binary for tiny app as tabby is ;-(

I've started to think of some MVVM based framework that would not link 4.7 MB of GTK lib to each app, but only few kb of native Go serialize/deserialize-able GTK-like messaging objects (not GTK based, without gtk C code) Then another binary Go app with linked GTK C code, can act as mini gtkserver. All Go apps that wants to use GTK might use same mini "gtkserver". My small (client) app will exec() GTK mini server at startup and estabilish IPC with it. Then if GTK function needed, my Go app will send interprocess "request" to mini server as JSON (or GOB) message and server instance will handle GTK's...this can replace dll hell dynamic load....

regarding IPC, I've found that eg. chrome uses similar practices for GUI tasks, so IPC overhead is not so important.

this will create chain: goGtkClientApp-goGtkMiniServer-xserver-xclient,... but it can be funny ;-)

do you think that this can be aproach for libGtkGo (more standard name for go-gtk)?

[bytting]

About the macros: If I understand correctly you have generalized all the _gtk* wrappers to take widget pointers. Is that correct? If so, it sounds like a good idea. I suggest you make your own clone of go-gtk here on github and implement those changes on it, then make a pull request so that mattn (or me possibly) can review and accept it. Preferably in not too big chunks at a time

About the mini server: I have been thinking about doing something like this myself, and I think it is a pretty good idea. However, I would definitely implement it in C or C++ Linking and using GTK from Go is a pain, and it may also be inefficient due to unnecessary context/thread switching that cgo has to do behind the scenes. Even if this has been improved or fixed, it is still a pain to use go for this because of its strict type checking (compared to C) and its different "programming scheme" just does not fit the OO nature of GTK wery well.

Other than that I think its a great idea and I would definitely join such a project =)

edit: As far as I can see, implementing the mini server in C/C++ or Vala is the only way to avoid the big executables too

[asida]

macros: not to all, because I didn't want to spent so much time with this, I updated it for ComboBox only and code is easier to read and yes, I would suggest to update it everywhere.

I have to learn "how to" git and pull,.... I am only dumb Windows monkey ;-(, ... aware of HG....

miniserver: You probably can't write mini server in C because you'll spent all your life with it ;-(, Go client msg must be translated into GTK "language" by some high level lang as Go.... Even C++ isn't easy option...

Can you please give me some link to CGo context/thread issue ? I can't find anything about it except this bugtrack: http://code.google.com/p/go/issues/detail?id=3250

I think that thread switch is quite natural process and is not that problematic ??

[bytting]

-macros:

Using github, making clones and doing pull requests is really easy =)

-miniserver:

But if you write the miniserver in Go, and that miniserver has to link GTK, don't you get the big executables again?

-context switch:

Russ Cox said something about it here

https://groups.google.com/group/golang-nuts/tree/browse_frm/month/2009-12/245aa464c86058eb?rnum=31&_done=%2Fgroup%2Fgolang-nuts%2Fbrowse_frm%2Fmonth%2F2009-12%3Fscoring%3Dd%26&scoring=d

Its an old thread. Besides, even if a cgo call is similar to 10 native calls, it probably doesn't matter much in a GUI program, since user interaction takes oodles of time anyway.

[asida]

thanx for link, I'll have to read it more in detail to understand all.

I expect that miniserver will get very huge, but I think that we have to distinguish 2 things: 1.go app disc size 2.app mem footprint

simple mini server resolves #1, all apps written in go for GTK will get small and only one binary (miniserver) will be big

"advanced miniserver" (that can be done later) can be shared multithreaded process for all apps, this will resolve #2

GTK natively supports multithread (currently hidden in gtk-go) so it can even create thread per app = thus it can act as Xserver masquerade that serve functions for apps... #2 will be a bit more complex, but not impossible... BTW there is only on typical workstation there is only 1 Xserver, 1 Gnome, so why not have only one miniserver instance on top of it ;-)

what do you think ?

A.

[bytting]

Yea one server/daemon solves the problems, but writing a single server/daemon is complex and requires a high degree of stability.

Writing the server/daemon in Go is still more work than writing it in C or Vala I think. Using Go only means a lot of extra wrappers. The GTK job still have to be done in C. Also, writing the server in Go requires the use of C through cgo, but I think Vala is a better choice for GTK.

We also have to consider the possibility that Go gets a dynamic linker in near future. But, even if it does, using cgo is still a pain so having a server/protocol is not a bad idea if its done right.

Lastly, the question is if it would be better to build a new toolkit on top of https://github.com/BurntSushi/xgb That would be a big project, but it would be a good fit for Go. No need for using cgo at all, and no need for a server.

Its an interesting idea though.

[asida]

I never thought of real daemon, but just listener process that runs on demand, eg. when first request from any gtk go app and stops with last closed go gtk app....I agree that build daemon with go isn't easy.

xgb looks very nice, but for my mind it is to revolutionary ;-) I look at gtk with high respect and I admire their work very much... I think of gtk as of huge, very usefull, stable, well documented and live library of functions with future perspective. As example I might use my desktop. I use gnome dark theme and have installed german Softmaker Office that automatically use gnome dark theme as well as gedit, tabby, VirtualBox, calculator,..... so if anybody will try with xserver he must prepare such environment in Go as well and this must be accepted by others which is....hard.... and it might get impossible to hook up some langs to Go model, compare to old good C used by GTK.

I bet on GTK, lets meet xgb 20 years later ;-)

dynamic linker or interprocess is almost same when shared mem involved, +4 linker is that it hides all the dirt work in framework.

[mattn]

Hmm, this is interesting & serious issue.

[bytting]

Hi mattn. Long time no see =) And happy new year guys.

Ok asida, so you are saying one listener process for many Go clients. I agree that would save both HD and memory space. Also, I consider that a daemon. That's basically what a daemon does.

I also agree that GTK is complete and stable. But I am still not sure Go is a good choice for the listener/daemon.

If we had network channels it would be tempting, but I don't think we do. The only IPC we have with Go is sockets right?

[asida]

huh ;-(, I found these 2: http://www.gtk-server.org http://developer.gnome.org/glib/2.28/glib-IO-Channels.html

things, that might help. Glib is small enough to be static linked with all go apps (only GTK itself is huge) so if glib supports mem namedpipes it might work. I have to read it more in detail...

also gtk server can be worth to study, in Introduction they declare not only socket comm but also named pipes

[bytting]

Nice

[mattn]

oops.