• Rebase

• Remove inline keywords

• Rebase

• Unfuzz borders and text
• Restore old help box functionality

• Fix magnifier border

In D12692#258302, @rkflx wrote:

In D12692#258300, @abalaji wrote:

• Fix all border issues

Selection border looks much better now ;) More comments:

• Is the bottom and right border of the magnifier working for you with 1x scaling? Just asking, because with QML it never worked for me, but for QPainter it should probably work?
• The borders of the size label and the bottom help text are still fuzzy.
• Make sure to add your fixes to the correct Diff (this one is only about the magnifier, IIRC ;)

• Rebase

• Fix rectangle border painting

• Fix all border issues

Oh I noticed that too, just figured it out, it is aligned, but the dark mask is one pixel off haha

Yeah, you're right, anti-aliasing wasn't the culprit, here's a screenshot with anti-aliasing back on for confirmation

Ahh, gotcha, and I know why: anti-aliasing, I'll disable it and take a screenshot again

Rectangle is now 1 "real" pixel wide even on HiDPI. Tested on 2x scaling on 3840x2160. Red line is 2 real pixels wide.

So, is it best to just ditch inline from everywhere and let the compiler decide?

Make the rectangle border one real pixel thick, and align border to crosshair

In D12692#258244, @anthonyfieroni wrote:

One nip-tick: inline should be placed in function definition not in declaration, you can make other review to correct it.

Rebase

Rebase

Fix diff

• Fix issues

Oh so sorry @rkflx, I keep forgetting that the "title" is the commit message, my bad! And the top of the crosshair was correct at one point, I pushed the wrong thing out whoops, I'll fix that right away. By logic, I guess I meant more about the behaviour, but a code review would be great too :D. I'll work on the border stuff next

Hooray, bless! You say the next ones won't be this easy, I believe you haha

Got the magnifier out here: D12692

@rkflx check out D12693

Done

• Undo change

The code still needs a little cleanup, but before that, please make sure I got the logic down

• Fix out of bounds by one pixel

• Optimize mouse tracking
• HiDPI and other fixes

• Rebase master

• Oops forgot light background mode

• Respect theme colors

• One more

• Undo split off changes

• Back to C++11

Split off from D12626

In D12626#257035, @rkflx wrote:

Cool, thanks for your continued work. Take your time, no need to rush. I'll still fix the colour scheme issues with the QML UI (see D12657), but it should be quick to also take those over into your port.

Note that my first comment was merely some quick feedback, obviously more in-depth testing and code review will follow when I have more time. As mentioned before, please adapt your title to the imperative mood, and split the patch up into multiple Diffs (e.g. porting, fixing leaks, adding the magnifier back etc.).

As for the VM: It does seem to have some kind of accelerated code path regarding video acceleration (e.g. for KWin there is OpenGL through the guest addition drivers instead of XRender), but my machine is pretty slow anyway.

(One more thing that came to mind: It's probably the approach of using getContext("2d") that made it so slow before your patch, because normally QML should be hardware accelerated, after all. It really depends on what your project is about: Pixel pushing vs. a fluid IVI UI. No QtQuick hate, please ;)

Regardless, as your patch makes it faster on your enormous screen, I'm all for it.

@anthonyfieroni

• Clean up header files

Thanks @ngraham, ikr so much faster. I think I'm going to think twice before using QtQuick for my next project

Before:
(pointing out a nitpicky bug of not changing the cursor before you move your mouse)

Before:

After:

PS: Sorry, just couldn't get my phone camera to focus (I think I might have broken it)

Alright, so I've now ported over the new help menu from D12617. Got to port over the magnifier from D11599. Videos and screenshots coming over soon.

• Implement new help menu

We can use the same trick we use for the selection size tooltip, and have a dark rectangle with light text with a dark theme

Hey, guess I'm too late. Was testing this with Breeze dark and looks like the text turns white, rip{F5829848}

I've taken inspiration from gwenview's trick of hiding unnecessary controls when not needed. So now I only draw the bottom help text and the drag handles when the mouse is up and no drag is in progress. This might give a slight performance boost again, since the function does less heavy-lifting while dragging.

• Refactor

• Switch to QWidget

@rkflx thanks for the review!

• That's right, I have a gwenview one that I'm kinda blocked on as I'm on the road and don't have enough means to test stuff, as for the dolphin one I'm seeing some weird issues with the Breeze widget style, trying to figure those out, I'll try my best to devote as much time as I can
• I kinda forgot the summary is a commit message, my bad, it's fixed now
• #3 and #4 can be made their own thing probably
• These are related to memory leaks I found and patched, related to #3
• Yeah, I saw those right after I pushed out this diff, D12617 should be quick, D11599 might take longer

@ngraham I've been out of town on an internship since early Jan, and haven't been able to test some of the HiDPI stuff across monitors with different scaling, so I've not made a lot of progress since. I'm coming back in a few weeks, and I can catch up after that

• Minor fixes and cleanup

And @markg I found this tool that lets you simulate a touchscreen: https://github.com/vi/virtual_touchscreen

I "abandonded" it, does that not do that?

Sorry @markg, I created this revision by accident while setting up arc, D12162 is the leading one

• Touch double click

Hmm, I had to get rid of the touch-hold-drag thing because earlier I was just adapting the existing mouse event handlers with touch, but because multitouch caused issues with that, I've now had to setAcceptTouchEvents(true) on the KItemListView, which means Qt will no longer emit fake mouse events on touch, and that also means no drag and drop because it seems that only works with mouse events. I also disabled rubberbands on touch so I'm seeing any on my end. What kind of touchscreen do you have? Can you verify if touchBeginEvent, touchUpdateEvent, and touchEndEvent are all firing for you?

Now using arc

Thanks! I'll use that from now on. I've just been using git format-patch so far.

Okay, so that seems to have fixed that. Is there a cleaner way to append a diff rather than squashing commits together? Can I just push to a branch or something?

Squash diffs together

Simplify some if-else statements

Due to the limitations of detecting multiple touches with "fake" mouse events triggered by automatically by Qt on touch, I've had to implement real touch event handlers and which means goodbye drag and drop because after some digging it seems that touch events and native drag n drop don't work well with each other. I've also added the touch gesture to the information panel which is partly broken right because of the "Drag windows by empty space" feature discussed before

So I'm facing issues with this thing which after a bit of digging turns out to be this feature where kwin lets you "Drag windows from all empty areas" (default System Settings -> Application style -> Widget Style -> Applications -> Configure... -> Windows' drag mode), which often gets triggered (incorrectly) by touching and dragging on an empty area like while touch scrolling on the information panel. If you click and drag with a mouse, the dragging works as expected, but when you touch and drag, the window gets put into dragging mode (turns translucent due to desktop effects), but stays where it is and freezes. I have to lift my finger and touch it back down at a spot to make the window move there. This probably has nothing to do with dolphin itself but it's really weird when this effect kicks in, but regardless of whether it happens correctly or not, I was wondering how kwin figures out which widget is an "empty area" and if there's a way for a widget to tell the window manager it wants to disallow that?

