API Unification

[tknopp]

I think it is pretty complicated that Gtk.jl provides different APIs (regular and ShortNames). Have not seen this in any Julia package elsewhere.

Whats you opinion on that @timholy @vtjnash. Was there a specific motivation for this split in API.

I don't know what my actual proposal is, but to be consistent what other packages are doing probably the best would be making the ShortNames the default. One issue is that Julia base/core has a type Box that would conflict with the Gtk version of that.

[lobingera]

               _
   _       _ _(_)_     |  A fresh approach to technical computing
  (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.5.1-pre+2 (2016-09-20 03:34 UTC)
 _/ |\__'_|_|_|\__'_|  |  Commit f0d40ec* (103 days old release-0.5)
|__/                   |  x86_64-linux-gnu

julia> Box(4)
ERROR: UndefVarError: Box not defined

julia> box(4)
ERROR: UndefVarError: box not defined

julia> Base.box
(intrinsic function #0)

julia> Core.box
ERROR: UndefVarError: box not defined

julia> Base.Box
ERROR: UndefVarError: Box not defined

julia> Core.Box
Core.Box

so it looks like they are not exported?

[timholy]

I wasn't involved until after that choice was made, but my impression was that it was to increase familiarity for people who come from a Gtk background. I agree with your general point, however, and I suspect scoping + short names is the way to go. @vtjnash may have a different perspective, however.

[tknopp]

@vtjnash: It would indeed be great if you could give some input if you are fine with such changes. In particular a response to #263 would be great.

[tknopp]

@lobingera: It seems you are right.

[lobingera]

... i don't remember the reference (could be a github issue or a julia-users discussion):
use orginial names without the library prefix and prefix with julia module name: gtk_window_new -> Gtk.window_new ?

In any case it should be a notation which has a 1:1 mapping back to the Gtk c-API for easier lookup.

And generally i'd like to see Gtk.jl to be split into smaller, independent parts, like a Glib and Gdk module/package, so the library dependencies can be followed easier (Glib is not only a dependency for Gtk, but also for Cairo and Pango and...).

[tknopp]

Splitting up the package might make sense although this would need to be done by someone understanding better the low level bits of Glib and Gobject wrapping (i.e. not me!). My current focus would more be on the user API. I agree that it should be mostly a 1:1 mapping, which it already is in most parts.

[tknopp]

My thinking is that the Python wrapping of Gtk is a pretty good API. We cannot do it 1:1 since in Julia some things are not possible but still one can make it similar.

[vtjnash]

My suggestion would be to split this package into three concepts (packages):

1. support code (most of GLib/src)
2. purely autogenerated code run as a separate GI XML -> Julia source script (replace gen/ and src/GLib/gtypes macros). I agree this should likely look much more like the python wrapping.
3. purely hand-written APIs that leverages the autogenerated code (e.g. the Julia-level convenience wrappers and such that currently comprise most of Gtk.jl)

[tknopp]

Yes this sounds good. Though 2. and 3. could live in the same package, no?

The question is if the user should actually use 2. directly or if 3. should somehow forward to the lower level methods. This would allow us to fix the 0-based indexing somehow.

(minor thing: GI package not working #277 currently.)