[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [RFC] Common library for Git GUIs
From:       Pieter de Bie <pieter () frim ! nl>
Date:       2009-02-17 20:08:23
Message-ID: 74161B7F-A178-49CB-990D-DF7299235C58 () frim ! nl
[Download RAW message or body]

Hi,

On Feb 16, 2009, at 9:24 PM, Jan Hudec wrote:

> What it should use:
>
> - It should probably be in C++ or C, with bindings for at least Perl,
>   Python, Ruby, C#(CLR) and Java. The bindings can be done either  
> with Swig,
>   or using some base library that already has them.

It should be either C++ or C. If you want git devvers to work on it too,
you'll probably want to go with C.

>   I think Java or CLR, while more portable, would not be appropriate  
> because
>   there is no standard way to combine them with other languages like  
> Perl,
>   Python and Ruby and those languages are still superior for the UI
>   programming itself. I somewhat prefer C++, because polymorphism  
> and some
>   template tools would be useful here, but I am open to arguments.

I think JGit is pretty far along for someone who wants to create a Java
GUI.
>    - Bindings for languages. We can use Swig, but it has e.g. no  
> support for
>      callbacks, so having portable runtime with already existing  
> bindings
>      that support this would be an advantage.

I'd say bindings are pretty easy to create yourself.

> Portable runtime options:
>
> So what do you people think would be best? I see several options:
>
> - QtCore
>
>   Qt seems to be the most popular library among Git GUI writers and  
> since
>   version 4.5 will be LGPL, so it will be allowed to link with  
> anything.
>   It is also probably the most portable one. On the downside, it's  
> rather
>   large and it's language bindings are a bit worse (the garbage  
> collector
>   integration was a bit bad last time I looked).
>
> - Glib
>
>   This is C based, so the core could be in plain C. It is also quite  
> modular
>   and has very good support for bindings to various languages. On the
>   downside it's a bit less portable and less used among the existing  
> guis.
>   C would mean more work, but we could probably save some of it by  
> using
>   gob2 (g object builder)
>
> - STL + Boost
>
>   I don't have experience with it, though I read some of the  
> documentation.
>   It should be sensibly portable. I know it has python bindings, the  
> rest
>   would probably have to be dealt with using swig.

None of these, if you want any GUI's to use it. Noone is going to
create a Gtk / Cocoa / Windows app that depends on Qt. Nobody wants
to use Boost in any situation and Glib, while being smaller than the
rest, is also difficult as it isn't shipped with many OS's, for example
OS X.

> - POSIX + Msys on Windows
>
>   I guess it would technically be usable, but I think it would be  
> rather lot
>   of additional work. It would probably be quite lightweight, though.

I think lightweight is the way to go. If you go for C++, you can also  
use
the STL.

But, isn't this time spent better on getting libgit2 off the ground?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]