In D12458#252790, @muhlenpfordt wrote:

Looks good. :)
Only arc patch fails:

Cherry Pick Failed!
Exception 
Command failed with error #1!
COMMAND
git cherry-pick 'arcpatch-D12300'
[...]

After the discussion in https://bugs.kde.org/show_bug.cgi?id=270980, I thought I'd create this patch to allow others to easily test out a higher value and provide input.

LGTM, apart from the mentioned small custom icon issue (see inline).

• Update i18nc context

In T6321#139303, @ngraham wrote:

In T6321#139272, @dporobic wrote:

Anyhow, here another solution, the one that you mentioned last. It's the same approach that Microsoft uses in PowerPoint, there you can have multiple items selected and you can select one by one

I'm still refactoring that thing but the visual should not change.

+1, that's great, and a very common UI in drawing apps.

In D12301#251549, @rkflx wrote:

Some smaller things, but looks good mostly.

In the end this endeavor turned into more than simply displaying "1/10" in the statusbar, but I think it was worth it!

• Use contents margins instead of stylesheets
• Remove old include
• Formatting
• Variable rename

In D12429#251563, @rkflx wrote:

Cool, works great! Perfection level 99% in the code ;)

In D12458#252085, @rkflx wrote:

Revert allowing to resize horizontally.

Let's wait what people think.

No need to wait for that, @huoni originally set a fixed size, after all.

In D12300#252037, @rkflx wrote:

I don't know, try it out ;) In the end there should be no division by zero, and there should be some lower (1x1) and upper (??) bounds in terms of pixel size.

Hm, thought about this again. The percentage spinbox allows to scale up to 10x, or to reduce size by factor 100 (after dropping the decimals in my patch, at least), e.g. from 20000px to 200px. I think that should be more than enough.

Also, the pixel spinbox takes precedence, thus allowing to override the percentage spinbox, so users can still set whatever they want. IOW, I wouldn't change anything in how it currently works.

• Remove the resize prevention
• Remove size policies for pixel spin boxes

In D12301#250759, @rkflx wrote:

In D12301#250758, @huoni wrote:

In D12301#250755, @rkflx wrote:

Aha! I've noticed this too: rm ~/.config/gwenviewrc shows 1 line, wiggling the slider shows 2 lines even for the lowest setting. Sure, go ahead and change it (but make sure to test with other styles too).

Hmm, different widget styles are a problem. But that seems to be an existing issue. The minimum thumbnail bar height is different depending on the style (it's set to mRightToolBar->sizeHint().height()).
Perhaps this needs a rework in a separate diff? 1) Make sure default and minimum sizes are the same (dynamically calculate default). 2) Ensure the minimum/default size shows exactly two lines.

Doing this in a separate patch sounds like a good plan. In general hardcoding sizes in the UI file is unfortunate, this should all be done by the layout itself. Or perhaps it just needs an adjust() after showing?

In D12301#250755, @rkflx wrote:

Aha! I've noticed this too: rm ~/.config/gwenviewrc shows 1 line, wiggling the slider shows 2 lines even for the lowest setting. Sure, go ahead and change it (but make sure to test with other styles too).

In T6321#139109, @dporobic wrote:

@huoni how about something like this for selected items:

In D12301#250675, @rkflx wrote:

One more thing about the fullscreen label: Before the patch it was centered vertically, now it is quite crammed to the top. I don't think we can change anything fundamental there, but perhaps we can tweak it a bit: For the default height, two lines of text are showing, but the bottom line is still positioned a bit above the image counter. If there was a way to manually align both, the top line would get a tiny bit more space to the top.

• Switch to KSqueezedTextLabel, and also use it in Browse mode
• Adjust full screen label margins so that labels line up at min height

Also LGTM :)

• Add UI markers to i18nc contexts
• Hide 0 image/video count unless 0 of both in Browse
• Implement autohiding doc count label in View mode

Thirded! Looks good.

In D12301#249381, @rkflx wrote:

Any extra width will cause more wrapping for the filename, because the labels are in a horizontal layout. I will try a vertical layout, which will mean the filename will only get one line's worth of space at minimum (default) thumbnail size.

It's not only about the filename, isn't it? You can choose to display all sorts of meta information there, spanning more than 5 lines in extreme cases. I don't think a single line will do. I don't think the linebreaks are too bad, my comment in the bug was more about the fact that despite so much whitespace you already needed two lines. I guess that's solved in the current version of your patch, so nothing to worry about IMO.

In D12301#249286, @rkflx wrote:

Cool. Some quick feedback and final tweaking for things we did not catch in the design phase:

• Please don't forget about BUG: 203042 ;)
• Browse mode:
  • I'd prefer "with the last part hidden if there are no videos" over "0 videos".

In D12300#248620, @muhlenpfordt wrote:

Works good for me.
Only when I modify pixel size too small or too big the percentage values does not update below 1.00 % or over 999.00 %.

