We Keep Coding

Changing GUI library : QT, wxPython... anything else?

Actually working on a project in python with PyQT, we choose to create widgets that were "unpleasant" or that didn't have a good enough behaviour.
So, we finally found that QToolbox, QDate and some others had a behaviour non acceptable for the project, so we had to adapt these.
We had also to create a complete new widget : A scheduler.
As we were creating these, it has been decided that it took too much time. So we were asked to think about other libraries.
I actually found a project of a scheduler in wxPython, that actually looks like what we want ( but we believe that we'll have to adapt it a lot ). Here it is : http://code.google.com/p/wxscheduler/
So, I ask everyone that have some more experience than me in GUI programming in python : Do we need to start again the project in anything other than PyQT? I know the question is weird, but what you need to know is :
The project has now been going on for 2 months
I know only PyQT, and started working in python 2 month ago
We are currently 3 in the project, and we currently know only PyQT
We have currently managed a lot of the PyQT widgets, and were starting to code these new widgets.
Please help us =)
Thanks
Edit : I should have add that the project is opensource and multi-platform

Feel free to look at other libraries if you like. Robin Dunn, the creator of wxPython, recently started working on PySide and he found it somewhat similar to wx, so you might find that wxPython will fit your brain fairly well too. I certainly think wx's class names are more intuitive than PyQt's. The only way to know for certain is to actually experiment a little and see if it works. I will say that the wxPython community is one of the best Python communities I've dealt with over the years.

One possibility would be to use an HTML scheduler control via QtWebKit. If your UI can accommodate a QWebView in the place where you'd otherwise have a custom scheduler widget, there are probably a number of excellent scheduler widgets (implemented as jQuery plugins, etc.) you could choose from.

we choose to create widgets that were "unpleasant" or that didn't have
a good enough behaviour.
Why don't you create "pleasant" widgets ?
so we had to adapt these.
Yes. It is the solution.
it has been decided that it took too much time
Don't you think it would take much more time if you change the whole GUI API ?
As for i know, there is not such native Scheduler in any Python GUI library, especially one you could use with Qt. I don't think it would be so long to recreate one, unless you have very specific needs, that would confirm you wouldn't find a such existing thing in an existing library.
Concerning wxScheduler, i guess you can have a look to the code, even it uses wxWidget and you're working with Qt, to get an idea how to do it.

PyQT vs PyObjc / Cocoa-Python

I'm thinking about developing an app for OS X using Python. I don't know Objective C and don't want to learn it right now.
I know and like Python. I'm trying to determine what GUI toolkit to use. I already have a bit of experience with PyQT, but not much. I've also seen that PyObjc or Cocoa-Python seem to allow use of Cocoa UI components from Python.
I'm curious if anyone has any input on how PyObjC stacks up to PyQT. I would be giving up cross platform abilities and I am not sure what I would be gaining.
I'm leaning towards PyQT right now, but wanted to see what you all thought. My big dislike of PyQT is having to pass around strings for the signals and slots. Is PyObjC similar?

If the only thing stopping you using PyQt is passing strings in signals, then the latest syntax should make your choice much easier. The old syntax (which can still be used) looks like this:
self.connect(self.action, SIGNAL('triggered()'), self.handler)
But the new style signals are much more pythonic:
self.action.triggered.connect(self.handler)

What are the downsides of using Python instead of Objective-C? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I know some Python and I'm really impressed by the language's ease of use. From what I've seen of Objective-C it looks a lot less pretty, but it seems to be the lingua franca for Mac OS X development (which means it has better documentation).
I'm thinking about starting Mac development - will using PyObjC+Python make me a second class citizen?

