Re: ctrl+tab switching

[Kai via meld-list]

On Wed, 16 Sep 2020 at 07:02, Donjan Rodic  wrote:

> After having used it for a couple of days, I'm happy to report that it
> works well. (binds in ui/notebook.py & unbinds in resources/meld.css)
> Thank you!
>
> These shortcuts are mightily useful IMO... any chances an MR with these
> changes would get accepted?
>

Not really, I'm sorry. I'm glad that it's working for you, but I have a
strong aversion to changing toolkit-level behaviour if we can avoid it. In
this case in particular, there are already established standard GNOME
shortcuts for changing notebook pages that we support. I would also feel
particularly bad about removing existing focus handling shortcuts; I don't
use them, but I wouldn't want to discount e.g., accessibility concerns that
this would cause.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: show absolute path instead of filename

[Kai via meld-list]

There's plenty of discussion at
https://gitlab.gnome.org/GNOME/meld/-/issues/84 about the issues around
this and some possibilities. The current state of 3.21.x has full path
display, but it will not stay as-is because it's extremely ugly. I haven't
yet got around to designing/implementing a more presentable option though.

cheers,
Kai

On Sun, 6 Sep 2020 at 04:26, Wes Westhaver  wrote:

> I agree with this. I find it difficult to differentiate the files
> (especially when doing a three way compare). Maybe a tool-tip could
> display the full file path/name when the mouse hovers over a file name?
>
>
> On 9/5/20 1:47 PM, Fourhundred Thecat wrote:
> > Hello,
> >
> > is it possible to show absolute path of the 2 files I am currently
> > viewing?
> >
> > Currently when I am comparing 2 files, I only see the filenames on top.
> > Since the filenames are the same (but in different paths) it is
> > confusing to see which is which.
> >
> > I did not find any such option in preferences.
> >
> > Is there a simple way to change this in sourcecode ?
> >
> > thanks,
> > ___
> > meld-list mailing list
> > meld-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/meld-list
> ___
> meld-list mailing list
> meld-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/meld-list
>
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: disable "tabs" in meld window

[Kai via meld-list]

Replace
self.notebook.child_set_property(page, 'tab-expand', True)\
with
self.notebook.child_set_property(page.widget, 'tab-expand', True)

cheers,
Kai

On Sat, 5 Sep 2020 at 14:16, Fourhundred Thecat <400the...@gmx.ch> wrote:

>  > On 2020-09-04 00:52, Kai wrote:
> > On Tue, 1 Sep 2020 at 15:40, Fourhundred Thecat <400the...@gmx.ch
> > > wrote:
> >
> > There's no way to do this in 3.20 without editing code, but this has
> > changed to be the default in the unstable 3.21.x. The commit that
> > changed this is
> >
> https://gitlab.gnome.org/GNOME/meld/-/commit/133aaccfcb32ed7c5778fbbd8f76bf609d09ba35
> ,
> > which you could probably apply to 3.20.x, though I haven't tried.
>
> Thank you Kai.
>
> I have patched meld/meldwindow.py and meld/ui/notebook.py in 3.20 based
> on this commit.
>
> However, I get this error when I run meld:
>
>
> Traceback (most recent call last):
>File "/usr/lib/python3/dist-packages/meld/meldapp.py", line 79, in
> do_command_line
>  tab = self.parse_args(command_line)
>File "/usr/lib/python3/dist-packages/meld/meldapp.py", line 365, in
> parse_args
>  focus=i == 0,
>File "/usr/lib/python3/dist-packages/meld/meldapp.py", line 159, in
> open_files
>  return window.open_paths(gfiles, **kwargs)
>File "/usr/lib/python3/dist-packages/meld/meldwindow.py", line 688,
> in open_paths
>  auto_merge=auto_merge)
>File "/usr/lib/python3/dist-packages/meld/meldwindow.py", line 637,
> in append_diff
>  gfiles, merge_output=merge_output, meta=meta)
>File "/usr/lib/python3/dist-packages/meld/meldwindow.py", line 598,
> in append_filediff
>  self._append_page(doc, "text-x-generic")
>File "/usr/lib/python3/dist-packages/meld/meldwindow.py", line 547,
> in _append_page
>  self.notebook.child_set_property(page, 'tab-expand', True)
> TypeError: argument child: Expected Gtk.Widget, but got
> meld.filediff.FileDiff
>
>
> could somebody more experienced with python programing suggest how to
> properly apply this patch in meld 3.20 ?
>
> thank you,
> ___
> meld-list mailing list
> meld-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/meld-list
>
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: disable "tabs" in meld window

[Kai via meld-list]

On Tue, 1 Sep 2020 at 15:40, Fourhundred Thecat <400the...@gmx.ch> wrote:

> Hello,
>
> when meld opens new window, it actually shows a tab (similar to browser
> tab). Presumably, if other instance is opened this will open second tab
> in existing window, instead of second window. Same as with browsers.
>
> Is it possible to disable this functionality?
>

There's no way to do this in 3.20 without editing code, but this has
changed to be the default in the unstable 3.21.x. The commit that changed
this is
https://gitlab.gnome.org/GNOME/meld/-/commit/133aaccfcb32ed7c5778fbbd8f76bf609d09ba35,
which you could probably apply to 3.20.x, though I haven't tried.

Having the instances be completely separate is a different problem which
requires a flag to disable the application session management. This is
annoying to do right for a few reasons, and there's an open issue for it.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: ctrl+tab switching

[Kai via meld-list]

On Fri, 28 Aug 2020 at 19:40, Donjan Rodic  wrote:

> Now I'm not sure if the "next pane" concept refers to just that,
> switching between left and right. Or if it actually should cycle through
> the tabs that appear in the top row, which is what I want, as outlined
> in the original post. That would be "notebook page" concept relevant to
> the "notebook.set_current_page()" code, e.g. tabbing through 20
> comparisons opened from a directory diff view.
>

Sorry, I misread the original post. You're right, and pane switching is not
what you want.


> I'm simply searching for a way to bind the Ctrl+Tab accelerator to
> something like this pseudocode:
>
>  notebook.set_current_page(get_current_page()+1)  # respectively -1
>

If you add

  bind "Tab" { "change-current-page" (1) };
  bind "Tab" { "change-current-page" (-1) };
to the CSS in notebook.py, the accelerators will mostly work, provided that
focus is on a child of the notebook. You'll also need the CSS unbind. For
me there appears to still be something catching Ctrl+Tab when the notebook
isn't in the focus chain.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: ctrl+tab switching

[Kai via meld-list]

I believe that the reason none of your options have worked is that you need
to unbind the Ctrl+Tab and Ctrl+Shift+Tab accelerators as well as adding
their use. I think if you  adapted your (B) attempt and added unbinding of
the default handling, it may well work. I've attached something that I
tried on current master that appeared to work, but this *will not* work on
3.18.x.

