major API changes

[vtjnash]

I'm am planning MAJOR api breakage for the next release version. Please tag existing packages as Gtk 0.1 0.6- to avoid upgrade headaches (including Winston.jl, ImageView.jl, ???)

1. constructors will be removed from all types, replaced by a function new which can be more easily generalized to construct anything in an inheritence-friendly way
2. the ...I suffix will be removed from interface types
3. the types that currently are referenced without an ...I suffix will be renamed to ...Leaf and will NOT be exported
4. abstract types will always be uniquely instantiated inside the GLib module (but @GType will generate the corresponding import GLib.newtype)
5. leaf types will always be (non-uniquely) instantiated inside the client library
6. deprecated getindex! alias to getproperty will be removed
7. any other deprecated stuff will also be removed (original enum declarations, exporting stuff not prefixed with G from using Gtk, like Window and Canvas)
8. I'm thinking of no longer automatically calling show in push! (ref. layouts forget to call show #30). Alternatives including calling showall in display, or just making the user aware of these functions

[timholy]

Thanks for the heads-up! Since the gtk branch of ImageView is not yet merged to master (I've been waiting for the "how do we handle the binary dependencies?" problem to be solved), people are kinda on their own anyway.

[bfredl]

Looks good, I also have thought the interface types to be the 'real' types. There is a question though, with multiple libraries implementing the concrete types: should client libraries still cooperate so that each GObject instance has mostly one juila wrapper, even when two libraries happen to define leaf types to the same GObject type? ( I guess with #47 we want this)

[vtjnash]

Yes, the idea is to allow libraries to provide custom behavior for the leaf type, while maintaining a common trunk of abstract types.

The primary reason I didn't initially introduce interface types as the 'real' type was the inability to add constructors to them. However, an appropriately named function new should make this feasible

[tknopp]

Would be interesting to see an example of how the API will be used after this change.

I am also for explicit show. Currently one sometimes has to do it and sometimes not. For instance when using the builder API one has to do an explicit show (obviously).

[vtjnash]

I'll make a pull request in a few hours which implements most of this

[vtjnash]

some of this happened, some did not, but various improvements were made

[tknopp]

@vtjnash So if I get this right we can now either use the macro syntax or the Leaf suffix, right? l ask because the examples still use the _new suffix. In README.md there is also still an example where _new is used.

[vtjnash]

thanks, i fixed the documentation. let me know if i missed anywhere else

[tknopp]

yes, the tests still use _new. I said examples in my last message but actually meant tests.
I have not yet found time to upgrade as I then have to upgrade Julietta.

[vtjnash]

i'm not sure how i missed that...fixed now

thanks again!