Yes.
For one thing, as you note, all the documentation is written for Objective-C, which is a very different language.
One difference is method name. In Objective-C, when you send a message to (Python would say “call a method of”) an object, the method name (selector) and arguments are mixed:
NSURL *URL = /*…*/;
NSError *error = nil;
QTMovie *movie = [QTMovie movieWithURL:URL
error:&error];
This isn't possible in Python. Python's keyword arguments don't count as part of the method name, so if you did this:
movie = QTMovie.movieWithURL(URL, error = ???)
you would get an exception, because the QTMovie class has no method named movieWithURL; the message in the Objective-C example uses the selector movieWithURL:error:. movieWithURL: and movieWithURL would be two other selectors.
There's no way they can change this, because Python's keyword arguments aren't ordered. Suppose you have a hypothetical three-argument method:
foo = Foo.foo(fred, bar=bar, baz=baz)
Now, this calls foo:bar:baz:, right?
Not so fast. Foo may also have a method named foo:baz:bar:. Because Python's keyword arguments aren't ordered, you may actually be calling that method. Likewise, if you tried to call foo:baz:bar:, you may actually end up calling foo:bar:baz:. In reality, this case is unlikely, but if it ever happens, you would be unable to reliably call either method.
So, in PyObjC, you would need to call the method like this:
movie = QTMovie.movieWithURL_error_(URL, ???)
You may be wondering about the ???. C doesn't allow multiple return values, so, in Objective-C, the error: argument takes a pointer to a pointer variable, and the method will store an object in that variable (this is called return-by-reference). Python doesn't have pointers, so the way the bridge handles arguments like this is that you pass None, and the method will (appear to) return a tuple. So the correct example is:
movie, error = QTMovie.movieWithURL_error_(URL, None)
You can see how even a simple example deviates from what documentation might show you in Objective-C.
There are other issues, such as the GIL. Cocoa apps are only going to get more concurrent, and you're going to want in on this, especially with tempting classes like NSOperation lying around. And the GIL is a serious liability, especially on multi-core machines. I say this as a Python guy myself (when not writing for Cocoa). As David Beazley demonstrates in that video, it's a cold, hard fact; there's no denying it.
So, if I were going to switch away from Objective-C for my apps, I would take up MacRuby. Unlike with PyObjC and RubyCocoa, messages to Cocoa objects don't cross the language bridge; it's a from-the-ground-up Ruby implementation in Cocoa, with language extensions to better support writing Cocoa code in it.
But that's too far ahead of you. You're just getting started. Start with Objective-C. Better to avoid all impedance mismatches between the language you're using and the one the documentation is written for by keeping them the same language.
Plus, you'll find some bugs (such as messages to deceased objects) harder to diagnose without knowledge of how Objective-C works. You will write these bugs as a new Cocoa programmer, regardless of which language you're writing the code in.
So, learn C, then learn Objective-C. A working knowledge of both shouldn't take more than a few weeks, and at the end of it, you'll be better prepared for everything else.
I won't go into how I learned C; suffice to say that I do not recommend the way I did it. I've heard that this book is good, but I've never owned nor read it. I do have this book, and can confirm that it's good, but it's also not Mac-specific; skip the chapter on how to compile the code, and use Xcode instead.
As for Objective-C: The Hillegass book is the most popular, but I didn't use it. (I have skimmed it, and it looks good.) I read Apple's document on the language, then jumped right in to writing small Cocoa apps. I read some of the guides, with mixed results. There is a Currency Converter tutorial, but it didn't help me at all, and doesn't quite reflect a modern Cocoa app. (Modern apps still use outlets and actions, but also Bindings, and a realistic Currency Converter would be almost entirely a couple of Bindings.)

This really says it all:
As the maintainer of PyObjC for nearly
15 years, I will say it bluntly. Use
Objective-C. You will need to know
Objective-C to really understand Cocoa
anyway and PyObjC is just going to add
a layer of bugs & issues that are
alien to 99% of Cocoa programmers.
a comment in an answer to this question. This question is also interesting.

DO NOT ATTEMPT to avoid learning objective-C if you're going to write apps for the Mac. The purpose of PyObjC and the other language bindings is to let you re-use existing libraries in your apps, not to let you avoid learning the native tools.

