On Fri, 24 Mar 2000, James Henstridge wrote:
You can currently do:
import gtk
gtk.GtkText()
That's what I do, currently wink. However, I feel to be saying the same
thing twice, which bothers me on a moral level.
I am more in favour of keeping the Gtk prefix, as this seems to be common
Moshe Zadka writes:
Well, I'm not sure how much breakage would be, but it's certainly not up
to James alone: Gtk+ 1.4 is sure to break code anyway. As PyGTK is still
young, I think there is still hope to fix those things...
Frankly, I have no idea how real Gtk+ 1.4 is. I've seen
Michael Lauer writes:
On Thu, 23 Mar 2000, Fred L. Drake, Jr. wrote:
Well, I'm not sure how much breakage would be, but it's certainly not up
to James alone: Gtk+ 1.4 is sure to break code anyway. As PyGTK is still
young, I think there is still hope to fix those things...
I
On Sat, 25 Mar 2000, Michael Lauer wrote:
On Thu, 23 Mar 2000, Fred L. Drake, Jr. wrote:
Well, I'm not sure how much breakage would be, but it's certainly not up
to James alone: Gtk+ 1.4 is sure to break code anyway. As PyGTK is still
young, I think there is still hope to fix those
Moshe Zadka [EMAIL PROTECTED] writes:
As long as you're breaking things anyway, let me suggest one change:
have the "Gtk" prefix stripped from the classes' names (GtkText - Text,
etc) [...]
For one, I would be happy to make that change, as well (partly because
I've not that much written so
François Pinard [EMAIL PROTECTED] writes:
Moshe Zadka [EMAIL PROTECTED] writes:
As long as you're breaking things anyway, let me suggest one change:
have the "Gtk" prefix stripped from the classes' names (GtkText - Text,
etc) [...]
For one, I would be happy to make that change, as
On Thu, 23 Mar 2000, Moshe Zadka wrote:
As long as you're breaking things anyway, let me suggest one change:
have the "Gtk" prefix stripped from the classes' names (GtkText - Text,
etc) and recommend that Gtk is imported via
import Gtk
And accesed via
Gtk.Text()
(Simillarily for
Moshe Zadka writes:
As long as you're breaking things anyway, let me suggest one change:
have the "Gtk" prefix stripped from the classes' names (GtkText - Text,
etc) and recommend that Gtk is imported via
[...]
I think (but am not sure) that James meant there would be *some*
breakage,
On Fri, Mar 24, 2000 at 01:03:58AM +0800, James Henstridge wrote:
On Thu, 23 Mar 2000, Moshe Zadka wrote:
As long as you're breaking things anyway, let me suggest one change:
have the "Gtk" prefix stripped from the classes' names (GtkText - Text,
etc) and recommend that Gtk is imported via
James wrote:
I haven't looked at the kde python bindings, so
can't comment on the quality of the bindings, or if I think their method
of wrapping is a good one (the current way pygtk and gnome-python is done
has its problems, which is why I am redoing parts of it).
Can you forsee if and to
On Wed, Mar 22, 2000 at 10:03:01PM +0100, Michael Lauer wrote:
Can you forsee if and to what amount these changes will break code which is
written now ?
As long as you don't use the low level gtk bindings (the _gtk module),
the impact should be minimal.
Matt
To unsubscribe: echo
On Thu, 23 Mar 2000, James Henstridge wrote:
There will be some changes necessary. I am moving some of the modules
around a bit to group them in a module. I am trying to keep things as
compatible as possible, but there may be small amounts of breakage. Of
course, gtk+-1.4 (or it may be
Howdy, don't want to start a flamewar (so
please don't comment on Qt/KDE itself), but
is someone amongst our little community who
has experience with the Python bindings to
Qt/KDE ? It seems to me that they're partly
automatically generated by some tool named
SIP (lightweight SWIG-alike). How do
The PyGTK bindings are not 100% hand crafted. A good deal of them are
generated automatically from a generic definition file. Work has
stared on a branch that will enable us to build even more of the
bindings automatically.
I've never found a tool that can do a complete wrapping 100%
The PyGTK bindings are not 100% hand crafted. A good deal of them are
generated automatically from a generic definition file. Work has
stared on a branch that will enable us to build even more of the
bindings automatically.
Hmm - I thought that especially the hand crafted stuff
do the most
On Wed, Mar 22, 2000 at 01:43:06AM +0100, Michael Lauer wrote:
Hmm - I thought that especially the hand crafted stuff
do the most work in hiding the naturally not object oriented
nature of the native GTK language - C.
Umm... nope. The object system in GTK+ wrapps quite well under
python.
16 matches
Mail list logo
