On Wed, Mar 11, 2009 at 9:08 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > 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. We can decide for the GUI part. RIght now, I am going through the background for Tcl/Tk. I am sure that using this tool will serve the purpose in the better way and portability issue can also be kept in mind. >> >> 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. All right. I agree with this and We can come up with a plan to implement the thing in an organized way. I agree with you that one common platform for these will not work because of the way they are represented and is comfortable for a normal computer user. >> 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 > > -- Saurabh Gupta Senior, NSIT,New Delhi, India -- 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
