Oh crap, sorry I didn't reply last time. Things are pretty dicey for me at
the moment, so I'm not going to have the time right now unfortunately :(.
If someone could take over this diff, I would appreciate it

Hey @ngraham,
I'm terribly sorry, I've been busy with other things. I'll definitely come
back to this is a month or two, after things get a little freed up on my
end. Sorry for making you wait this long, I just saw your message

Hey man I'm still working on it, almost done, sorry it's been over a month.
Almost good to go. The plan is to wrap it up this weekend so we can get it
reviewed and merged before the next kde applications release

@ngraham still in the works unfortunately. Found an issue with it actually in one of the info panel widgets, tried to fix that a little. Last worked on it in the weekend, I'll let you know when it's done (hopefully really soon)

@ngraham I'm all settled down and have enough free time in a day to start contributing once again. I'll put up the updated diffs in the coming days

Hey, I'll be free come May, then I'll get back into action :)

@ngraham @volkov sure I don't mind, I already have too many things open haha, and I haven't been delivering :/. Life's been too hard on me lately and I can't catch a break. I expect to be freed up during the summer, so hopefully I can come back and finish some of the other work

Well true, probably for the best to go for 19.08. Sorry, I should have
tried to manage my time better

Oh rip, looks like I missed the bus. I have it done halfway locally,
perhaps I can get it cleaned up by tomorrow. Any chance for 19.04?

Hey @ngraham Im so sorry, I didn't see your message come through. I've been pretty busy the past week because of midterms at my university. I'll split this into two asap

