Added GtkGLArea for Gtk3.

[kuldeepdhaka]

GtkGLArea was introduced in Gtk3 as part of library.
Earlier, (Gtk2) it was a separate library.

[kuldeepdhaka]

works for me.
gtk_gl_area got introduced in 3.16.7 https://developer.gnome.org/gtk3/3.16/api-index-3-16.html

[vtjnash]

Lgtm. Do you have an idea on how to get CI passing?

[kuldeepdhaka]

@vtjnash i do not have any experience with CI.
problebly i will do the conditional check and only perform loading of gtk_gl_area if the gtk version number is atleast 3.16.7

[lobingera]

@kuldeepdhaka , @vtjnash
The Travis details go
ERROR: LoadError: LoadError: Could not find gtk_gl_area in libgtk. This is likely a issue with a missing Gtk.jl version check.

maybe a wrong libgtk?

[kuldeepdhaka]

@lobingera hum, CI probebly has older version of libgtk (less than 3.16.7)

[tknopp]

@kuldeepdhaka: I am interested in this work. Did you test this with some actual drawing of OpenGL commands? Did you use the package ModernGL.jl for that?

[kuldeepdhaka]

@tknopp You can find the code in the PR file example/gl-area.jl
basically draw nothing, (black screen) and print different event received by the widget.

[tknopp]

thats was my point: in order to make this useful one would have to overload the render method and apply some openGL commands. And my question was, if you have already tried that.

@SimonDanisch: In Gtk one can embed OpenGL commands by implementing a function like the following:

static gboolean
render (GtkGLArea *area, GdkGLContext *context)
{
  // inside this function it's safe to use GL; the given
  // #GdkGLContext has been made current to the drawable
  // surface used by the #GtkGLArea and the viewport has
  // already been set to be the size of the allocation

  // we can start by clearing the buffer
  glClearColor (0, 0, 0, 0);
  glClear (GL_COLOR_BUFFER_BIT);

  // draw your object
  draw_an_object ();

  // we completed our drawing; the draw commands will be
  // flushed at the end of the signal emission chain, and
  // the buffers will be drawn on the window
  return TRUE;
}

Would it be staight forward to use all you GL packages with this or is your stuff tightly integrated with GLFW?

[SimonDanisch]

After a short glimps at GdkGLContext it seems like everything is in place to work smoothly ;)

Someone would need to port all these callbacks to retun similar signals for GDK.
And then I'd need to rewrite GLWindow a bit to work with contexts and signals created by another package.

Related:
JuliaGL/GLVisualize.jl#94

[tknopp]

Nice Simon. It seems that this requires some pluggable architecture in GLWindow, right?

[SimonDanisch]

It was created with modularity in mind, but time constraints and other priorities have compromised this noble goal so far ;) I'll gladly try to fix things up when someone has an example application ;)

[tknopp]

@vtjnash @timholy: How should we handle such APIs that are newly introduced into Gtk during the version 3 period.

Should we use a dynamic version check? I tried to call

ccall((:gtk_get_minor_version,Gtk.libgtk),Cint, ())

and this gives the minor version number that could be checked for.

[timholy]

Seems reasonable. Might be best to have something like

const libgtk_version = VersionNumber(
    ccall((:gtk_get_major_version,Gtk.libgtk),Cint, ()),
    ccall((:gtk_get_minor_version,Gtk.libgtk),Cint, ()),
    ccall((:gtk_get_micro_version,Gtk.libgtk),Cint, ()))

run early in Gtk's load sequence.

[tknopp]

@kuldeepdhaka: With #237 being merged you can now make a version check libgtk_version >= v"3.16.7"
Could you add this, which will then hopefully make CI happier?

[vtjnash]

How should we handle such APIs that are newly introduced into Gtk during the version 3 period.

a version check isn't really needed unless the API changed. Otherwise, the function call will just fail, so there's no real need to pre-declare the failure (maybe other than to add a comment to the docs that if you get a function-not-found, check the gtk version)

[tknopp]

Really? I thought that the Gtk type construction macros check within the lib to determine whether the symbols are there, no?
Other than that the version checks could be used to make the CI happy (where the tests are skipped if the Gtk version is not high enough)

[vtjnash]

oh right, it does use that information to build the supertype tree. well, nevermind me then.

[kuldeepdhaka]

done!

[tknopp]

Since CI is now happy I would merge if there are no further objects. Not 100% sure about the newly created examples directory. Until now we use the test directory and the documentation for theses things but I can see that it can be handy to have an isolated, runnable example file.

@kuldeepdhaka Have you used this for actually draw something?

[kuldeepdhaka]

@tknopp im not drawing anything.
the example print the width, height of GL surface and event.

[tknopp]

Yes I see that the example code does not draw anything. My question is whether you plan to use this for drawing something? Or did you just want to wrap the bindings to make Gtk.jl more complete?

[lobingera]

... i'd be interested in doing examples if the interface is functional ...

[tknopp]

@lobingera: That would be great. As a proof of concept this should be not to complicated. The documentation https://developer.gnome.org/gtk3/3.16/GtkGLArea.html#GtkGLArea-struct suggests that one signal_connects the render event to a render method and from that on it should be able to do OpenGL drawing. Next step would be integrating this with our OpenGL packages @SimonDanisch is working on.