Second class citizen seems a bit strong. The Objective-C API's are available from Python as well, should you need them, and that's mostly if you want to make Cocoa apps. But then they are restricted to OS X anyway. Personally, I have no interest in building apps that isn't cross-platform, but that's me. That also means I haven't actually done this, so I don't know how tricky it is, but there was an article in the Python Magazine not long ago, and it didn't look that horrible.
The major drawback of Python is execution time, and that mainly comes from it being a dynamic language. This can be solved with Cython and C-extensions, etc, but then you get a mix of Python + ObjectiveC API's + Cython which can be daunting.
So it depends a lot of what kinds of applications you are going to make. Something uniquely OSX-ish that makes no sense anywhere else? ObjectiveC is probably the ticket. Cross-platform servers, well then Python rocks! Something else? Then it depends.

This is something I've been wondering myself, and although I hope someone comes by with more experience, from what I know you will not be seriously constrained by Python itself. Along with Java and GCC, Python is an excellent way to write native cross-platform applications. Once you get the hang of it you should be able to map example code in Objective C to your Python code.
Since you have access to all libraries and events, everything that you can do in Objective C will be there in Python. Of course, the more OS X-only calls and functions you use, the less easy it will be to port to another platform, but that's beside the point. Usually graphics programming and working with device drivers is somewhat of a limiting factor - but in both cases I'm finding evidence of good support and community libraries (search for Python and Quartz, Lightblue, libhid, PyUSB, for some examples).
The decisive factor for me would be: what is the level of tooling and IDE support that is needed. Apple provides some great software for building new software, but then again with something like Pydev you've got a great place to write Python code too! http://pydev.org/
So give it a try, I'm sure you won't regret it, and there will be a supportive community to draw on for help and insipiration.

You're going to need Objective-C: that's what all the tutorials, documentation, sample code, and everything is written in. In addition to a wilder variety of people being able to help you.
So learn ObjC first. If, on your second or third project, or a year down the road, you start a project that needs a Python module (like, say, Twisted, or SQLAlchemy. But a SERIOUS need like foundation of your app need, where the extra boost your app gets makes everything worth it), then you can write a PyObjC app and get a lot of the speed benefits of that language, with your background in Cocoa.

Just as an extra option, consider that wxPython can produce some pretty good applications on Mac as well as on Linux and Windows. For the most part you can get native appearance but maintain portability with little or no attention to platform-specific issues.
In other words, PyObjC + Python is not the only way to do Mac development with Python.

No you dont need to know Objective C you dont need to use PyObjC , and you wont be a second class citizent.
Unless you want to do something extremely specific to the MAC platform , coding in Objective C or using PyObjC is a really bad idea.
The reason is obvious, once you go the objc route you say a big "goodbye" to other platforms. Its that simple.
Apple does not want you to code for other platforms the same way Microsoft does not want you to code for other platforms. And that is why more and more developers are turning to open source languages like, python, java, ruby etc. Because you dont care what Apple and Microsot , you only care about an App that is the most useful and most easy to develop. And making your App available only for MAC will make it less useful and obviously developing in Objective C is way more difficult.
Python has more than enough libraries to accomodate you , hundrends of them , readily available for the mac platform. I for instance develope a new application in pygame, no its not a game, if I have done the same thing in ObjC or PyObj I would have to rewrite the code for windows and linux. While with pygame my code works exactly the same in windows and linux even though my main platform is macos.
Thats the appeal of most python libraries , they are cross platform. WxPython is another example, someone mentioned that "it does not exactly look natively" , do you want this to stop you from making your application available for windows and linux. Why limit yourself only on the MAC platform ? Do you think the average user will care how natively your app will look. Even macos apps do not look native , many of them introduce their own "eye candy" gui. Not that you cant make WxPython look 100% native, the way you code is always importnat.
Objc makes sense when you intend to develop for Iphone OS , as Apple thought it a great idea to exclude python (and not only python), even though they were forced to include javascript (or else websurfing would have being a nightmare on iphoneos) . Pyjamas, can make python available for iphone os as well (with no hacks or jailbroken phones), but with the obvious limitations since it translates python code to javascript, but still its a valid solution till Apple decide that excluding python from iphone os is a really bad idea.
link text
There is no harm done in studying Objective C though. You can always use the native libraries via pyobjc.
But to be absolutely sincere with you, If my app reaches a dead end with the python libraries ( a very unlikely scenario) I would rather wrap an existing cross platform C/C++ Libraries with Cython than go the objective c pyobjc route and detroy the cross platform ability of my app. The last thing I would be using is anything platoform specifc.
Now if you dont care about other platforms at all, then I guess Objective C can be a valid choice. It certainly looks ugly as hell, but I have heard that it gets much better the more you use it and there are many people that prefer it over C/C++.

