{"thread":{"id":"17832","subject":"[RFC] Common library for Git GUIs","startedAt":"2009-02-16T21:24:59Z","lastAt":"2009-02-19T07:30:22Z","messageCount":15,"participants":["Jan Hudec","Marco Costalba","Guilhem Bonnefille","Pieter de Bie","Johannes Schindelin","Frank Li","Abhijit Bhopatkar","David Aguilar"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"105011","messageId":"20090216212459.GA25046@efreet.light.src","threadId":"17832","inReplyTo":null,"subject":"[RFC] Common library for Git GUIs","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2009-02-16T21:24:59Z","receivedAt":"2009-02-16T21:24:59Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"Hello Folks,\n\nSorry for a long mail. I am CC'ing people who wrote some git guis; I hope\nit does not offend you.\n\nLooking at the current situation with Git GUIs, I thought it might be useful\nto create a generic library that would make it easier to develop git guis\n(especially plugins to various tools) and to add a new features to many of\nthem with less effort. What do you people think about such idea?\n\nUnfortunately in current situation no gui really supports all I would need to\nget my colleagues at work to accept git (they are somewhat obsessed with\nplugin to Visual Studio and explorer and generally avoiding command line).\nI started working on VS plugin some time ago, but I feel like a bit more\nreuse would be in order.\n\nThe proposed library should contain:\n\n - Models for the most common data GUIs want to display\n\n   All modern GUI libraries (Qt, Gtk, WinForms, Cocoa) have some kind of\n   generic interface for obtaining list, textbox and perhaps editbox data.\n   Morover, the interfaces are pretty similar, so it should possible to\n   create one interface and adapt it for the remaining toolkits.\n\n   Data we want to export like this are:\n\n    - Tree of all files in the work area with their status\n      Seeing status (unchanged/modified/staged/new/...) of individual files\n      in Visual Studio is the most wanted features of my colleagues at $work.\n      The feature is applicable for Windows shell extension (Tortoise Git),\n      similar KDE and Gnome extensions and all IDE bindings.\n\n    - Tree of files in given revision\n      For browsing other revisions than the checked out one.\n\n    - History *tree*\n      Starting gitk as separate process is suboptimal, because versions from\n      the tree can't be easily selected for operations (checkout, merge, ...).\n\n    - Blob data\n      For looking at other revisions than the checked out one.\n\n    - Commit properties\n      For showing details of revisions in the history view.\n\n    - Diffs\n      Obviously...\n\n    - Annotations\n      Again, should be integrated with the rest of gui, so selecting line in\n      annotation can open the revision in diff view, select it in history\n      etc.\n\n    - Configuration\n      Many tools (eg. gui designers) feature a tree view of all properties of\n      some object (property grid) with editable values and short\n      descriptions. It's not as nice gui designed for individual options, but\n      can provide good-enough easy-to-write way to set all valid options from\n      the gui.\n\n    Quite likely you can think of more data. Having generic implementation\n    would save some coding when implementing the various plugins and have the\n    benefit that additional view could be easily added to other guis, when\n    it's implemented for one, because the interfaces will be the same.\n\n - Menu and action definitions for the common operations\n\n   At least Gtk and Qt (don't know about others) have a concept of Action,\n   which combines function for executing some operation with icon, name and\n   enabled status of that action. These are than used for general menu\n   descriptions.\n\n   A generic library could provide arrays of such actions, that would define\n   generic context menus for many things. For file, all Guis probably want to\n   be able to add, revert, diff and annotate it. For revisions, all Guis\n   probably want to check it out, merge it or rebase on it. Ditto for branch,\n   which can additionally be pushed and updated from remote etc. Most of\n   these operations take no or one additional parameter or few defined types\n   (revision, branch, file). So if we extend the Action concept a bit, adding\n   support for new simple operations (stash, submodule operations, etc.)\n   quite easy for the Guis.\n\n   Also Git Gui supports defining such operations that run specified shell\n   commands. Qgit has similar, slightly more limited feature. Defining it in\n   reusable library would make allow once defined command show in all guis\n   a user uses.\n\nWhat it should use:\n\n - It should probably be in C++ or C, with bindings for at least Perl,\n   Python, Ruby, C#(CLR) and Java. The bindings can be done either with Swig,\n   or using some base library that already has them.\n\n   I think Java or CLR, while more portable, would not be appropriate because\n   there is no standard way to combine them with other languages like Perl,\n   Python and Ruby and those languages are still superior for the UI\n   programming itself. I somewhat prefer C++, because polymorphism and some\n   template tools would be useful here, but I am open to arguments.\n\n - It needs a portable runtime supporting at least:\n    - Starting processes. We need to run git and shell commands. Even when\n      libgit2 is implemented and this library ported to it, ability to run\n      external commands should remain and libgit2 is not usable yet anyway.\n      Should include ability to properly quote and dequote command lines in\n      Windows.\n    - Event loop. We should be able to process git output asynchronously.\n    - Threads. Not all guis will be able to integrate the event loop in their\n      own, so we need ability to run the event loop in a thread and run\n      callbacks there (which can than wake the gui main loop).\n    - Filesystem access.\n   Also it would be very nice to have:\n    - File alteration monitor. It would be very nice to notice changes in the\n      work area automatically and both Linux and Windows have, although\n      greatly incompatible, ways to get notifications for that, so it would\n      be nice to be able to use that.\n    - Bindings for languages. We can use Swig, but it has e.g. no support for\n      callbacks, so having portable runtime with already existing bindings\n      that support this would be an advantage.\n\nPortable runtime options:\n\n So what do you people think would be best? I see several options:\n\n - QtCore\n\n   Qt seems to be the most popular library among Git GUI writers and since\n   version 4.5 will be LGPL, so it will be allowed to link with anything.\n   It is also probably the most portable one. On the downside, it's rather\n   large and it's language bindings are a bit worse (the garbage collector\n   integration was a bit bad last time I looked).\n\n - Glib\n\n   This is C based, so the core could be in plain C. It is also quite modular\n   and has very good support for bindings to various languages. On the\n   downside it's a bit less portable and less used among the existing guis.\n   C would mean more work, but we could probably save some of it by using\n   gob2 (g object builder)\n\n - STL + Boost\n\n   I don't have experience with it, though I read some of the documentation.\n   It should be sensibly portable. I know it has python bindings, the rest\n   would probably have to be dealt with using swig.\n\n - POSIX + Msys on Windows\n\n   I guess it would technically be usable, but I think it would be rather lot\n   of additional work. It would probably be quite lightweight, though.\n\n - Apache portable runtime\n\n   I have no experience with this one.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec <bulb@ucw.cz>\n"},{"id":"105087","messageId":"e5bfff550902162340i1970eeb6ofcf8ce4ee7a35874@mail.gmail.com","threadId":"17832","inReplyTo":"e5bfff550902162337m43156398kb06320796838c953@mail.gmail.com","subject":"Fwd: [RFC] Common library for Git GUIs","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2009-02-17T07:40:05Z","receivedAt":"2009-02-17T07:40:05Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Mon, Feb 16, 2009 at 22:24, Jan Hudec <bulb@ucw.cz> wrote:\n>\n> Hello Folks,\n\n\nHi Jan,\n\n   nice to hear you again.\n\n\n>\n> Looking at the current situation with Git GUIs, I thought it might be useful\n> to create a generic library that would make it easier to develop git guis\n> (especially plugins to various tools) and to add a new features to many of\n> them with less effort. What do you people think about such idea?\n\n I fail to see the reason to do it given that git GUIs are already\nquite mature and stable tools, feature addition at this stage is only\nvery limited and for only small things. Big features are already in\nfrom a long time, as example (I speak about QGit but the same applies\nto the others):\n\n>\n>    - Tree of all files in the work area with their status\n>      Seeing status (unchanged/modified/staged/new/...) of individual files\n>      in Visual Studio is the most wanted features of my colleagues at $work.\n>      The feature is applicable for Windows shell extension (Tortoise Git),\n>      similar KDE and Gnome extensions and all IDE bindings.\n\n\nAlready in. Modified files are bolded.\n\nWhat qgit misses is new files (but this could be easily added if\nneeded because alre already known to qgit) and staged files (but I\ndont understund the useful of this info).\n\n>\n>    - Tree of files in given revision\n>      For browsing other revisions than the checked out one.\n\nAlready in.\n\n>\n>    - History *tree*\n>      Starting gitk as separate process is suboptimal, because versions from\n>      the tree can't be easily selected for operations (checkout, merge, ...).\n\nAlready in.\n\n>\n>    - Blob data\n>      For looking at other revisions than the checked out one.\n\nAlready in.\n\n>\n>    - Commit properties\n>      For showing details of revisions in the history view.\n\nAlready in.\n\n>\n>    - Diffs\n>      Obviously...\n\nAlready in.  Obviously :-)\n\n>\n>    - Annotations\n>      Again, should be integrated with the rest of gui, so selecting line in\n>      annotation can open the revision in diff view, select it in history\n>      etc.\n\nAlready in.\n\n>\n>    - Configuration\n>      Many tools (eg. gui designers) feature a tree view of all properties of\n>      some object (property grid) with editable values and short\n>      descriptions. It's not as nice gui designed for individual options, but\n>      can provide good-enough easy-to-write way to set all valid options from\n>      the gui.\n\n\nTo what should this feature apply? Some examples please?\n\n\n>\n>  - Menu and action definitions for the common operations\n\nAlready in. Plus customizable actions/macros.\n\n\n>\n>\n>  So what do you people think would be best? I see several options:\n>\n>  - QtCore\n>\n>   Qt seems to be the most popular library among Git GUI writers and since\n>   version 4.5 will be LGPL, so it will be allowed to link with anything.\n>   It is also probably the most portable one. On the downside, it's rather\n>   large and it's language bindings are a bit worse (the garbage collector\n>   integration was a bit bad last time I looked).\n\n\nI never felt the need for a garbage collector at all. I strongly\nprefer to spend time to manually fix the (very few) memory leaks that\nslept in. Qt class model already does object housekeeping for you at\ndeterministic and well known times (when parent object is deleted so\nare all corresponding children).\n\n\nThanks\nMarco\n"},{"id":"105132","messageId":"8b65902a0902170455lda80ea3ybb8ca94eb86d0453@mail.gmail.com","threadId":"17832","inReplyTo":"20090216212459.GA25046@efreet.light.src","subject":"Re: [RFC] Common library for Git GUIs","fromName":"Guilhem Bonnefille","fromEmail":"guilhem.bonnefille@gmail.com","sentAt":"2009-02-17T12:55:04Z","receivedAt":"2009-02-17T12:55:04Z","isPatch":false,"sender":{"key":"guilhem.bonnefille@gmail.com","avatar":"https://gravatar.com/avatar/375364bfee1f61197c540e37465abe3619fc24eb3a36b0edcea7f15b124036b0?d=mp&s=160"},"body":"Hi,\n\nI don't know if it is possible to elect a toolkit. Each toolkit is good.\n\nConcerning the design of the library, I think it is better to split\nthe library into different layers. The part of the e-world I know\nconcern Gtk/Gnome, so I will use it for my example.\n\nIMHO, it should be interesting to build a library containing only\nGObject'ification of Git and some wrappers/helpers to construct these\nobjects. For example, some objects to represent authors, commits,\nbranches, remotes and so on. Coupled to these base-types, this library\nshould provide solutions to construct these base-types (wrappers\naround Git commands and/or internal files).\nThis library can be named libgit-glib for example.\nSuch library can help developement of current UI (giggle, gitg,\nanjuta-git plugin, and probably others I don't know).\n\nThen, on top of this library, we can imagine another one providing\nhigh-level widgets. But it seems harder to identify common widgets\nbetween different GUI.\n\nIn order to justify my idea, take a look at Qt. They started with a\nlarge library, merging low-level with widgets. And then, they split it\nin order to allow access to low-level features only.\n\n\nI'm really interested in such project. So, if someone knows such\nproject, or create such a project, drop me a line, please.\n\nRegards,\n-- \nGuilhem BONNEFILLE\n-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com\n-=- mailto:guilhem.bonnefille@gmail.com\n-=- http://nathguil.free.fr/\n"},{"id":"105207","messageId":"20090217192825.GA2216@efreet.light.src","threadId":"17832","inReplyTo":"e5bfff550902162337m43156398kb06320796838c953@mail.gmail.com","subject":"Re: [RFC] Common library for Git GUIs","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2009-02-17T19:28:25Z","receivedAt":"2009-02-17T19:28:25Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Tue, Feb 17, 2009 at 08:37:13 +0100, Marco Costalba wrote:\n> On Mon, Feb 16, 2009 at 22:24, Jan Hudec <bulb@ucw.cz> wrote:\n> > Looking at the current situation with Git GUIs, I thought it might be\n> > useful\n> > to create a generic library that would make it easier to develop git guis\n> > (especially plugins to various tools) and to add a new features to many of\n> > them with less effort. What do you people think about such idea?\n>  I fail to see the reason to do it given that git GUIs are already quite\n> mature and stable tools, feature addition at this stage is only very limited\n> and for only small things. Big features are already in from a long time, as\n> example (I speak about QGit but the same applies to the others):\n\nUnfortunately I would not say that. There are many, many GUIs, but for me\neach of them fails in something. Qgit does not have pull/push and per-hunk\nstaging (which git gui does), while git gui does not integrate with gitk (to\neg. select revision to merge or cherry-pick from the version tree). Most\nothers don't have version tree etc.\n\nCurrently we finally dropped ConfusingCase at work, but my boss does not want\nto switch to git until it has good shell extension and visual studio plugin.\nGit Extensions are starting to look pretty good, but does not have the file\nstatus at all yet and in current TortoiseGit it does not work yet (some icons\nare overlaid, but they are not correct). When that works, that's windows, but\nwhat about KDE, Gnome and OS X...\n\nSo the motivation is to create something, that could factor out the features\nfrom the existing GUIs to make it easier for other GUIs to adopt. So all\nplugins can adopt version tree easily etc. Also the goal is to make writing\nnew GUIs -- meaning mainly plugins to more IDEs and other tools -- easier.\n\n> >    - Tree of all files in the work area with their status\n> Already in. Modified files are bolded.\n> \n> What qgit misses is new files (but this could be easily added if needed\n> because alre already known to qgit) and staged files (but I dont understund\n> the useful of this info).\n\nIn a stand-alone GUI not big, but in a plugin for an IDE it is nice to see in\nthe list of files in a project which ones are modified etc. Also all other\nversion control plugins do that, so it's what people expect.\n\n> >    - Tree of files in given revision\n> Already in.\n> >    - History *tree*\n> Already in.\n> >    - Blob data\n> Already in.\n> >    - Commit properties\n> Already in.\n> >    - Diffs\n> Already in.  Obviously :-)\n> >    - Annotations\n> Already in.\n\nYes - in Qgit. However, if I wanted to e.g. write a plugin for e.g. KDevelop,\nI would have to re-implement it all by direct calls to git program, because\nthe implementation inside existing guis is not much reusable. Which is why\nI propose to create some reusable code for such tasks.\n\n> >    - Configuration\n> >      Many tools (eg. gui designers) feature a tree view of all properties\n> >      of some object (property grid) with editable values and short\n> >      descriptions. It's not as nice gui designed for individual options,\n> >      but can provide good-enough easy-to-write way to set all valid\n> >      options from the gui.\n> To what should this feature apply? Some examples please?\n\nOften I need to configure some options in ~/.gitconfig and .git/config, but\nthe GUIs generally only allow to set very few basic ones. I had to resort to\nediting ~/.gitconfig to turn off the cursed core.autocrlf, because git gui\ndoes not have that setting. And there are many more settings like that that\nusers may want to tweak and something to guide them would be highly\nappreciated especially by the command-line-fearing windooze users.\n\nSo my idea is to provide some kind of \"property sheet\" -- a treeview with all\nthe sections and options with editable values with proper constraints (so\nboolean and enum values could be entered with drop-down menus) and\ndescriptions. If a generic library read the list of options from some data\nfile and provided the values in a QAbstractItemModel, than any Qt gui could\nsimply design the widgets (table + info pane) and instantiate that and have\nthe feature. And since Gtk, Windows.Forms and other toolkits have similar\ninterfaces, it is possible to provide an interface, that is easily adapted to\nany of them. If done right, that would simplify providing that feature and\nwhen new option would be defined in git, there would be just one place that\nwould need to know about it to make it settable with all the guis.\n\n> >  - Menu and action definitions for the common operations\n> Already in. Plus customizable actions/macros.\n\nI know that Qgit has it. Git Gui has it too -- done in an incompatible way,\nso if you define it in Qgit, you won't have it in Git Gui and vice versa.\nCommon implementation would improve the user experience in this case.\n\n> >  So what do you people think would be best? I see several options:\n> >\n> >  - QtCore\n> >\n> >   Qt seems to be the most popular library among Git GUI writers and since\n> >   version 4.5 will be LGPL, so it will be allowed to link with anything.\n> >   It is also probably the most portable one. On the downside, it's rather\n> >   large and it's language bindings are a bit worse (the garbage collector\n> >   integration was a bit bad last time I looked).\n> \n> I never felt the need for a garbage collector at all. I strongly prefer to\n> spend time to manually fix the (very few) memory leaks that slept in. Qt\n> class model already does object housekeeping for you at deterministic and\n> well known times (when parent object is deleted so are all corresponding\n> children).\n\nMy complaint is not about Qt in C++ -- where the ownership model is\nreasonable -- but about it's bindings for other languages. In python\nprogrammer expects all objects he has access to to be valid, but Qt objects\nwill be destroyed with their parents and accessing a reference to them\nafterwards will cause the python interpreter to segfault. The programmer can\navoid that by being careful not to leave such references around, but it's\na thing python programmer is not supposed to care about. That's why I say the\nbindings are a bit worse (comparing to e.g. Glib/Gtk, which gets this part\nright). It can be fixed by better bindings -- it is just that the bindings\nwhen I last saw them didn't handle it.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec <bulb@ucw.cz>\n"},{"id":"105213","messageId":"74161B7F-A178-49CB-990D-DF7299235C58@frim.nl","threadId":"17832","inReplyTo":"20090216212459.GA25046@efreet.light.src","subject":"Re: [RFC] Common library for Git GUIs","fromName":"Pieter de Bie","fromEmail":"pieter@frim.nl","sentAt":"2009-02-17T20:08:23Z","receivedAt":"2009-02-17T20:08:23Z","isPatch":false,"sender":{"key":"pieter@frim.nl","avatar":null},"body":"Hi,\n\nOn Feb 16, 2009, at 9:24 PM, Jan Hudec wrote:\n\n> What it should use:\n>\n> - It should probably be in C++ or C, with bindings for at least Perl,\n>   Python, Ruby, C#(CLR) and Java. The bindings can be done either  \n> with Swig,\n>   or using some base library that already has them.\n\nIt should be either C++ or C. If you want git devvers to work on it too,\nyou'll probably want to go with C.\n\n>   I think Java or CLR, while more portable, would not be appropriate  \n> because\n>   there is no standard way to combine them with other languages like  \n> Perl,\n>   Python and Ruby and those languages are still superior for the UI\n>   programming itself. I somewhat prefer C++, because polymorphism  \n> and some\n>   template tools would be useful here, but I am open to arguments.\n\nI think JGit is pretty far along for someone who wants to create a Java\nGUI.\n>    - Bindings for languages. We can use Swig, but it has e.g. no  \n> support for\n>      callbacks, so having portable runtime with already existing  \n> bindings\n>      that support this would be an advantage.\n\nI'd say bindings are pretty easy to create yourself.\n\n> Portable runtime options:\n>\n> So what do you people think would be best? I see several options:\n>\n> - QtCore\n>\n>   Qt seems to be the most popular library among Git GUI writers and  \n> since\n>   version 4.5 will be LGPL, so it will be allowed to link with  \n> anything.\n>   It is also probably the most portable one. On the downside, it's  \n> rather\n>   large and it's language bindings are a bit worse (the garbage  \n> collector\n>   integration was a bit bad last time I looked).\n>\n> - Glib\n>\n>   This is C based, so the core could be in plain C. It is also quite  \n> modular\n>   and has very good support for bindings to various languages. On the\n>   downside it's a bit less portable and less used among the existing  \n> guis.\n>   C would mean more work, but we could probably save some of it by  \n> using\n>   gob2 (g object builder)\n>\n> - STL + Boost\n>\n>   I don't have experience with it, though I read some of the  \n> documentation.\n>   It should be sensibly portable. I know it has python bindings, the  \n> rest\n>   would probably have to be dealt with using swig.\n\nNone of these, if you want any GUI's to use it. Noone is going to\ncreate a Gtk / Cocoa / Windows app that depends on Qt. Nobody wants\nto use Boost in any situation and Glib, while being smaller than the\nrest, is also difficult as it isn't shipped with many OS's, for example\nOS X.\n\n> - POSIX + Msys on Windows\n>\n>   I guess it would technically be usable, but I think it would be  \n> rather lot\n>   of additional work. It would probably be quite lightweight, though.\n\nI think lightweight is the way to go. If you go for C++, you can also  \nuse\nthe STL.\n\nBut, isn't this time spent better on getting libgit2 off the ground?\n"},{"id":"105216","messageId":"20090217203942.GB2216@efreet.light.src","threadId":"17832","inReplyTo":"8b65902a0902170455lda80ea3ybb8ca94eb86d0453@mail.gmail.com","subject":"Re: [RFC] Common library for Git GUIs","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2009-02-17T20:39:42Z","receivedAt":"2009-02-17T20:39:42Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Tue, Feb 17, 2009 at 13:55:04 +0100, Guilhem Bonnefille wrote:\n> I don't know if it is possible to elect a toolkit. Each toolkit is good.\n\nUnfortunately this is quite important question. The selected foundation\nneeds to be very portable and fairly lightweight. Heavy dependency would\ndiscourage gui implementors from using it.\n\nNote, that I am *not* talking about GUI toolkit! The layer I am proposing\nshould be gui toolkit agnostic or mostly so. Consider a model-view-controller\ndesign pattern. The goal is to provide generic model and controller parts in\none layer and adaptors to model interfaces (like QAbstractItemModel and\nGtkTreeModel) in a set of thin layers for each gui toolkit.\n\nAnother set of thin layers could wrap them for various dynamic languages --\npython, perl, ruby, C# (CLR) and Java, either using binding infrastructure of\nthe selected toolkit, or using Swig.\n\n> Concerning the design of the library, I think it is better to split\n> the library into different layers. The part of the e-world I know\n> concern Gtk/Gnome, so I will use it for my example.\n> \n> IMHO, it should be interesting to build a library containing only\n> GObject'ification of Git and some wrappers/helpers to construct these\n> objects. For example, some objects to represent authors, commits,\n> branches, remotes and so on. Coupled to these base-types, this library\n> should provide solutions to construct these base-types (wrappers\n> around Git commands and/or internal files).\n> This library can be named libgit-glib for example.\n> Such library can help developement of current UI (giggle, gitg,\n> anjuta-git plugin, and probably others I don't know).\n\nYes -- that's my idea. Basically it would be one layer for calling to git\nprogram behind the scenes, parsing and caching the results and presenting\nthem in a form of genericish API.\n\nSuch API must not be too generic -- that would be just pointless wrapping one\ninterface in another. The API would be strongly tied to the GUI features --\ne.g. an object holding all data a dialog for preparing commit needs. But it\nmust not be tied to any particular GUI, because that is usually restricted by\nthe environment one wants to integrate git with.\n\n> Then, on top of this library, we can imagine another one providing\n> high-level widgets. But it seems harder to identify common widgets\n> between different GUI.\n\nActually it is quite possible. There is a rather restricted set of\nprimitives:\n - button (also toolbar button and simple menu item)\n - choice (toggle button, check button, radio button group, combo box)\n - entry (entry, label (read-only entry))\n   - number entry (spinbutton, slider, scrollbar)\n   - text edit (for longer texts)\n - multi-column tree\n\nFor each of these primitives, you can create a generic interface:\n - button:\n\n   This is a method to be executed on the button activation. It might be\n   accompanied by name of the action, it's icon and a flag whether it should\n   be enabled.\n\n   Gtk has GtkAction and Qt has QAction, that do just this. We can easily\n   create simple object with the same properties and adapt it to both of\n   these and any similar interface used by any other toolkit.\n\n - choice:\n\n   This is a variable with current value, that can be read and written and an\n   array of valid choices. Some kind of signal must be emited when the value\n   is changed, either by gui or by underlying application logic.\n\n   I don't think there is a generic interface for this in either Gtk or Qt,\n   but a generic one can be written and connections to the relevant widgets\n   would than be generic for each toolkit.\n\n - entry:\n\n   This is just a variable with current value, that can be read and written.\n   Again, I don't think there is generic interface in Gtk or Qt, but one can\n   be written and the connections would than be generic.\n\n - number entry:\n\n   This is again a variable with current value, this time accompanied by\n   minimum, maximum, precision and possibly page size. Adaptation can be done\n   generically again.\n\n   I am not sure we actually need this. The only I can think of is some\n   numerical configuration options (like gc.reflogexpire) and that might not\n   be worth the hassle. Definitely for the earlier versions.\n\n - text entry:\n\n   Gtk has GtkTextBuffer, but Qt does not seem to have anything similar and\n   to tell the truth I don't think we need either. We simply provide the\n   initial text and get fed the final from the widget.\n   \n   Simple interface would be like for entry, where we provide the intial text\n   and get fed the final one.\n\n   Advanced interface needs to additionally support handling selection, so we\n   can support things like selecting hunks in a diff.\n\n - multi-column tree:\n\n   This is the most complex thing. It provides a tree of items, each of them\n   consisting of several columns. Each column may additionally be editable,\n   so it may need to be necessary to create one of the simple interfaces for\n   it. Selection handling, at least single-line, would also be needed.\n\n   For Gtk this would implement the GtkTreeModel and for Qt the\n   QAbstractItemModel. All modern widget toolkits (Gtk, Qt, Windows.Forms,\n   Cocoa, ...) have some kind of interface like that and they will be similar\n   enough so that we can create some and than generically implement the rest\n   in terms of that.\n\nThis is where I'd stop, since everything above that is very much specific to\nthe selected toolkit. However, if layer like this is done right, it can\nreally simplify creating the GUI itself quite a lot.\n\n> In order to justify my idea, take a look at Qt. They started with a\n> large library, merging low-level with widgets. And then, they split it\n> in order to allow access to low-level features only.\n> \n> I'm really interested in such project. So, if someone knows such\n> project, or create such a project, drop me a line, please.\n\nI am not aware of it existing. I was playing with an idea of refactoring some\nof the existing GUIs to get a generic library out of it. Mainly because I am\nnot really satisfied with any of them and I thought such refactoring would\nsimplify adding new features.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec <bulb@ucw.cz>\n"},{"id":"105219","messageId":"20090217212145.GC2216@efreet.light.src","threadId":"17832","inReplyTo":"74161B7F-A178-49CB-990D-DF7299235C58@frim.nl","subject":"Re: [RFC] Common library for Git GUIs","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2009-02-17T21:21:45Z","receivedAt":"2009-02-17T21:21:45Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Tue, Feb 17, 2009 at 20:08:23 +0000, Pieter de Bie wrote:\n> On Feb 16, 2009, at 9:24 PM, Jan Hudec wrote:\n>> What it should use:\n>> - It should probably be in C++ or C, with bindings for at least Perl,\n>>   Python, Ruby, C#(CLR) and Java. The bindings can be done either with\n>>   Swig, or using some base library that already has them.\n> It should be either C++ or C. If you want git devvers to work on it too,\n> you'll probably want to go with C.\n\nI don't think the really core devs need to work on this -- their time is best\nspent on the core. And many of the existing guis are in C++. For me, it\ndepends on the user portable runtime more than anything else.\n\n>>    - Bindings for languages. We can use Swig, but it has e.g. no  support\n>>      for callbacks, so having portable runtime with already existing\n>>      bindings that support this would be an advantage.\n> I'd say bindings are pretty easy to create yourself.\n\nThe advantage of swing is, that one definition with a few typedefs would\ngenerate Python, Perl, Ruby, CLR, Java and a few more bindings. GObject would\nneed more language-specific work, but would nicely solve integration into the\ngarbage collector. You know, I want to save as much work as possible.\n\n>> Portable runtime options:\n>> So what do you people think would be best? I see several options:\n>> - QtCore\n>> - Glib\n>> - STL + Boost\n> None of these, if you want any GUI's to use it. Noone is going to\n> create a Gtk / Cocoa / Windows app that depends on Qt. Nobody wants\n> to use Boost in any situation and Glib, while being smaller than the\n> rest, is also difficult as it isn't shipped with many OS's, for example\n> OS X.\n\nI fully agree that nobody will want to depend on Qt -- QtCore is now\na separate library, but the sources are not shipped separately AFAIK, so it'd\nbe a pain. I would not think the case is as strong against boost and glib,\nthough. People would either be getting binaries, in which case we can just\nbundle whatever dependency along, or building it and than one extra source\ntree (that can also be bundled for convenience) is not so much pain.\n\n>> - POSIX + Msys on Windows\n> I think lightweight is the way to go. If you go for C++, you can also use\n> the STL.\n\nSTL does not have any support for threads, event loop nor signals. Though\nthinking about it, we may not actually need them.\n - we only need threads if our event loop can't be integrated into gui's one\n   and the gui can start our in thread itself -- it's not too much code.\n - we only need file descriptors in the event loop and it needs to be\n   integratable into the gui's one anyway.\n - simple callback is quite likely good enough for us -- the gui will need\n   multiple callbacks, but it will need to connect in it's own signal system\n   anyway.\nSo the shell invocation remains and that's little enough we can cut&paste\nthat from glib.\n\n> But, isn't this time spent better on getting libgit2 off the ground?\n\nNo, because what I have in mind is orthogonal to libgit2. libgit2 is supposed\nto be generic API for git, while I am proposing a specifically gui-oriented\ninterface, which should implement all logic of a gui except opening dialogs\nand the widgets themselves, allowing the guis built on top of it to be\ntotally dumb. Actually part of my idea is to create something, that can be\nlater ported to libgit2 and immediately benefit many git interfaces.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec <bulb@ucw.cz>\n"},{"id":"105242","messageId":"alpine.DEB.1.00.0902180044550.10279@pacific.mpi-cbg.de","threadId":"17832","inReplyTo":"20090217212145.GC2216@efreet.light.src","subject":"Re: [RFC] Common library for Git GUIs","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-17T23:45:33Z","receivedAt":"2009-02-17T23:45:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 17 Feb 2009, Jan Hudec wrote:\n\n> I don't think the really core devs need to work on this -- their time is \n> best spent on the core.\n\nThank you for choosing what I should work on.\n\nCiao,\nDscho\n"},{"id":"105257","messageId":"1976ea660902171738j777e0af3mbd3b8aae8d1e7aaf@mail.gmail.com","threadId":"17832","inReplyTo":"20090217212145.GC2216@efreet.light.src","subject":"Re: [RFC] Common library for Git GUIs","fromName":"Frank Li","fromEmail":"lznuaa@gmail.com","sentAt":"2009-02-18T01:38:42Z","receivedAt":"2009-02-18T01:38:42Z","isPatch":false,"sender":{"key":"lznuaa@gmail.com","avatar":"https://avatars.githubusercontent.com/u/40642?v=4"},"body":"I think TortoiseGit need C\\C++ git library, which should be also used\nby git itself. Otherwise, it is difficult sync with git.\n\n2009/2/18 Jan Hudec <bulb@ucw.cz>:\n> On Tue, Feb 17, 2009 at 20:08:23 +0000, Pieter de Bie wrote:\n>> On Feb 16, 2009, at 9:24 PM, Jan Hudec wrote:\n>>> What it should use:\n>>> - It should probably be in C++ or C, with bindings for at least Perl,\n>>>   Python, Ruby, C#(CLR) and Java. The bindings can be done either with\n>>>   Swig, or using some base library that already has them.\n>> It should be either C++ or C. If you want git devvers to work on it too,\n>> you'll probably want to go with C.\n>\n> I don't think the really core devs need to work on this -- their time is best\n> spent on the core. And many of the existing guis are in C++. For me, it\n> depends on the user portable runtime more than anything else.\n>\n>>>    - Bindings for languages. We can use Swig, but it has e.g. no  support\n>>>      for callbacks, so having portable runtime with already existing\n>>>      bindings that support this would be an advantage.\n>> I'd say bindings are pretty easy to create yourself.\n>\n> The advantage of swing is, that one definition with a few typedefs would\n> generate Python, Perl, Ruby, CLR, Java and a few more bindings. GObject would\n> need more language-specific work, but would nicely solve integration into the\n> garbage collector. You know, I want to save as much work as possible.\n>\n>>> Portable runtime options:\n>>> So what do you people think would be best? I see several options:\n>>> - QtCore\n>>> - Glib\n>>> - STL + Boost\n>> None of these, if you want any GUI's to use it. Noone is going to\n>> create a Gtk / Cocoa / Windows app that depends on Qt. Nobody wants\n>> to use Boost in any situation and Glib, while being smaller than the\n>> rest, is also difficult as it isn't shipped with many OS's, for example\n>> OS X.\n>\n> I fully agree that nobody will want to depend on Qt -- QtCore is now\n> a separate library, but the sources are not shipped separately AFAIK, so it'd\n> be a pain. I would not think the case is as strong against boost and glib,\n> though. People would either be getting binaries, in which case we can just\n> bundle whatever dependency along, or building it and than one extra source\n> tree (that can also be bundled for convenience) is not so much pain.\n>\n>>> - POSIX + Msys on Windows\n>> I think lightweight is the way to go. If you go for C++, you can also use\n>> the STL.\n>\n> STL does not have any support for threads, event loop nor signals. Though\n> thinking about it, we may not actually need them.\n>  - we only need threads if our event loop can't be integrated into gui's one\n>   and the gui can start our in thread itself -- it's not too much code.\n>  - we only need file descriptors in the event loop and it needs to be\n>   integratable into the gui's one anyway.\n>  - simple callback is quite likely good enough for us -- the gui will need\n>   multiple callbacks, but it will need to connect in it's own signal system\n>   anyway.\n> So the shell invocation remains and that's little enough we can cut&paste\n> that from glib.\n>\n>> But, isn't this time spent better on getting libgit2 off the ground?\n>\n> No, because what I have in mind is orthogonal to libgit2. libgit2 is supposed\n> to be generic API for git, while I am proposing a specifically gui-oriented\n> interface, which should implement all logic of a gui except opening dialogs\n> and the widgets themselves, allowing the guis built on top of it to be\n> totally dumb. Actually part of my idea is to create something, that can be\n> later ported to libgit2 and immediately benefit many git interfaces.\n>\n> --\n>                                                 Jan 'Bulb' Hudec <bulb@ucw.cz>\n>\n"},{"id":"105271","messageId":"20090218055221.GD2216@efreet.light.src","threadId":"17832","inReplyTo":"alpine.DEB.1.00.0902180044550.10279@pacific.mpi-cbg.de","subject":"Re: [RFC] Common library for Git GUIs","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2009-02-18T05:52:21Z","receivedAt":"2009-02-18T05:52:21Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Wed, Feb 18, 2009 at 00:45:33 +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Tue, 17 Feb 2009, Jan Hudec wrote:\n> \n> > I don't think the really core devs need to work on this -- their time is \n> > best spent on the core.\n> \n> Thank you for choosing what I should work on.\n\nSorry. I didn't mean to tell you what should be doing.\n\nWhat would we mere mortals do without people like you working on git core,\nthoug?\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec <bulb@ucw.cz>\n"},{"id":"107012","messageId":"1234936574.20168.11.camel@bain-laptop","threadId":"17832","inReplyTo":"20090216212459.GA25046@efreet.light.src","subject":"Re: [RFC] Common library for Git GUIs","fromName":"Abhijit Bhopatkar","fromEmail":"bain@devslashzero.com","sentAt":"2009-02-18T05:56:14Z","receivedAt":"2009-02-18T05:56:14Z","isPatch":false,"sender":{"key":"bain@devslashzero.com","avatar":"https://gravatar.com/avatar/3f9bfde580be8d4de9df5a129387d9069d43eb1a65d745c583de9dfe9d97ebc8?d=mp&s=160"},"body":"\n> Looking at the current situation with Git GUIs, I thought it might be useful\n> to create a generic library that would make it easier to develop git guis\n> (especially plugins to various tools) and to add a new features to many of\n> them with less effort. What do you people think about such idea?\n> \nI don't think lack of library is holding this back, all the\nfunctionality is exposed through cli and i find it perfectly fine\ninterface. ( on teamgit side its lack of devtime :( thats holding it\nback) On the other hand a generic Qt/Gtk lib to interface with cli's\nwould be nice.\nIn any event i do not plan to switch to a library. Mainly because there\nis no value add (barring performance). And of-course, i already worked\nso hard to interface with the cli :D.\n\n> Unfortunately in current situation no gui really supports all I would need to\n> get my colleagues at work to accept git (they are somewhat obsessed with\n> plugin to Visual Studio and explorer and generally avoiding command line).\n> I started working on VS plugin some time ago, but I feel like a bit more\n> reuse would be in order.\nBTW take a look at git extensions for windows, it should provide both,\nwin ui and VS plugin based on msysgit\n\n> \n> The proposed library should contain:\n> \nI think an effort to convert git into libgit+cli is already underway,\nunless i missed something very obvious and you are talking about/for the\nsame effort.\n\nAnyway,\nSorry folks no interest here.\n\nBAIN\n"},{"id":"105272","messageId":"20090218055700.GE2216@efreet.light.src","threadId":"17832","inReplyTo":"1976ea660902171738j777e0af3mbd3b8aae8d1e7aaf@mail.gmail.com","subject":"Re: [RFC] Common library for Git GUIs","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2009-02-18T05:57:00Z","receivedAt":"2009-02-18T05:57:00Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Wed, Feb 18, 2009 at 09:38:42 +0800, Frank Li wrote:\n> I think TortoiseGit need C\\C++ git library, which should be also used\n> by git itself. Otherwise, it is difficult sync with git.\n\nI don't mean to reimplement a single bit of what is implemented in git\nitself. I want to factor out some stuff that is above git, only useful for\n_graphical_ user interfaces.\n\n> 2009/2/18 Jan Hudec <bulb@ucw.cz>:\n> > On Tue, Feb 17, 2009 at 20:08:23 +0000, Pieter de Bie wrote:\n> >> On Feb 16, 2009, at 9:24 PM, Jan Hudec wrote:\n> >>> What it should use:\n> >>> - It should probably be in C++ or C, with bindings for at least Perl,\n> >>>   Python, Ruby, C#(CLR) and Java. The bindings can be done either with\n> >>>   Swig, or using some base library that already has them.\n> >> It should be either C++ or C. If you want git devvers to work on it too,\n> >> you'll probably want to go with C.\n> >\n> > I don't think the really core devs need to work on this -- their time is best\n> > spent on the core. And many of the existing guis are in C++. For me, it\n> > depends on the user portable runtime more than anything else.\n> >\n> >>>    - Bindings for languages. We can use Swig, but it has e.g. no  support\n> >>>      for callbacks, so having portable runtime with already existing\n> >>>      bindings that support this would be an advantage.\n> >> I'd say bindings are pretty easy to create yourself.\n> >\n> > The advantage of swing is, that one definition with a few typedefs would\n> > generate Python, Perl, Ruby, CLR, Java and a few more bindings. GObject would\n> > need more language-specific work, but would nicely solve integration into the\n> > garbage collector. You know, I want to save as much work as possible.\n> >\n> >>> Portable runtime options:\n> >>> So what do you people think would be best? I see several options:\n> >>> - QtCore\n> >>> - Glib\n> >>> - STL + Boost\n> >> None of these, if you want any GUI's to use it. Noone is going to\n> >> create a Gtk / Cocoa / Windows app that depends on Qt. Nobody wants\n> >> to use Boost in any situation and Glib, while being smaller than the\n> >> rest, is also difficult as it isn't shipped with many OS's, for example\n> >> OS X.\n> >\n> > I fully agree that nobody will want to depend on Qt -- QtCore is now\n> > a separate library, but the sources are not shipped separately AFAIK, so it'd\n> > be a pain. I would not think the case is as strong against boost and glib,\n> > though. People would either be getting binaries, in which case we can just\n> > bundle whatever dependency along, or building it and than one extra source\n> > tree (that can also be bundled for convenience) is not so much pain.\n> >\n> >>> - POSIX + Msys on Windows\n> >> I think lightweight is the way to go. If you go for C++, you can also use\n> >> the STL.\n> >\n> > STL does not have any support for threads, event loop nor signals. Though\n> > thinking about it, we may not actually need them.\n> >  - we only need threads if our event loop can't be integrated into gui's one\n> >   and the gui can start our in thread itself -- it's not too much code.\n> >  - we only need file descriptors in the event loop and it needs to be\n> >   integratable into the gui's one anyway.\n> >  - simple callback is quite likely good enough for us -- the gui will need\n> >   multiple callbacks, but it will need to connect in it's own signal system\n> >   anyway.\n> > So the shell invocation remains and that's little enough we can cut&paste\n> > that from glib.\n> >\n> >> But, isn't this time spent better on getting libgit2 off the ground?\n> >\n> > No, because what I have in mind is orthogonal to libgit2. libgit2 is supposed\n> > to be generic API for git, while I am proposing a specifically gui-oriented\n> > interface, which should implement all logic of a gui except opening dialogs\n> > and the widgets themselves, allowing the guis built on top of it to be\n> > totally dumb. Actually part of my idea is to create something, that can be\n> > later ported to libgit2 and immediately benefit many git interfaces.\n> >\n> > --\n> >                                                 Jan 'Bulb' Hudec <bulb@ucw.cz>\n> >\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec <bulb@ucw.cz>\n"},{"id":"105273","messageId":"2fcfa6df0902172202n70c355dbg2a3f8ef50b9ea65c@mail.gmail.com","threadId":"17832","inReplyTo":"20090218055700.GE2216@efreet.light.src","subject":"Re: [RFC] Common library for Git GUIs","fromName":"Abhijit Bhopatkar","fromEmail":"bain@devslashzero.com","sentAt":"2009-02-18T06:02:04Z","receivedAt":"2009-02-18T06:02:04Z","isPatch":false,"sender":{"key":"bain@devslashzero.com","avatar":"https://gravatar.com/avatar/3f9bfde580be8d4de9df5a129387d9069d43eb1a65d745c583de9dfe9d97ebc8?d=mp&s=160"},"body":">> I think TortoiseGit need C\\C++ git library, which should be also used\n>> by git itself. Otherwise, it is difficult sync with git.\n>\n> I don't mean to reimplement a single bit of what is implemented in git\n> itself. I want to factor out some stuff that is above git, only useful for\n> _graphical_ user interfaces.\n>\n\nAh!!\nSorry i missed that detail in the orig long mail :(\nI still don't think it making things simpler. What you are proposing\nis yet one more abstraction. But me thinks cli abstraction is enough.\n\nAbstractions at interface levels are usefull, abstractions at\nfunctional level (gui's vs clis) are complex and don't solv anything.\nBAIN\n"},{"id":"105277","messageId":"e5bfff550902180004x5e10e391wb80988fa892da413@mail.gmail.com","threadId":"17832","inReplyTo":"20090217192825.GA2216@efreet.light.src","subject":"Re: [RFC] Common library for Git GUIs","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2009-02-18T08:04:47Z","receivedAt":"2009-02-18T08:04:47Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Tue, Feb 17, 2009 at 20:28, Jan Hudec <bulb@ucw.cz> wrote:\n>\n> Often I need to configure some options in ~/.gitconfig and .git/config, but\n> the GUIs generally only allow to set very few basic ones. I had to resort to\n> editing ~/.gitconfig to turn off the cursed core.autocrlf, because git gui\n> does not have that setting. And there are many more settings like that that\n> users may want to tweak and something to guide them would be highly\n> appreciated especially by the command-line-fearing windooze users.\n>\n> So my idea is to provide some kind of \"property sheet\" -- a treeview with all\n> the sections and options with editable values with proper constraints (so\n> boolean and enum values could be entered with drop-down menus) and\n> descriptions.\n\n\nThis is nice. Thanks for the idea, I will implement that in qgit when\nI find a bit of time :-)\n\n\n\nRegarding your proposal I really wish you good luck and especially \"have fun!!!\"\n\nFor me it is like to trash out 95% of the stuff and start again from\nzero because of the last 5% is missing (but I can add it anyway with\nmuch smaller effort and time spent).\n\nI understand the main reason, as per any GPL project, is having fun\nand good time coding and exchanging ideas with peers, but I really\nlack time and I am now moving to different interests. So, thank you\nvery much, but I think I'll stick with qgit.\n\nBest\nMarco\n"},{"id":"105399","messageId":"20090219073020.GC25870@gmail.com","threadId":"17832","inReplyTo":"e5bfff550902180004x5e10e391wb80988fa892da413@mail.gmail.com","subject":"Re: [RFC] Common library for Git GUIs","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2009-02-19T07:30:22Z","receivedAt":"2009-02-19T07:30:22Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On  0, Marco Costalba <mcostalba@gmail.com> wrote:\n> \n> I understand the main reason, as per any GPL project, is having fun\n> and good time coding and exchanging ideas with peers, but I really\n> lack time and I am now moving to different interests. So, thank you\n> very much, but I think I'll stick with qgit.\n> \n> Best\n> Marco\n\n\nOne thing, though, that I think everyone can agree on is\nthat getting a common lib for git guis is really step #2.\n\nStep #1 would be to work towards libgit, since it is something\nthat everyone would benefit from regardless of language or\ntoolkit.  I know that Shawn and co. have been working\ntowards this goal.  Keep it in C, keep it simple, and\nkeep git stupid.  A solid C core is portable and easy\nto wrap for Python, Ruby, Perl, etc.\n\nBTW I recall that one of the first questions in this thread\nwas \"what toolkit\" with proposed choices of QtCore, glib,\nPOSIX+Msys, etc.\n\nJust my $.02 -- I feel that the POSIX + MSys combination\nis the most viable solution since it has already been\nproven by the hard work of the msysgit team.  It is also\nthe environment which is most familiar to core git\ndevelopers and thus there is much benefit to staying\nwithin that world.  It's also the same choice made\nby Shawn in his libgit efforts.\n\nThe fact that git's output is identical regardless of\nplatform (for instance, git ls-files always uses \"/\" as\nits path delimiter, even on windows) is really what\nhas made creating portable git guis possible.\n\nGit to me is like a familiar and happy land that I know\nI can escape to even if I have the misfortune of being\nstuck on a windows machine.  Thus, a system like msys\nthat bends over backwards trying to make windows into\nsomething unix-like feels like the right way to go if\nyou ask me.  I'm *not* a windows user, though =)\n\n-- \n\n\tDavid\n"}]}