Re: Diff Differ Project Coordination

[Leovi Nutakor <lvnutakor gmail com>]

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 <meld-list gnome org> 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 <lencho dwight gmail com
> <mailto:lencho dwight gmail com>> 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
meld-list gnome org
https://mail.gnome.org/mailman/listinfo/meld-list