From: david@lang.hm Date: Wed, 11 Mar 2009 16:32:05 GMT Subject: Re: Google Summer of Code 2009: GIT Message-ID: In-Reply-To: On Wed, 11 Mar 2009, Johannes Schindelin wrote: > Hi, > > On Wed, 11 Mar 2009, saurabh gupta wrote: > >> What I think is to implement file formats other than text like that >> written on wiki i.e. latex, xml, or even any database file (db file). >> Another idea (although it can be weired also) is to implement the new >> file formats in the plug-in formats. For example, to incorporate the >> merger engine for a new file format, a plug-in is created and can be >> integrated with the present merger in the git. However, I am not sure >> how much valid is this idea to make the present merger in git to be >> compatible with the plug-ins for enabling newer file formats. > > I am not sure that a plugin structure is needed. Take, for example, three > different .xml based formats: OpenOffice documents, .svg files and Ant > build.xml files. They need very different user interfaces. > >> I am thinking of using gtk+ libraries to implement the GUI part (I am >> quite comfortable with gtk+). > > I mentioned Tcl/Tk, because it is portable, but I'll also take gtk-based > stuff ;-) > >> However, I think in merging and notifying about the conflicts in the xml >> files, other things can also be put forward. Like the GUI will show the >> number of tags differing and what are the new tags added and even if any >> tag is renamed with the content unchanged. If possible, how about >> showing a tree like structure (just like DOM model) to compare (or diff) >> the two xml files. > > This is a little bit too low-level for my liking. Taking the OpenOffice > example again, the GUI should not expose XML at all... don't assume that you have a GUI just to handle a filetype. if you have one, good, make use of it. but have a fallback for how to deal with things if all you have is a text terminal. David Lang