Bug 86138 - TOOLBAR: Context menu should state the name of the toolbar
Summary: TOOLBAR: Context menu should state the name of the toolbar
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium enhancement
Assignee: Philippe Jung
QA Contact:
URL:
Whiteboard: target:5.0.0
Keywords:
Depends on:
Blocks: Calc-Toolbars Context-Menu
  Show dependency treegraph
 
Reported: 2014-11-11 03:57 UTC by Yousuf Philips (jay)
Modified: 2015-05-22 14:46 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of new menu appearance (50.22 KB, image/png)
2015-05-12 11:38 UTC, Philippe Jung
Details
Updated screenshot (30.20 KB, image/png)
2015-05-13 14:31 UTC, Philippe Jung
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) 2014-11-11 03:57:46 UTC
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.
Comment 1 Cor Nouws 2014-11-11 09:01:37 UTC
very good :)
Comment 2 Philippe Jung 2015-05-12 11:38:42 UTC
Created attachment 115521 [details]
Screenshot of new menu appearance
Comment 3 Yousuf Philips (jay) 2015-05-12 15:50:21 UTC
(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?
Comment 4 Adolfo Jayme 2015-05-12 16:23:36 UTC
I prefer Philippe’s solution since it won’t make menus even wider, which is a huge issue in other languages.
Comment 5 Cor Nouws 2015-05-12 18:51:05 UTC
(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> ..
Comment 6 Philippe Jung 2015-05-12 18:56:29 UTC
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".
Comment 7 Philippe Jung 2015-05-13 14:31:34 UTC
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.
Comment 8 Commit Notification 2015-05-14 17:18:53 UTC
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.
Comment 9 Yousuf Philips (jay) 2015-05-15 21:48:50 UTC
Looks great Philippe.
Comment 10 Mike §chinagl 2015-05-21 16:21:19 UTC
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)
Comment 11 Adolfo Jayme 2015-05-21 21:41:03 UTC
Disregard the previous comment. That user has been spamming everyone with that comment, apologies.
Comment 12 Cor Nouws 2015-05-22 07:29:42 UTC
(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..
Comment 13 Mike §chinagl 2015-05-22 13:51:42 UTC
(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.
Comment 14 Julien Nabet 2015-05-22 14:33:24 UTC
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
Comment 15 Cor Nouws 2015-05-22 14:46:04 UTC
(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.