I will probably get flamed and people will hate me for this post. Oh
well...
I might be wrong on multiple issues, but..
my question(s) ..
Why is fedora using a (very) old version of PyGtk?
[freax@pluisje src]$ rpm -q pygtk2
pygtk2-2.2.0-1
[freax@pluisje src]$
If this is the wrong package-version, the package management systems of
Fedora Core 2 are wrong. It's a standard installation (upgrade from
Fedora Core 1). I have not forced anything.
- gtk.ComboBox is not supported at all
- gtk.Menu is not fully supported. I forgot which was missing but at the
end it was impossible to create a gtk.OptionMenu. I think the attach
method of gtk.Menu was not supported.
- Thus a gtk.OptionMenu cannot be created either. I really did not
succeed at this. I have more than four maybe five years experience in
Gtk+ development using C. If I cannot create a stupid ComboBox using a
specific language, it must mean the bindings with Gtk+ just .. suck.
- Which basically means that a read-only ComboBox is not possible unless
you hack a gtk.ComboBoxEntry using the get_child() of it to make the
entry (which is that child, I guess) in it read-only. This ain't HIG
compatible since ComboBoxEntry widgets should NEVER be read-only (as
there is a ComboBox-widget for that purpose). Yet this looks like the
'only' possible solution. Thats just incredible. I'm stunned about this.
- A gtk.ToolButton is not supported
- Therefor when using glade you cannot make a ToolBar that has
homogeneous buttons. This is impossible. I can't understand how this can
be impossible?? Again, I am stunned! You can set the homogeneous
property in glade, it won't work! You can try to get the button using
the get_widget function of glade, and force this property in code. It
will tell you that gtk.Bin has no such method. Thats probably because
gtk.Toolbar is not supported in the 2.2.x version of PyGtk thus it will
make a reference to a gtk.Bin as I guess gtk.Toolbutton inherits from
gtk.Bin. So for pythons libglade it's the closest match.
- The gtk.Toolbar has no support for the get_nth_item method. Therefor
it's also impossible (in glade) to get the nth button.
SO ... something very very basic and very simple ain't supported in the
PyGtk of Fedora Core 2:
self.toolbar = self.xml.get_widget ("toolbar")
self.toolbar.get_nth_item (0).set_homogeneous (gtk.TRUE)
How are we suppose to create HIG compliant system-config-* tools if such
simple things aren't possible? Do we have to just abandon glade so that
we then 'can' get some typical GUI properties of GUI elements right?
That would be ridiculous.
If I checkout the sources of the current system-config.* tools it really
does look like ALL those developments have been done by NOT creating the
windows with a toolbar in glade. Instead developers hard coded them to
do such stuff in Python. The efforts put in doing that, for EVERY
system-config-* tool, are MUCH greater that supporting a gtk.Toolbar in
PyGtk. I am ... *stunned*.
Do we have to include both platform invocation-code and glue-code
written in C to get such stuff working (in glade)? That would also be
ridiculous.
IMHO developers are loosing time finding hacks to get simple stuff
working.
The reference documentation of PyGtk does announce support for all these
things in version 2.4.x or higher. Why is the default Fedora Core 2
PyGtk package at version 2.2.x, if that version is incomplete. It's to
incomplete for serious userinterface development purposes.
My opinion on this is that if PyGtk at it's current version is incapable
of supporting these simple features, backporting features or using an
unstable version sounds like the only good solution.
... Or every single Fedora developer should be focused on getting a
stable PyGtk 2.4.x.
If THAT ain't possible, I suggest the Fedora team should accept
system-config-* tools that are _not_ written in Python using PyGtk. I
for one would love to use Gtk-Sharp or gtkmm for this purpose. I do like
Python now that I once used it to write a tool (that system- config-
schedule thingy). But seriously: The binding is lacking major
functionality. Without this functionality it's impossible or very very
difficult to create HIG compliant GUI's. This renders PyGtk, at it's
current stable version, unusable.
--
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
work: Philip dot VanHoof at cronos dot be
http://www.freax.be, http://www.freax.eu.org
--
Fedora-config-list mailing list
Fedora-config-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-config-list