cheers,
Kai

On Sat, 22 Aug 2020 at 19:01, Donjan Rodic  wrote:

> I'm using Meld a lot recently and my productivity would be increased if
> Ctrl+Tab and Ctrl+Shift+Tab were available for switching to the next,
> respectively previous, tab (notebook page). I'm aware that GNOME doesn't
> like this particular shortcut, but I've set it up in every other GNOME
> application I use (Gedit, gnome-terminal, Nautilus) and find it to be
> highly efficient.
> I've tried to hack it unsuccessfully and would like to request some
> help. This was done on Meld 3.18.0 (default Ubuntu 18.04 repo version).
> If newer versions help with this particular issue, I'll sideload...
> updates will eventually catch up.
>
> Attempt A)
> In meldwindow.py:MeldWindow:__init__() write these built-in Gtk methods:
>
>  from meld.meldapp import app
>  app.set_accels_for_action("win.tab-previous",
> ["Tab", "Page_Up"])
>  app.set_accels_for_action("win.tab-next", ["Tab",
> "Page_Down"])
>  print(app.get_accels_for_action("win.tab-next"))
>
> The keybindings get stored (printed) correctly, but apparently Meld
> ignores this feature.
>
>
> Attempt B)
> In meldwindow.py:MeldWindow:__init__(), there is a block "# Add
> alternate keybindings ..." setting F5 etc. Just below, write:
>
>  (keyval, mask) = Gtk.accelerator_parse("J")
>  accels.connect(keyval, mask, 0, lambda *_:
> self.notebook.set_current_page(1))
>  (keyval, mask) = Gtk.accelerator_parse("Tab")
>  accels.connect(keyval, mask, 0, lambda *_:
> self.notebook.set_current_page(1))
>  (keyval, mask) = Gtk.accelerator_parse("KP_Tab")
>  accels.connect(keyval, mask, 0, lambda *_: print("foo"))
>  (keyval, mask) = Gtk.accelerator_parse("ISO_Left_Tab")
>  accels.connect(keyval, mask, 0, lambda *_: print("bar"))
>
> Now Ctrl+J correctly switches to the second tab from the left, but
> Ctrl+Tab and Ctrl+Shift+Tab get ignored (no terminal output either).
> They do iterate through Meld's icon list at the top, for what that's worth.
>
>
> Attempt C)
> In filediff.py:FileDiff:on_key_event(), write:
>
>  if event.state & Gdk.ModifierType.CONTROL_MASK and
> Gdk.keyval_name(event.keyval) == 'Tab':
>  print("switch to tab right")
>
> This correctly prints to the terminal when Ctrl+Tab is pressed. But I'm
> at a loss on how to hook it up to notebook.set_current_page() here.
> app = Gtk.Application.get_default()   is empty and I can't get a higher
> parent than self.widget.
>
>
> Attempt D)
> In meldwindow.py:MeldWindow:__init__(), register the signal:
>
>  self.connect("key-press-event",self.on_key_press_event)
>
> #...
>
>  def on_key_press_event(self, window, event):
>  print("key press event")
>
> crashes with "AttributeError: connect", unless I let MeldWindow
> additionally inherit from
>
>melddoc.MeldDoc
>
> or
>
>GObject.GObject
>
> and call
>
>melddoc.MeldDoc.__init__(self)
>
> respectively
>
>GObject.Object.__init__(self)
>
> , in which case it simply doesn't know the signal name. Also, inheriting
> from Gtk.Window yields
>
>File "/usr/lib/python3/dist-packages/meld/ui/gnomeglade.py", line 47,
> in __init__
>self.widget = getattr(self, root)
>RuntimeError: field is not writable
>
>
> Attempt E)
> Using an external library pretty much anywhere:
>
>  from pynput.keyboard import Listener
>  with Listener(on_press=self.my_press,
> on_release=self.my_release) as listener:
>  listener.join()
>
>  def my_press(key, *_):
>  print("Key pressed: {0}".format(key))
>  def my_release(key, *_):
>  print("Key released: {0}".format(key))
>
> Works in principle by printing any pressed keys. But it's blocking
> w.r.t. Meld's loops, so the GUI doesn't show.
>
>
> Help?
>
> Best
> Donjan
> ___
> meld-list mailing list
> meld-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/meld-list
>
diff --git a/meld/accelerators.py b/meld/accelerators.py
index ad116e06..d3030250 100644
--- a/meld/accelerators.py
+++ b/meld/accelerators.py
@@ -12,10 +12,10 @@ VIEW_ACCELERATORS: Dict[str, Union[str, Sequence[str]]] = {
 'view.go-to-line': 'I',
 # Overridden in CSS
 'view.next-change': ('Down', 'KP_Down', 'D'),
-'view.next-pane': 'Page_Down',
+'view.next-pane': ('Page_Down', 'Tab'),
 # Overridden in CSS
 'view.previous-change': ('Up', 'KP_Up', 'E'),
-'view.previous-pane': 'Page_Up',
+'view.previous-pane': ('Page_Up', 'Tab'),
 'view.redo': 'Z',
 'view.refre

Re: Windows dev environment

[Kai via meld-list]

On Sun, 16 Aug 2020 at 00:32, Adam Antium via meld-list 
wrote:

> Hey,
>
> I'm wondering what tools people are using in windows for a development
> environment when they are working on Meld?
>
> I was about to try to get a convenient setup going in VS Code (which I
> only recently started using) for debugging etc., but I thought I'd check if
> anyone had any strong opinions or experiences that could be useful.
>

I'll let people with more Windows experience speak, but I think VS Code is
probably a good option. We have some limited linting configuration that I
think should be easy to get working with default Python plugins.

If you do end up getting a nice setup going, it would be good to get steps,
etc. documented on the project wiki.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: new contributor

[Kai via meld-list]

On Sat, 15 Aug 2020 at 06:05, Vasily Galkin  wrote:

> Logically, after merging 61 to master the your MR should become green to.
>
> However, technically I'm not sure that gitlab reruns CI the merge-target
> branch changes.
>

Sadly, it doesn't (or at least it's not configured to do so... not sure
which). However, both MRs have been merged now, so we're all good! Thanks
to you both.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: new contributor

[Kai via meld-list]

On Fri, 14 Aug 2020 at 06:11, Adam Antium via meld-list 
wrote:

> I have a simple fix for issue #354, I posted a comment on the issue page.
>
> Are there some basic guidelines for testing code changes? How much
> checking should I be doing of, for example, path formats and stuff like
> that?
>

