Re: [pygtk] PyQt/PyKDE Bindings
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 things... > > I can't find anything about future Gtk+ versions on www.gtk.org - where > do you got these information from ? > Owen Taylor and Tim Janik gave a good talk about what will be in gtk+-1.4 (or 2.0, as it may be called when they release it) at GUADEC. The slides for their presentation are available at: http://people.redhat.com/otaylor/gtk/guadec/ You could also look at the gtk-devel-list archives, as the future of gtk is often discussed there. James. - To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
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 can't find anything about future Gtk+ versions on www.gtk.org - where > do you got these information from ? The text you quoted was actually from Moshe; I've asked him the same as you have! -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives - To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
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 references, mostly in the Gnome world, but www.gtk.org is a little short on anything but the 1.2 material and freshmeat announcements. Is there a Web site where Gtk+ 1.4 develpment is reported on? I'm interested in overview material, not CVS checkins. > In the mediaveal times I used Tkinter, my code usually started with > > import Tkinter;Tk=Tkinter;del Tkinter Mine as well. But I've matured; I just stop at "import Tkinter" now. Too many people were confused by the renaming when they went to read the code. (No, I really don't understand that) -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives - To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
On Sat, 25 Mar 2000, Michael Lauer wrote: > > On Thu, 23 Mar 2000, Fred L. Drake, Jr. wrote: I wrote that, not Fred. Please try to attribute correctly > > 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 can't find anything about future Gtk+ versions on www.gtk.org - where > do you got these information from ? Well, I think I read something there. Anyway, sheer extrapolation will also work -- see the distance between 1.2 and 1.4 -- Moshe Zadka <[EMAIL PROTECTED]>. http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com - To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
Wow - It's now getting really far from my original question... (by the way, really no one with experience with both the QT/KDE and the GDK/GNOME bindings to compare and comment ?), however: > 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 can't find anything about future Gtk+ versions on www.gtk.org - where do you got these information from ? -- Regards & Gruesse from Mickey @ http://www.Vanille.de - How could anyone know me - when I don't even know myself ? - To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
On Thu, 23 Mar 2000, Fred L. Drake, Jr. wrote: > 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, not *lots* of breakage. 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... > As it stands, my PyGTK code always does: > > import gtk > w = gtk.GtkWindow() # or whatever Mine too... > I don't mind the leading Gtk prefix, but wouldn't mind seeing it go, > either. If the expected breakage isn't too bad, I'd keep it as-is. > What I *really* want to see go is code that does > > from import * > > for any value of . +1 on that. > (same for Tkinter, which should be named tk > or, at worst, Tk). In the mediaveal times I used Tkinter, my code usually started with import Tkinter;Tk=Tkinter;del Tkinter ah-the-memories-ly y'rs, Z. -- Moshe Zadka <[EMAIL PROTECTED]>. http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com - To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
On Fri, 24 Mar 2000, James Henstridge wrote: > You can currently do: > import gtk > gtk.GtkText() That's what I do, currently . 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 > in some of the other language bindings (even the java bindings kept the > Gtk prefix when the classes were in a gtk package). But in Java importing things into the current namespace is much more common then in Python... > Most of your > application is made up of manipulating widgets, rather than constructing > them, so the extra three characters is not that much of a problem. Well, I'm not that worried about RSI: more about asthetics, as it seems we're using C's shameful hack for a namespace (common prefix) in a language with the best (IMHO) namespace mechanism in the world . It's not that important to me, though... waiting-for-the-next-pygtk-version-ly y'rs, Z. -- Moshe Zadka <[EMAIL PROTECTED]>. http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com - To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
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
>
> I am more in favour of keeping the Gtk prefix, as this seems to be common
> in some of the other language bindings (even the java bindings kept the
> Gtk prefix when the classes were in a gtk package). Most of your
> application is made up of manipulating widgets, rather than constructing
> them, so the extra three characters is not that much of a problem.
I rather liked Moshe's proposal because it supports the "principle of
least surprise". This is especially important when there's any chance
of name collision. The issue of three vs. four character prefix,
("Gtk" vs. "Gtk."), seems to be too small to be a consideration.
--
Randolph Bentson
[EMAIL PROTECTED]
-
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
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, not *lots* of breakage. As it stands, my PyGTK code always does: import gtk w = gtk.GtkWindow() # or whatever ... I don't mind the leading Gtk prefix, but wouldn't mind seeing it go, either. If the expected breakage isn't too bad, I'd keep it as-is. What I *really* want to see go is code that does from import * for any value of . This just makes code hard to read. Short, lowercase module names are always best, and they can really make the code more readable. There should be no recommendation that the "import *" form be used (same for Tkinter, which should be named tk or, at worst, Tk). So there. ;) -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives - To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
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 Gnome/GnomeUI) > > It seems much more Pythonic then > > from gtk import * > > GtkText() > You can currently do: import gtk gtk.GtkText() I am more in favour of keeping the Gtk prefix, as this seems to be common in some of the other language bindings (even the java bindings kept the Gtk prefix when the classes were in a gtk package). Most of your application is made up of manipulating widgets, rather than constructing them, so the extra three characters is not that much of a problem. > > -- > Moshe Zadka <[EMAIL PROTECTED]>. James. - To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
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 > > import Gtk > > And accesed via > > Gtk.Text() > > (Simillarily for Gnome/GnomeUI) > > It seems much more Pythonic then > > from gtk import * > > GtkText() I'm in 100% agreement - "import *" is kind of nasty. I'd gladly change code to get around this. Also, the required edits could most likely be automated, and if we really wanted we could make a module "oldgtk" or something to ease the transitions: oldgtk.py: import Gtk GtkText=Gtk.Text ... Then people could do "from oldgtk import *" and have their old code work. - To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
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 well (partly > because I've not that much written so far :-). ... > I'm not sure of anything, beside the fact I would like to turn > `GtkText' into `Gtk.Text'. That would be definitely cool. I tend to write `import gtk' rather than `from gtk import *' for two reasons: * It's a good idea in general to avoid `from FOO import *'. Many modules tend to clash in names, e.g. re.split and string.split, etc. * gtk specifically exports a whole bunch of unprefixed names. For example, I really don't want unadorned TRUE and FALSE in my namespace. Having said that, I often note that gtk.GtkWindow looks sort of ugly. In an ideal world, we'd be able to write: import gtk w = gtk.Window(...) w.set_foo(gtk.TRUE, ...) And so on. - To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
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 far :-). However, should we write `Gtk.FILL' instead of `FILL'? Just from an aesthetical viewpoint, since we already use `GDK.' to prefix GDK constants, maybe we should import GTK and write `GTK.FILL', or just `from GTK import *' if we like to stay terse with GTK constants. The need of another import might be unwelcome, but on the other hand, `import gtk, GTK, GDK' is easy to write on one line. I'm not sure of anything, beside the fact I would like to turn `GtkText' into `Gtk.Text'. We might even guess that `pygtk' intensive applications/users would like `from gtk import *' still, and just use unprefixed `Text'. What is not nice is having the module name repeated in module objects. -- François Pinard http://www.iro.umontreal.ca/~pinard - To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
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 called 2.0) is comming up as well, which > will cause some breakage. It may be possible to synchronise the > changeover so you only need to change your code once. 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 Gnome/GnomeUI) It seems much more Pythonic then from gtk import * GtkText() -- Moshe Zadka <[EMAIL PROTECTED]>. http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com - To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
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 called 2.0) is comming up as well, which will cause some breakage. It may be possible to synchronise the changeover so you only need to change your code once. I am not trying to gratuitously break things though. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Wed, 22 Mar 2000, Michael Lauer wrote: > 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 what amount these changes will break code which is > written now ? > > -- > Regards & Gruesse from Mickey @ http://www.Vanille.de > - > How could anyone know me - when I don't even know myself ? > To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED] > To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
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 "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
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 what amount these changes will break code which is written now ? -- Regards & Gruesse from Mickey @ http://www.Vanille.de - How could anyone know me - when I don't even know myself ? To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
Well, the pygtk/gnome-python bindings are not completely hand crafted. The low level wrappers are auto generated. In the next version almost all of pygtk will be autogenerated, so I don't think the fact that it is autogenerated is a big deal. I use my own code generators as none of the general ones do what I wanted (generate object oriented wrappers using ExtensionClass for a C library). I guess the Qt guys came to the same conclusion, as they have there own code generator as well. 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). James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ On Wed, 22 Mar 2000, Michael Lauer wrote: > 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 these > bindings compare to the "handcrafted" PyGTK > /PyGnome ones ? > > I'm currently evaluating both bindings > for using on my forthcoming project, a > decent Python RAD Environment. > > Any comments ? > > Have a nice day! > > -- > Regards & Gruesse from Mickey @ http://www.Vanille.de > - > How could anyone know me - when I don't even know myself ? > To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED] > To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
On Wed, 22 Mar 2000, Moshe Zadka wrote: > On Wed, 22 Mar 2000, 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. One wonders what you think that the first C++ compiler was built in. If only OO languages can interpret OO, that would be a chicken/egg problem, no? After all, how can Python, which is written in C, be OO? (by your logic) > Gtk+ is perfectly object oriented. Hence, PyGTK only exposes that OO in > Python's way, rather then Gtk+'s (admittedly idisyncristic) OO > methodology. They made a good choice in terms of allowing alternate language bindings. The Python bindings are great. -- _Deirdre * http://www.linuxcabal.org * http://www.deirdre.net "In /dev/null, no one can hear you scream" To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
On Wed, 22 Mar 2000, Michael Lauer wrote: > > 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 work in hiding the naturally not object oriented > nature of the native GTK language - C. Gtk+ is perfectly object oriented. Hence, PyGTK only exposes that OO in Python's way, rather then Gtk+'s (admittedly idisyncristic) OO methodology. -- Moshe Zadka <[EMAIL PROTECTED]>. http://www.oreilly.com/news/prescod_0300.html http://www.linux.org.il -- we put the penguin in .com To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
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. You have to cooperate with python's refcounting, so you have to wrap the base class by hand, basically. Matt To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
> 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 work in hiding the naturally not object oriented nature of the native GTK language - C. -- Regards & Gruesse from Mickey @ http://www.Vanille.de - How could anyone know me - when I don't even know myself ? To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
Re: [pygtk] PyQt/PyKDE Bindings
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% automatically. Matt On Wed, Mar 22, 2000 at 01:00:10AM +0100, Michael Lauer wrote: > 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 these > bindings compare to the "handcrafted" PyGTK > /PyGnome ones ? > > I'm currently evaluating both bindings > for using on my forthcoming project, a > decent Python RAD Environment. > > Any comments ? > > Have a nice day! > > -- > Regards & Gruesse from Mickey @ http://www.Vanille.de > - > How could anyone know me - when I don't even know myself ? > To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED] To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