How can I program software using Python for Linux/Windows?

For example, using C# I can make software fairly easily for Windows.
I downloaded Python but all I get is a terminal like window for executing single lines of code.
Is there a free IDE/Visual editor for designing GUI's in conjunction with Python?
Thank SO. :D

The character-based terminal (console) interface isn't the only one Python affords. It is often the most visible because it is
"built-in"
often used in the early stages of learning the language, allowing one to focus on various idioms of the language, without the added complexity of the object model and API associated with a GUI
quite handy for many quick jobs, script-like / awk-like type applications, whether ad-hoc or more permanent.
GUIs for Python are aplenty, in fact overwhelmingly so, which can be handicap as people try and decide which one to use. Often, the choice may be driven by one's familiarity with these GUI frameworks, for as you can see they are not specific to Python (recognize their names, often with a Py prefix). Another criteria may be their support (or lack thereof) on various Operating Systems. And yet another criteria may be the way these framework tie-in with broader systems such as MVC frameworks etc..
Anyway the arguably most popular one may be:
TkInter (tk/tcl)
PyQT
WxPython
and if you want more...
here's a "complete" list
Similarly, there are several IDEs for developing in Python, although many of these do not include GUI designer features. Here's a representative but certainly incomplete list. They are listed in no particular order (do comment on possible significant omissions or errors with regard to features). Most are either free or inexpensive.
IDLE
Eric
PyDev
Wing IDE
Netbeans IDE
the following have some GUI design features (underlying GUI in parenthesis)
BlackAdder (Qt)
Boa Constructor (Wx)
Komodo (Tk) (I think commerical, now)
Eclipse
The capabilities of these IDEs vary greatly, and some may cover some areas of development rather well (ex debugging, or unittesting) while being weak in other areas (say auto-completion). Many Python developers also manage rather well with "plain" (but well featured) text editors and a few macros/plug-ins.

Yes, lots.
http://wiki.python.org/moin/GuiProgramming

If you know .Net and C#, you could use IronPython and WPF. Then you can use Visual Studio 2010 Beta 2 as your development environment. Here's an example of how it can be done.

Glade or no glade: What is the best way to use PyGtk?

I've been learning python for a while now with some success. I even managed to create one or two (simple) programs using PyGtk + Glade.
The thing is: I am not sure if the best way to use GTK with python is by building the interfaces using Glade.
I was wondering if the more experienced ones among us (remember, I'm just a beginner) could point out the benefits and caveats of using Glade as opposed to creating everything in the code itself (assuming that learning the correct gtk bindings wouldn't exactly be a problem).

I would say that it depends: if you find that using Glade you can build the apps you want or need to make than that's absolutely fine. If however you actually want to learn how GTK works or you have some non-standard UI requirements you will have to dig into GTK internals (which are not that complicated).
Personally I'm usually about 5 minutes into a rich client when I need some feature or customization that is simply impossible through a designer such as Glade or Stetic. Perhaps it's just me. Nevertheless it is still useful for me to bootstrap window design using a graphical tool.
My recommendation: if making rich clients using GTK is going to be a significant part of your job/hobby then learn GTK as well since you will need to write that code someday.
P.S. I personally find Stetic to be superior to Glade for design work, if a little bit more unstable.

Use GtkBuilder instead of Glade, it's integrated into Gtk itself instead of a separate library.
The main benefit of Glade is that it's much, much easier to create the interface. It's a bit more work to connect signal handlers, but I've never felt that matters much.

Glade is very useful for creating interfaces, it means you can easily change the GUI without doing much coding. You'll find that if you want to do anything useful (e.g. build a treeview) you will have to get familiar with various parts of the GTK documentation - in practice finding a good tutorial/examples.