Point of discussion: Compare / Light table mode. In normal View mode, I simply hide the document count in order to make room for the Synchronize checkbox. But in Full Screen mode, this is unnecessary, so it's not hidden.
So do we leave it like this, even if there's inconsistency? Show the label in normal View mode and but hide if the window width too small? I feel like the count isn't super useful in this mode anyway, so I would be happy leaving it like it is.

What are people's thoughts on lack of "width" and "height" labels? We could do something similar to KolourPaint where the columns are labelled.

In T6321#138792, @dporobic wrote:

I'm not sure about the selection rectangle, especially for lines/arrows. I think drawing an outline/stroke to indicate selection would look better, and perhaps less confusing when there are a lot of shapes selected. Additionally, the resize handles already indicate which item is selected, so you could go without the selection outline when only one item is selected.

I was trying to accomplish this before but it isn't that easy with the tools that I currently have. I was not able to get only the outline of items as they are composed of paths and you get some strange construction when you try only to draw the outline. What could eventually work is using something like the shadow effect to have the outline, but that is just some guess. I'll try to play around with it more, let's see if I can come up with something. Any other ideas are also welcome.

In T6321#138408, @dporobic wrote:

Would be nice if you could test it out and give me some feedback.

At least you won't get bored in the meantime with CMYK and the statusbar…

Tested and working in both cases, and code makes sense.

• Explicitly pass ViewMainPage to DocumentViewContainer

• rebase

• rebase
• update summary

In D11798#243110, @rkflx wrote:

In D11798#243070, @huoni wrote:

Sorry to hear, but which Diff is this supposed to be a duplicate of? For me the problem is still there, and your patch fixes it (pending complete review).

D11633

Oops ;) I guess I did not make the connection because you retitled the other Diff.

What if we provided the <release> tag XML on the website, instead of embedding in the tarball? Discover could then just pull it down live and display them the same way it does currently.
If I understand it correctly, that would result in the same good UX like this patch, which also avoiding the issues with having developers embed the release notes in the tarball.

In D12059#244951, @rkflx wrote:

In D12059#244707, @huoni wrote:

This technically clips up to 1 pixel of the actual SVG, but I still agree it's the best solution.

Hm, hard to reproduce for me. For my test SVG I could not get the red border to be clipped, even when trying with other sizes (i.e. different to 180px width).

• Remove leftover include

Redo works perfectly, and unit tests succeed. LTGM.

In D12059#244215, @rkflx wrote:

Another way which made it work good enough for me (i.e. the best among all iterations we tried so far) was reverting your introduction of SvgImageView::setScale (which is a bit brittle anyway), while keeping ItemClipsToShape. I never got a clear gap, only in very few situations there was some antialiasing over the background. Could you try that? If that worked for you, that would be my preferred option.

• Remove setScale to rely on ItemClipsToShape

I tested by:

In D12059#243863, @rkflx wrote:

Where I still got problems was when I let the rectangle extend generously over both the left and right side of the document (black rectangle on the top), which led to Gwenview drawing the rectangle 1px wider than the transparent background (yellow) (apart from that, clipping to the document size worked fine):

Might as well be a totally different topic, and certainly extending content beyond the document size is not that common.

• Fix some SVGs painting outside their bounds

In D12059#243639, @rkflx wrote:

Yay, works much better now. I still get some overflow on the right edge, though. Perhaps you also need to adapt the size?

• adjust SVG size so it never goes outside background

In D12059#243493, @huoni wrote:

In your screenshot, you can see the border is correctly drawn next to the background. It's the SVG itself that seems to be unaligned. I will look into this, and probably submit another patch.

• Also make sure SVGs are drawn at integer coordinates

In D12059#243477, @rkflx wrote:

For SVGs depending on the zoom level I still get some displacement, however this is also visible when viewing an SVG in single mode, i.e. without a frame. Might be some rounding problem related to where the SVG renderer is placed, so unrelated to this patch but still kinda annoying:

In D12059#243126, @rkflx wrote:

The current Browse mode frames already seem to contain considerations for these points, maybe cleaning them up and applying them everywhere will be sufficient.

Or another idea - force it to be drawn 1.5 pixels away from the image, resulting in @rkflx's screenshot but without the gap. That could help with when the image is a similar colour.

In D12059#243109, @rkflx wrote:

Also, a proper fix for this would be to alter the frame, i.e. use a different coloured line or add a shadow. As you can see in my screenshot, this is already the case (not sure why this is missing in Huon's screenshot, probably because of the background colour?).

In D11798#243028, @rkflx wrote:

In D11798#242943, @huoni wrote:

Duplicate

Sorry to hear, but which Diff is this supposed to be a duplicate of? For me the problem is still there, and your patch fixes it (pending complete review).

In D12059#242978, @muhlenpfordt wrote:

But I would prefer keeping the gap because the frame is nearly invisible if the image has similar colors.

Tested, no issues for me :)

Duplicate

I'm not sure if my comments sufficiently explain the reasoning. Would welcome feedback, especially since it feels necessary to explain things in multiple places.

I can't reproduce this on 18.04 or 17.12.3 (my system version), so I'm afraid I can't test.