Properties is always the last entry of the context menu. New Page is useful, always good to have alternative workflows. Same for delete, background etc. Don't see why we have to drop the Page submenu.

In general you are right Telesto. It may be a bit confuse, the reasons are:

1. Property is always the last item and I wouldn't move it somewhere into a submenu.
2. New Page has a submenu, cause it was always that way in the past and I didn't want to remove the New Page item cause of the reason, I always get bug report when remove stuff.

Thanks for the Feedback Telesto. For me it's a WFM or WF

(In reply to Heiko Tietze from comment #1)
> Properties is always the last entry of the context menu. New Page is useful,
> always good to have alternative workflows. Same for delete, background etc.
> Don't see why we have to drop the Page submenu.

There might be alternative workflows possible.. But we also have customization feature.. So from my perspective LibreOffice should have only 'baseline' options.

This topic belong again on the design principle/guidance list :-). GUI must useful for the general public and restrict itself to they basics. Special needs, practical features for group of people should not be implemented as (default) setting, IMHO.

So not denying this makes sense for some; or multiple workflows are possible . Not against multiple workflows. This more about how it should be configured by default (stock).

If there a templates with settings for different configurations (fine). Say Newbie, Pro] A configuration manager for most used 'tweaks/ features' also makes sense.. But (a) duplicating setting in (b) a not the most obvious place (like here) or enabled Markdown by default (not here) not the right way to go.

There is kind of baseline configuration. Which uses they 'typical' prototype (sorry undefined) user workflow.

(In reply to andreas_k from comment #2)
> 2. New Page has a submenu, cause it was always that way in the past and I
> didn't want to remove the New Page item cause of the reason, I always get
> bug report when remove stuff.

Surely understand removing stuff ends up in complains :-). So also get you're not volunteering :P. There is a need for 'design' principles first. This setting is redundant. History based etc. With proper principles and nice argument you can at least explain to people why it got removed :-)

And in addition their is an answer how to 'solve' their problem. People may configure LibreOffice in every way the want. This simply about default. If would be impossible to adjust, I get they objection. But this isn't the case.

This simply a customization thing

if there is a solution, the issue can be fixed by change the page.xml file. it's really simple.
- https://opengrok.libreoffice.org/xref/core/sd/uiconfig/sdraw/popupmenu/page.xml?r=bd96f02f

but please have also a look at impress page.xml file
- https://opengrok.libreoffice.org/xref/core/sd/uiconfig/simpress/popupmenu/page.xml?r=bd96f02f

When I redesign the popup menues, I removed a lot of commands from the context menu. After some bug reports, I added some items back.

(In reply to andreas_k from comment #5)
> if there is a solution, the issue can be fixed by change the page.xml file.
> it's really simple.
> -
> https://opengrok.libreoffice.org/xref/core/sd/uiconfig/sdraw/popupmenu/page.
> xml?r=bd96f02f
> 
> but please have also a look at impress page.xml file
> -
> https://opengrok.libreoffice.org/xref/core/sd/uiconfig/simpress/popupmenu/
> page.xml?r=bd96f02f
> 
> When I redesign the popup menues, I removed a lot of commands from the
> context menu. After some bug reports, I added some items back.

Hmm, will try to find those reports first.

Properties dialog always belongs on the context menu.

The new Page sub menu adds convenience of the Rename, and New Page (from the Pages pane and menu) are nice to have. And while the 'Set background image...' dialog workflow can be done from the Properties dialog -> Background 'Bitmap' tab it requires a lot of user understanding that the new command simplifies. 

Presence of these controls on the context menu rather than on the Properties dialog is fine, and it not be helpful to reexpand the Properties dialog.

(In reply to V Stuart Foote from comment #7)
> Properties dialog always belongs on the context menu.
> 
> The new Page sub menu adds convenience of the Rename, and New Page (from the
> Pages pane and menu) are nice to have. And while the 'Set background
> image...' dialog workflow can be done from the Properties dialog ->
> Background 'Bitmap' tab it requires a lot of user understanding that the new
> command simplifies. 
> 
> Presence of these controls on the context menu rather than on the Properties
> dialog is fine, and it not be helpful to reexpand the Properties dialog.

They Page Properties I'm able to get. They Page sub menu not so.

1. Dislike sub menu's in context menu in principle [are there guidelines?]. So needs to avoided as far as possible. In context of costs/benefits. 
2) With the page sub menu present I'm inclined to move properties to the sub menu (except simply less accessible). So not really an option..

--Renaming sub menu item
I prefer to see what I'm doing; noticing names of other pages and such. And certain page needs to be selected
* Available in Page Panel being obvious choice
* And ideally in the right context menu of the sidebar/navigator [currently not the case somehow, why not?)
* Selecting page & Pressing F2 (ouch, F2 using for insert text; this key normally used for rename on Windows.. but there probably is shortcut)

--Background item sub menu
Can be set in 
* Menu Page -> background 
* Sidebar -> Page
* Right Click Context Menu -> Properties (will be page properties in the future)
And maybe even right click -> Slide/Page panel (currently not the case).

But in the context menu. Not seeing the point (as a default)

--New page/delete page sub menu item
Prefer this doing a point where you can see slides. So page/slide panel. And maybe navigator context menu (currently not present)
And Page menu -> New page

And I personally select a page in panel & press Delete key. Surely not taking the de-tour in a context menu. New page has (can have?) a short cut to.. 

They context menu is really superfluous. If people find it useful for some reason, fine. But they should add it themselves. There enough ways of reaching the goal. And the Context Menu entry surely most logical thing. 
---

I qualify this as an (superfluous) customization, IMHO. LibreOffice should deliver some workflow. Not making every workflow possible in advance.

And if there is a need for such commands, combine those in different template configurations. Or let people share their dialog customization (similar to the Personas thing)

That's possible to have different workflows, doesn't every workflow should by present in they UI by default (bloating stuff).

You put commands at positions where it's "obvious" to look. And right click context menu on page have certain page settings doesn't that criteria, IMHO

I can't explain more clearly, it simply feels off/wrong.

And with more specific design principles, this might be 'obvious'. While my argument maybe not followed here, this same argument will be brought up in other case.. To archive they opposite. We can't add a new command in a sub menu.. because  ...

And cherry picking argument or selective weighting arguments being something I really dislike. There is simply not not a consistent pattern. Which kind of infuriating  

Design principles/guidelines are still guidelines. So still a possibility to do it differently. However there must be good arguments for doing so. But there a kind of barrier.

Setting to UNCONFIRMED..like this on they regular UX meeting. Even if i'm (likely) not attending

My opinion is Wantfix.

So far three times -1, no need to bring this up in the meeting.