GNOME Bugzilla – Bug 556404
Patch to make meld run on windows
Last modified: 2009-03-07 16:42:42 UTC
Attached is a patch that attempts to get the basics of meld running on platforms that do not support the full gnome environment, naturally this includes windows (and as such the patch also contains some work to get meld working correctly on windows) It works good enuff for me to do a forthcoming *horrible* merge at work, it can merge and save files, however the normal warnings apply, don't blame me if this microwaves your cat YMMV. *Howto Apply:* 1 - Install windows compatible version of python 2.5 (I am using the active state distribution, I do not know if this makes a difference as I have not tested the python.org distribution) 2 - Download the latest developer GTK runtime 3 - Get the latest Glade kit 4 - Install the latest versions of PyCario / PyGObject and PyGTK 5 - Checkout meld from SVN (my patch is against rev 1061, but it should apply to trunk) 6 - Put the dev GTK and glade into your PATH e.g. `set PATH=C:\opt\gtk\bin;C:\opt\gtk\glade\bin;%PATH%' *It Must come ahead of any existing GTK+ runtimes* 7 - Fire up meld with `python meld' *Watch the pretty tracebacks and warnings* *Whats working* The basics appear to work correctly, this is the vcs, file and dir windows, however there are many breakages within the application. The state it is in after this patch it is usable enuff to do basic work with, but it defiantly lacks some of the niceties that meld currently has when running on *nix. The preferences pane does not work correctly and will not persist preferences at present, there is code there to back preferences onto a ConfigParser object, I think its something higher up that I am missing at present. The GnomeEntry and GnomeFileEntry widgets that I have replaced with the GTK+ equivalents have lost their nice history and auto complete behavior, I will look into making this work again, once I iron out some of the other bugs. Various bits in the views don't work properly, e.g. right clicking in the vc view and attempting to do a "compare" will result in a traceback. I intend to attack this once I have done the preferences. There are probably other breakages around the application, I would have held off from posting this but it seems that there is a fair amount of interest, and I feel that early exposure might help us to get it coded faster (sadly my real life keeps getting in the way of getting this finished). Help currently assumes a dumb default of finding help on the web, really it should be pointed locally if possible. In the future, I would like to get this finished, get it tested to see if it works on OSX (since gtk has been recently cut for OSX), and see if we can build meld with py2exe. Of course if anyone thinks that this is crap code, then start mocking :D Share and enjoy Greg Bowyer
Created attachment 120640 [details] [review] Win32 and Gnome reduction
First up: congratulations on getting it to work so quickly, and good luck with that merge! The following is just some very quick feedback (keeping in mind that I'm not the maintainer... I'm just an interested party). The patch doesn't apply to head; the glade files get rejects. The problem is that glade *loves* to rewrite your entire .glade file in some arbitrary order every time you make a minor change (for example, in your patch everything between lines 187 and 4928 is glade changes). I'm not sure how much you've actually changed in the .glade files, but if it's a relatively small amount of GnomeFileEntry->FileEntry or similar, then I usually do that sort of thing by hand. It's the only way I've found to get a clean, reviewable patch. You've made some basic portability-related changes to the VC directory-finding code that look sensible, but probably should go in separately to the gnome-related stuff - maybe you could split the patch? I've never touched the VC code, so I can't say whether those changes are right or not... someone else may be able to help you out there. Running under Gnome, I get a bunch of errors about icon.png, caused by the glade-based image loading being messed up. Fortunately, I have some GtkIconTheme-related patches that I'll try and get mergeable soon that should fix this. Your FileEntry recreation, while obviously still a work-in-progress, is probably the only way to keep the interface more-or-less unchanged. However, you probably want to start with a GtkComboBoxEntry and shove history into its tree model rather than manually recreate the dropdown. (Personally, I think it would be better to just use the stock GtkFileChooserButton for a small, simple port, and if history turns out to be necessary later on, then your rewrite would make a good start. But that's just my opinion...) Anyway, nice work.
Yeah sorry about the lack of decent apply to trunk, you are right, my copy of glade mangled the files a little. I will rework the glade files for they cleanly apply. ... I will split out the win32 elements I think from the gnome redcuiton elements, to be honest it was a last minute change that I put in when I spotted that on win32 all the vc plugins were going to go round forever trying to find / from C:\. ... The icon.png this is an artifact of win32 glade deciding that it knows best about where the icon should be found. However can I hold off on that until you have your GtkIconTheme work mergable (or semi mergable) You are right about the FileEntry being a work in progress, and that a lot of the design is based around trying to keep the interfaces as similer as is possible to the original version. I did think about using the GTkFileChooserButton, however I find the button not very user firendly from a view point of being able to dive into the box and type a new file name. I will however look into the suggestion about using a GtkComboBox instead of attempting to rebuild the wheel.
Created attachment 122550 [details] [review] Patch removing libgnomeui dependency from meld Part of getting meld to run on Windows is removing the libgnomeui dependency. This means replacing GnomeEntry, GnomeFileEntry, GnomeAbout, and GnomeFontPicker. This patch removes these widget, replacing GnomeAbout and GnomeFontPicker with Gtk equivalents, and adding a python port of Gedit's HistoryEntry to replace GnomeEntry, and porting GnomeFileEntry to python.
So, the above patch provides functional replacements for GnomeEntry and GnomeFileEntry. I'm sure there are still bugs there, but it seems to work for me... it even fixes a couple of annoyances (i.e., selecting a file from the file dialog now activates the text entry, causing a comparison). However, it introduces a new dependency on atk (easy to rip out, but should be installed by default with pygtk), and it depends on both gconf and gnomevfs. For the new widgets, making gconf optional would be easy; it just kills history-saving. Likewise, gnomevfs is used only once and only simply. The patch does *not* fix the VC-path problems, gconf-replacement, etc. that Greg's patch addresses. If no one complains, I'll commit the patch in more digestable pieces after meld has branched.
Created attachment 122775 [details] [review] Patch removing libgnomeui dependency from meld Update version of patch 122550 that makes gnomevfs and gconf optional for the new widgets. If these cannot be imported, history saving and drag n' drop are simply disabled for these widgets, but everything else should work as expected.
Brilliant, at last the gnome.ui dependency is gone. I've commited Kai's patch to svn. Greg, could you pick out the other relevant bits from your original patch and reattach? I came across a few issues: * The second time browse... is clicked the dialog is somehow invalid and crashes. * VcView fileentry needed an explicit .show() call. Somehow, dirdiff didn't * Copy & paste in he entries is not enabled (though the context menu works) * It would be nice to have gobject.property as a decorator so they are near the relevant methods
> * The second time browse... is clicked the dialog is somehow invalid and crashes. Fixed in svn. > * VcView fileentry needed an explicit .show() call. Somehow, dirdiff didn't In dirdiff, the set_num_panes callback explicitly shows/hides all file entries, but there is no equivalent in vcview. The reason it's needed at all is that libglade doesn't set common properties on custom created widgets (see bug 97503). I've made a note of this, but given the age of the bug I doubt it's likely to be fixed any time soon. > * Copy & paste in he entries is not enabled (though the context menu works) Working on this. It works for dialogs using the widgets, but not in the main view. On the upside, it didn't work before, so it's not a regression. > * It would be nice to have gobject.property as a decorator so they are near the relevant methods Hmmm... this is a tradeoff, since you either have half of the properties as decorators on class methods, and then specifically declare non-method-backed properties elsewhere, or you can group them all together. I went with the second option, but if you prefer I can easily go the other way.
Addendum to the above: the cut/copy/paste bug has been resolved (in r1092), fixing a couple of other bugs in the process. The shortcuts were being eaten by custom handling in melddoc and filediff.
Created attachment 127707 [details] [review] Updated and slightly modified version of Greg's patch I've updated Greg's patch to current head, cleaning some of it up along the way and trying to minimise the changes. Apart from a little rewording of comments (hope you don't mind Greg) the biggest change to Greg's code is the find_vcs_root method. Meld's original version wouldn't work on Windows for several reasons, but Greg's version walked a lot of directories that it didn't need to. I've rewritten Meld's existing version such that it should work either way. I want to emphasise that this is just an updated version; it's entirely untested, and not ready to be committed. Ideally, someone familiar with the VC code should review those changes and get them in, at which point the Preferences code is relatively low-risk.
No I dont mind at all, to be honest I have been very slack on this, new job and a lack of windows made this much less a problem I needed to fix. The vcs walk, was largly me just hacking the existing implementation to avoid it trying to run back to / (not htere on win32). I will pull out meld sometime this week and see if / what can be done to finsih this off Many thansk for carrying this onwards
As per Kai's comment, I took parts of the VC fixes, and committed them after factorization, please look at bug Bug #573049 for details. Not yet taken from patch 127707: - git reordering of directory walk vs GIT_DIR env var use - monotone code not reviewed
Created attachment 129869 [details] [review] Updated patch Rebased patch, updated to after Vincent's VC refactoring
I've rebased the patch to current SVN. I dropped the git reordering - it doesn't seem significant to this bug at least. The monotone changes are still in there, though I suspect that they're also unnecessary. Anyone who knows the VC subsystem better should chime in... At this stage, more-or-less all that this patch does is remove our reliance on gconf by providing an alternative backend. The only questionable bit here is that our use of gconf is not exactly transparent, so there are a few knock-on effects, code-wise at least. I'll try to get around to doing a proper review some time, but any assistance would also be welcome.
Took almost all of monotone hunk, I just left the os.path.normpath() in, since I don't know if this will change the behavior and break. Committed in r1207.
I've just committed the remaining hunk of the patch implementing a ConfigParser fallback if we can't import gconf. I made a few small changes, mostly just tweaking little bits of behaviour. Most notably, I changed the backend to put the config file in ~/.meld/meldrc.ini, and %APPDATA%/meldrc.ini on Windows; this is XP-and-later only, but does the right thing for those systems and seems like the right place to put settings. I tested this by disabling gconf, and the ConfigParser backend works fine for me. However, I don't have access to a Windows box, so further testing will have to be done by someone else. I'm closing this bug, since the last of the patch has been applied. I think at this point most of the hard non-gtk dependencies are gone (though a few gnomevfs calls remain), so it's probably easier to work through any remaining problems as separate bugs or on the mailing list. Thanks for the patch.