When I right click the Windows 10 Desktop and select the New entry there are entries for Presentations, Spreadsheets and Drawings but not one for Writer.
I have only noticed this in the latest release - Have been updating between releases installing over the top of the old version every time.
There should be a Libreoffice Writer entry there as well as the others.
I can not confirm with LO 5.1.2, win10. Item New text document is present.
New Text document is a TXT file not an ODT - Opens in Notepad on my system.
(In reply to Martin Hooper from comment #2)
> New Text document is a TXT file not an ODT - Opens in Notepad on my system.
Yes, you're right, correct name is Text document OpenDocument
Number of items in this menu is limited. How many items in menu do you have? Did you tried reinstall LibreOffice?
8 items plus folder and shortcut - Not tried un-installing and re-installing yet.
Will report back when I have.
Re-installed and still no ODT on the menu.
Where are these entries stored on the filesystem?
Want to see if it is there and how many are actually there if there are a certain number that can be displayed.
Actual count of entries on the Desktop context menu New list is not limited that I can find.
And, the correct ShellNew entry is being created, but on Windows 10 it is not populating the Desktop context menu New list for Writer or Calc document.
Yet the entry for .odg and .odp are both present with similar ShellNew registry entries and do appear on the context menu list.
Given that, this seems more a Windows OS issue.
Stuart: you confirm the issue?
Comments from cloph:
"the new document works by placing empty documents somewhere and having registry entries point to those templates.
when using new form explorer's context menu, windows will then simply copy that sample over to the desired folder
So it is different from File|New in LO (that would create a new document based on the default template, which the user can modifiy/change to a different one), new via Explorer will always just copy the empty doc that was installed by the msi"
Just checked for the following file following the registry entry:
C:\Program Files (x86)\LibreOffice 5\share\template\shellnew\soffice.odt
and its there....
So not sure whats going on now...
Cloph said everything looks fine and thus it is likely a Windows bug, if no one else can reproduce it.
Created attachment 124726 [details]
Windows 10 registry ShellNew entries for LibreOffice, all appear correct in registry, but .ODS, .ODT entries do not appear in shell context menu
(In reply to Buovjaga from comment #8)
> Stuart: you confirm the issue?
> Comments from cloph:
> "the new document works by placing empty documents somewhere and having
> registry entries point to those templates.
> when using new form explorer's context menu, windows will then simply copy
> that sample over to the desired folder
> So it is different from File|New in LO (that would create a new document
> based on the default template, which the user can modifiy/change to a
> different one), new via Explorer will always just copy the empty doc that
> was installed by the msi"
That is correct and the shell context menu does copy the template from the C:\Program Files\LibreOffice 5\share\template\shellnew\ folder to the current folder.
The correct keys and values (ShellNew & FileName) are being recorded for the ODF document types during LO .msi installation into the Widnows registry (see attached).
But for some reason only the entries for OpenDoucument Drawing and OpenDocument Presentation are populating the Windows 10 Explorer shell's New context menu.
To me this is an OS issue, I'm looking for cause and we may have to adjust the LO .msi packaging once we figure out why. For now I'd say NOT OUR BUG
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present on a currently supported version of LibreOffice
(5.2.7 or 5.3.3 https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the version of LibreOffice and
your operating system, and any changes you see in the bug behavior
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave
a short comment that includes your version of LibreOffice and Operating System
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to "inherited from OOo";
4b. If the bug was not present in 3.3 - add "regression" to keyword
Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!