Bug 99776 - UI Firefox theme selection dialog makes bad use of screen space
Summary: UI Firefox theme selection dialog makes bad use of screen space
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected)
Hardware: All All
: medium minor
Assignee: Muhammet Kara
Whiteboard: target:6.2.0
: 93599 (view as bug list)
Depends on: 113385
Blocks: Firefox-Themes
  Show dependency treegraph
Reported: 2016-05-11 13:58 UTC by Katarina Behrens (Inactive)
Modified: 2018-10-10 12:38 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Katarina Behrens (Inactive) 2016-05-11 13:58:32 UTC
This is a spin-off of bug 88502. Now that fetching/searching for Firefox themes actually works, there are still some small tweaks to be made. Quoting from IRC discussion on topic:

"atm the dialog shows 9 empty previews. I don't think that's smart usage of screen space. Either hide the previews until a category is actually selected or pre-select LibreOffice category and load those previews"

My comments: I wouldn't go with preloading (since fetching those previews is dog-slow)  and I'd wait for user to actually select something and only then enlarge the dialog accordingly.
Comment 1 steve 2016-05-11 14:08:12 UTC
agreed → new
Comment 2 Heiko Tietze 2016-05-11 14:17:50 UTC
My suggestion is to treat the categories as filter and to preload all themes. The whole thing would be designed completely wrong, otherwise.

Dogginess: Can't be such a big deal to get a couple of bytes.
Comment 3 Heiko Tietze 2016-05-11 14:19:04 UTC
Component -> UI, Keyword -> needsUXEval (+CC ux-advice)
Comment 4 steve 2016-05-11 14:24:05 UTC
I still don't understand which themes are showing for the categories. Are they random? Or the first 9 mozilla shows for the specific category? Imo those themes should work really well with LO and not change.

If they don't change the preview image could be hardcoded and no loading at all needs to be done. Problem solved?
Comment 5 Heiko Tietze 2018-04-10 09:19:26 UTC
No further input so removing UX. Whether the first items are loaded (after making it fast, bug 113385) or hard-coded (as Steve suggests in c4) doesn't change my take in c2 => preselect one category and load on start.
Comment 6 Heiko Tietze 2018-04-10 09:21:47 UTC
*** Bug 93599 has been marked as a duplicate of this bug. ***
Comment 7 Heiko Tietze 2018-04-10 09:22:29 UTC
Some further information in bug 93599.
Comment 8 Muhammet Kara 2018-10-10 10:56:51 UTC
Preloading seems fine now as the search/preview is much faster than before. Patch is on gerrit: https://gerrit.libreoffice.org/#/c/61609/
Comment 9 Commit Notification 2018-10-10 12:34:40 UTC
Muhammet Kara committed a patch related to this issue.
It has been pushed to "master":


tdf#99776: Preload a persona category initially

It will be available in 6.2.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.
Comment 10 Muhammet Kara 2018-10-10 12:38:04 UTC
It currently preloads the "LibreOffice" category, but it can be easily changed by adjusting the number on https://opengrok.libreoffice.org/xref/core/cui/source/options/personalization.hxx#29