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.
Created attachment 52566 [details] SmallerWindow
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
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 ***
@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.
@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.
@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".
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?
I apologize, copy&paste error. That should be "Having just reread through Bug 34725, ..."
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.
@Ivan: I forgot to assign
Created attachment 56215 [details] Mockup: the picker as a submenu Oooh... Do we want to see pickers as submenus? %-)
@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
@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.
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.
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! :)
*** Bug 41895 has been marked as a duplicate of this bug. ***
*** Bug 36440 has been marked as a duplicate of this bug. ***
*** Bug 51612 has been marked as a duplicate of this bug. ***
*** Bug 50143 has been marked as a duplicate of this bug. ***
Reset Assignee to default, because I don't contribute to LibreOffice anymore.
*** Bug 44111 has been marked as a duplicate of this bug. ***
This is an enhancement request, marking as such.
@Maxim As far as I can see this issue is a bug for all small screen resolution users than an 'enhancement'.
*** Bug 68466 has been marked as a duplicate of this bug. ***
(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.
*** Bug 79768 has been marked as a duplicate of this bug. ***
*** Bug 51826 has been marked as a duplicate of this bug. ***
*** Bug 88078 has been marked as a duplicate of this bug. ***
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.
*** Bug 94754 has been marked as a duplicate of this bug. ***
Created attachment 121858 [details] googledocs mockup This is how it is made in google docs, "More" button spawns subpanel with buttons
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.
*** Bug 101278 has been marked as a duplicate of this bug. ***
Removing comma from Whiteboard (please use a space to delimit values in this field) https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Whiteboard#Getting_Started
(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.
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.
*** Bug 103549 has been marked as a duplicate of this bug. ***
*** Bug 105104 has been marked as a duplicate of this bug. ***
*** Bug 105425 has been marked as a duplicate of this bug. ***
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.
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?
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.
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.
(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).
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)?
(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 ;-).
(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