The rename command was split 6 years ago for bug 84258 into RenamePage and RenameSlide. I don't get "Rename Slide" in Draw but "Rename Page" (and Slide in case of Impress).

Please try again with a clean user profile (Help > Restart in Safe Mode > Continue in Safe Mode).

I tried a new profile. The same behavior. 

This also occurs with LO 7.2.6. With a new profile too.

I am unable to reproduce your issue with either:

Version: 7.3.1.3 (x64) / LibreOffice Community
Build ID: a69ca51ded25f3eefd52d7bf9a5fad8c90b87951
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: default; VCL: win
Locale: es-ES (en_IE); UI: en-US
Calc: threaded

or

Version: 7.2.6.2 (x64) / LibreOffice Community
Build ID: b0ec3a565991f7569a5a7f5d24fed7f52653d754
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win
Locale: en-IE (en_IE); UI: en-GB
Calc: CL

Did you follow Heiko's recommendation to use "Help > Restart in Safe Mode > Continue in Safe Mode"?

(In reply to Dave Barton from comment #3)


> Did you follow Heiko's recommendation to use "Help > Restart in Safe Mode >
> Continue in Safe Mode"?

Yes, I did. 

This also occurs with LO 7.0.4 in Debian.

Version: 7.0.4.2
Build ID: 00(Build:2)
CPU threads: 2; OS: Linux 5.10; UI render: default; VCL: gtk3
Locale: de-DE (de_DE.UTF-8); UI: en-US
Debian package version: 1:7.0.4-4+deb11u1
Calc: threaded

Did you do exactly the steps in comment 1?

(In reply to lol from comment #4)

> Did you do exactly the steps in comment 1?

Yes it appears to be an error in the procedure/function called from the main menu "Page -> Rename Page" option.

Confirmed as a bug in 7.3.1.3, 7.2.6.2 and:
Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 6adabd915d931b845fcf2fef15fbf3fca14ec9b3
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win
Locale: en-IE (en_IE); UI: en-GB
Calc: CL

This seems to be a definite bug, but I will test for both rpm & deb installations.

Have now tested on deb & rpm installs of TDF provided editions of 7.3.13 and can definitely confirm this bug.

Obvious typo: 7.3.13 should read 7.3.1.3

(In reply to Dave Barton from comment #6)
> Have now tested on deb & rpm installs of TDF provided editions of 7.3.13 and
> can definitely confirm this bug.

Of unclear origin. Draw and Impress should use Slide and Pages, thus not a matter of UX.

(In reply to Dave Barton from comment #5)

> Yes it appears to be an error in the procedure/function called from the main
> menu "Page -> Rename Page" option.

Maybe I find the reason why you couldn't reproduce the bug at first. Did you clicked first on the page in the page pane? See the different steps.

Steps:

1. Open Draw
2. Open the dialog via Page - Rename Page...
3. Dialog appears with the title "Rename Slide"

Steps:

1. Open Draw
1a. Click on the page in the Page Pane
2. Open the dialog via Page - Rename Page...
3. Dialog appears with the title "Rename Page"

If the focus is on the page in the page pane the dialog has a another title.

Created attachment 179115 [details]
Screencast

Both, the context menu as well as the main menu run the same command and show the rename dialog with page not slide.

(In reply to Heiko Tietze from comment #10)
> Created attachment 179115 [details]
> Screencast
> 
> Both, the context menu as well as the main menu run the same command and
> show the rename dialog with page not slide.

It apparently depends on the order.. If you use the menubar Page -> Rename it will show 'Rename Slide' 

If you use the context menu first, also Page -> Rename will we called "Rename Page"

Also in
Version: 6.1.6.3
Build ID: 5896ab1714085361c45cf540f76f60673dd96a72
CPU threads: 4; OS: Windows 6.3; UI render: default; 
Locale: nl-NL (nl_NL); Calc: CL

(In reply to Telesto from comment #11)
> It apparently depends on the order.. If you use the menubar Page -> Rename
> it will show 'Rename Slide' 

True, running the command from the main menu returns Slide until it is started from the page sorter pane - then it will be Page as well on the main menu.

Gabor, you implemented this for bug 107183. Any idea how to solve this? Apparently pDrView->GetDoc().GetDocumentType() == DocumentType::Draw is false as long no Draw specific action has been done.