I started out using glade, but soon moved to just doing everything in code. Glade is nice for simple things, and it's good when you're learning how GTK organizes the widgets (how things are packed, etc). Constructing everything in code, however, you have much more flexibility. Plus, you don't have the glade dependency.

I usually start with Glade until I come to a point where it doesn't have the features I need, e.g. creating a wizard. As long as I'm using the standard widgets that Glade provides, there's really no reason to hand-code the GUI.
The more comfortable I become with how Glade formats the code, the better my hand-coding becomes. Not to mention, it's real easy to use Glade to make the underlying framework so you don't have to worry about all the initializations.

If you're writing a traditional GUI application which reuses a lot of standard components from GTK+ (buttons, labels, containers etc.) I'd personally go with Glade + Kiwi (a convenience framework for building GTK+ GUI applications).
The single greatest advantage to using Glade is that it greatly reduces layout/packing code. Here's an extremely simply example which already shows the issues with manually laying out a GUI (without using any helper functions):
container = gtk.HBox()
label = gtk.Label(str="test")
container.add(label)
For more examples take a look here. Even if you're writing a complicated custom widget you can always create a placeholder in Glade and replace that after instantiation.
It shouldn't be all too long now for the Glade team to release a new version of the designer (3.6.0). This new version will add support for GtkBuilder, which replaces libglade (the actual library that transforms the Glade XML files into a widget tree). The new Glade designer also once again adds support for defining catalogs (sets of widgets) in Python, so you can easily add your own custom widgets.

First, start to put this in perspective.
You will be using GTK. This is a huge C library built in 1993 using the best traditions of 1970s coding style. It was built to help implement the GIMP, a Photoshop competitor wanna-be with user interface blunders of legend. A typical gui field might have forty or more parameters, mostly repetitive, having getters and setters. There will be pain.
The GTK itself manages a complete dynamic type system in C using GObject. This makes debugging a special joy that requires manually walking through arrays of pointers to methods full of generic argument lists with implicit inheritance. You will also be jumping through Pango libraries when you least expect it, e.g., using a Pango constant for where in a label the ellipsis go when the page is small. Expect more pain.
By now, you are probably vowing to wrap all your GTK interactions in a Model-View-Controller architecture specific to your application. This is good.
Using Glade, or gtkBuilder, or Stetic, will help coral the huge coupling problem of forty parameters to a function. Glade provides a basic GUI builder to drag and drop components together. The parameters and inherited parameters are somewhat separated out. The output of Glade is .glade XML file which you will then read in, attach your callbacks ("signal handlers") to identically named functions, and query or update the in-memory version of that XML to get widgets that you then use pyGTK to manipulate. Glade itself is a creaky and not well maintained.
Using pyGTK gives you annoyingly fine grained control in order to build your GUI. This will be verbose, copy-and-paste code. Each attribute will be a separate function call. The attribute setter does not return anything, so chaining the calls is out of the question. Usually, your IDE will give only minimal help on what functions mean and you will be constantly referring to DevHelp or some other tool.
One would almost expect GTK GUIs were meant to fail.

I recommend using Glade for rapid development, but not for learning. Why? because some times you will need to tune up some widgets in order to work as you want they to work, and if you don't really know/understand the properties attributes of every widget then you will be in troubles.

For quick and simple screens I use Glade. But for anything that needs finer levels of control, I create a custom classes for what I actually need (this is important, because it's too easy to get carried away with generalisations).
With a skinny applications specific classes, I can rapidly change the look and feel application wide from a single place. Rather like using CSS to mantain consistency for web sites.

Personally I would recommend coding it out instead of using Glade. I'm still learning python and pyGtk but I will say that writing out the UI by hand gave me a lot of insight on how things work under the hood.
Once you have it learned I'd say to give glade, or other UI designers a try but definitely learn how to do it the "hard" way first.

You may use glade-2 to design, and use glade2py.py to generating the pure pygtk code,
it use pygtkcompat to support gtk3