Re: Remarks on gtk docs

[Joost <1 depikt net>]

Hm - not fully.

I've used TK with tcl 1995-1999 writing software to handle plain
TeX on Linux. And nearly every Python programmer is using it in the
Tkinter form, when making the first steps in Python (which by its readability is well fit to large projects - far more than a better tcl or php). I turned away from it, because it has no tabular widget and from my kind of perfectionism - in my eyes it's unbearable, that TKinter
is internally starting tcl. And i have some C++ experience with XView (long ago and not with exact remembrance enough to compare). No, when
you have alleged to the Qt i've mentioned, that is not, what i meant.

And gtk 2.18.6 currently has the following bug on my system: Leaving
entries the pointer icon is remaining the text icon and the pointer
only functional after any extra click. Besides the pointer gets
sometimes invisible when over the application of the left entry.
With focus handling at all one can have all sorts of catastrophies,
especially dysfunctional focus chains. The key-release-event with
tab definitely goes to the next widget. 

When one wants live editing of TreeView cells from an outer entry widget
(a quite normal Excel function) connected to marked cells there is the
problem, that sorting by that column stays active and every new letter
causes sorting without the selection moving along. Thus you write into
other cells after each letter. I found no way to turn off column sorting
on enter-events (and turning on on leave-events) for that entry widget - gtk has the methods for that, but the code didn't work reliably.

The letters inside the table's cells must be as small as possible, as 
long as they stay comfortably readable, because as many lines as
possibly should be on the screen. They are too small for comfortable writing then (that means especially: For setting insertion points with
the pointer comfortably). This has be overlooked by the
programmers, who have provided the default way of cell editing - let
alone support for editing some number of cells (to the same content)
simultaneously. Misdesign.

The missing feature, that sorting of a column cannot regularly made with
a one-way-action without changing any state of the column is so bad, that i consider that as a bug. It would have been so easy to provide this. This is no proposal, as soon as i have some 40 hours to spare, i
will write my own table for depikt (without any cell renderer, drawing on
an unparted surface. Framing of cells for example is easy so). The Python model is finished meanwhile. Gtk is probably better as a
widget builder than as a GUI-builder.

The bugs around keyboard focus are bugs with basic behavior and demonstrating, that there is no core of reliable code established. "... as if it has some sort of fundamental problems ..." - yes, i write so
(but not with every single problem, let alone question), but not in any
"as-if"-pose. The entry-leaving error is not in pygtk - currently i have
switched back to gtk-2.16 with the same pygtk, there it doesn't appear. Besides: That is nicely easy from the ambulance of gtk - just renaming of directories (my Python apps set the PATH themselves).

It is on Windows - and that should be the platform of main interest.
Because Xlib abstraction with gdk is useless on Unix - there alone
it were just idling. The XProtocoll also could provide interfacing with
non-C-languages, would Xlib be under the hood of gtk, not gdk.

This is about tables and focus chains, about bureau software. What your
beautiful DAW is using, might be from better parts of gtk. No, really no 
"as-if"-pose, but i might have misunderstood you.

Thanks for reading, Joost