Hi, On Wed, 11 Mar 2009, saurabh gupta wrote: > On Wed, Mar 11, 2009 at 7:32 PM, Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: > > > 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. > > okay. In that case, if they have a different user interfaces then > separate plug-in would be needed for each of these. May be this will get > more messy. The thing is: "plugin" is an architecture issue, which I think we will have plenty of time hashing out. "GUI" is the bigger problem, because if we cannot come up with something that is worth implementing, we can stop the project early. > >> 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... > > hmmmm.....I think I get your point somewhat. Let me do some research > over the formats and the background formats in which tools like > OpenOffice store the data in xml files. May be for docbooks by > OpenOffice, the best thing would be to give the *diff* output in terms > of lines. Actually, I think that the diff is not the issue. What is needed is a way that is both intuitive and versatile enough that all kinds of merge conflicts in OpenOffice documents can be resolved by a total computer illiterate. The same problem applies for SVG files, but the user interface would look completely different. As such, it might not be wise to have a common framework at all, but to make the first an extension for OpenOffice, and the second a modification of, say, inkscape. Of course, David will then come and say: "But that is more appropriate a project for OpenOffice and inkscape, then!". The good thing is that this is Open Source, and we'll just ask them to co-mentor this project. > I would also appreciate to know what you think and would like to see the > output in such case. That's the thing: I do not know yet how it should look like. Ciao, Dscho -- 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
