When you right-click on a toolbar there isnt any indication of what the name of the toolbar is. This could easily be fixed by having the name of the toolbar mentioned in the 'Close Toolbar' item.
very good :)
Created attachment 115521 [details] Screenshot of new menu appearance
(In reply to Philippe Jung from comment #2) > Created attachment 115521 [details] > Screenshot of new menu appearance I was thinking that instead of adding another entry to the context menu, we could add the toolbar name to one of the existing entries. For example, we can change 'Close Toolbar' to 'Close Standard Toolbar'. What does the ux team think?
I prefer Philippe’s solution since it won’t make menus even wider, which is a huge issue in other languages.
(In reply to Adolfo Jayme from comment #4) > I prefer Philippe’s solution since it won’t make menus even wider, which is > a huge issue in other languages. Are you sure? Philippe's solution implies "close <NAME> toolbar" which is definitely wider then "<NAME> ..
I think he prefers the solution from the screenshot :-) We have: - Title (bold, top of menu, coherent with left to right, top to bottom reader), read-only, defined as a menu title. or - Modified label of close. Simple solution, few modifications. What I asked to Jay is what is the use case we want to face by adding toolbar name to contextual menu. This is what should drive the choice. What I understood, it is to avoid closing the wrong toolbar. So the information has to be visible, simply and quickly. But it also has to be geographically close to the "Close action".
Created attachment 115562 [details] Updated screenshot Patchset 3 pushed to gerrit. This is the new appearance of the popup. I reused an existing aTitleText defined with Menu::SetText The title is painted on top of the menu. It is no longer a hacked MenuItem. It is bold, centered on a slightly darker background.
Philippe Jung committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=415454cfbc6add8534e1dcff1ff16cc8dcc9296c tdf#86138 Context menu should state the name of the toolbar It will be available in 5.0.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.
Looks great Philippe.
This bug fix is mentioned in the release notes of the coming LibreOffice 5.0 (see release notes https://wiki.documentfoundation.org/ReleaseNotes/5.0). Therefore it would be wonderful if this feature really worked well, otherwise it should not be mentioned in the release notes. In the notes it reads: Toolbar’s context menus display the name of the corresponding toolbar. tdf#86138 (Philippe Jung)
Disregard the previous comment. That user has been spamming everyone with that comment, apologies.
(In reply to Adolfo Jayme from comment #11) > Disregard the previous comment. That user has been spamming everyone with > that comment, apologies. Hmm.. We've seen examples in the past that features were listed but not ready or OK, so a reminder to check is not that strange..
(In reply to Adolfo Jayme from comment #11) > Disregard the previous comment. That user has been spamming everyone with > that comment, apologies. Some reaction to my reminder to please do an up-to-date-check on the status of bugs if mentioned in release notes in my view was not adequate and unfriendly. If unfixed bugs are mentioned this gives a bad impression and this sometimes was the case on previous releases. Journalists will read the release notes carefully and might check on the "fixed" bugs. If these then are not really fixed, this understandably may lead to avoidable negative reports. My activity, also before previous releases, initiated that some bugs were reopened or had their status reconsidered. Examples: https://bugs.documentfoundation.org/show_bug.cgi?id=47302#c9 https://bugs.documentfoundation.org/show_bug.cgi?id=84504#c21 https://bugs.documentfoundation.org/show_bug.cgi?id=45618#c16 https://bugs.documentfoundation.org/show_bug.cgi?id=87972#c13 https://bugs.documentfoundation.org/show_bug.cgi?id=82309#c19 https://bugs.documentfoundation.org/show_bug.cgi?id=80538#c34 https://bugs.documentfoundation.org/show_bug.cgi?id=85594#c36 https://bugs.documentfoundation.org/show_bug.cgi?id=83808#c12 https://bugs.documentfoundation.org/show_bug.cgi?id=80538#c34 https://bugs.documentfoundation.org/show_bug.cgi?id=85804#c24 https://bugs.documentfoundation.org/show_bug.cgi?id=63905#c16 Unfortunately not always were the release notes then changed accordingly before the release or the bug status was changed to fixed https://bugs.documentfoundation.org/show_bug.cgi?id=81475#c48 https://bugs.documentfoundation.org/show_bug.cgi?id=62437#c9 https://bugs.documentfoundation.org/show_bug.cgi?id=83308#c6 In some cases one might still have to consider taking the mentioning of that bug off the list in the release notes, i.e.: https://bugs.documentfoundation.org/show_bug.cgi?id=87342#c4 (that is my understanding, https://wiki.documentfoundation.org/ReleaseNotes/4.4#Toolbar_improvements) If the way I reported can be improved, or if we can find another/better way, I would be happy.
Mike: I understood you wanted to avoid that some bugs indicated in release notes might be indeed not fixed. But what you did is: - retrieve each bug indicated fixed in 5.0 - let a comment on each of these bugs indicating it's not fixed without even giving a try to them So what you're doing is just fud and it's quite annoying. So PLEASE STOP SPAMMING unless you indeed reproduce a bug indicated as fixed
(In reply to Julien Nabet from comment #14) > - retrieve each bug indicated fixed in 5.0 From what I understood, it is about stuff that is marked as newly implemented, or is listed as such.