Created attachment 73253 [details] mockup 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. Ad a) 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.) Ad b) Right, hopefully we can use Glade's/GTK+'s Scale widget – that would help immensely. (See above.) Ad c) 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. @Lior: Is that the usual RTL logic to increase / decrease numbers with a horizontal slider?
Created attachment 73321 [details] Screenshot from 4.0.0.1 rc with comments It's a little difficult to see the Slider because of an other bug what has been fixed in between for 4.0.0.1+
(In reply to comment #4) > @Lior: > Is that the usual RTL logic to increase / decrease numbers with a horizontal > slider? 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).
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.