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@xxxxxx>: > > 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@xxxxxx> > > -- Jan 'Bulb' Hudec <bulb@xxxxxx> -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
