Bug 74371 - UI: Delay in pushing in/out toolbar on/off (toggle, Boolean) option buttons
Summary: UI: Delay in pushing in/out toolbar on/off (toggle, Boolean) option buttons
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: lowest trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: Button-Controls
  Show dependency treegraph
 
Reported: 2014-02-02 12:19 UTC by dg1727
Modified: 2019-08-30 07:37 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dg1727 2014-02-02 12:19:31 UTC
I noticed this on the Options toolbar in Draw.  

Some toolbar buttons are Boolean option selections that look "pushed in" when the option is enabled.  

Issue:  there is too much delay from when the user clicks the button to when the button toggles its status.  

This can cause the user to click the button several times rapidly, on the assumption that the first click may not have registered.  This can cause the button to toggle its state a couple of times after the user stops clicking; this can be further annoying.  

LibreOffice 4.1.4.2 on Ubuntu 13.04.  I'm using the "libreoffice/ppa" PPA from launchpad.net.
Comment 1 Dominique Boutry 2014-02-03 16:02:24 UTC
Hi. Thank you for your report. It deals with the great subject of UI reactivity.

The facts are that :
- the modern "fat" softwares perform tons of calculations, UI updates, etc. at each user interaction,
- the reactivity depends on the power of PCs, their workload (multiple software running at the same time ; or CS architecture like CITRIX), and the design of the observed software (LibreOffice here).

A trade-off must be found between :
- a less multi-threaded design, wich ensure good synchronisation between all part of the software (UI and internal state, for instance), at the price of a slow reactive UI,
- a more multi-threaded design, which leads to complex bugs, often impossible to reproduce, due to the accepted desynchonisation (see bug 73829 comment 3).

In the current case, it is not very difficult to make the button toggling exactly at the time it is depressed, but an unavoidable calculation time is needed to set accordingly the internal state of the (rich, large) LibO software. Not all users have very powerful workstations.

Status kept to UNCONFIRMED, to get additionnal advices.
Comment 2 Joel Madero 2015-02-22 06:49:53 UTC
Ubuntu 14.10 x64
LibreOffice 4.4.0.3 release
LibreOffice 3.3 (updating version to reflect that this bug came from OpenOffice days). 

Note that version reflects oldest version that the bug is confirmed on - comments are used to say that the bug still exists on a currently supported version.

Confirmed

Marking as:
New
Trivial - virtually has no impact - the delay is less than 1 second. Even if a user is impatient, they'll quickly learn what's going on and hopefully slow down by 1 second when they click an option.

Lowest - default for trivial bugs - seems appropriate.
Comment 3 tommy27 2016-04-16 07:28:45 UTC Comment hidden (obsolete)
Comment 4 QA Administrators 2017-05-22 13:26:58 UTC Comment hidden (obsolete)
Comment 5 Thomas Lendo 2019-08-29 13:23:24 UTC
Adding needsUXEval to discuss this issue.

Is this still relevant? My take is this is a WFM or a NAB.
Comment 6 Heiko Tietze 2019-08-29 13:50:57 UTC Comment hidden (obsolete)
Comment 7 Heiko Tietze 2019-08-30 07:37:42 UTC
(In reply to Thomas Lendo from comment #5)
> Adding needsUXEval to discuss this issue.
> 
> Is this still relevant? My take is this is a WFM or a NAB.

Let's close as WFM.