Re: [RFC] Common library for Git GUIs

[Frank Li <lznuaa@gmail.com>]

I think TortoiseGit need C\C++ git library, which should be also used
by git itself. Otherwise, it is difficult sync with git.

2009/2/18 Jan Hudec <bulb@ucw.cz>:
> On Tue, Feb 17, 2009 at 20:08:23 +0000, Pieter de Bie wrote:
>> 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 don't think the really core devs need to work on this -- their time is best
> spent on the core. And many of the existing guis are in C++. For me, it
> depends on the user portable runtime more than anything else.
>
>>>    - 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.
>
> The advantage of swing is, that one definition with a few typedefs would
> generate Python, Perl, Ruby, CLR, Java and a few more bindings. GObject would
> need more language-specific work, but would nicely solve integration into the
> garbage collector. You know, I want to save as much work as possible.
>
>>> Portable runtime options:
>>> So what do you people think would be best? I see several options:
>>> - QtCore
>>> - Glib
>>> - STL + Boost
>> 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.
>
> I fully agree that nobody will want to depend on Qt -- QtCore is now
> a separate library, but the sources are not shipped separately AFAIK, so it'd
> be a pain. I would not think the case is as strong against boost and glib,
> though. People would either be getting binaries, in which case we can just
> bundle whatever dependency along, or building it and than one extra source
> tree (that can also be bundled for convenience) is not so much pain.
>
>>> - POSIX + Msys on Windows
>> I think lightweight is the way to go. If you go for C++, you can also use
>> the STL.
>
> STL does not have any support for threads, event loop nor signals. Though
> thinking about it, we may not actually need them.
>  - we only need threads if our event loop can't be integrated into gui's one
>   and the gui can start our in thread itself -- it's not too much code.
>  - we only need file descriptors in the event loop and it needs to be
>   integratable into the gui's one anyway.
>  - simple callback is quite likely good enough for us -- the gui will need
>   multiple callbacks, but it will need to connect in it's own signal system
>   anyway.
> So the shell invocation remains and that's little enough we can cut&paste
> that from glib.
>
>> But, isn't this time spent better on getting libgit2 off the ground?
>
> No, because what I have in mind is orthogonal to libgit2. libgit2 is supposed
> to be generic API for git, while I am proposing a specifically gui-oriented
> interface, which should implement all logic of a gui except opening dialogs
> and the widgets themselves, allowing the guis built on top of it to be
> totally dumb. Actually part of my idea is to create something, that can be
> later ported to libgit2 and immediately benefit many git interfaces.
>
> --
>                                                 Jan 'Bulb' Hudec <bulb@ucw.cz>
>