Bug 59570 - UI: scrollbar used in place of a slider in image export dialog
Summary: UI: scrollbar used in place of a slider in image export dialog
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:5.3.0
Keywords: difficultyBeginner, easyHack, topicUI
: 92028 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-01-18 19:11 UTC by Rainer Bielefeld Retired
Modified: 2017-02-14 08:57 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
mockup (61.52 KB, image/png)
2013-01-18 19:11 UTC, Rainer Bielefeld Retired
Details
Screenshot from 4.0.0.1 rc with comments (62.56 KB, image/png)
2013-01-20 08:21 UTC, Rainer Bielefeld Retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2013-01-18 19:11:11 UTC
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
Comment 1 Stefan Knorr (astron) 2013-01-20 00:40:37 UTC
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?
Comment 2 Rainer Bielefeld Retired 2013-01-20 07:07:59 UTC
(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?
Comment 3 Rainer Bielefeld Retired 2013-01-20 07:31:30 UTC
Or with something like a scale

 ========================V=========   ___82_ %
-|   |    |    |    |    |    |    |+
Comment 4 Rainer Bielefeld Retired 2013-01-20 08:18:23 UTC
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?
Comment 5 Rainer Bielefeld Retired 2013-01-20 08:21:52 UTC
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+
Comment 6 Lior Kaplan 2013-01-27 22:00:26 UTC
(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).
Comment 7 Heiko Tietze 2016-06-08 08:04:00 UTC
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.
Comment 8 Heiko Tietze 2016-06-28 15:11:35 UTC
NEEDINFO for the code pointers.
Comment 9 Adolfo Jayme Barrientos 2016-07-10 23:18:15 UTC
*** Bug 92028 has been marked as a duplicate of this bug. ***
Comment 10 Adolfo Jayme Barrientos 2016-07-13 02:26:03 UTC
I’ve provided some code pointers in the description of bug 92028, which is a duplicate of this one.
Comment 11 Commit Notification 2016-07-13 09:00:29 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d31e13efa8eca0997f02bceadff659f06d4dc9a0

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:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Heiko Tietze 2016-07-14 10:51:53 UTC
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.