digitalmars.D.learn - Dub and GtkD
- Russel Winder (37/37) Dec 21 2013 I just created a new vibe.d project using dub, all fine. Well once I had
- Jacob Carlborg (9/17) Dec 21 2013 I don't know if this is the issue in this case but Dub build everything
- qznc (8/47) Dec 21 2013 For some reason GtkD uses some unreleased version of Gtk with
- Mike Wey (6/46) Dec 22 2013 Just depending on the subpackage you need will stop dub from including
- Russel Winder (23/35) Dec 22 2013 .
- Mike Wey (7/30) Dec 22 2013 I don't think that would be a good approach with D, you either need a
- Artur Skawina (8/15) Dec 22 2013 It's not that bad; no compile time magic and zero runtime overhead is
- Mike Wey (8/23) Dec 23 2013 Those are generated from the gir files beforehand like GtkD is generated...
- Artur Skawina (22/41) Dec 24 2013 Didn't realize that. It kind of makes sense for a scripting language whi...
I just created a new vibe.d project using dub, all fine. Well once I had solved the libevent problem. Then, as the project is to be a GUI client, I added a gtk-d dependency. I tried building the empty project and the binary comes out at 42MB. Not only that there are two copies of it one in . and one in ./.dub/build. I was gobsmacked, this isn't Go, there should be dynamic linking by default. Is this something I have missed? There ought to be a clean target for dub as well as a build and run target for dub, or have I missed something? Re GtkD, when I run the "Hello World" vibe.d web server with GtkD doing nothing, I get: |> dub Checking dependencies in '/home/users/russel/Repositories/Git/Masters/Arcam= Client_D' Target is up to date. Skipping build. Running ./arcamclient=20 Listening for HTTP requests on ::1:8080 Listening for HTTP requests on 127.0.0.1:8080 Please open http://127.0.0.1:8080/ in your browser. object.Exception ../../../../.dub/packages/gtk-d-master/src/gtkc/Loader.d(1= 27): Library load failed: libgtkglext-3.0.so.0 Error: Program exited with code 1 In an earlier thread here, Mike Wey's response was "download libgtkglext and build it yourself". I am not sure this is the right approach. Debian packages GNOME 3 quite well but they do not have this libgtkglext-3.0.so.0 and yet things work. I think mayhap GtkD should have this as an optional dependency rather than a mandatory one. Or am I missing something? --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Dec 21 2013
Jacob Carlborg <doob me.com> On 2013-12-21 15:51, Russel Winder wrote:I just created a new vibe.d project using dub, all fine. Well once I had solved the libevent problem. Then, as the project is to be a GUI client, I added a gtk-d dependency. I tried building the empty project and the binary comes out at 42MB. Not only that there are two copies of it one in . and one in ./.dub/build. I was gobsmacked, this isn't Go, there should be dynamic linking by default. Is this something I have missed? There ought to be a clean target for dub as well as a build and run target for dub, or have I missed something?I don't know if this is the issue in this case but Dub build everything at once. The correct solution in this case would be to build GtkD separate from the application. This is planed in a future release of Dub, hopefully the next release. Have a look at this thread: http://forum.rejectedsoftware.com/groups/rejectedsoftware.dub/thread/652/ -- /Jacob Carlborg
Dec 21 2013
On Saturday, 21 December 2013 at 14:52:08 UTC, Russel Winder wrote:I just created a new vibe.d project using dub, all fine. Well once I had solved the libevent problem. Then, as the project is to be a GUI client, I added a gtk-d dependency. I tried building the empty project and the binary comes out at 42MB. Not only that there are two copies of it one in . and one in ./.dub/build. I was gobsmacked, this isn't Go, there should be dynamic linking by default. Is this something I have missed? There ought to be a clean target for dub as well as a build and run target for dub, or have I missed something? Re GtkD, when I run the "Hello World" vibe.d web server with GtkD doing nothing, I get: |> dub Checking dependencies in '/home/users/russel/Repositories/Git/Masters/ArcamClient_D' Target is up to date. Skipping build. Running ./arcamclient Listening for HTTP requests on ::1:8080 Listening for HTTP requests on 127.0.0.1:8080 Please open http://127.0.0.1:8080/ in your browser. object.Exception ../../../../.dub/packages/gtk-d-master/src gtkc/Loader.d(127): Library load failed: libgtkglext-3.0.so.0 Error: Program exited with code 1 In an earlier thread here, Mike Wey's response was "download libgtkglext and build it yourself". I am not sure this is the right approach. Debian packages GNOME 3 quite well but they do not have this libgtkglext-3.0.so.0 and yet things work. I think mayhap GtkD should have this as an optional dependency rather than a mandatory one. Or am I missing something?For some reason GtkD uses some unreleased version of Gtk with some OpenGL features. You can use the "normal/stable" variant by adapting your dependency a little: "dependencies": { "gtk-d:gtkd": "~master" } Not sure, why GtkD does this. There are also no versions, just "~master".
Dec 21 2013
On 12/21/2013 11:19 PM, qznc wrote:On Saturday, 21 December 2013 at 14:52:08 UTC, Russel Winder wrote:This is because the released version of GtkGLext doesn't support Gtk+ 3.x.I just created a new vibe.d project using dub, all fine. Well once I had solved the libevent problem. Then, as the project is to be a GUI client, I added a gtk-d dependency. I tried building the empty project and the binary comes out at 42MB. Not only that there are two copies of it one in . and one in ./.dub/build. I was gobsmacked, this isn't Go, there should be dynamic linking by default. Is this something I have missed? There ought to be a clean target for dub as well as a build and run target for dub, or have I missed something? Re GtkD, when I run the "Hello World" vibe.d web server with GtkD doing nothing, I get: |> dub Checking dependencies in '/home/users/russel/Repositories/Git/Masters/ArcamClient_D' Target is up to date. Skipping build. Running ./arcamclient Listening for HTTP requests on ::1:8080 Listening for HTTP requests on 127.0.0.1:8080 Please open http://127.0.0.1:8080/ in your browser. object.Exception ../../../../.dub/packages/gtk-d-master/src/gtkc/Loader.d(127): Library load failed: libgtkglext-3.0.so.0 Error: Program exited with code 1 In an earlier thread here, Mike Wey's response was "download libgtkglext and build it yourself". I am not sure this is the right approach. Debian packages GNOME 3 quite well but they do not have this libgtkglext-3.0.so.0 and yet things work. I think mayhap GtkD should have this as an optional dependency rather than a mandatory one. Or am I missing something?For some reason GtkD uses some unreleased version of Gtk with some OpenGL features.You can use the "normal/stable" variant by adapting your dependency a little: "dependencies": { "gtk-d:gtkd": "~master" }Just depending on the subpackage you need will stop dub from including the other parts of GtkD in your app. So this should fix your problem.Not sure, why GtkD does this. There are also no versions, just "~master".-- Mike Wey
Dec 22 2013
On Sun, 2013-12-22 at 12:58 +0100, Mike Wey wrote:On 12/21/2013 11:19 PM, qznc wrote:[=E2=80=A6]. OK so that is why it isn't in Debian. Does Fedora 20 or RPM Fusion have the pre-release as a package?For some reason GtkD uses some unreleased version of Gtk with some OpenGL features.=20 This is because the released version of GtkGLext doesn't support Gtk+ 3.x==20You can use the "normal/stable" variant by adapting your dependency a little: "dependencies": { "gtk-d:gtkd": "~master" }=20 Just depending on the subpackage you need will stop dub from including=the other parts of GtkD in your app. So this should fix your problem.OK, that can work for me. Python now uses the reflection approach to providing a Python binding to the API: PyGTK has given way to PyGobject. Has the PyGobject approach been rejected for GtkD staying with the PyGtk approach? I am currently rewriting a gtkmm application I had in GtkD and once a few problems of connectSignals is solved I am going to be loving it, thanks for keeping it going. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Dec 22 2013
On 12/22/2013 03:36 PM, Russel Winder wrote:On Sun, 2013-12-22 at 12:58 +0100, Mike Wey wrote:Not as far as i know.On 12/21/2013 11:19 PM, qznc wrote:[…]OK so that is why it isn't in Debian. Does Fedora 20 or RPM Fusion have the pre-release as a package?For some reason GtkD uses some unreleased version of Gtk with some OpenGL features.This is because the released version of GtkGLext doesn't support Gtk+ 3.x.I don't think that would be a good approach with D, you either need a whole lot of compile time magic, or loose type safety and do everything at runtime.OK, that can work for me. Python now uses the reflection approach to providing a Python binding to the API: PyGTK has given way to PyGobject. Has the PyGobject approach been rejected for GtkD staying with the PyGtk approach?You can use the "normal/stable" variant by adapting your dependency a little: "dependencies": { "gtk-d:gtkd": "~master" }Just depending on the subpackage you need will stop dub from including the other parts of GtkD in your app. So this should fix your problem.I am currently rewriting a gtkmm application I had in GtkD and once a few problems of connectSignals is solved I am going to be loving it, thanks for keeping it going.-- Mike Wey
Dec 22 2013
On 12/22/13 20:21, Mike Wey wrote:On 12/22/2013 03:36 PM, Russel Winder wrote:It's not that bad; no compile time magic and zero runtime overhead is possible: http://repo.or.cz/w/girtod.git/tree/gtk2:/gtk2 While I haven't updated those bindings in ~2 two years, they should still work; may just need some tweaks, to deal with recent d language changes and to support newer lib features. The biggest remaining issue is lack of integrated Cairo bindings. arturPython now uses the reflection approach to providing a Python binding to the API: PyGTK has given way to PyGobject. Has the PyGobject approach been rejected for GtkD staying with the PyGtk approach?I don't think that would be a good approach with D, you either need a whole lot of compile time magic, or loose type safety and do everything at runtime.
Dec 22 2013
On 12/22/2013 10:00 PM, Artur Skawina wrote:On 12/22/13 20:21, Mike Wey wrote:Those are generated from the gir files beforehand like GtkD is generated from the documentation (Moving to a gir based generator is on the TODO list, but time currently doesn't permit it). While with the PyGobject approach the bindings aren't generated beforehand but everything is done at runtime. -- Mike WeyOn 12/22/2013 03:36 PM, Russel Winder wrote:It's not that bad; no compile time magic and zero runtime overhead is possible: http://repo.or.cz/w/girtod.git/tree/gtk2:/gtk2 While I haven't updated those bindings in ~2 two years, they should still work; may just need some tweaks, to deal with recent d language changes and to support newer lib features. The biggest remaining issue is lack of integrated Cairo bindings. arturPython now uses the reflection approach to providing a Python binding to the API: PyGTK has given way to PyGobject. Has the PyGobject approach been rejected for GtkD staying with the PyGtk approach?I don't think that would be a good approach with D, you either need a whole lot of compile time magic, or loose type safety and do everything at runtime.
Dec 23 2013
On 12/23/13 19:30, Mike Wey wrote:On 12/22/2013 10:00 PM, Artur Skawina wrote:Didn't realize that. It kind of makes sense for a scripting language which does not care about performance at all[1]. It doesn't for a compiled language like D, where the equivalent would be to extract the gi/typelib data at /compile-time/. Which could be done via CTFE and mixins. But, as the lib i/f is very stable, it's much better to pay the conversion cost once and use a cached, pre-built version. The only advantage of parsing the introspection data at run-time would be that you could use a compiled D binary to access libs that it didn't know about at build time. Writing programs that use dlls w/o having any idea about the interface that those libs provide isn't exactly common. All checks would have to be done at runtime, which is what "loose type safety" meant, i guess. It didn't occur to me that somebody might want this functionality in a compiled statically typed language. Something that /was/ on my to-do list is a binary gtk-server like approach, that would allow decoupling the gui parts from the "core" application. In D this could be done transparently, with full type safety and negligible runtime cost (might still be cheaper than using gtkd). artur [1] If it did, it could just build (and cache) a bindings-dll on first use, avoiding ffi etc. Probably only matters in practice if you're already JITting the code anyway, as dealing with the args will be expensive.On 12/22/13 20:21, Mike Wey wrote:Those are generated from the gir files beforehand like GtkD is generated from the documentation (Moving to a gir based generator is on the TODO list, but time currently doesn't permit it). While with the PyGobject approach the bindings aren't generated beforehand but everything is done at runtime.On 12/22/2013 03:36 PM, Russel Winder wrote:It's not that bad; no compile time magic and zero runtime overhead is possible: http://repo.or.cz/w/girtod.git/tree/gtk2:/gtk2 While I haven't updated those bindings in ~ two years, they should still work; may just need some tweaks, to deal with recent d language changes and to support newer lib features. The biggest remaining issue is lack of integrated Cairo bindings.Python now uses the reflection approach to providing a Python binding to the API: PyGTK has given way to PyGobject. Has the PyGobject approach been rejected for GtkD staying with the PyGtk approach?I don't think that would be a good approach with D, you either need a whole lot of compile time magic, or loose type safety and do everything at runtime.
Dec 24 2013