Bug Hunting Session
Bug 101193 - Return object Name and Description dialog buttons to object context menus
Summary: Return object Name and Description dialog buttons to object context menus
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.1.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL: https://ask.libreoffice.org/en/questi...
Whiteboard:
Keywords: accessibility
: 96405 116289 (view as bug list)
Depends on: Object-Properties-Dialog
Blocks: Context-Menu a11y
  Show dependency treegraph
 
Reported: 2016-07-29 13:26 UTC by horus
Modified: 2019-07-16 14:24 UTC (History)
16 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description horus 2016-07-29 13:26:34 UTC
I come from OpenOffice and found (thanks to Ask) that Image description has been moved!

First, it's removed from an image's context menu!

Second, it's put in to Format (menu) > Description.  But that's illogical!  Description has *nothing* to do with *format*!

Can't you put it back on context menu and remove it from "Format" menu?
Comment 1 Peter Roelofsen 2016-07-29 14:00:41 UTC
Confirmed for the Windows version of 5.1.4.2. For pictures inserted in a master document, Description hides in Format - Object - Description. Please move it back to the pop-up menu that comes with right-clicking the image.
Comment 2 horus 2016-07-30 06:02:27 UTC
To be fair, I just found that Format (menu) > Description actually came from old version of OpenOffice, so it's nothing new in LibreOffice. It's just that I never looked in that place :D

So, please make "Description" reappear in context menu.
Comment 3 V Stuart Foote 2016-07-30 21:49:37 UTC
This was by design--context menus were simplified in general.

Adding Title and/or Description for assistive technology is a formatting action for each object.

If one prefers to have it the  Description dialog available via the context menu--simply add it, the context menus are now fully customizable as toolbars.

