Re: [RFC] Common library for Git GUIs

[Jan Hudec <bulb@ucw.cz>]

On Wed, Feb 18, 2009 at 09:38:42 +0800, Frank Li wrote:
> I think TortoiseGit need C\C++ git library, which should be also used
> by git itself. Otherwise, it is difficult sync with git.

I don't mean to reimplement a single bit of what is implemented in git
itself. I want to factor out some stuff that is above git, only useful for
_graphical_ user interfaces.

> 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>
> >
-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>