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