20110123: Some random notes on GTK and Pike
When building Pike from source, be sure to have libgtk2.0-dev installed (or equivalent on non-APT systems) first; Pike will then include the GTK2 module. I don't know what the GTK module is or where the differences are; maybe GTK is version 1.2 and GTK2 is version 2? Don't have Pike's GTK module on this system; presumably I would need another package to get the GTK1.2 dev before that would become available.
The GTK2.setup_gtk() function wants to be given argv. Presumably it then parses out the "standard GTK parameters" eg --gtk-debug; what does it do with the rest? Or do I have to consciously ignore any parameters that it's going to use?
TextView is an MLE, basically, although with a lot more capabilities than just straight multiline text. Needs to have an associated TextBuffer which stores the actual content. Querying the text in the MLE is buffer->get_text(buffer->get_start_iter(),buffer->get_end_iter()) and passing 0 for the iterators doesn't work.
For some reason, putting a TextView into a Vbox results in the TextView expanding as text is entered into it - even if it's not needing all its available space yet. Calling obj->set_size_request(0,0) makes it stay at its given size.
How do you do a simple listbox in GTK2? The Clist class isn't available.
Any X event will have a corresponding signal. This makes some odd constructs, such as that the "destroy" signal is when something's destroyed, but that "delete_event" is actually a cancellable request - on a window, that means that the user hit the cross.
Where's GDK2.Databox?? That thing looks cool!!
My project: Document all the classes and functions, in a nice readable way. Borrow layout ideas from a2z.inf from VX-REXX because, let's face it, for a dead product it's pretty good!
* Have a landing page that lists:
** Frequently used widget classes
** Frequently used non-displaying classes (eg Adjustment)
** Unusual widget classes
** Noninstantiable widget classes (eg Box), with links to their usual versions
** Support classes
* Have each class clearly and thoroughly document:
** Creation parameters
** Methods, with those created at the current level bolded (or if you like: Methods, including those inherited from other objects, with the latter shown non-bold)
** Signals, ditto
* For each method/signal, have a page. Obviously when a class inherits methods from the parent, it will link to the parent's version of the method docs. Capitalize on this by having each class in a directory, and its method files in that dir; whenever one is inherited, hovering the link will show where it's inherited from.
Docs error. Returns int (1 for success, 0 for failure) not iterator.
http://pike.ida.liu.se/generated/manual/modref/ex/predef_3A_3A/GTK2/TreeModel/iter_next.html