Bug 42029 - Can't access toolbar split/group button dropdowns from chevron button on smaller window size
Summary: Can't access toolbar split/group button dropdowns from chevron button on smal...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high enhancement
Assignee: Maxim Monastirsky
URL:
Whiteboard: target:5.4.0
Keywords:
: 36440 41895 44111 50143 51612 51826 68466 79768 88078 94754 101278 103549 105104 105425 (view as bug list)
Depends on:
Blocks: Toolbars-Overflow
  Show dependency treegraph
 
Reported: 2011-10-19 23:15 UTC by Kevin Hunter
Modified: 2017-10-07 11:24 UTC (History)
22 users (show)

See Also:
Crash report or crash signature:


Attachments
MaximizedWindow (71.90 KB, image/png)
2011-10-19 23:15 UTC, Kevin Hunter
Details
SmallerWindow (123.05 KB, image/png)
2011-10-19 23:21 UTC, Kevin Hunter
Details
Mockup: the picker as a submenu (26.36 KB, image/png)
2012-01-26 23:55 UTC, Ivan Timofeev (retired)
Details
googledocs mockup (12.05 KB, image/png)
2016-01-11 12:08 UTC, Yan Pas
Details
qbittorrent wtith chevron closed and opened (54.89 KB, image/png)
2016-09-08 16:10 UTC, Yousuf Philips (jay) (retired)
Details
how it looks (19.50 KB, image/png)
2017-02-16 12:09 UTC, Yousuf Philips (jay) (retired)
Details
ignore separators (25.51 KB, image/png)
2017-02-16 16:20 UTC, Maxim Monastirsky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Hunter 2011-10-19 23:15:10 UTC
Created attachment 52565 [details]
MaximizedWindow

Often, the most expedient method to make a document manipulation is with a shortcut button.  Some buttons have a submenu of options; for example, the foreground or background color buttons, or the borders button in Calc.  If the product (say, Writer) window is large enough, the button displays on screen and a user can click it for a drop-down menu of options (say a color swatch).  (Example shown in attached image "MaximizedWindow".)

However, if the window is too small and/or the button is too far to the right on the toolbar, then one must first access the button as a menu item of the '>>' button (menu shown in attached image "SmallerWindow").  This means that for buttons that have sub-items, like the borders button in Calc, the button is useless.

I don't know the proper way to fix this issue.  My first thought is to include the submenu of available options as a further submenu, akin to what "Visible Buttons" does with the right triangle in the "SmallerWindow" attached image.
Comment 1 Kevin Hunter 2011-10-19 23:21:36 UTC
Created attachment 52566 [details]
SmallerWindow
Comment 2 Kevin Hunter 2011-10-19 23:40:55 UTC
Forgot to add that the screenshots and described interaction were off of master:


$ date
Thu Oct 20 02:39:36 EDT 2011

$ git log -1 --format=oneline
5ad4d151dac1eb887d92200330e31af269d8d1fd migrate to StringRangeEnumerator in pdfexport
Comment 3 Rainer Bielefeld Retired 2011-10-20 22:02:30 UTC
Reproducible!
IMHO DUP of "Bug 34725 - Color Picker only comes up for visible icons"
Very old bug, not a particular Master problem. Also observe it with "LibreOffice Portable 3.3.3  - WIN7  Home Premium (64bit) German UI [OOO330m19 (Build:301  Tag 3.3.3.1)]".

"Submenus" are accessible, in example you see in screenshot you will have access to "Visible Buttons"

@Kevin Hunter
Due to <http://wiki.documentfoundation.org/BugReport_Details#Version> and especially for problems you observe in Master please always check whether the problem also exists for earlier versions.

Please feel free to reopen this Bug if you find evidence that we have an independent issue here.

*** This bug has been marked as a duplicate of bug 34725 ***
Comment 4 Kevin Hunter 2011-10-20 22:27:49 UTC
@Rainer:

Ah!  I had not seen that wiki entry.  I did check that this bug had already been reported, but apparently with less success and not specifically in older versions.  Just a general search.  Thank you for spotting it.

There's no need to reopen this bug.  Your first comment in Bug 34725 "Color Picker only comes up for visible icons" states exactly the issue I was trying to describe.
Comment 5 Kevin Hunter 2011-10-20 22:38:16 UTC
@Rainer:

Actually, I've looked a little more in depth at Bug 34725 and I'm do not think this bug is a duplicate of it.  filken specifically talks about the 'foreground color button' behavior vs the 'background color button' behavior whereas this bug is about the /change/ in behavior of those buttons when they are hidden in the overflow (">>") menu.  I think filken's attachment (https://bugs.freedesktop.org/attachment.cgi?id=47328) describes very well the problem behavior of Bug 34725.