For cases like this issue where there's not really much risk of unexpected
interactions with other functionality, I wouldn't worry too much about it.
Specifically in your case here, I'd probably just... check that
os.startfile does the right thing for folders, text files and "other" files
(which are the three clear cases that that code needs to handle) and that's
enough.

Also I am a bit unsure about the cleanest way to do a code submission after
> a fix, should I check out a whole new clean source to make the changes in
> to avoid polluting it with random stuff?
>

While the instructions are based around GNOME tools, there's a guide at
https://wiki.gnome.org/Newcomers/SubmitContribution that covers the basic
process. In short, make a fork on GNOME gitlab (where you already have an
account), clone that locally, make your changes, push a branch with your
change and create a merge request.

When you create the MR you can see what changes you're proposing, so that's
a good time to double-check that there's nothing extraneous there. If you
have issues or questions, I'm happy to try to help out. Also don't worry if
the MR isn't perfect! It's all easy enough to change after the fact.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Slow startup under Windows10

[Kai via meld-list]

Sorry, this fell off my radar.

On Mon, 15 Jun 2020 at 20:41, ISHIKAWA,chiaki  wrote:

> The startup of meld is very slow under windows.
>


> Does anyone have an idea? Are there dlls under windows that do not get
> cached for some reason?
>

We have several open issues about slow startup under Windows. A very quick
search found:

https://gitlab.gnome.org/GNOME/meld/-/issues/334
https://gitlab.gnome.org/GNOME/meld/-/issues/349

The startup time appears to be a mix of issues in Meld and GTK+ on Windows,
but are probably *mostly* about missing caching in the binary Meld
distribution. Unfortunately, we don't have a good idea or profiling here,
and in general don't have enough Windows expertise.

But someone annoyed by the slow startup can try this.
> 1. Start a meld instance without specifying any file/dir parameters.
> Wait patiently for 10-20 seconds YMMV.
> 2. Without doing anything, minimize this first instance of MELD.
> (Iconify, that is).
>
> 3. Now try starting MELD using the startup ICON.
> Somehow under my windows10 setup, this seems to invoke another meld
> instance afresh.
> This second meld instance starts in a second or two(!) Very quick.
> (If your windows MELD setup tries to use the first instance of meld,
> this workaround is not possible.)
>

This works because Meld supports single-instance behaviour, so when you
start the "second" instance of Meld, you're actually effectively opening a
second window in the primary instance (with some additional special
handling).

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Diff Differ Project Coordination

[Kai via meld-list]

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  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
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: disable the "recent" functionality in meld

[Kai via meld-list]

On Sat, 2 May 2020 at 17:06, Fourhundred Thecat <400the...@gmx.ch> wrote:

> Hello,
>
> how can I disable the "recent" functionality in meld?
>
>
> Meld creates files such as these:
>
>~/.local/share/meld/recent-p260e59z.meldcmp
>
> and shows the history in
>
>files -> open recent
>
> I looked in preferences how to disable this, but did not find any option.
>
> When I make the directory ~/.local/share/meld/ unwritable, meld reports
> error and does not even start:
>
> PermissionError: [Errno 1] Operation not permitted:
> '~/.local/share/meld/recent-p260e59z.meldcmp'
>
> I consider this history "feature" as evil. The idea of opening files
> from history instead of from file paths seems confusing. How do you
> distinguish files with same names, but in different locations ?
>

Recent comparisons are stored using file URIs (or paths on older versions).


> Anyways, How can I disable this misfeature?
>

There's no preference for this, and I am not interested in adding one.


> If there is no option in preferences, can somebody suggest how to modify
> the python code to disable this ?
>

The core of the recently used handling is in `meld/recent.py`. It's
probably possible to simply return from a few functions there to get empty
files lists and not add new entries.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Meld 3.21.0

[Kai via meld-list]

On Tue, 21 Apr 2020 at 16:59, Braykov, B. (Branimir) <
branimir.bray...@ing.com> wrote:
>
> Great news. Where can we download the Windows version?

We don't provide official binaries for unstable releases. You can usually
download a CI-built binary from
https://gitlab.gnome.org/GNOME/meld/pipelines, but the Windows pipeline is
currently broken for upstream dependency reasons.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Meld 3.21.0

[Kai via meld-list]

Meld 3.21.0 has been released, and is now available at:
  https://download.gnome.org/sources/meld/3.21/meld-3.21.0.tar.xz


Features


 * Add support for CVS in version control comparisons (gitqlt)
 * Copy selected file paths in folder comparison (WenGuoyao)
 * Improve dark theme detection so custom Meld highlighting better matches
   the user's theme (Kai Willadsen)
 * Meld's built-in GtkSourceView schemes now support syntax highlighting
   (Kai Willadsen)
 * Moving past the first or last change using our change navigation now
   alerts with the standard error bell (Kai Willadsen)
 * Support nightly Flatpak builds of Meld using GNOME's CI (Kai Willadsen)
 * Support development using GNOME Builder's workflow


Fixes
-

  * CI and build system fixes (Michael Behrisch, Frank Dana, Piotr Drąg,
Vasily Galkin)
  * Fix running uninstalled from non-project-base folder (Vasily Galkin)
  * Fix file comparison closing after file save (Vasily Galkin)
  * Fix file comparison handling of certain line breaks (Kai Willadsen)
  * Fix folder comparison display of large file sizes (andre)
  * Fix folder comparisons with pre-epoch timestamps (Kai Willadsen)
  * Fix folder comparisons not handling ignore blank lines + text filters
(Kai
Willadsen)
  * Handle file deletion better on NFS mounts (Kai Willadsen)
  * Fix handling of bad filter regular expressions (Kai Willadsen)
  * Fix push action on missing changes in three way comparison (Kai
Willadsen)
  * Default file chooser encoding to autodetect (Kai Willadsen)
  * Minor UI fixes:
* Statusbar now correctly sets default encoding & file type for empty
  files (Kai Willadsen)
* Statusbar tries to keep a constant width for the cursor label (Kai
  Willadsen)
* Folder comparisons set sensitivity correctly for empty rows (Kai
  Willadsen)
* Give commit dialog message area a reasonable height (Kai Willadsen)
* Fix long file name wrapping in info bar notifications (Kai Willadsen)
* Fix long file name ellipsization in file comparisons (Kai Willadsen)
  * Windows fixes:
* Fix crash when started with unexpected environment (Vasily Galkin)
* Fix dbus support for single-instance behaviour (Vasily Galkin)
* Fix internationalisation building from source (ThunderEX)
* Fix SVG icon display (Kai Willadsen)
* Support logging to a file on Windows for debugging (Kai Willadsen)
* Default file encoding to UTF-8 to avoid Windows-specific locale issues
  (Kai Willadsen)
  * Typo fixes (luzpaz)
  * Localisation fixes (Piotr Drąg)
 Internal changes:
  * Add Meson build system support; setuptools is still supported for