1. Tools -> Customize -> Context Menus
2. On the Menu dropdown list select "Image"
3. Click the Add button
4. From the Format category select Description
5. Click the Add button
6. The Description action will be added to the Image context menu
7. drag the action to position it to desired location on the context menu
Comment 4 V Stuart Foote 2016-07-30 22:31:26 UTC
(In reply to V Stuart Foote from comment #3)
Sorry, this comes in with the 5.2 release. Through 5.1 the UI is not yet present to customize the context menus.
Comment 5 Peter Roelofsen 2016-07-31 08:08:08 UTC
(In reply to V Stuart Foote from comment #3)
> This was by design--context menus were simplified in general.
> 
> Adding Title and/or Description for assistive technology is a formatting
> action for each object.
> 
> If one prefers to have it the  Description dialog available via the context
> menu--simply add it, the context menus are now fully customizable as
> toolbars.
> 
> 1. Tools -> Customize -> Context Menus
> 2. On the Menu dropdown list select "Image"
> 3. Click the Add button
> 4. From the Format category select Description
> 5. Click the Add button
> 6. The Description action will be added to the Image context menu
> 7. drag the action to position it to desired location on the context menu

I don't see a Context menus tab there in 5.1.4.2 for Windows, am I missing something there?
Comment 6 horus 2016-08-01 08:42:29 UTC
(In reply to V Stuart Foote from comment #3)
> 
> Adding Title and/or Description for assistive technology is a formatting
> action for each object.

I don't agree.  Title & description are content/attribute, not format.  You could make a poll and I'm pretty sure over 90% of people would not consider title & description as a format.
Comment 7 Regina Henschel 2016-08-01 11:41:30 UTC
It is not normative, but in appendix D of the ODF specification you can read:
<quote>
D.1.2.Authoring tool responsibility for presenting and prompting for the <svg:title> and <svg:desc> elements 

Authoring tools should provide an option from an objects context menu to allow the user to enter the text for either of these elements as a minimum. More proactive authoring tools should have a facility for prompting the author for this text. Since the <svg:desc> element is a long description, a text area vs. a text field should be used to prompt the user accordingly in GUI-based authoring tools like office applications.
</quote>

Notice the part "from an objects context menu".

As the context menu cannot be configured in LO5.1, removing these two items should be reverted in the 5.1 branch.

"Invalid" is not the correct Status. There will be one bug fix release before 'end of life' in the 5.1 branch in November. So a change would be possible.
Comment 8 V Stuart Foote 2016-08-01 15:04:39 UTC
Per our HIG--all controls should be provided via menu actions.

Through 5.2 the Menu rework has the Description object dialog for "Description & Title" and the Name object dialog for "Name" positioned:

for Writer on the Format menu,
for Impress on the Format menu,
for Draw on the Modify menu, and
for Calc it is not provided on menu, either Format or Format -> Object. 

For Calc it remains only on the Context menu for the object (where the control had been for the other modules (except Draw's Modify menu). Handling in Calc will need to be corrected.

And except for Calc, the context menu entry for both has been removed. Otherwise from 5.2 the addition of context menu customization allows user to add it Image or Object.

So more work needed to handle some of the UI inconsistencies of these dialogs.

Only question here becomes should the Name and Description actions be present on context menu by default.

Aside from preparing tagged content for a11y use, given our desire to improve Navigator function--facilitating Name, Title and Description for each object by providing context menu access seems desirable in the general case.

Not sure there is any advantage to adding context menu entries back for a 5.1.6 release--but it should be benign if done this late in the branch.

@Maxim, Adolfo?
Comment 9 Yousuf Philips (jay) (retired) 2016-08-01 19:33:47 UTC
(In reply to horus from comment #0)
> Second, it's put in to Format (menu) > Description.  But that's illogical! 
> Description has *nothing* to do with *format*!

Name, title and description are attributes/properties of the image and the format menu focusing on altering those properties.

> Can't you put it back on context menu and remove it from "Format" menu?

Unfortunately it wouldnt be included back in the context menu as we are keeping the context menus short. Name is available through the context menu with the image properties entry on the options tab. It would be useful for title and description to also be in the dialog.

(In reply to horus from comment #2)
> To be fair, I just found that Format (menu) > Description actually came from
> old version of OpenOffice, so it's nothing new in LibreOffice. It's just
> that I never looked in that place :D

You are incorrect as openoffice had and still has it in Format > Object > Description and it was moved to Format > Description in libreoffice 5.1.

(In reply to Regina Henschel from comment #7)
> As the context menu cannot be configured in LO5.1, removing these two items
> should be reverted in the 5.1 branch.

Cant say i'd agree as the image context menu already has 15 entries in it.

(In reply to V Stuart Foote from comment #8)
> for Writer on the Format menu,
> for Impress on the Format menu,
> for Draw on the Modify menu, and

Draw's menus have been modified during the rework.

> for Calc it is not provided on menu, either Format or Format -> Object. 

Yes that was an oversight because it was never in the menus before the rework.

> For Calc it remains only on the Context menu for the object (where the
> control had been for the other modules (except Draw's Modify menu). Handling
> in Calc will need to be corrected.

Yes most of the context menu alterations happened in writer and impress/draw, so calc hasnt had the clean up as yet.

> Only question here becomes should the Name and Description actions be
> present on context menu by default.

No they shouldnt, which is why it was removed them.

> Aside from preparing tagged content for a11y use, given our desire to
> improve Navigator function--facilitating Name, Title and Description for
> each object by providing context menu access seems desirable in the general
> case.

Users shouldnt need to open up 2 different dialogs to modify name, title and description, so it is better to consolidate all of these in the image properties dialog.
Comment 10 V Stuart Foote 2016-08-01 21:58:28 UTC
@Jay, *

(In reply to Yousuf (Jay) Philips from comment #9)
> > Only question here becomes should the Name and Description actions be
> > present on context menu by default.
> 
> No they shouldnt, which is why it was removed them.
> 
> > Aside from preparing tagged content for a11y use, given our desire to
> > improve Navigator function--facilitating Name, Title and Description for
> > each object by providing context menu access seems desirable in the general
> > case.
> 
> Users shouldnt need to open up 2 different dialogs to modify name, title and
> description, so it is better to consolidate all of these in the image
> properties dialog.

The need to Name, or to provide a Description (Title--for Alternative text--and a Description) is a requirement not just for Images, but for all objects. It is a UI issue as the Name/Title controls their behavior on Navigator.

And from a UX perspective the time to set an attribute is while the object is being created or placed. Frankly that is most efficient from the context menu. Removing them was fine--having added ability to customize context menus (as we've been doing for toolbars forever) allows us to pick and choose reasonable defaults, and then for users to adjust as they prefer.

I do agree that adding the attributes to the properties dialog for each object would be helpful. In addition to the Name field that is is there already.

Yes, behavior of the Name dialog and Description dialogs launched from menus--or from context menus--needs to be handled in a more consistent interface across modules.
Comment 11 Heiko Tietze 2016-08-01 22:20:01 UTC
How about a properties dialog for images that allows to enter name, description, caption (if available), and positon & size? I would also include the line properties and image options (brightness, contrast etc.).
Otherwise consistency first so both belong to the format menu.

(In reply to Regina Henschel from comment #7)
> Authoring tools should provide an option from an objects context menu...

Surprising how demanding the specs are sometimes. This paragraph should be changed as the tool is responsible how functions are presented. Without a use case, scenario, workflow, or any reason, this statement makes no sense.
Comment 12 Cor Nouws 2016-10-18 14:57:42 UTC
(In reply to Heiko Tietze from comment #11)

> Surprising how demanding the specs are sometimes. This paragraph should be
> changed as the tool is responsible how functions are presented. Without a
> use case, scenario, workflow, or any reason, this statement makes no sense.

Maybe someone can give some insight on the reasons for this detailed demand in the specs? From contact with someone in accessibility, looking for those attributes, I wouldn't be surprised if it comes from that expertise.
Comment 13 Cor Nouws 2016-10-18 18:48:39 UTC
(In reply to Cor Nouws from comment #12)

> Maybe someone can give some insight on the reasons for this detailed demand
> in the specs? From contact with someone in accessibility, looking for those
> attributes, I wouldn't be surprised if it comes from that expertise.

Looks so. Accidentally coming across https://bugs.documentfoundation.org/show_bug.cgi?id=81132#c5

(Michael Meeks in comment #5)
> So - a point of fact here; the context menu is often exposed for a11y
> reasons to the Accessibility Technology, and removing things can have an
> impact. Having said that having smaller context menus is also a worthy goal.
> Ultimately this is one for the UX team I think - personally I love Jay's
> data-driven approach.
Comment 14 Yousuf Philips (jay) (retired) 2017-05-03 11:58:41 UTC
Closing this as there isnt a need to keep it open, but just to clarify, what is needed is the description field be added to the images dialog in writer (bug 107589) and the creation of an all-in-one object properties dialog (bug 96355) that has fields for name, title and description. This will give easy context menu access to these fields.
Comment 15 Cor Nouws 2017-05-03 12:24:15 UTC
(In reply to Yousuf Philips (jay) from comment #14)

> ... and the creation of an all-in-one object properties dialog (bug
> 96355) that has fields for name, title and description. This will give easy
> context menu access to these fields.

I especially like this idea.
However, waiting for that to be done, sometime somehow, one could argue that for time being an easy user friendly improvement is to restore the context menu.
Let me be the one to argue so.
Comment 16 Cor Nouws 2017-05-03 12:24:29 UTC Comment hidden (obsolete)
Comment 17 Yousuf Philips (jay) (retired) 2017-05-24 04:24:17 UTC
(In reply to Yousuf Philips (jay) from comment #9)
> Draw's menus have been modified during the rework.

Correction: Draw's menus have not been modified during the rework.

> Yes that was an oversight because it was never in the menus before the
> rework.

Fixed in this patch - http://cgit.freedesktop.org/libreoffice/core/commit/?id=606894486d7eb85d9748675ef4ef5bda12846753
Comment 18 V Stuart Foote 2018-03-12 20:21:01 UTC
*** Bug 116289 has been marked as a duplicate of this bug. ***
Comment 19 V Stuart Foote 2018-03-12 20:21:41 UTC
*** Bug 96405 has been marked as a duplicate of this bug. ***
Comment 20 andreas_k 2018-09-07 22:58:30 UTC
Hi I need feedback for Name and Description items in Context menu.

Name Description in writer context menu
- graphic not available
- draw available
- media available
- oleobject available
- form available


From my point of view Name and Descriptions should be available for all the objects or for none.

Description
- graphic, draw, media, oleobject, form for ALL apps available

Name
- graphic, draw, media, oleobject, form for Draw available
- form for ALL apps available
other area Name isn't needed cause it's only needed to separate stuff in the navigator.

Did I miss something
Comment 21 Heiko Tietze 2018-09-16 15:53:37 UTC
(In reply to andreas_k from comment #20)
> Did I miss something

Maxim, something that comes in your mind?
Comment 22 V Stuart Foote 2018-09-16 20:38:15 UTC
(In reply to andreas_k from comment #20)
> Did I miss something

Yes, this is the point of bug 96355--we need a unified handling of a properties dialog for all objects to add back to context menus.
Comment 23 Cor Nouws 2018-09-16 20:53:22 UTC
(In reply to V Stuart Foote from comment #22)
> (In reply to andreas_k from comment #20)
> > Did I miss something
> 
> Yes, this is the point of bug 96355--we need a unified handling of a
> properties dialog for all objects to add back to context menus.

Is that so? I thought we could add to context menu what we have. And improve later.
Don't let the better be the enemy of the good :)
Comment 24 andreas_k 2018-09-16 20:59:52 UTC
All I want to know is should
 a. Name
 b. Description
be added to 
 1. graphic
 2. draw
 3. media
 4. oleobject
 5. form
to the following apps
 I.   writer
 II.  calc
 III. draw
 IV.  impress

cause I can't finish the context menu patches without this feetback. I don't care about yes or no. I need your feedback and which option the most +1 get will go to master.

fyi in 6.1 writer name and description are available in
 3. media
 5. form
Comment 25 V Stuart Foote 2018-09-16 21:21:22 UTC
(In reply to Cor Nouws from comment #23)
> 
> Is that so? I thought we could add to context menu what we have. And improve
> later.
> Don't let the better be the enemy of the good :)

Guess that remains your position as in comment 15--but as noted we provide ability to customize the context menu to add the controls--none the less the place to correctly fix this is exposing a properties dialog common to all objects.


(In reply to andreas_k from comment #24)
> cause I can't finish the context menu patches without this feetback. I don't
> care about yes or no. I need your feedback and which option the most +1 get
> will go to master.
> 

None! forget doing the context menu piecemeal. Resolve the properties dialog and add that to the context menu in a consistent fashion.

> fyi in 6.1 writer name and description are available in
>  3. media
>  5. form

And should be removed
Comment 26 Cor Nouws 2018-09-17 09:14:09 UTC
(In reply to V Stuart Foote from comment #25)

> Guess that remains your position as in comment 15--but as noted we provide
> ability to customize the context menu to add the controls--none the less the
> place to correctly fix this is exposing a properties dialog common to all
> objects.

Of course. How long will that take? Anyone working on it?
Simply adding the imperfect solution for now, will help users very soon?
Comment 27 Heiko Tietze 2018-09-17 09:27:29 UTC
(In reply to V Stuart Foote from comment #22)
> (In reply to andreas_k from comment #20)
> > Did I miss something
> 
> Yes, this is the point of bug 96355--we need a unified handling of a
> properties dialog for all objects to add back to context menus.

Aren't you talking about the whole context menu? The question here is just whether or not to have Name and Description in it (+1 from my side) and if Andreas has forgotten something (no idea).
Comment 28 andreas_k 2018-09-20 08:25:21 UTC
> None! forget doing the context menu piecemeal. Resolve the properties dialog
> and add that to the context menu in a consistent fashion.

I don't do the context menu piecemeal. I have an overall concept see BUG 119398. I can't resolve the properties dialog cause I'm not a developer. Name and Description are available in the menubar if needed. If there is an bug that name and description is needed in the context menu (as long as the properties dialog isn't finished) I can add them. All I want is an go left or right.
Comment 29 Cor Nouws 2018-09-20 08:29:33 UTC
(In reply to Heiko Tietze from comment #27)

> Aren't you talking about the whole context menu? The question here is just
> whether or not to have Name and Description in it (+1 from my side) and if
> Andreas has forgotten something (no idea).

+1 from me too, Andreas,
Comment 30 Thomas Lendo 2018-09-20 08:44:41 UTC
(In reply to Cor Nouws from comment #29)
> (In reply to Heiko Tietze from comment #27)
> > Aren't you talking about the whole context menu? The question here is just
> > whether or not to have Name and Description in it (+1 from my side) and if
> > Andreas has forgotten something (no idea).
> +1 from me too, Andreas
+1 from me to have it in all context menus.
A unified name/description dialog is highly appreciated but we shouldn't wait until thats implemented.
Comment 31 V Stuart Foote 2018-09-20 13:12:57 UTC
(In reply to Heiko Tietze from comment #27)
> (In reply to V Stuart Foote from comment #22)
> > (In reply to andreas_k from comment #20)
> > > Did I miss something
> > 
> > Yes, this is the point of bug 96355--we need a unified handling of a
> > properties dialog for all objects to add back to context menus.
> 
> Aren't you talking about the whole context menu? The question here is just
> whether or not to have Name and Description in it (+1 from my side) and if
> Andreas has forgotten something (no idea).

Guess I'm "tilting at windmills" ;-)

+1 do it now, with understanding that *when* bug 96355 unified object dialog is implemented--the individual context menu entries will be removed (or hidden).
Comment 32 andreas_k 2019-01-28 22:56:29 UTC
context menues get an update in 6.2 to close this bug as WFM. is it ok?
Comment 33 Heiko Tietze 2019-01-29 10:00:26 UTC
(In reply to andreas_k from comment #32)
> context menues get an update in 6.2 to close this bug as WFM. is it ok?

We definitely do not list Name and I don't know if Description has made it into the menu. So closing this ticket is not just FIXED.
Comment 34 Thomas Lendo 2019-01-29 19:04:13 UTC
(Only a bureaucratical argument: We can't close this bug until bug 96355 has been fixed which this bug depends on.)
Comment 35 Heiko Tietze 2019-02-06 19:36:10 UTC
(In reply to andreas_k from comment #32)
> context menues get an update in 6.2 to close this bug as WFM. is it ok?

Don't get this. 

In c27, c29, c30, c31 the idea to re-add Name and Description got +1. 

And I would close this ticket by removing the dependency. Makes not much sense to me.
Comment 36 Katarina Behrens (CIB) 2019-02-07 09:09:40 UTC
I saw those entries in Impress context menu with master build as of yesterday, so this is pretty much fixed, no?
Comment 37 Heiko Tietze 2019-02-10 13:51:11 UTC
(In reply to Katarina Behrens (CIB) from comment #36)
> I saw those entries in Impress context menu with master build as of
> yesterday, so this is pretty much fixed, no?

Yes, but not in the other modules. Sure, Draw/Impress is much more focused on images  but for consistency we should have similar menus across the modules.
Comment 38 andreas_k 2019-07-16 14:24:05 UTC
> Yes, but not in the other modules. Sure, Draw/Impress is much more focused
> on images  but for consistency we should have similar menus across the
> modules.

I added Name and Description ONLY to Impress/Draw context menu, cause in writer and calc there is no benefit to have a Name/Description. In Draw you can see the Name in the Navigator where you can than easy select an specific shape.

In writer/calc I don't see an benefit to have it in the context menu. In writer there is insert capture, cause you link to an image/shape with capture. So from my point of view this bug can be closed.