However, I'll let you decide if this is still a duplicate because your comment 1 in the other bug is the concept I attempted to address with this bug.
Comment 6 Rainer Bielefeld Retired 2011-10-20 23:38:22 UTC
@Kevin:
You are right, i did a wrong interpretation of the original report in Bug 34725. So this one is a DUP of my misinterpretation, but not of reporter's intention. Thank you for your attention.

I will check what activities already have been started for Bug 34725 and then divide these different issues "somehow".
Comment 7 Kevin Hunter 2011-12-24 13:07:40 UTC
Having just reread Bug 36646, here's a gentle reminder that the latest thought process I understood was that this bug was to reopened.  Has this changed behind the scenes?
Comment 8 Kevin Hunter 2011-12-24 13:09:28 UTC
I apologize, copy&paste error.  That should be "Having just reread through Bug 34725, ..."
Comment 9 Rainer Bielefeld Retired 2012-01-20 07:43:49 UTC
Reopened becauseProblem still exists for CALC "LibreOffice 3.5.0 RC1 German UI/Locale [Build-ID: b6c8ba5-8c0b455-0b5e650-d7f0dd3-b100c87] on German WIN7 Home Premium (64bit) and is different from Bug 34725.

Problem is not limited to CALC, also DRAW / Impress / Writer are affected

@Ivan:
Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Comment 10 Rainer Bielefeld Retired 2012-01-26 21:33:40 UTC
@Ivan:
I forgot to assign
Comment 11 Ivan Timofeev (retired) 2012-01-26 23:55:33 UTC
Created attachment 56215 [details]
Mockup: the picker as a submenu

Oooh... Do we want to see pickers as submenus? %-)
Comment 12 Stefan Knorr (astron) 2012-02-06 02:28:35 UTC
@Ivan: Not exactly, what we probably want is a "split" menu entry, so you can
* click the toolbar icon or
* go to the submenu to choose a different colour

For an example, see Firefox's new menu:
#1 right-click somewhere in the FF toolbar and disable "Menu bar"
#2 click on the Firefox menu
#3 Observe behaviour of "New Tab", "Print" or "Preferences" item
Comment 13 Rainer Bielefeld Retired 2012-02-06 02:41:36 UTC
@Ivan:
Your mockup is completely correct, here we have to solve the problem that the picker currently does not appear. 

I can't tell whether it's related to the fix you plan, but we will have to modify picker behavior for "Bug 35042 - [EasyHack] previous color applied instead of latest "no fill" for "highlighting"", I believe your fix will be independent to fix for Bug 35042.

@Astron:
Please do not violate the workflow by talking about completely different problems! Your Comment 12 has nothing to do with the problem reported here.
Comment 14 Stefan Knorr (astron) 2012-02-06 03:07:10 UTC
FTR, I believe my comment has something to do with this bug. Of course, in this case, Ivan's mock-up is correct (at least currently).
Anyway, we need both behaviours, for different toolbar buttons.
Sorry for any confusion caused.
Comment 15 Ivan Timofeev (retired) 2012-02-17 08:38:35 UTC
The idea of a splitted menu entry requires cross platform hacking and testing, Ivan can't do that. :( The idea of making picker a submenu sounds scary wrt hacking, too. I'll try to find a way to implement it...

