Re: [RFC] Common library for Git GUIs

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