Be warned - this is a long post.
I've got GTK/VC9express running, so now I'm going
to write GTK bindings for my PILS language. Having
done wxWidgets bindings for this PILS version (and
...aaargh ... Win32 for earlier versions), I think
I have an idea of how the PILS/GTK bindings should
work, but the bare-C style of GTK is somewhat
foreign to me - though I got the impression that
what I want is feasible, I don't quite understand
how and I hope someone might shed a bit of light on
me by commenting this and telling me if I'm on the
right trail.
PILS has reference-counted memory and resource
management, and a global hash table for unifying
constants and alien (= gtk, wxWidgets, COM or
whatever) object wrappers. When their reference
count reaches zero, they are unlinked from the
hash table and released.
When an alien object (from GTK or wxWidgets or some
other universe) is passed to PILS, the hash table
is searched and if PILS already has a wrapper for
it, that wrapper is reused. If no wrapper exists, a
new wrapper is created.
In the wxWidgets version, PILS specialises the
wrappers by using rtti. Depending on the class
of the object, some wrappers free the object on
destruction, some don't.
Window wrappers (both top level and child) install
an event handler which has the double function of
marshalling events to PILS and blocking the wrapper
on window destruction, implementing a sort of weak
pointer, plus adding some other functionality. Such
weak wrappers get an extra PILS-internal reference
count and stay alive for the liftime of the window.
When a top level window is created by PILS code, a
"show" action is queued. When the initialization or
event routine executing the PILS code is left, the
windows it created are made visible. This prevents
the experimenting programmer from accidentally
creating hidden windows that get lost and don't get
closed.
With mostly auto-generated wxWidgets method call
marshallers and little information on ownership,
this was the best I could do, though I had to
provide special logic for sizers, menu items,
treeview items etc...
With GTK, I get the impression from the docs that
I will be able to create ownership-consistent
bindings in a generic fashion. Right???
Concerning ownership, I have the following ideas
but I'd much like to be corrected if they are bad.
- The general case:
When a GObject* is marshalled to PILS, I assume
it comes with a refcount hold - i.e. when the
wrapper is no longer referenced by PILS,
g_object_unref() should be called. Right?
If, when hashing the object, it is found that
PILS already has a live reference to this
particular object, it gets an immediate
g_object_unref() and the wrapper gets its own
(PILS-internal) reference count incremented.
(This is how I did COM interfacing in an earlier
PILS version. It worked well with COM. Am I
right in assuming it will work well with GTK???)
- Windows:
When a window is shown, the user or the
windowing system generally gets control of the
life time of the window. The user or some other
agent can close the window while PILS has live
references to it. I assume this will destroy the
window. (Or am I wrong here?)
With window/widget handles, I can see 4 paths to
follow (pros and cons are shown with + / -):
1. I can do like with the wxWidgets bindings,
treating all wrappers for windows and objects
owned by windows as weak references, queuing
the show operations (with GTK, I should perhaps
queue a combined realise&show???)
+ I can copy/paste from the wxWidgets bindings
+ window creation is generally safe
- I might loose some control - there might be
operations that should be performed after the
window is realised/shown
- I have to identify weak-referenced classes
beforehand, which may pose a maintainance/
extensibility problem
- I might have to provide for special logic for
menus etc.
2. I can treat windows and widgets as normal
references on creation, changing them to weak
references when they get shown or owned by
another object.
+ This might be more generic?
- Not quite sure how to define and implement it.
3. I can let the strong/weak-ness of a wrapper be
fixed at creation time, but independent of the
class. Top level windows will be created with a
delayed show and can't be hidden without
destroying them. Widget creation will be through
methods of their owners; their ownership is
fixed.
+ I think I know how to implement it.
+ Conceptually simple for the programmer
- may be too restrictive. What happens if one
and same widget is to occur in several pages
of a tab thing?
- I'm not sure how this works with menu creation
Do gtkPython etc. employ similar mechanisms? Do any
easy-readers exist that explain how these bindings
work?
I get the impression that the GTK designers thought
a lot about these matters and provided a lot of
functionality for dealing with them - but it is a
bit hard to read their thoughts behind all these
function specs.
One more thing:
Given a class name, a method name and some arguments,
what are the steps required to:
- create an object of the specified class,
- call the method with arguments on the object???
If you really got this far - thanks for your patience/Ole Nielsby
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
