GitLab

- remove the button in toolbar
- add a menu entry in the global menu
- add a shortcut "alt + backslash" to fire the swap action

- only supports in the two panes mode
- the left pane to right and the right one to left

The goal here is to have the marker survive tree modifications, and also
to make the comparison that we do for rendering emblems somewhat more
correct. Because handling TreeRowReferences is slightly more annoying
than dealing with pure TreeIters, I've moved the marker to be a
NamedTuple to make the rest of our logic appear slightly simpler.

This is deliberately choosing to override the "newest" marker for two
reasons:
 - if you're manually marking something for comparison like this, you
   probably don't actually care about whether this one or the other side
   is newest, since you're basically indicating that the file you're
   comparing to on the other side isn't the correct one; and
 - adding a new tree store column (or a third emblem location) just to
   store mark information seems like massive overkill.

If the user marks file X in the left pane and compares file Y in the
right, the launched comparison should be the same as if they mark file
Y in the right and compare with file X in the left; in both cases, the
comparison should be X -> Y.

1 remove unmark
2 sperate the section, use a new section
3 after mark-then-compare, do not set marked = None. It can be reused.
4 coding as a pythoner, change code to fit python style

The main change here is making comparison options not be an attribute,
but rather just recreate it when doing our scan. The reason here is that
it's nicer to not have duplicate state on the class, and it's somewhat
better to have the action state be explicit.

This change also fixes a linting error that was breaking CI.

This adds in some additional typing for the update CanonicalListing
class, and also fixes some minor linting problems.

The issue being addressed here is that once the comparison has been
opened, there's no clear indication of whether it was the left or the
right pane that was missing from the folder comparison.

The down-side to making us always open in two-pane mode is that we lose
the screen real estate of the single-pane view, but the benefits in
consistency feel like they outweigh that consideration. If a user really
wants a full-size view of an added/removed file without the screen
split, the Open Externally action is already available.

This is a supplement to our toolbar spinner, since the latter is not
that obvious and also indicates ongoing tasks anywhere in the
application, rather than just the current pane.

It would possibly be nicer to have this presented as a spinner cell
renderer, but since we're only using this for one row (currently) that
seems like huge overkill in terms of additional cell data and renderers
for large trees. In the future if we move to more granular progress on
a per-file basis, per-cell spinners might make more sense.

This change sets the current folder for each chooser to the currently
displayed folder for the corresponding pane. This should mean that if
the user wants to change folders in the comparison, the chooser should
start at where ever is currently being compared.

This is a very debatable change. I'm weighing up a desire for the
header bar to not be too wide (because it gives us a minimum size that
we can't easily work around) with the desire to have the UI be stable.
In this case, I've gone with having the available buttons change per
view, on the basis that there are three text buttons here and they take
up really quite a lot of horizontal allocation.

Ideally, I think this would be responsive and we'd try to always show
all three buttons, collapsing down to just the relevant one(s) if
necessary... but that's really quite a lot more work.

This is what I get for having local linting config.

Without these additional revealers, the sourcemap visibility toggle
shows a very unpleasant bump at the end while the dummy toolbar and
statusbar elements are hidden.

The goal here is to make the folder comparisons action bar UI the same
as the UI for file comparisons. We're also looking to fix the same kinds
of problems that the file UI change fixes, namely: access to the full
path, better overall display, and avoiding the deprecated
GtkFileChooserButton.

This change also moves to having a GObject property for the folders
being compared. Currently we don't really make great use of this, but
it gives us a starting point for migrating to a more property-driven
model here.

add_dismissable_msg now closes only the panes given or just current pane
Couple of simple style changes

In situations where we cancel existing folder scan tasks before they're
finished, we incorrectly didn't clear the _scan_in_progress sentinel
variable. This could happen when e.g., toggling a file filter button
before the current scan had completed, and disabled most of our menu
items (because they're correctly disabled while a scan is running).