Re: Git User's Survey 2008 partial summary

From: David Aguilar <davvid@gmail.com>
Date: Sep 6, 2008, 04:17 UTC
Message-ID: <20080906041733.GA18930@gmail.com>
In-Reply-To: <20080905221731.GI15520@efreet.light.src>

On  0, Jan Hudec <bulb@ucw.cz> wrote:

Show 10 quoted lines

> > 
> > 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.

Show 6 quoted lines

> > 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