(Added dependency manually, as apparently {D...} does not trigger, only D... works.)

Only had time to look at the screenshots so far. Great in general, only for this one a small niggle: I kinda imagined the button to be aligned to Help, not to Export Image. Rationale:

• Group functions by two topics: App related and screenshot related.
• In other dialogs it's done similarly for the Defaults ("preferences") button.
• Easier to choose between 3 buttons than between 4 (and for 1 vs. 2 it doesn't really matter).

+1 for using the standard terminology.

Regarding an icon-only button: Scratch that, we need the text too.

Both arc patch and manually applying the patches result in

Applying patch doc/index.docbook with 3 rejects...

In D10289#201050, @rkflx wrote:

Only had time to look at the screenshots so far. Great in general, only for this one a small niggle: I kinda imagined the button to be aligned to Help, not to Export Image. Rationale:

• Group functions by two topics: App related and screenshot related.
• In other dialogs it's done similarly for the Defaults ("preferences") button.
• Easier to choose between 3 buttons than between 4 (and for 1 vs. 2 it doesn't really matter).
  
  +1 for using the standard terminology.
  
  Regarding an icon-only button: Scratch that, we need the text too.

I had the same thought, but QDialogButtonBox is designed to always have the Help button on the left and all other buttons aligned to the right.

I'll need to look into whether this kind of manual alignment is possible with QDialogButtonBox.

In D10289#201095, @rkflx wrote:

Both arc patch and manually applying the patches result in

Applying patch doc/index.docbook with 3 rejects...

Yeah, I could use a quick primer in how to properly create patches that depend on other patches. arc diff --create on top of an existing patch just tried to update it instead of creating a new one.

In D10289#201117, @ngraham wrote:

Yeah, I could use a quick primer in how to properly create patches that depend on other patches. arc diff --create on top of an existing patch just tried to update it instead of creating a new one.

While I don't agree with some of the hate Arcanist gets by some devs over here, dependent revisions (sometimes used as an approximation of feature branches) are indeed a topic which could have easier handling, although upstream seems to be aware of that. Nevertheless it cannot be that hard, because even with zero arc experience I managed to do it for my early patches (https://phabricator.kde.org/D7164).

The basic gist is that you should be aware of the rules arc follows to determine which commits to include in a given Diff (see Arcanist User Guide: Commit Ranges), and change those if necessary: arc which <commit>, arc which --base <rule>, an option in .arcconfig or simply by using arc feature beforehand for the start of the range; and git checkout <branch or commit> or arc feature for the end of the range. When updating a Diff later you should not forget to also update its dependent Diffs.

To give you an example with branches (a single branch with multiple commits would work too, but requires different options and more typing):

# work on a feature and a dependent feature
arc feature f1
git commit -m c1
arc feature f2 # this equals "git checkout -b f2 --track f1"
git commit -m c2

# initial submission (replace "which" with "diff" when going from testing to actual submission)
arc feature f1
arc which
arc feature f2
git commit --amend  # Add "Depends on D..."
arc which

# update first feature and rebase second feature
arc feature f1
git commit -m c1.1
arc which
arc feature f2
git rebase f1
arc which

# land step-by-step
# (beware, did not test, see also https://phabricator.kde.org/D10207#199285)
arc feature f1
arc land --preview
arc feature f2
arc land --preview # Do we need to rebase to the correct branch first? Is the upstream still correct?

(Some of the manual work could probably be automated via git rebase -i -x arc....)

Please let me know how landing works for you in the end, so I can improve the notes above.

EDIT: I did test for D10470 and its dependencies. Turns out we get this error:

$ arc land --hold
Landing current branch 'save-button-better-dropdown'.
 TARGET  Landing onto "master", selected by following tracking branches upstream to the closest remote.
 REMOTE  Using remote "origin", selected by following tracking branches upstream to the closest remote.
 FETCH  Fetching origin/master...
These commits will be landed:

      - 39c6b13 Improve usability of Save dropdown button
      - 348377a Refactor saveMode handling to use enums instead of ints

Usage Exception: There are multiple revisions on feature branch 'save-button-better-dropdown' which are not present on 'master':

     - D10467: Refactor saveMode handling to use enums instead of ints
     - D10468: Improve usability of Save dropdown button

Separate these revisions onto different branches, or use --revision <id> to use the commit message from <id> and land them all.

The fix is easy: Before each arc land, perform an additional git rebase origin/master.

The upstream tracking branch is still incorrect, but as long as we don't git pull --rebase, all should be fine.

I don't know too much about the layout of your specific case here, but try git checkout <commit> and arc which/diff HEAD^. If this is too fiddly, do it properly with arc feature and just cherry-pick your old commits.

Maybe commit first part ( D10283 ) and continue from master? ;)

@alexeymin Yes, that should work, but I want to figure out how to do this right right way!

@rkflx thanks for the notes. I'll see what I can do later today. It's probably too late for these, but I'll follow those instructions for my next multi-patch chain.

This should be apply-able now. Sorry for the hassle. I'll do a better job with my next multi-patch chain.

@alexeymin Any tips on how to align the button properly?

In D10289#201864, @rkflx wrote:

@alexeymin Any tips on how to align the button properly?

You want to reorder buttons as you wish? I would remove dialog button box, create a custom horizontal layout and add buttons (and spacers) inside in whatever order, it should not be so hard...
But I'm kind of used to spectacle's buttons layout and it doesn't seem "wrong" to me :)

In D10289#201894, @alexeymin wrote:

You want to reorder buttons as you wish?

We want to implement D10289#201050.

I would remove dialog button box, create a custom horizontal layout and add buttons (and spacers) inside in whatever order, it should not be so hard...

Hmh, I guess that would not adapt anymore to platform conventions, as can be tested with XDG_CURRENT_DESKTOP=gnome spectacle.

Thanks @rkflx, that was just what the doctor ordered!

Ok, great. Checked 1/3 which is fine, I'll try to squeeze in some time today for a review of 2/3 and 3/3 (which still does not apply the docbook hunk, but don't worry about it).

FWIW @rkflx, I did my best to turn your arc tutorial above into official documentation: https://community.kde.org/Infrastructure/Phabricator#If_the_patches_are_all_for_the_same_project

Let me know if anything's radically wrong there (or fix it, I guess; it is a wiki!)

Thanks Nate, I guess that's appreaciated very much by new contributors. I kinda had bigger plans with the material I researched and added here and there on Phab occasionally, but I guess I should've kept it secret if I didn't want anyone to use it ;) Did not spot any glaring mistake so far, although I cannot spent too much time reviewing/refining/completing it currently either.

Big thumbs up for the rest of the changes, in particular how to install Arcanist on Linux.