Can we get a comment or a TODO in the code that explains the reason for this workaround?

With Phabricator, patches can have parents, and multi-commit dependency chains are fully supported: https://community.kde.org/Infrastructure/Phabricator#If_the_patches_are_all_for_the_same_project

Your choice, and if we do, then fractional-scale-factor-hi-dpi users of Kate and KDevelop on Bionic will be happy!

It is a problem for 5.9 (confirmed), but I thought it best not to unnecessarily mess with the LTS release.

@broulik addressed your remaining comments in another commit. Sorry for missing them the first time around; flaky bus wifi didn't show me the email for your comments until after I had already landed the patch, following Aleix's approval.

I'd thought of that idea too, but it requires more substantial changes than just playing around with the UI, so it'll have to be done in another patch.

In D14238#295135, @esedgh wrote:

Just a quick question. Why does it have to be so big and waste so much space? It still feels kind of weird.

Thank you Nate, btw. You are doing amazing work everywhere.

Address review comments

Use smooth transformation to slightly improve appearance

Results of testing:

• After I create a new tag, it doesn't show up in the Places panel tag list or under the tags:/ ioslave until I restart Dolphin.
• When I navigate to tags:/ ioslave using the All Tags item in the Places panel and I click on a tag, its icon disappears.
• When I remove a tag from an item and navigate to that tag entry on the Places panel, the un-tagged item still shows up there until I restart Dolphin.
• When I add a tag to an item and navigate to that tag entry on the Places panel, the item does not show up there until I restart Dolphin.

Or maybe there's something wrong with us, or maybe git is just obtuse and it takes 10 years of constant use to avoid making silly mistakes with it. :)

Looks better with fractional scaling and doesn't regress at all for 1x scaling. Drop shadows are still rendered. Code looks good.

Update the string

This doesn't seem to have the desired effect. Here's how it looks for me without the patch:

In D14196#294949, @rkflx wrote:

In D14196#294948, @ngraham wrote:

"while dragging selection box" is pretty common and well understood in English.

You are dragging "something", and as I tried to point out above, that "something" is not the rectangle, box or whatever you call it. The rectangle stays stationary, and only changes its size. What you are dragging is the physical mouse, the cursor on the screen, and the selection handle under it (along with the edges attached to it, but not all edges and thus not the complete box).

In D14196#294947, @rkflx wrote:

It's probably impossible to specify the exact conditions the magnifier appears in, unless you put tens of lines of code into writing. Therefore we have to find the most accurate compromise.

Since initially drawing the selection and afterwards using the mouse to modify it are the most common scenarios, the text should adapt to those. Also, for keyboard navigation (which I'd assume is a rather minor use case) the meaning of Shift is redefined in the text, so I don't think it would be that confusing.

"Changing" also seems to cover the case of using the new keyboard shortcuts to modify the selection rectangle, even though it won't actually appear while doing so.

To me, "Resizing selection" communicates modifying something that already exists, not creating it anew. Also, it wouldn't be accurate now that we have the keyboard manipulation feature merged, because it's now possible to resize the selection with the keyboard and not see the magnifier.

Should this be marked as resolved?

Fantastic, thanks!

You don't have to ask the majority to determine a good default. That's the job of a good UX designer, using the skill of empathy.

Address review comments and adjust side padding

Sorry for the delay!

Thanks! BTW, It's now technically acceptable for the BUG: keyword to go at the beginning. Sysadmins fixed the bug that was preventing this from working before.

Since this code is somewhat counterintuitive, we might want to add a comment explaining it.

Thanks for the update!

@tmarshall, any update on this?

I will land the patches later today. Thanks again for submitting them and making Dolphin even more awesome!

For now, one of us can land these very nice patches for you. Since you didn't use arc to upload the patches (see https://community.kde.org/Infrastructure/Phabricator#Using_Arcanist_to_post_patches), we'll need to add the git authorship information by hand. Can you tell us your real name and preferred email address?

Yeah, the magnifier shows up while dragging the selection rect (or not, depending on whether or not you've holding down ⇧), but it currently doesn't show up when you're using Alt to resize the rect using the keyboard arrow keys.

I'm noticing that the magnifier doesn't er show up while you're using the keyboard to resize the selection rect. Might wanna hook that up.

Retroactive +1 :)

Heh, each of our preferred wordings reveals our workflow: I always drag a new selection rectangle, so to me, "dragging" makes sense as a description of how it's used. But as I recall now, you prefer to have Spectacle remember the previous selection, and you resize it from one of the handles, so "resizing" is the word that best describes how you use it. It seems we need to think of a string that adequately describes both use cases...

Fixed in 75a3723c45e3cfeae6c57b7661e0a8864f42b51c. Code in question is no longer in master, 18.08, or 18.04 branch; 17.12 branch is obsolete.

Ping? Is the proposed wording good enough, or should we maybe instead just remove the word "this" and make it use "Remove <widget name>?

Excellent. @rkflx, any last comments or objections, or shall we push this to the 18.08 branch?

I mean, they have an outline when not hovered. As in, they look like buttons. :)

Maybe out of scope here, but I'd really like to see borders around the number buttons. I've used software dialers where the numbers didn't look buttonlike, and they always felt slower and more awkward to use.

Fantastic, that's fixed it! This is a terrific patch, IMHO. Let's land it in master rather than the just-created 18.08 branch, and let's also probably wait for @hindenburg's opinion, too. :) I don't feel comfortable doing a real code review for this kind of diff, so my review is for behavior only.

I'm happy with this patch now. The behavior seems useful and is invoked naturally, the inline documentation is clear, the code is sensible, and I couldn't find any regressions.

In D14174#293468, @hein wrote:

We have blurred context menus now? Wtf.

But ok.

Thanks! Can you commit this to the Applications/18.08 branch so we can be sure it gets into the 18.08 release?

Well done. You fixed one of my biggest annoyances with Konsole: the high precision required to re-order tabs without detaching them. I feel like the size of the dead zone could be increased even a bit more, but this implementation is already radically better then what we had before. Kudos!

Sorry to hear that, and I hope things get easier.

Yeah, I say let's remove the test for now so we can commit this, and then you can add the test back in another patch please (in working form, of course!). :)

Whoops, my bad! It has been so long since I last saw this that I forgot completely what it was about and trusted the Phabricator metadata.

Only use the alternating row colors for multi-column views, to avoid having it on any vertical sidebar-style lists

Also, the title of this patch needs to follow commit message best practices. See https://community.kde.org/Infrastructure/Phabricator#Formatting_your_patch and https://chris.beams.io/posts/git-commit/#seven-rules

In D13901#292871, @steffenh wrote:

Hi, @ngraham,

thank you again for your time, to test this patch.

• Address review comments
• Make it a level 3 label to match other Headings used for panel adjustment
• Make the buttons span the full width of the menu

Here are the behavioral quirks that I found during testing:

• When drag-re-ordering tabs, the dragged tab visually stays on the bar now and only moves horizontally (yay!) but if you release the mouse outside of the tab bar, the dragged tab now detaches with no warning*
• Tab context menu lost its Close menu item
• When "Show new tab and close tab buttons" becomes checked after being unchecked, the space reserved for the New Tab button doesn't actually have that button in it until you quit and restart Konsole

+1 from VDG. As with others, please get a code review too.

VDG-approved, but please get a code review too.

+1 visually and conceptually (I like the idea of a single Scale effect that animates both opening and closing). KCM looks fine. No comment on the code since this isn't my area of expertise.

Shall we commit this? maxrd2 , can you do it, or does one of us need to commit it for you?

Ping?

@andreask verbally (textually?) approved this in the VDG room; landing it.