Created attachment 73253 [details]
In DRAW Menu 'File -> Export -> As PNG' you find a horizontal scroll bar what changes the compression rate in a range 0 ... 9 (left to right)
Although that is an interesting idea and a scroll slider hase some advantage compared to spin buttons (move fast for big change and then slower for fine tuning) for me that is a little unintuitive.
a) Numbers become changed up and down, that's the reason why most spin buttons (and as far as I know all in our UI are top-down. This left right concept is new and unintuitive. And no idea how that is for RLT countries users.
There should be something like a swelling curve or similar
b) Because that slicer has a very different function compared to a scroll slider, it should look different from a scroll slider. I owuld prefer some slide control look.
c) The knob has some strange owns own life. To reproduce,
1. increase width of dialog as you see in attached mockup
2. drag and drop the knob to the very right position
3. drag some mm left until Number changes from 9 to 8
4. release mouse button
> Unexpectedly the slider does a big jump to the left
Confirming on 3.5-openSUSE/x86-64, 4.1-master build/Linux x86-64 (both with the dialogue in the old src file format as well as in the new ui format).
I fully agree with Rainer that this is indeed a undesirable and rather quirky UI idea. I do not agree with him on the solution though:
* PNG compression is lossless anyway (thus doesn't impact perceived quality),
* CPU cycles for compressing should be reasonably cheap v/ the brain cycles of people trying to figure out if they should compress their image
=> Why not hardcode compression to "9" and remove the slider altogether?
However, even then we do have the same slider problem with JPEG "Quality" slider. Since JPEG compression is (visibly) lossy, it does make sense to show a slider here.
I would opt for the simple solution of structuring the UI like (ASCII mockup):
JPEG Quality ----------------------------
========================V====== ___82_ %
The left side being a real slider widget, the right side is the text, with an added percentage sign. The text "1 is minimum quality[...]biggest file size." can IMO be done away with without harm – I reckon our users understand what a percentage sign means.
I can't really agree – if you've ever worked with a number ray/coordinate system in school, you know the values become larger towards the right side.
(IIRC, this (having to do with Maths) is something that doesn't change in RTL layouts, so extra care should be taken that this UI is not mirrored.)
Right, hopefully we can use Glade's/GTK+'s Scale widget – that would help immensely. (See above.)
Can't reproduce in my master build. Maybe the widgets repaint faster on Linux?
(In reply to comment #1)
a) In Wikipedia I found only number lines from lift - to right +, so this indeed seems to be no problem(In reply to comment #1).
I did not want to say that horizontal slider is wrong, only that it is a little unexpected in that environment, where all other number changing UI elements are up <-> down. A more intuitive slider design as you suggested would help a lot.
Concerning PNG compression: I always use compression 9, but may be for some applications it might cause performance problems decompressing these pictures?
Or with something like a scale
========================V========= ___82_ %
-| | | | | | | |+
I did a check with RTL UI Arabic and Hebrew and found that there the slider function is flipped: increase LEFT maximum <-> decrease RIGHT minimum.
Is that the usual RTL logic to increase / decrease numbers with a horizontal slider?
Created attachment 73321 [details]
Screenshot from 188.8.131.52 rc with comments
It's a little difficult to see the Slider because of an other bug what has been fixed in between for 184.108.40.206+
(In reply to comment #4)
> Is that the usual RTL logic to increase / decrease numbers with a horizontal
It looks OK on master due to the scrollbar bug fixed. The logic seems fine (max compression on the left, near the box with the number).
Of course it has to be a normal slider. And meanwhile we have the control with an attached spinedit. The scrollbar vs. slider issue is relevant for png and jpg.
Personally I'd be fine with a fix number, but the whole workflow with an interaction (properties) after the conformation dialog (file save) is awkward.
Using the wrong control is a bug -> medium/normal. To replace a control should be an EASYHACK.
NEEDINFO for the code pointers.
*** Bug 92028 has been marked as a duplicate of this bug. ***
I’ve provided some code pointers in the description of bug 92028, which is a duplicate of this one.
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":
Resolves: tdf#59570 scrollbar used instead of slider
It will be available in 5.3.0.
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
Affected users are encouraged to test the fix and report feedback.
Looks good. I observed a strange behavior if sliders that might be attributed to KDE althought. Moving the slider slowly to left or right making the thumb jumping back and forth between the new and the last position. Just to mention it.