Added a couple inline comments for you to address. Also, please use four spaces instead of tabs, and keep the spacing consistent (spaces around +, space between if () and the {. I have yet to run and test this, but if you check the comment on the left side of the diff, I wonder if just removing that .toLower() is enough.

• Add comments to i18n strings

In D17654#378981, @yurchor wrote:

However, the whole structure of the messages after 958fdc0a2532e30e7edfd1ec71f63fd3c87b5d35 is a classic case of word puzzles [1]. Anyway. it is better with this patch. So my +1.

• Fix typo

Oh, I see, I'll just move them into the constructor

• Change constexpr to const

• Cleanup

• Fix leak and warning

• Add my name to copyright

@ngraham sorry the past two weeks were quite busy for me, I've been travelling. I finally got some time to fix the help text. No more hacks like &nbsp

• Fix help text

Looks good! We can probably merge this before my D12626

• I don't think WA_TranslucentBackground is necessary
• Change newline handling

• Fix window flags

No nevermind that did the trick, Qt::Popup is the way to go 👍 thanks @kpiwowarski!

Hmph it was working properly with multiple screens, but with a single screen, it dodges the panels for me regardless of Qt::WindowStayOnTopHint. There should be a way to tell Qt to not do this.

Well, with WindowStaysOnTop, what about 374009?

• Make bottom text static
• Fix multi-screen situation

In D12626#368299, @kpiwowarski wrote:

I was experimenting some with that and finnaly I've found solution!

Replace showFullScreen(); with

setWindowFlags(Qt::Tool|Qt::FramelessWindowHint|Qt::NoDropShadowWindowHint|Qt::WindowStaysOnTopHint);
show();

Well, Qt::BypassWindowManagerHint is not really an option since the window manager is what's responsible for Alt-Tab and things like that. We'll have to make the widget extend across multiple screens some other way.

@ngraham @broulik I think I addressed all the comments. Let me know if there's anything else

• Microoptimize some arithmetic

• Update help text

• Rename variable
• Reorder includes
• Don't stay on top
• Don't hardcode font size
• Use KLocalizedString

In D12626#367822, @ngraham wrote:

Awesome work, I'm impressed. Now it's really fast, much faster than the current implementation. I left a few inline comments.

As-is, this almost entirely fixes https://bugs.kde.org/show_bug.cgi?id=374009, so it's at least worth a CCBUG: 374009. I left an inline comment detailing how you can make it fix that bug entirely. :)

Sorry @ngraham my bad, accidentally left some things uncommitted. It should now compile.

• My bad

• Add back keyboard controls

• Merge in lost changes and fix compiler warnings

Now merged into D12626

In D12626#367098, @ngraham wrote:

FWIW this also needs to implement the recently-added feature where you can move and resize the rectangle with the arrow keys.

• Merge branch 'qpainter-magnifier' into performance-enhancements-new-features

• Realized parent is a QObject, which won't work with QWidget superclass
• Now compiles

• Add more const
• If braces
• Color instead of colour
• Better name: mouseLocation
• Call super constructor

• Fix reference counting
• Delet "delete this"
• Forward declare
• Simplify using bitwise operators

In D12626#367054, @ngraham wrote:

The QWidgets port of the magnifier was originally added in a separate patch (D12692) because at the time the QML version hadn't landed yet, but now that it has I think we can merge the contents of that patch into this one so we can get 100% feature parity in one fell swoop. :)

• Change to Q_SIGNALS

In D12626#367052, @broulik wrote:

"Include mouse pointer" setting now blends the cursor into the screenshot right away, letting the user see it while cropping, rather than blending it in after cropping

As for this change, I prefer the old way: When I want to take a region screenshot, I place my cursor where I want to start the selection hit Meta+Shift+PrtScr, then draw the selection and then place the cursor where I want it in the screenshot (e.g. pointing at something) and take it.

I could probably get used to placing the cursor first and then taking the selection, dunno, it's for usability/VDG to decide what is the best approach here.

Since then I've fixed the camera on my phone, so I think it's about time I record new videos for the description.

• Rebase

• Remove unnecessary change

• Correct diff

• Rebase

• Rebase

• Rebase

I think most it is in there. I'll have a quick look just in case and let
you know. If anything it might have to be with HiDPI

• Remove unnecessary newline

• Tidy up diff

Hey @ngraham, as you can see I just added scrolling to two list views in the configure menu. Apart from that, there's just one minor issue in the information panel that I'm working on right now: when you touch a clickable thing like a link or a ratings star, then touch scroll, then release the touch point at the same spot on top of the clickable thing, it gets activated. I'm in the process of fixing this. But otherwise, a code review would be appreciated.

• Add scrolling to item lists in Configure menu

• Rebase

@davidedmundson awesome! I've been running around in circles trying to find this, glad that you fixed it! Although in the future we should support this properly.

• Rebase

Hey everyone, I can make some time for myself during this weekend to work on this, feel free to leave comments

@ngraham I can resume next week, having my exams right now

@fvogt I haven't worked on it for quite a while. I can resume working on this in a few weeks, after my exams are done.

Hi @rkflx sorry if me adding the arrow keys here threw you off, I personally thought it's trivial enough to have here, but I can move it into a new patch if that makes testing and review easier.

Thanks @steffenh, I've fixed the issues with the scroll bars.

• Fix issues with scroll bar on touch

Rebase

In D13450#283871, @sharvey wrote:

In D13450#283469, @abalaji wrote:

Also, looks like the current policy for HiDPI is to "scale up" the moves, so if I set QT_SCALE_FACTOR=5, the smallest move is 5 real pixels. We probably want to change that, so that we move by `factor / Screen.devicePixelRatio` which would ensure we move by `factor` "real" pixels. Apart from that, 15px seems pretty good on my 2560x1440 monitor.

I knew I should have held out for that 4K laptop. Does anyone receiving me have a genuine HiDPI monitor to test with, along side simulating it with QT_SCALE_FACTOR.

A few thing tho @sharvey, it looks like currently the resize functionality only moves the bottom right corner, and I've preserved that. But was wondering if we can add in Ctrl or something to control that. Maybe something like:

Alright everyone, I just ported over the arrow key functionality over at D12626.

Remove unused code

• Implement arrow keys to move and resize rectangle

In D13450#283466, @sharvey wrote:

In D13450#283464, @abalaji wrote:

Why not make it a user configurable option?

Certainly a managble task, but I sense there's some reasonable reluctance to adding even more config options to our beloved Spectacle.

In D13450#283463, @sharvey wrote:

In D13450#283448, @rkflx wrote

Hm, my intention when I triaged the bug was indeed to make it possible to set the selection rectangle from the keyboard. When I mentioned the separate patch, this was only about how to start the actual selection process. I don't think it makes sense to change the speed later again, we should get it right here.

The largeChange value is currently set at 15px. It's a variable (which I should probably make a const), so we can tweak it without monkeying about deeply in the code. All unmodified changes are 1px. I'd like to have people with various screen sizes help determine if 15px is a good setting.

And @rkflx, I'm also almost done porting this over to D12626

! In D13450#283442, @sharvey wrote:
My intent behind this patch remains geared toward incremental adjustments to the original mouse-drawn rectangle, not a full-blown replacement for drawing a rectangle entirely from the keyboard and having to make dramatic changes.

We discussed starting a rectangle with a keypress (maybe Space), but that idea was set aside for a separate patch. Perhaps we can revisit and further optimize the arrow keys then.

So, currently the arrow functionality depends on repeated Keys.onPressed events, which depend on keyboard repeat delay and rate (system settings -> input devices -> keyboard). This means we will always have an initial stutter followed by an arbitrary speed. This also disallows us to move in two directions at the same time, top and right for instance, since Qt only seems to generate repeated events for the last key pressed. Instead, this should be handled in a different way: have flags keeping track of pressed keys, which get set on Keys.onPressed and unset on Keys.onReleased, and requestPaint in the key press handler if one or more keys are set. Then onPaint repeatedly requestsPaint to keep calling itself if one or more of the keys remain pressed.