(In reply to comment #14)
> FTR, I believe my comment has something to do with this bug.

Yes, of course! :)
Comment 16 sasha.libreoffice 2012-04-13 23:19:14 UTC
*** Bug 41895 has been marked as a duplicate of this bug. ***
Comment 17 sasha.libreoffice 2012-04-13 23:19:32 UTC
*** Bug 36440 has been marked as a duplicate of this bug. ***
Comment 18 Rainer Bielefeld Retired 2012-07-01 13:28:50 UTC
*** Bug 51612 has been marked as a duplicate of this bug. ***
Comment 19 Ivan Timofeev (retired) 2012-08-11 06:28:56 UTC
*** Bug 50143 has been marked as a duplicate of this bug. ***
Comment 20 Ivan Timofeev (retired) 2013-12-15 16:56:12 UTC
Reset Assignee to default, because I don't contribute to LibreOffice anymore.
Comment 21 Maxim Monastirsky 2014-05-15 13:41:37 UTC
*** Bug 44111 has been marked as a duplicate of this bug. ***
Comment 22 Maxim Monastirsky 2014-05-15 13:45:07 UTC
This is an enhancement request, marking as such.
Comment 23 V字龍(Vdragon) 2014-05-15 13:50:22 UTC
@Maxim
As far as I can see this issue is a bug for all small screen resolution users than an 'enhancement'.
Comment 24 Maxim Monastirsky 2014-05-15 14:45:28 UTC
*** Bug 68466 has been marked as a duplicate of this bug. ***
Comment 25 Maxim Monastirsky 2014-05-15 14:51:11 UTC
(In reply to comment #23)
> @Maxim
> As far as I can see this issue is a bug for all small screen resolution
> users than an 'enhancement'.

Hi Henry,

enhancement = Feature that still not implemented (even if it's annoying without it).
bug = Feature that implemented once, but got broken at some point.

Those are the rules in this bug tracker.
Comment 26 Maxim Monastirsky 2014-08-06 06:28:10 UTC
*** Bug 79768 has been marked as a duplicate of this bug. ***
Comment 27 Maxim Monastirsky 2014-09-04 19:38:16 UTC
*** Bug 51826 has been marked as a duplicate of this bug. ***
Comment 28 Adolfo Jayme 2015-01-07 09:02:24 UTC
*** Bug 88078 has been marked as a duplicate of this bug. ***
Comment 29 Jim Avera 2015-01-10 20:24:01 UTC
Hi, Just wondering if Ivan or someone else still has 
this bug^H^H^Henhancement still on their radar.   It sounded like some work was started a couple of years ago.
Comment 30 Adolfo Jayme 2015-10-05 14:46:59 UTC
*** Bug 94754 has been marked as a duplicate of this bug. ***
Comment 31 Yan Pas 2016-01-11 12:08:14 UTC
Created attachment 121858 [details]
googledocs mockup

This is how it is made in google docs, "More" button spawns subpanel with buttons
Comment 32 Yousuf Philips (jay) (retired) 2016-01-19 09:11:09 UTC
In reply to Yan Pashkovsky from comment #31)
> Created attachment 121858 [details]
> googledocs mockup
> 
> This is how it is made in google docs, "More" button spawns subpanel with
> buttons

Interesting approach to have a new toolbar popup that is filled with all the missing buttons.
Comment 33 Yousuf Philips (jay) (retired) 2016-08-09 13:49:34 UTC
*** Bug 101278 has been marked as a duplicate of this bug. ***
Comment 34 Xisco Faulí 2016-09-08 14:34:01 UTC Comment hidden (obsolete)
Comment 35 V Stuart Foote 2016-09-08 15:42:05 UTC
(In reply to Yousuf Philips (jay) from comment #32)

> Interesting approach to have a new toolbar popup that is filled with all the
> missing buttons.

Yes doing the horizontal list/toolbar popup rather than the vertical menu might allow dialogs/pop-outs to function normally. Not sure how involved a change of the "plumbing" for the toolbar -> overflow to menu list becomes. But seems it would be a better UI.

Visually we'd of course want to drop the labeling that now shows on the menu for the button widgets if organized into a horizontal list/toolbar popup.
Comment 36 Yousuf Philips (jay) (retired) 2016-09-08 16:10:29 UTC
Created attachment 127221 [details]
qbittorrent wtith chevron closed and opened

So i recently saw a similar UI implemented with qbittorrent and we recently implemented a not enough space popup feature in the notebookbar.
Comment 37 Maxim Monastirsky 2016-10-31 13:10:26 UTC
*** Bug 103549 has been marked as a duplicate of this bug. ***
Comment 38 Emersson Augusto Suarez Ortiz 2017-01-05 15:42:43 UTC
*** Bug 105104 has been marked as a duplicate of this bug. ***
Comment 39 Maxim Monastirsky 2017-01-18 20:08:14 UTC
*** Bug 105425 has been marked as a duplicate of this bug. ***
Comment 40 V Stuart Foote 2017-02-13 01:27:09 UTC
Maxim has posted https://gerrit.libreoffice.org/#/c/34180/ with commit

https://cgit.freedesktop.org/libreoffice/core/commit/?id=81d4fbc0daa54889ccb09e6a3fadff9c70d99448

Will be available on daily TB build of master/5.4.0alpha0+, testing and feed back would be appreciated.
Comment 41 V Stuart Foote 2017-02-13 04:40:02 UTC
Present in the Windows TB42 build for 2017-02-13
Version: 5.4.0.0.alpha0+
Build ID: 1d810b69a584fc33f4178c7012f68f551ba2e03b
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2017-02-12_23:34:02
Locale: en-US (en_US); Calc: CL

Thanks Maxim!

On this build for master the floating panes showing the controls truncated from collapsed toolbars are functional--labeling/tooltips are active and the pane resizes as needed to hold the full toolbar.

Resolves a noteworthy annoyance. Assuming there are no structural issues with toolbars (5.3 -> master), maybe a good candidate for backport to 5.3?
Comment 42 Jim Avera 2017-02-14 10:07:11 UTC
Very nice!   

It looks like the icons & drop-down arrows in the overflow thing are somewhat miniaturized, which makes them less comfortable on the eyes for oldsters like me.  

But that's a nit; this is a really big UI improvement.  Thank you thank you.
Comment 43 Yousuf Philips (jay) (retired) 2017-02-16 12:09:52 UTC
Created attachment 131271 [details]
how it looks

Functions fine, but it wraps across multiple rows, which doesnt look good. I think the separator is causing it to move the items to the next row. It would be good if the right side of the popup was aligned with the chevron and the items were being added leftwards, so they dont go outside of the window area.
Comment 44 Maxim Monastirsky 2017-02-16 13:41:55 UTC
(In reply to V Stuart Foote from comment #41)
> maybe a good candidate for backport to 5.3?
I don't think so, as this is still WIP, and there are still some issues. Also it's a new feature, and we usually don't backport new features to stable branches (except if approved by ESC - but again I don't think it should go, at least not now).

(In reply to Jim Avera from comment #42)
> It looks like the icons & drop-down arrows in the overflow thing are
> somewhat miniaturized, which makes them less comfortable on the eyes for
> oldsters like me.  
Hmm they should be of the same size as on the toolbar. Can you post a screenshot of what you get (better in a new bug, as this one is too long already)?

(In reply to Yousuf Philips (jay) from comment #43)
> but it wraps across multiple rows, which doesnt look good. I
> think the separator is causing it to move the items to the next row.
Indeed, the algorithm tries to put different button groups on different rows whenever possible. But even without separators it will have a quadratic layout. That's the same algorithm that we use for sub-toolbars split buttons (e.g. basic shapes).

> It would be good if the right side of the popup was aligned with the chevron
> and the items were being added leftwards, so they dont go outside of the
> window area.
That's also reuses the same positioning code as other toolbar dropdowns, nothing special. Actually I tried at first to make it work the way you describe (left aligned + one row), but couldn't make it work reliably. So decided to go with the current approach for now (better than nothing), until I find how to solve the issues I had with it.

Anyway, as the direction taken here seems good in general, I'm going to close this bug as RESOLVED FIXED, and it will be good to have the remaining issues reported as separate bugs (with me CCed there).
Comment 45 Maxim Monastirsky 2017-02-16 16:20:40 UTC
Created attachment 131280 [details]
ignore separators

(In reply to Yousuf Philips (jay) from comment #43)
> but it wraps across multiple rows, which doesnt look good. I
> think the separator is causing it to move the items to the next row.
Will simply ignoring the separators (like in the screenshot) be sufficient (or at least an improvement)?
Comment 46 Heiko Tietze 2017-02-16 19:50:37 UTC
(In reply to Yousuf Philips (jay) from comment #43)
> It would be good if the right side of the popup was aligned with the chevron
> and the items were being added leftwards, so they dont go outside of the
> window area.

Depending on the space to the right side it works like this. This, as well as placing the toolbar at the bottom and having the chevron thing extend upwards, both work perfectly. Multi-row is uncommon but maybe even better than single rows that have a less concise layout with icons wrapped and extended down to the screen bottom.

Really minor nitpick: there is a gap in the surrounding frame likely coming from the cursor. On bright themes like at Jays screenshot it's hard to discover but when you have a dark background with a frame around forms in light gray as in Breeze Dark it's becomes noticeable. Not enough to file another bug report, or actually I'm too lazy ;-).
Comment 47 Yousuf Philips (jay) (retired) 2017-04-25 07:12:41 UTC
(In reply to Maxim Monastirsky from comment #45)
> Will simply ignoring the separators (like in the screenshot) be sufficient
> (or at least an improvement)?

I would keep the separator, so atleast the buttons that are grouped together appear on a single line. Sorry for the delayed reply, must have missed the email. :D

(In reply to Heiko Tietze from comment #46)
> Really minor nitpick: there is a gap in the surrounding frame likely coming
> from the cursor. On bright themes like at Jays screenshot it's hard to
> discover but when you have a dark background with a frame around forms in
> light gray as in Breeze Dark it's becomes noticeable. Not enough to file
> another bug report, or actually I'm too lazy ;-).

Screenshot please. :D