Hi @ngraham thanks for reviewing this!

• I'll implement touch in the information and settings panels next.
• 1 second is probably too long, but regardless it might be failing because a mouseMove event is accidentally getting triggered while you're holding (probably finger fatigue during that one long second), which instantly cancels the QTimer that enables dragging. One way to fix that would be to store the coordinates of the mouse press event, and on a mouse move event, rather than cancelling the timer, have a threshold of distance your finger can wiggle around.
• The last issue is probably because I'm currently assuming that the events fire like touch start -> (maybe) touch move -> touch release, which would obviously break with multiple fingers. I can just ignore every additional finger touch, easy fix.

Remove unnecessary edits

Can we just multiply with dpr here and elsewhere? I'm asking because before this could have two distinct values, but now depending on a fractional scaling factor this can vary wildly.

Maybe this is okay if this is just a threshold internal to Gwenview, but in case this is related to an external standard which specifies this sizes (thumbnail caching?) it would be a problem.

Could you research this a bit?

The thumbnail sizes are specified in thumbnailgroup.h. I think the thumbnails are stored in the thumbnail cache somewhere. I'm not too sure right now about where exactly the logic governing that is, but I think we should be storing high DPI thumbnails in the cache if the user has a hidpi display, and let QPaintDevice->devicePixelRatio() handle the scaling while painting. Either way, I think we should let thumbnailgroup.h specify the base "logical" thumbnail size, and scale that up accordingly, like I've done here. What's your opinion on this?

Hi,
Hope everyone is enjoying the holidays!

Fixing rendering of frames and shadows.

I figured these out, so these are not pixelated anymore :). Going up to like 6x scaling helps a lot with identifying and fixing these issues, thanks @rkflx for the tip!

I should be using QPaintDevice while painting them it seems, so I'll need to get that sorted out

This was pointed out in D7581#141493, so qApp->devicePixelRatio() gives the largest value of all the DPR's of the connected monitors, and QPaintDevice->devicePixelRatio() gives the DPR of the current screen, so while painting, I need to use this value to ensure that the scaling is correct. This needs to be fixed in the main patch as well

Thumbnail Bar broken, regardless if I apply your patch standalone on master, on the tip of the gsoc branch or on the commit before the tip. Am I holding this wrong? I wonder, because you said 1. is fixed, but the Thumbnail Bar is listed there…
Video thumbnails still pixelated, even though you said 1. was fixed.

I guess I just fixed part 1 of the 1, sorry I missed all these cases. I'll try and get these fixed soon as well, sound be similar enough

Thumbnails should fit the space available, but when previewing a very low-res image the thumbnail is also very tiny. Should we upscale in this case?

Well, so if the image itself is tiny, then I don't think we should upscale, since that's the way it is currently, and we shouldn't change the existing behaviour

Do you know about the list of issues in D7581#163655 (1. specifically)? Is this all expected to work with your patch?

1. is the only issue fixed in this patch. The frames around the thumbnail pixmaps seem to be already working correctly: I cannot make out any issues with it.

Hi, if you haven't already, please have a look at D9078, where I figured out HiDPI for thumbnails. I would love to have some feedback, As for the small thumbnail issue @hetzenecker was facing, I was facing that too, but I realized I needed to generate bigger thumbnails, so if I have 2x scaling, I generate 256px * 2 = 512px wide thumbnails, unlike D6083 which suggests upping the base thumbnail size itself. The HiDPI patch for Okular (thank you @hetzenecker!) landed and I'm glad I can finally switch back from evince, and it would be great to have gwenview fixed soon as well!

Hi, sorry for replying this late, I'm glad you're happy about my contribution. I'm currently using QApplication rather than QWindow, QScreen etc, just like it is in the rest of the work by Lukas (basically I just looked at what he did and tried to do the same). So it's probably not the best solution, but it does take care of the thumbnails, which look much better now.