I was thinking the exact same thing as André when I first saw these mails. Exporting patchfiles or some other diff format, then comparing those in Meld seems a lot less cumbersome than having to implement support for all the different ways in which you may need to obtain the two initial diffs for comparison.
I don't know if Meld can generate patchfiles, the projects I work with are typically on TortoiseSVN so I usually get my two patchfiles from there and then pop them into Meld when I need to 'diff a set of diffs'. But if not, implementing an export functionality seems like it would be less complicated (existing libraries?) and cover a much wider use case for all users. Just my two cents :) -- Leovi Le sam. 30 mai 2020 à 02:26, andré via meld-list <[email protected]> a écrit : > Le 20-05-26 à 05 h 29, Kai via meld-list a écrit : > > First up, sorry about taking ages to respond. There's just been a lot > > happening. > > > > As for your idea, it's intriguing. I kind of feel like this could be > > implemented as a sufficiently complex set of git refspecs, but obviously > > that would need to be done for all version control systems. I'm not sure > > whether this would be something for Meld proper... if we had a plugin > > architecture (as you say below) it feels like a perfect fit for this. > > > > On Tue, 31 Mar 2020 at 04:56, Waldo Withers <[email protected] > > <mailto:[email protected]>> wrote: > > > > I'll plan on just making my own fork for now. I'll try to > > incorporate anything that makes sense in base Meld, like adding > > patches under diffs or having a read-only-by-default option. > > > > > > We *kind of* have this already in the way we treat diffs from version > > control (and read-only files). I'm not sure how we'd extend it further, > > but maybe? > > > > I think ideally I'd make a plugin, but plugin support seems very > > difficult to add, and so it's probably not worth it. (If I'm wrong > > about this, let me know. I'd be willing to do the work to add plugin > > support if it's not too difficult, though that'd still entail some > > guidance and help with code on your part.) Other than plugin > > support, I haven't run across anything that needs changing to make > > my stuff easier, but I'll let you know. > > > > > > I'd love to add plugin support, but honestly it's likely to be a large > > amount of work, particularly given the hooks you'd need for this. I > > haven't spent a lot of time on it, but libpeas looks promising for > > adding plugin support with some UI support, but I really think that > > adding the appropriate hook points might be very tricky. > > > > I am having trouble using Glade. It says, "Failed to load > > [path]\meld\resources\ui\appwindow.ui. The following required > > catalogs are unavailable: meld.ui.gladesupport.", and when I open > > new-diff-tab I get "Unable to create object with type > > MeldFileChooserDialog". I see there's a \meld\ui\gladesupport.py, > > but I don't know how to use it or if that's what I need. > > > > > > So this is harder in current master, and I haven't looked at fixing it > > yet. However, from a 3.20 checkout you should be able to do something > like: > > > > PYTHONPATH=./ GLADE_CATALOG_SEARCH_PATH=./meld/ui/ > > GLADE_MODULE_SEARCH_PATH=./ glade data/ui/filediff.ui > > > > and *most* of the widgets should work. You may have to go back in > > afterwards and fix things that glade has replaced with placeholders. I'm > > also not confident that those search paths are correct... I do this > > rarely enough that it's trial and error. I typically hand-edit the .ui > > files, but I realise that's less than ideal. > > > > I've made an attempt to allow all of our widgets to have a sane empty > > render state in glade, but that routinely breaks because it's tricky to > > maintain given actual application state management, and because it's not > > typically that important. Patches to fix these are always welcome, but > > it's also tricky because most of our widgets (somewhat unfortunately) > > connect to application-global config. > > > > Thanks for the help, and for all the dev on Meld. It was the best > > differ I found to base this off of. > > > > > > Thanks for the kind words, and again I'm sorry about my slackness in > > replying. Good luck with your project! > > > > cheers, > > Kai > > > Just an initial impression without much thought, but wouldn't exporting > the diffs of a1 vs a2 and b1 vs b2, > then comparing the exported diffs work ? > I'm assuming that diffs can be exported. > It could be a little cumbersome, but wouldn't it work ? > > -- > André > _______________________________________________ > meld-list mailing list > [email protected] > https://mail.gnome.org/mailman/listinfo/meld-list >
_______________________________________________ meld-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/meld-list
