Qt programming

[Chuck Robey]

Danny Pansters wrote:
[some eliding]
> I find this a tad biased. Let me try to counter a bit and provide some more 
> info. 

Oh, I admit I am a bit prejudiced.  I might be a bit more than a little, 
even.  I heartily dislike C++ (I find it FAR too complicated for it's 
feature set).  I Like Python, but I dislike Perl, for very nearly the 
same reasons as C++, except  in the case of perl, it's even worse.

I also admit a prejudice against precompilers, but sir, I ADMITTED 
THAT UP FRONT!	  Read it, I said it out front that it was a "very 
personal prejudice".  If I go out of my way to show that it's an opinion 
with more than one side, then I find your complaining about it in very 
poor taste.  I'm not against  your disagreeing, I just don't appreciate 
you calling me biased over it, not when I try so hard to be fair.

Note I am not commenting (yet) on the meat of your opinions.  I like 
your opinions.  I disagree in many cases, but I like the way you 
expressed them.

> 
> One could also argue that qt has a bootload more high level functionality. And 
> "based upon a preprocessor"? You mean it's C++?

No, how about I call up an example I think that most of us have hit, the 
sql precompilers, stuff that has you putting stuff like $READ into you C 
code.  stuff that is illgal in C, but precompiled away.  That's what 
"moc" is, right?  I do not like precompilers.  I am not talking about 
cpp.  Gnome does the job without precompilers, proving at least that it 
CAN be done without it.

  Yes. So is wxwidgets (FKA
> wxwindows) which is another fine toolkit. Python bindings to any of them 
> might have a bit less functionality than the native C or C++ toolkits but 
> generally their amount of functionality reflects that of the underlying 
> toolkit. 

True.  I find Python's fantastic ease, in being able to bring in all 
those outside toolkits, one of it's greatest strengths.  I'm absolutely 
in LOVE with pygtk | pyqt | (about 6 others).  All done without 
precomilers.  Of course, that arguments makes little sense here.

> 
> 
>>Another thing you might want to consider is, leaerning python, and then
>>using python's incredible facilities to program directly in gtk (see
>>pygtk) or qt (see pyqt).  I have myself done a large job in pygtk, it's
>>a great environment to work  in, a very rich programming environment for
>>gui work.
> 
> 
> I like using python for both low level stuff (or quick-and-dirty scripts) and 
> GUI stuff. It's very versatile with lots of added modules. The base modules 
> are pretty much optimized for speed, no need to try and reinvent the wheel. I 
> played with py-gtk a bit (with ROX desktop) but found it a little cumbersome.
> 
> I also used py-wx for a little accounting app for my own which I wanted to be 
> able to run on both *NIX and Windows. On *NIX it renders as gtk widgets, on 
> Win32 natively. 
> 
> But qt (py-qt) definately has the most functionality to get started with. I 
> never really done a project with it and am personally more interested in 
> py-kde (which builds upon it), but it surely has a lot of stuff ready to use 
> to build a complex app using python.

So just out of curiosity, because I am more at ease with pygtk than 
pyqt, what is it that you can do in pyqt that I can't in pygtk?

> 
> There's also a py-anygui that abstracts widgets (with some limitations of 
> course) and then you can deploy them with py-gtk, py-wx, py-qt, py-kde, 
> py-ncurses...).

Don't like that, too little features, lost while chasing the god of 
cross-architectures.

> 
> Also python has lots of very useful modules, lots more unofficial ones which 
> at the very least you can use as starting point. So yeah, considering today's 
> processors and RAM the average PC has, python is certainly something to 
> consider.
> 
> HTH,
>