Re: Git User's Survey 2008 partial summary

[David Aguilar <davvid@gmail.com>]

On  0, Jan Hudec <bulb@ucw.cz> wrote:
> > 
> > There's already a python git-gui:
> >     http://cola.tuxfamily.org/
> > 
> > PyQt is a very mature library, which is one of the primary reasons I
> > chose Python.
> 
> Sorry, but I disagree. Tried PyQt, been hugely disapointed. Boils down to any
> thing that can make Python (or, for that matter, any) interpreter segfault
> being totally broken.


That's curious, I've never seen a single segfault.
You don't happen to run suse or fedora, do you?
I've not experienced your pains once on debian.


> But as far as Qt goes, I would really just stick with C++. Python or Ruby
> have some advantage, but I am not sure it's that big to offset the fact, that
> a lot of code already exists in QGit.

I have no comment here -- for me it boils down to the fact
that I end up writing much less code in Python vs. C++.  GUIs
are not performance critical.  Most of the time is spent in
the event loop waiting for user input.  Ditto for Ruby, tcltk,
etc --the benefit is in writing less code that does more.  I
sure as hell wouldn't write something performance critical in
those languages, but for something simple like a GUI it makes
perfect sense.

git-cola and qgit actually do different things.  qgit has
an awesome history viewer.  git-cola is primarily for doing
stuff like splitting apart changes into separate commits, etc.
I tend to work things up into a working state and then commit
things separately.  For example, there might be one commit
that does some refactoring and a second commit that uses the
refactored code, etc.  git-cola started out with emulating
git-gui's featureset though it has surpassed it now, which is
why its focus is on the commit workflow.


> > Does Ruby have any good and mature UI libraries?  I know it's all the
> > rage for web stuff, but I haven't heard too much about people using it
> > for GUIs.
> 
> Qt? I believe Ruby Qt bindings are in better shape (properly handle Qt
> deleting objects under Ruby's hands).

Right -- if you got segfaults due to object deletion it's
because you let things go out of scope.  I do not doubt that
the ruby bindings handle this better, but I have not ever
seen the problems you describe so I wouldn't know.
RubyQt looks interesting but the differences are superficial
given that I've not run into any problems.  As far as suckage
goes, ruby and python both suck equally so the choice is
immaterial ;)

Anyways, this is getting off topic for the git list so I'll
stop here.  If you have some pyqt examples that demonstrate
segfaults then I'm sure phil (pyqt author) would be happy
to see them, but those details are probably left off-list or
on the pyqt devel list. 

ciao,

-- 

	David