Hello,
this will be a long text. Parts of it have been circulated in my brain since
many months - i must do this. Please keep in mind, that i do not want
to offend anyone, my username "viciousdog" on sourceforge is nothing else
than a warning.
python/gtk/sqlite has been chosen as the ("virtualized") poor man's computer
by OLPC. I learned that after i had chosen this platform myself.
Continuing to read this, some of you might want to respond: "Then write
documentation yourself !!" - but i cannot. Living in a country, where a labour
politician has reintroduced forced labor recently i really have no time for
that.
I'd really like to write 10-20 pages about rc syntax, but what will come
below must be enough for the moment.
I will continue to write for this platform and make improvals of it for my
own use. Working on my pygtk alternative depikt i learned that the promise
of easy interfacing with other languages (than C) is not empty. Then there
is gdk.Pixbuf and the integration of the well-designed pango and cairo. The
latter must have been a bit painful for the authors of the
gimp-tk - many thanks for that ! And thanks for the introduction to
widget construction.
But that is all, what is really good in gtk.
Beginning my work on that software, which helped me to survive as an
intermediary internet dealer and beginning to use gtk i searched border-width.
>From the promise of high-quality-surfaces i was sure to find all what
tcl's TK - designated as "poor" by many programmers - has too.
You know, what followed. I learned that border-width means margin-width
with gtk, but that was of course no reason to continue searching. The
inevitable result: Hours of senseless pain. I am probaly fairly dumb
(i've met really better brains in my life playing bridge for example) -
on the other hand i am someone capable of learning Python's infamous
C-.API and to make depikt.
Yes, you can make high-quality-surfaces with gtk. You can determine every
pixel of your widget, if you want. But the way thereto is nearly not documented
at all. And the standard equipment is leading to surfaces as gnumeric has -
reminding me at GEM on the Atari ST.
During 3 years the documentation of gtk and gtk itself has never ceased to cause
this kind of pain. It is my fourth GUI-builder - and what is in the tutorial is
100%
useless in such a situation. No word about the style sharing, no word about the
needed full path to a widget's name in rc files, (probably) no word about
property-notify events, no word about what "Style properties" in the
references mean ... These thousands of pages have caused a lot of work on
your side - with about 100 good pages they were as useful as they could and
should be as the result of so much work
Only last week i learned that the "GtkEntry::cursor-color" in
GtkEntry::cursor-color = "DarkGrey"
is necessary - or is it not ? Again in a session fighting rc syntax with pain.
No chance at all to get to fluid writing with this beasty material. That comes
absolutely unexpected, after all we will link the style, where it is in, to an
entry
(and we absolutely should, when we want to produce well maintainable
software) thus it looks redundant on the first view.
What i had to learn in November under pains also is, that you have to
write the full path to the widget down in lines like:
widget "OKambaDialog.outer_bd.inner_bd" style
"st_dialog_inset"
"OKambaDialog" is necessary here - again deviating from what
contemporary programmers know from CSS's id versus class.
And if someone is prepared to this difference to class, he would
probably expect this whole path with "class", not with "widget".
And i had found it somewhere on library.gnome.org - yes it is documented.
But not at the prominent place, where it has to. This must be in one
of the first paragraphs on .rc files everywhere.
gtk authors will have had reasons for this ideosyncratic behavior of "widget".
>From the first look it appears as nothing as another weakness - and
that is, what i want to state as the second main point here: The documentation
must be more honest to be well usable. These days i begin to make
the User Manual for my commercial OKamba. I will cut off any try of
pseudo-objectivity there and use a lot of "i"s (hopefully not too penetrant)
using it for advertisement with the same move. But i will speak of more than one
weakness of OKamba there - and prevent useless searching of the users so.
The gtk docs - without any need - do so nowhere :(
That is a sure way to loose the battle against QT.
Yes, still i will continue to work with gtk. Here is what i wrote on depikt.net:
"""
With much more time i'd very like to make a simplified python-connected gtk,
dismissing the outdated painting methods of gdk (since some years obsoleted by
cairo inside gdk), some outdated features in imitation of X11 (as ... pixmaps),
the styles sharing, properties at all, and would let it work with python
classes
instead of glib. But that will probably stay one of my dream projects.
Unfortunately i
am no wizard at coding, not at all.
Some code of depikt, providing Python support for about 15 widgets, gdk.Pixbuf
and something else is on sourceforge.
A note on properties: They describe side-effects of attribute assignment. And
side-
effects are bad. Functional programming languages advertise with the
impossibility
of side-effects of their functions and nobody is vetoing. While nothing is
wrong with
only public attributes and methods as in Python a class should nevertheless be
usable as a black box, its programmer should not require reading its code by
the
class's user (this is no less true, if this user is she himself).
Best usable are those classes with attributes independent of each other. This
is
common sense for databases, where normalization is widely accepted as
desirable. But so far i've never met discussions on "orthogonalization" of
attributes
in OOP ....
Sometimes properties are useful, it is correct to have them in a programming
language. But they should be the exception. And assignment to a property should
be differenciated from assignment to an attribute in the calling code.
With GUI-builders it is very useful, when modifications of attributes or
variables can
be made to events. The callback connected to the corresponding signal makes the
attribute to a property then. Providing a general mechanism in the GUI-builder
for
doing so with any kind of variable or attribute is fine - but making all
attributes born
properties for that is bad and slothful design.
"""
(Yes - i am megalomaniac enough to state, that the method/attribute unification
in SmallTallk - and the recommended use in ObjectiveC - is the wrong track).
That "slothful" is too hard probably. Methods are easier to interface with
objects
of other languages than attributes - that might be a reasonable case for that
preference of properties in gtk.
At last a word to the "Read the sources" garbage read on this list too. It is
in no way specific to gtk.
We all know, that reading code is more difficult than writing code. An author
of software requesting "Read the sources" does wrong thus and
damages his work: After all that means, that the asking part would
do better writing what is in question himself (as i do with my depikt).
Thus "Read the sources" must be combined with a hint to the focal
files and object names of the matter in question, otherwise it is mere arrogance
helping nobody (in the full sense of the word arrogance, stated in full
conscience
of the difference between arrogance and self-confidence) helping nobody.
And now: Good luck and success, viciousdog
_______________________________________________
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
