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
