Re: Remarks on gtk docs

[1 depikt net]

Hello Thor,

after this mishap probably caused by Pegasus (or a misconfiguration by me -
but so far i never heard from problems other addressees had) i'll use my
ISP's webmailer for this mailbox for a while.

"Battle" was an adoption from wikipedia's "browser war" - a bit superficial
of course. But there is chitchat about an uprising "economy of attention" - in
such an economy the concurrency of Gnome versus KDE is a bit more severe
than any academic pastime. Of course we already have advertisement as the
main income of google for instance - but many protagonists of the advertising
business are having doubts about the effectiveness of advertisement at all.
And the first task in establishing such an economy were to sanction  
advertising
lies severely. And their grips below the belt. As spam is dealt with already
today (and this is a feature of such an economy).

I guess moreover, that the common open source programmer is convinced  
of his work's quality. At least i am for my little Python tool  
thrases. And that she
wants to be read like any author of poetry - of course "read" means  
"used" here.

By the way: Thanks for your work with the Windows update. I didn't have those
great problems John Stowers reported. But a bad bug: When leaving an entry's
window from a "drag" for selection, the cursor remains the text  
insertion cursor
and doesn't work no more - only an arbitrary extra click reestablishes the
normal functions of the pointer. A bug 2.16.6 didn't have.

Yes - there are maintainance problems with gtk+ - serious maintainance  
problems.
Providing connect() in depikt i studied the standard method of gtk+ of  
course -
learning, that the use of closures and marshallers is only providing hooks in
comparision with g_signal_connect() and GCallback. And signatures we currently
do not need. Hooks - that means side-effects. Why not have the actions of
these hooks in the using code around my_object.connect() ? And - if needed
multiply - write a function around g_signal_connect() ? That is always
better readable, 100%. I won't probably support that with depikt, only  
if the simpler GCallback will be dismissed also. As the well-done  
simplicity of the
old Tooltips, which are deprecated now (which didn't show correct colours
though, as GtkTreeView::base[NORMAL] didn't too). And apparently we only got
bars as containers for widgets with tooltips instead (i might have missed
something here - i will still use the deprecated methods).

Thanks for reading, Joost