Windows
and Mac OS builds, but Linux distributions should switch to building
with
Meson (Bilal Elmoussaoui, Kai Willadsen)
  * Move from GtkUIManager to GAction-based actions
  * Move all UI-file-constructed widgets from custom Python wrapper classes
to using real GtkWidget templates
  * Move UI templates, menus, custom icons and CSS to be resource-loaded
  * Move to pre-commit using flake8 and isort for CI linting
  * Move to new GtkSourceView 4 API
  * Modernised Python GObject API usage, including signal and property usage
  * Fix some deprecated GTK API usage
  * Support Python 3.8
  * Updated dependencies:
* Python 3.6
* GTK+ 3.20
* GLib 2.48
* GtkSourceView 4.0
* pygobject 3.30
* pycairo 1.15
  * Issues fixed: 62, 78, 119, 170, 240, 265, 265, 267, 279, 290, 313, 314,
316, 321, 322, 337, 341, 342, 344, 344, 350, 351, 359, 419, 432, 439,
442,
451


Translations


 * Alan Mortensen (da)
 * Anders Jonsson (sv)
 * Asier Sarasua Garmendia (eu)
 * Ask Hjorth Larsen (da)
 * Balázs Meskó (hu)
 * Balázs Úr (hu)
 * Daniel Mustieles (es)
 * Daniel Șerbănescu (ro)
 * Emin Tufan Çetin (tr)
 * Fran Dieguez (gl)
 * Guillaume Bernard (fr)
 * Jiri Grönroos (fi)
 * Kukuh Syafaat (id)
 * Marek Černocký (cs)
 * Matej Urbančič (sl)
 * Milo Casagrande (it)
 * Piotr Drąg (pl)
 * Rafael Fontenelle (pt_BR)
 * Ryuta Fujii (ja)
 * Sabri Ünal (tr)
 * sicklylife (ja)
 * Wolfgang Stöggl (de)
 * Yuri Chornoivan (uk)


What is Meld?
-

Meld is a visual diff and merge tool. It lets you compare two or three
files,
and updates the comparisons while you edit them in-place. You can also
compare
folders, launching comparisons of individual files as desired. Last but by
no
means least, Meld lets you work with your current changes in a wide variety
of
version control systems, including Git, Bazaar, Mercurial, CVS and
Subversion.
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: New macOS build coming soon

[Kai via meld-list]

On Mon, 13 Apr 2020 at 04:07, Youssef A. Abukwaik 
wrote:

> Ops! I had already pushed a release before I received your response -
> about two hours earlier in fact. The good news is that it is pretty stable
> and given the underlying libraries condition, it is better than the
> previous macOS release. I guess we're about to get about 200k of testers
> for an unstable release. It would be great if you can make an unstable
> release that I can match indeed, but note that this current release is
> working for most use cases and is performing well as far as I can tell.
> We'll see if users start reporting anything out of the ordinary.
>

I'll try to do that this weekend coming!


> As for upstream help, I have two things that can make life easier for me:
> 1. Hooks: Mainly for MeldApp & MeldWindow -
>post_init, (MeldApp, MeldWindow)
>will_become_visible, did_become_visible, (MeldWindow)
>menu_items_changed
>post_destroy & pre_destroy (MeldApp, MeldWindow)
> This would cleanup the code considerably. I don't like how my code looks
> one bit at the moment.
>

I've just spent some time checking out the diff to master, and I think I
can see some possible hook points... but also I feel like we might be able
to do this more cleanly if you were able to cleanly subclass MeldApp and
MeldWindow for the customisations. I feel like MeldApp should probably be
subclassable as-is (though obviously I haven't tried) and that would be
much easier to merge upstream.

MeldWindow is a little tricky because of the limitations of GtkTemplate in
Python. I *think* I could create some kind of MeldWindowBase subclass and
have MeldWindow be just:

@Gtk.Template(resourcepath)
class MeldWindow(MeldWindowBase):
...

which would then make it a bit easier for you to do some of  the
OSX-specific overrides. If you think this makes sense, let me know and I'll
take a look at the details.

Regarding some of the specific hooks:
  * post_init: pretty easy to do I think, but I also feel like subclassing
here might be a better option
  * will_become_visible, did_become_visible: I don't think there's any way
of doing this with GTK+, unless you want these on first visibility, in
which case I would look at subclass + overriding do_realize(). I'm happy to
add that hook if overriding do_realize in the subclass ends up being messy
though.
  * menu_items_changed: we don't actually change menus any more, because
without GtkUIManager (which is deprecated and has several long-standing
issues) we'd have to roll our own menu state handling or pick up another
library.
  * post_destroy & pre_destroy: I'm not sure whether this is possible in
GTK+ lifecycle, but maybe we can figure out what hooks could actually be
provided to help you.

2. This is perhaps a discussion rather than request. For UI files, do you
> think it would be better if I create a different UI file for any
> customization (which are usually small) or would it be better if we pass a
> variable from the application and include conditional statements within the
> ui file?
>

I'm not sure whether you mean actual `widget.ui` files here, or Python
files in the `ui` subpackage. Looking at the branch, there's not much of
either. I feel like the statusbar change should *probably* be doable with a
platform-specific CSS change; shipping OSX-specific CSS should be fairly
easy and I'm happy to help with those hooks.

For the UI file changes like appwindow.ui, it depends. I think that
customisations like showing the window manager buttons are doable (and
probably easier to handle) in code. Having the additional menu definitions
is more difficult, and I think should probably be broken out to its own UI
file.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Redesign of start screen

[Kai via meld-list]

On Sat, 4 Apr 2020 at 22:26, Vincent P 
wrote:

> (I tried to put attachments to this message at first, but obviously this
>> list doesn't support them.)
>>
>
> > My bad, sorry. I didn't see the filtered email in time.
>
> I tried to upload a image too but the file limit is really really low (40k
> including text)
>
> So I uploaded my proposition here
> https://ibb.co/mbcBd2S
>
>
> This is a total rewrite of my initial proposal
> https://bugzilla.gnome.org/show_bug.cgi?id=789174
> which was already 2,5 years old.
>
> In fact my proposal for a start page is ... no start page at all :)
> Just show the following screen whan user launch the app for the first
> time.
>
> I think
> It's more informative for user
> It will need less code
>

Just following up here to say that I agree that not having a New Comparison
screen at all may be the best option, although it is a fair bit of work.
There's more details on the Gitlab issue (
https://gitlab.gnome.org/GNOME/meld/-/issues/73).

How we deal with introducing users to such a workflow is a challenge. A
GtkAssistant-style guide like you suggest is definitely an option. Ideally
I think we could provide guidance in a more subtle, GNOME-y style, but I'm
definitely concerned that things like the three pane expansion are going to
be easily missed.
cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Meld choose text filters based on file type ?

[Kai via meld-list]

On Tue, 14 Apr 2020 at 03:15, Krolnik, Adam via meld-list <
meld-list@gnome.org> wrote:
>
> Hi all;
>
> I've been using meld for several years - great tool.
> Today, I was merging code and found that meld missed 2 merges due to text
filters.
>
> I had a text filter for assembly code files enabled that caused code
lines with "!" to be ignored. Obviously this can apply to other codes where
the wrong comment delimiter enabled can cause meld to ignore changes.
>
> So I was wondering if there could be a new feature to select text filters
based on the type of the file ? Thus, my assembly text filter would only be
enabled for files ending with the suffix I choose (.[sS]). Similarly,
scripts would enable '#' as a comment filter. These may need to run file to
determine that it is a script...

Something like this is a long-standing request (see
https://gitlab.gnome.org/GNOME/meld/-/issues/13).

I think it's definitely a reasonable feature, but needs work to figure out
how to make the behaviour clear to the user. I also don't have any good
idea what the UI would look like, which might be tricky. For the file type
I would suggest that we can rely on gio's detection (though not 100%
reliable, it should probably be Good Enough).

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: New macOS build coming soon

[Kai via meld-list]

This is awesome! Thank you so much for continuing to work on this.

I would caution that since I haven't even released one version on the
unstable 3.21.x series yet, it might be best to avoid homebrew users
automatically getting the update... but that's your call obviously.

The 3.21 series has been very drawn out because it's been huge UI changes
that required a fair bit of architecture rework, and I'm also still trying
to sort out further UI updates so that we can wrap a bunch of related UI
disruptions into a single major release... but then that's also caused it
to be under development for *way* too long. However, if you're moving
towards making an OSX release, maybe I'll try to find time to make a 3.21.0
release so that there's at least an unstable release for you to match with.

Is there anything that I can help with upstream that would make your life
easier with this port?

cheers,
Kai

On Fri, 10 Apr 2020 at 14:46, Youssef A. Abukwaik via meld-list <
meld-list@gnome.org> wrote:

> Good evening everybody,
>
> I've been doing some catching up on the macOS side and things are finally
> coming together. Preparing the environment is quite a lengthy process, but
> I finally got the all pre-requisites building on Catalina as well as
> updated to latest meld upstream. I have some kinks that I need to figure
> out before I push a binary to the github download page for users to start
> pulling it (either manually or through homebrew). I'm thinking probably
> this weekend.
>
> However, I did promise Kai a demo of what it looks like, so here it is:
>
>
> https://drive.google.com/file/d/1nJFveh5DOQenbDUdEKNwq-m7DL_F9V0j/view?usp=sharing
>
> (The build process is a bit lengthy, if you get board watching the console
> scrolling, skip to 1:25 to where the user experience starts after
> downloading the dmg image.)
>
> Regards,
> Youssef
> ___
> meld-list mailing list
> meld-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/meld-list
>
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Redesign of start screen

[Kai via meld-list]

On Thu, 2 Apr 2020 at 16:27, Heikki Ketoharju 
wrote:

> Hello again!
>
> This thing started to interest me, and although I'm not a designer, I
> still decided to make a small mockup to play with the idea, what the start
> screen should look like.
>
> Linked here is a SVG-file of my first thoughts. Also, I'll put a link to a
> PNG, because for me, the SVG shows a little bit wrong in image viewer.
>
> PNG:
> https://heikkiket.kapsi.fi/files/meld%20start.svg.png
> SVG:
> https://heikkiket.kapsi.fi/files/meld%20start.svg
>
> Should I make a Gitlab issue about this, or is there one already?
>

Just replying to say that yes, keeping this on the Gitlab issue you've
found is probably the best option. I do want to emphasise that while I
agree that the current design is a problem, replacing it is also not
easy... but I'll follow up on gitlab with the issues that the current
design tried to address, and the constraints we have from the toolkit.

(I tried to put attachments to this message at first, but obviously this
> list doesn't support them.)
>

My bad, sorry. I didn't see the filtered email in time.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Diff Differ Project Coordination

[Kai via meld-list]

On Wed, 25 Mar 2020 at 13:36, Waldo Withers via meld-list <
meld-list@gnome.org> wrote:

> Hi y'all,
>
> I'm thinking to use Meld as the basis for a diff differ, and I was
> wondering if I could coordinate with some of y'all. I presume Kai, but
> maybe others as well.
>
> Specifically, the diff differ would take in two sets of files or two
> comparisons you've done and diff their patches. This would be useful, for
> example, for when you are merging into master and need to make sure the
> changes you made since the beginning of your branch are reflected in master
> before you commit. On many occasions I've opened up two diffs and compared
> them by eye, and that's dumb; it should be automated.
>

I definitely understand your motivation, though I'm not entirely sure I get
what the workflow will look like. Would the user pass in... four files? and
what does each input represent here?


> Anyway, I've been working on this for a bit, getting my head around the
> code, and I figure it'd be best to coordinate with y'all so the changes I
> make can eventually be integrated into Meld proper and make sense both
> architecturally and for the long-term vision.
>

So I really, *really* don't want to discourage you, but I also have to say
that I'm currently struggling to get enough spare time & energy to maintain
Meld's current scope, so incorporating new things is definitely likely to
be slow going. There's also the question of how to add extra functionality
without complicating the interface, which is usually the hardest part.

That said, I'm always extremely happy to help out with guidance around the
code and what not, and I'm very willing to look at WIP patches or similar
if you'd like some feedback.

If you have any specific questions about how to integrate things, or if
there's functionality/classes that I could split in Meld to make stuff
easier for you, please let me know.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Meld - Suggestion

[Kai via meld-list]

On Thu, 5 Mar 2020 at 05:07, Heikki Ketoharju 
wrote:

> Hello!
>
> > How did this "Text Filters" not a sub-category drop down under "Filter"
> drop down??
> > Why make it hidden in preference.
>
> That is a great idea actually! I learned about text filters only when
> I decided to fix a minor bug connected to them. A hidden gem indeed.
>
> If no one opposes the idea, maybe someone could make an issue about
> this to the issue tracker and then it could be fixed? I'm willing to
> do that if it's seen as a good idea.
>

This already exists in the current master branch. We need a new unstable
release, but between a bunch of changes, a new build system, and a lack of
motivation, I haven't managed to make this happen yet. If people wanted to
test out master then that would help, as always.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Meld 3.20.2

[Kai via meld-list]

Meld 3.20.2 has been released, and is now available at:
  https://download.gnome.org/sources/meld/3.20/meld-3.20.2.tar.xz


Fixes
-

 * Fix crash when launched from external process on Windows (Vasily Galkin)
 * Fix single-instance behaviour on Windows (Vasily Galkin)
 * Fix display of large file sizes (Andrey Efremov)
 * Set file chooser encoding to autodetect by default (Kai Willadsen)
 * Always use UTF-8 as user's "current" encoding on Windows (Kai Willadsen)
 * Fix ignoring blank lines on text-filtered files in folder comparison (Kai
   Willadsen)
 * Fix expand/collapse actions for missing folders (Kai Willadsen)
 * Fix some incorrect action sensitivity settings (Kai Willadsen)
 * Fix height of commit dialog (Kai Willadsen)
 * Fix install support for Python 3.8 (Kai Willadsen)
 * Add support for file debug logging on Windows (Kai Willadsen)
 * Fix icon display on Windows (Kai Willadsen)
 * Issues fixed: 267, 279, 314, 322, 337, 341, 342, 350, 351, 359


Translations


 * Anders Jonsson (sv)
 * Andika Triwidada (id)
 * Asier Sarasua Garmendia (eu)
 * Balázs Úr (hu)
 * Daniel Mustieles (es)
 * Marek Černocký (cs)
 * Milo Casagrande (it)
 * Piotr Drąg (pl)
 * Rafael Fontenelle (pt_BR)


What is Meld?
-

Meld is a visual diff and merge tool. It lets you compare two or three
files,
and updates the comparisons while you edit them in-place. You can also
compare
folders, launching comparisons of individual files as desired. Last but by
no
means least, Meld lets you work with your current changes in a wide variety
of
version control systems, including Git, Bazaar, Mercurial and Subversion.
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Meld for Personal projects

[Kai via meld-list]

On Wed, 15 Jan 2020 at 17:04, murali Krishna
 wrote:
> I want to use the existing meld source code and remove meld UI.
> I want to use it as a library that takes 2 folders, return differences
> as objects and build HTML pages that look like meld UI. The main idea
> is to get the differences as objects in any programming language. Is
> this possible?

Not easily, no. Meld's folder comparison logic builds its comparison
directly to a GtkTreeModel, which is our data model for the widget
rendering. You *could* use that as your object representation for
building HTML pages, but I don't think it would be straightforward.
There's no "library" separation of the tree building; it's part of the
DirDiff GtkWidget.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Meld for Personal projects

[Kai via meld-list]

On Mon, 30 Dec 2019 at 18:14, murali Krishna via meld-list
 wrote:
> I found a Google library(https://github.com/google/diff-match-patch)
> that does the same for texts but I want to extend this to large files.
> I'm stuck at comparing the files in a folder effectively. Meld does
> this effectively but there is no library for personal use. Can someone
> please help me with this?

I'm not sure what you mean by "for personal use" here. Meld is
licensed under the GPLv2 or later, so you can use Meld's code under
the terms of that license. Specifically, if your project is also GPLv2
or later then you can make use of Meld's code in that project. I don't
want to get into details of how the GPL works, but you should be able
to find plenty of resources explaining the conditions and requirements
for reusing GPLed code.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Meld nightly flatpak builds

[Kai via meld-list]

Hi all,

Meld now has "nightly" flatpak builds from CI, published as
`org.gnome.MeldDevel` to the GNOME nightly repo (see
https://wiki.gnome.org/Apps/Nightly).

Somewhat related to this, I've updated Meld's build instructions for
the now-supported Meson build system. We still have the old
setuptools/distutils-based build in place, but it's now *only* used
for Windows builds.

I'm extremely confident that there will be issues with both of these
changes, so please do file bugs.

It's worth mentioning that getting packages from your
distribution/Flathub/Windows binaries are still the suggested way to
run Meld for most people... but I'm hopeful that the nightly flatpak
option will help get some more testing on the development branch.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: meld files checksum?

[Kai via meld-list]

Meld doesn't use a hash. In shallow comparison mode it doesn't read
file contents at all; in content comparison mode it simply reads and
compares the bytes (or decoded + filtered text, if text filters are
being applied).

cheers,
Kai

On Sun, 22 Dec 2019 at 18:50, Phlique via meld-list  wrote:
>
> Hello M. Kai Willadsen,
>
> I looked in vain in all the documentation of meld for what hash you use for 
> comparing two files: md5, shaxxx, which  checksum? I am very keen to know, it 
> is a precious information (reliability issue), although I do not doubt for a 
> second for the excellence of your program, I would be overbearing.
> Thank you in advance for your answer.
> Best regards
>
> Phlique
> ___
> meld-list mailing list
> meld-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/meld-list
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: A key binding for: Close file window and save as needed

[Kai via meld-list]

On Thu, 21 Nov 2019 at 05:33, Sven Hartrumpf  wrote:
>
> Hi.
>
> I am a happy meld user; saves me a lot of time and increases merge quality :-)
>
> My typical tasks are 3-way merges of directories with around 1 small
> files each. A task will show differences for 1-5 % of these files.
> I work through the list, the job per file is typically quite simple
> and does not involve a mouse for speed reasons:
>
> 1. merge 1 or 2 changes from B to A with Alt-Left (or similar)
>
> 2. Ctrl-w Tab Tab Tab Return (i.e. saving the modified file
>   and returning to the directory view)
>
> Instead of the 5 key presses in step 2, I am looking for a
> shortcut: "Close file window and save as needed".
> Or an option ("Save as needed without asking") so that Ctrl-w would
> behave like 2.
> Or ...

There's already an accelerator for the Save action, so step 2 should
be: Ctrl+w, Alt+S.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: starting new cloned meld gives FileNotFoundError

[Kai via meld-list]

Yes, glib-compile-resources is a required tool for running Meld from a
checkout. I can't tell you what Ubuntu package it's in, but the Fedora
package is glib2-devel.

cheers,
Kai


On Fri, 22 Nov 2019 at 06:19, Fischer, Claudio
 wrote:
>
> Hi,
>
> running meld directly from git clone on master branch commit 
> ca9ef23f3d476e4adf90e6d98e75cb5802cb74bb
> from 28.10.2019. System is Ubuntu 19.10 64 bit.
>
> Meld is running fine on my machine.
>
> But if I do a fresh clone of meld in a new folder, from this folder meld is 
> not running and gives following error:
>
>
> user@ubuntucf:~/test/meld/bin$ ./meld
> Traceback (most recent call last):
>   File "./meld", line 405, in 
> setup_resources()
>   File "./meld", line 257, in setup_resources
> cwd=melddir
>   File "/usr/lib/python3.7/subprocess.py", line 339, in call
> with Popen(*popenargs, **kwargs) as p:
>   File "/usr/lib/python3.7/subprocess.py", line 800, in __init__
> restore_signals, start_new_session)
>   File "/usr/lib/python3.7/subprocess.py", line 1551, in _execute_child
> raise child_exception_type(errno_num, err_msg, err_filename)
> FileNotFoundError: [Errno 2] Datei oder Verzeichnis nicht gefunden: 
> 'glib-compile-resources': 'glib-compile-resources'
>
>
> I compared the running folder and the new cloned folder and found the file 
> "data/org.gnome.meld.gresource" in the running version.
> This file is missing in the new cloned folder and this seems to give the 
> error.
> If I copy the file to the new cloned folder, the new cloned meld is running 
> also fine.
>
>
> Regards,
> Claudio
>
>
> WEINIG DIMTER GMBH & CO. KG
> Rudolf-Diesel-Strasse 14-16
> 89257 Illertissen
> Germany
> www.weinig.com
>
>
> Registergericht Memmingen A 10071
> Geschaeftsfuehrer: Dr. Mario Kordt
> UST / ID-Nr. DE 812 382 348
>
> ___
> meld-list mailing list
> meld-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/meld-list
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Developing in Windows

[Kai via meld-list]

On Mon, 14 Oct 2019 at 05:26, Waldo Withers via meld-list
 wrote:
>
> Hi y'all,
>
> Can one develop and build this in Windows, or do I need to use Linux? If it 
> needs to be Linux as I suspect, does anyone have a virtual machine they don't 
> mind giving me, by chance? It'd save me a bit of time, though it's not 
> necessary. If it can be built in Windows, how? I keep getting this error:
>
> > compiling gresources
> > glib-compile-resources --target=build\data\org.gnome.meld.gresource 
> > --sourcedir=meld/resources meld/resources/meld.gresource.xml
> > error: command 'glib-compile-resources' failed: No such file or directory

Yes, you can build and develop on Windows, though I haven't personally
done this in a while. You'll need a MinGW environment set up, and from
there our Gitlab CI build script *should* give you some idea of the
requirements:

https://gitlab.gnome.org/GNOME/meld/blob/master/.gitlab-ci.yml#L42

Specifically, I think `glib-compile-resources` should be in the
glib2-devel package there.

As a minor note though... depending on what you're doing, I'd
recommend developing against the `meld-3-20` branch at the moment.
`master` is currently in the midst of changing build systems and I
don't know whether anyone has tried getting the new build to run on
Windows at all. Theoretically the old build will still mostly work,
but... I'm far from confident.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Meld for OSX / GTK issues

[Kai via meld-list]

On Sat, 5 Oct 2019 at 09:45, Youssef A. Abukwaik
 wrote:
>
> I have already figured out how to fix this from the GTK side (GTK 3.24). I'll 
> try this and see if it helps with performance (going back to be windowed) - 
> thank you.

Oh nice. Well I hope that addresses at least that headerbar issue.

> It would help me so much if you make each release a branch so that I can pull 
> stable upstream changes instead of master as I do now.

We already do this! Individual releases are tagged as e.g., `3.20.1`,
and the stable release series is on a branch named e.g., `meld-3-20`.
Is this enough for your purposes?

Currently I don't do this for unstable series; since there's only ever
been one at a time, that's essentially just whatever is in `master`. I
guess if we ever needed unstable 3.21.x and 3.23.x branches at the
same time this could get messy, but it's not something that's ever
come up.

> It would be awesome if anyone could help. I've asked for help in the issues 
> on github, on my Facebook with my techie friends and even in some of the 
> forums. Everyone is excited but not one stepped up. To be honest, building 
> the environment is boring, but it's pretty much done and the I have already 
> figured out the nasty tricks (the gir files and the typelibs were a real 
> challenge - I wanted one binary without a wrapper and spent days with the 
> linker and the typelib files till I got that right)
> This part:
> https://github.com/yousseb/meld/blob/master/osx/build_app.sh#L129
> and this part:
> https://github.com/yousseb/meld/blob/master/osx/build_app.sh#L155
> Took about three weeks until I got them right..

It was a long time ago, but I do remember doing something similar for
the original Windows build. It's not a fun process, I'm sorry!

> PS: I'll record a video of how it looks/feels on Mac. You should at least see 
> it in action. :)

Awesome, please do.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Meld for OSX / GTK issues

[Kai via meld-list]

On Tue, 1 Oct 2019 at 11:33, Youssef A. Abukwaik via meld-list
 wrote:
> During the past three weeks, I have struggled with bringing the Mac build to
> sync up with upstream. JHBuild has significantly changed. Meld has also
> significantly changed. I'm not complaining about either, but I am seriously
> complaining when it comes to GTK. GTK on Mac is way behind. The stable
> GTK/quartz implementations is slow, incomplete and has some significant
> issues. The git GTK/quartz does not even compile.

I thought that GNOME had moved away from jhbuild, but checking now I see
that the gtk-osx project is still using it (according to
https://gitlab.gnome.org/GNOME/gtk-osx), and looks like they're still
maintaining independent module sets, so that at least is good.

> 1. GTKHeaderBar - Meld has moved to borderless window and by using
> GTKHeaderBar, the window controls (min/max/close) are now embedded
> within the header bar. GTK implementation sets the flag
> GDK_QUARTZ_BORDERLESS_WINDOW in gdkwindow-quartz.c, however, it never
> sets the flag GDK_QUARTZ_MINIATURIZABLE_WINDOW. I'm unable to minimize
> the app window! Take a look at this:
> https://github.com/yousseb/meld/blob/master/meld/macwindow.py#L264

I realise that this is side-stepping the problem slightly, but maybe we
could consider special handling for the OSX build that reparents the
header bar so that we're no longer using the borderless/client side
decoration window?

This could be as simple as:

@@ -60,6 +60,10 @@ class MeldWindow(Gtk.ApplicationWindow):
 def __init__(self):
 super().__init__()

+header_bar = self.get_titlebar()
+self.set_titlebar(None)
+self.appvbox.pack_start(header_bar, False, True, 0)
+
 # Manually handle GAction additions


I notice that your branch is using Gtk.UIManager. Migrating away
from this to GActions is one of the huge changes in our current master
branch. I'm not saying that your window class needs to match, but it
might be easier in the future if it does so.

Also, we don't have a menu bar option at all at the moment, mostly
because I had thoroughly burnt out by the time I finished the GAction +
GtkHeaderBar transition. I think maintaining a GAction-based menubar
option probably makes sense for the OSX (and maybe Windows?) ports.

> 2. Fullscreen mode: With the borderless window, I have big gaps around
> the app from all sides.. It's much better to maximize instead of
> entering full screen!
>
> 3. Fullscreen mode: To top it off, GTK cannot tell that it has entered
> fullscreen mode on quartz. is_full = window_state &
> Gdk.WindowState.FULLSCREEN is never true on GTK/quartz even if the app
> is really in fullscreen

These two definitely feel like outright GTK bugs that should be reported.

Having said this, Meld's current fullscreen behaviour is actually very
bad - we don't reparent the header bar and end up with no UI and no
obvious way to exit fullscreen. I doubt that fixing that would fix the
issues you've found however.

> 4. I was hoping to be able to use GTK with vulkan
> (https://vulkan.lunarg.com) in order to speed things up. Vulkan is only
> available in the git version (3.96) of GTK and the quartz backend does not
> build. This is very disappointing because the GTK/quartz rendering is slow
> right now (especially with the new borderless window which adds RGBA flag -
> A being the issue here - to the main window making it report that
> isOpaque = false to the OS)

Meld doesn't currently support GTK 4, and honestly I'm not sure when it
will. The experience of maintaining Meld during the GTK 3.x series with
constant toolkit breakages was unspeakably awful, and I have no reason
to believe that the GTK 4 series is going to be any different.

In other words, I wouldn't be trying to get GTK 4 to compile right now...
let's see if we can figure out another way around the rendering issues.

> I should probably take this post to the GTK mailing list, but I spent
> a significant amount of hours trying to get Meld working on Mac during
> the past three weeks that I just had to give you guys an idea of what's
> been happening on the Mac side. I can probably get GTK 3.96 to build
> on Mac and create a patch. I'll give it a shot over the next weekend.

Thanks for the update. If you do try to take some of these issues to
GTK, the mailing list is now actually a Discourse instance at
https://discourse.gnome.org/.

While it's great that you're trying to update to Meld's master branch,
that branch is also still changing a fair bit. I'm getting used to the
new UI, but there are several parts of it that I'm not yet happy with. If
the recent changes end up being too much for you to migrate easily, I
do suspect that our 3.20 branch will be maintained for a fair while.

If I can help out with the (as you say, very significant) changes, then
let me know. I still don't really have access to an OSX machine to help
out (and don't have the spare time anyway) but I'd like your project
to continue t

Re: Meld for OSX / GTK issues

[Kai via meld-list]

Hi,

I'll address the technical details in another email when I can, but I
just wanted to say how sorry I am for your brother and his family. I
can't begin to appreciate what this was like for you. Please know that
your contributions here are valued, but also that no one should
hesitate to take whatever time they need to away from open source.
Also, thank you for sharing your brother's story.

thanks,
Kai

On Tue, 1 Oct 2019 at 11:33, Youssef A. Abukwaik via meld-list
 wrote:
>
> Hi,
>
> I'm the maintainer of the OSX fork. I've just pushed an update to the fork to 
> get my fork on par with the latest upstream code. I haven't made any updates 
> for a while due to personal reasons (a scumbag killed my brother in the 
> Christchurch terrorist attack last March). I'm now trying to catch up and get 
> Meld for OSX back on its feet.
>
> During the past three weeks, I have struggled with bringing the Mac build to 
> sync up with upstream. JHBuild has significantly changed. Meld has also 
> significantly changed. I'm not complaining about either, but I am seriously 
> complaining when it comes to GTK. GTK on Mac is way behind. The stable 
> GTK/quartz implementations is slow, incomplete and has some significant 
> issues. The git GTK/quartz does not even compile.
>
> Here are some examples:
> 1. GTKHeaderBar - Meld has moved to borderless window and by using 
> GTKHeaderBar, the window controls (min/max/close) are now embedded within the 
> header bar. GTK implementation sets the flag GDK_QUARTZ_BORDERLESS_WINDOW in 
> gdkwindow-quartz.c, however, it never sets the flag 
> GDK_QUARTZ_MINIATURIZABLE_WINDOW. I'm unable to minimize the app window! Take 
> a look at this:
> https://github.com/yousseb/meld/blob/master/meld/macwindow.py#L264
>
> 2. Fullscreen mode: With the borderless window, I have big gaps around the 
> app from all sides.. It's much better to maximize instead of entering full 
> screen!
>
> 3. Fullscreen mode: To top it off, GTK cannot tell that it has entered 
> fullscreen mode on quartz. is_full = window_state & 
> Gdk.WindowState.FULLSCREEN is never true on GTK/quartz even if the app is 
> really in fullscreen
>
> 4. I was hoping to be able to use GTK with vulkan (https://vulkan.lunarg.com) 
> in order to speed things up. Vulkan is only available in the git version 
> (3.96) of GTK and the quartz backend does not build. This is very 
> disappointing because the GTK/quartz rendering is slow right now (especially 
> with the new borderless window which adds RGBA flag - A being the issue here 
> - to the main window making it report that isOpaque = false to the OS)
>
> I should probably take this post to the GTK mailing list, but I spent a 
> significant amount of hours trying to get Meld working on Mac during the past 
> three weeks that I just had to give you guys an idea of what's been happening 
> on the Mac side. I can probably get GTK 3.96 to build on Mac and create a 
> patch. I'll give it a shot over the next weekend.
>
> PS: At the time of writing this message, the binaries from my fork have been 
> downloaded 251,000 times. The latest version can be found here: 
> https://github.com/yousseb/meld/releases/tag/osx-17
>
> Thank you for Meld.
> Please pray for Osama - 
> https://www.stuff.co.nz/national/christchurch-shooting/111375038/osama-abu-kwaik-was-a-refugee-born-to-an-orphan-who-died-in-christchurch-the-city-he-loved
>
> Regards,
> Youssef
> ___
> meld-list mailing list
> meld-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/meld-list
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list

Re: Floppy disc access dialogs

[Kai via meld-list]

On Thu, 22 Aug 2019 at 07:48, scootergrisen via meld-list
 wrote:
>
> In Windows there are some problems with dialogs that appear.
> I have a memory card reader that uses drive E:.
> When the memory card is mounted there is no problem.
> But if i eject the memory card and open Meld or open a new comparison i
> get dialogs about some access problems.
>
> I have seen this in other software to.
> I think the software was just trying to scan everything. A:, B:, C:,
> etc. and since there is no A: and B: the dialog comes... i think.
>
> In 3.20.0 i have to click Cancel 31 times to get rid og the dialog.
> In 3.18.3 i think i had to click Cancel two times.

This most likely has to do with the GTK+ file selectors that we're
using. In 3.20 they (unintentionally) changed to be non-native, which
most likely explains the increasing number of prompts. See
https://gitlab.gnome.org/GNOME/meld/issues/348 for a few more details.

cheers,
Kai
___
meld-list mailing list
meld-list@gnome.org
https://mail.gnome.org/mailman/listinfo/meld-list