Created attachment 45020 [details] Screenshot of the start menu Windows Seven (perhaps even Vista) has extended the "recent documents", by making a recent docs list for every application. It takes place in the start menu : at the right of each application in the start menu (the white part on the left, for frequently used apps), a little arrow shows the list of the, say, 10 last documents opened with it. (see screenshot attachment) As far as I could see, every application, even older ones, shows this list. But LibreOffice doesn't. Maybe something in LibO prevents the list from being build by the system (which is the way it seems to work).
.
possibly related: someone on the Dutch users list reported too that the list does not work, or only unreliable. Looks more as a bug to me..?
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
I am pretty sure that there has been some rework on this problem, but I can't find the related bug. WFM for now. @reporter: Please feel free to reopen this bug if you find out that the problem still exists with a current stable LibreOffice version and if you can contribute requested additional information due to <http://wiki.documentfoundation.org/BugReport> (especially BugReport Details)!
Hi Rainer, this is about recent document in the Windows Start menu. See picture attached
Created attachment 60033 [details] picture windows start menu
Changed the Summary to make clear that this is an enhancement request (not a but report) and about the Windows 7 Start menu (not about our File menu).
Why enhancement request? It was there and now it's broken!?! That's why bug 56125 seems to be exist.
Hi, I can confirm this bug. It still exists in 3.6.5.2. The jump lists used to work fine with 3.5. Roman: Could you please clarify why this bug is an enhancement request for you?
*** Bug 56125 has been marked as a duplicate of this bug. ***
I guess the importance needs to be changed from "enhancement" to "normal".
This problem is probably related to: set explicit Application User Models IDs in the native Windows launchers 776db316d271d14e653426e21e66b983ec52100a To restore the old behavior, this could be partially reverted in the LibreOffice 4.0.x branch and then fix properly for 4.1, as it requires some work.
Coincidentally I was browsing the git 3.6 branch yesterday and found 67673e9ba6788f4c85bfdaac6091148086f12941 and was wondering if that has anything to do with our problem. Unfortunately I do not have a sane development environment on my laptop, so I could not test anything. But anyways: Thanks for you comment, Jesus.
Jumplists used to work for me with version 3.something, but after upgrading to 4.0.0.3 I also have this problem.
Bug 45600 is a duplicate bug. Someone please marks it. I don't follow the release of every official version of LibreOffice. I jumped from 3.5.7 to 4.0.0 (but "About" indicates it's version 4.0.0.3!) and "Jump list" is broken somewhere between these two versions. If someone could tell me where I can download old released versions, I can help you pinpoint the exact moment where this is broken.
(In reply to comment #15) > ... > If someone could tell me where I can download old released versions, I can > help you pinpoint the exact moment where this is broken. It could be very helpful indeed! I don't know if there are official links but here's an url: http://www.oldapps.com/libreoffice.php
(In reply to comment #15) This is probably the best source for older LibreOffice builds: http://downloadarchive.documentfoundation.org/libreoffice/old/
(In reply to comment #17) > (In reply to comment #15) > > This is probably the best source for older LibreOffice builds: > > http://downloadarchive.documentfoundation.org/libreoffice/old/ Indeed! Bookmarked now, thank you V Stuart Foote! :-)
Closing fdo#45600 as duplicate, but refer to comments in bug 45600#c18 regards SHAddToRecentDocs (i.e. is calling from /core/vcl/win/source/app/salinst.cxx correct ) or bug 45600#c19 regards use of LibreOffice specific ICustomDestinationList with developer notes.
*** Bug 45600 has been marked as a duplicate of this bug. ***
bug#45600 pre-dates this, has a better discussion with code pointers and was a 3.6 MAB - adjusting this to be one too.
OK, the breaking point is version 3.6.0.1 (LibO_3.6.0.1_Win_x86_install_multi.msi) That means all previous versions (..., 3.5.7.2, ..., 3.6.0.0.beta2) were all ok and don't have this problem. A little comment on versions 3.5.99.1 & 3.6.0.0.beta2: their respective setups LibO-Dev_3.6.0beta1_Win_x86_install_multi.msi and LibO-Dev_3.6.0.0.beta2_Win_x86_install_multi.msi don't create file associations after installation. We just need to make manual associations (*.odt to LOWriter, *.ods to LOCalc, etc), and jump list will appear without problem.
(In reply to comment #22) > OK, the breaking point is version 3.6.0.1 > (LibO_3.6.0.1_Win_x86_install_multi.msi) > > That means all previous versions (..., 3.5.7.2, ..., 3.6.0.0.beta2) were all > ok and don't have this problem. Not sure we can say that. Clearly reviewing the comments for this and associated bugs, the issue has come and gone for folks with reports of non functional Windows 7 "jump list" at the 3.3.4, 3.4.5 builds and now your 3.6.0.1 mark. I suspect the problem may be masked by presence or absence of a valid Windows file association to the ODF formats--which is handled by the MS Installer for LibreOffice during installation. The development build installers, or when folks install in parallel with /A administrative, aka server installations, do not make file associations as they do not write into the Windows registry. So doing a comprehensive bibsect will require clean installations at each build with Windows registry and user account clean-up for each test cycle. One reason VMs are so convenient for doing the testing.
(In reply to comment #23) > Not sure we can say that. Clearly reviewing the comments for this and > associated bugs, the issue has come and gone for folks with reports of non > functional Windows 7 "jump list" at the 3.3.4, 3.4.5 builds and now your > 3.6.0.1 mark. I have just gone back to bug 45600 and done a test with 3.4.5 but I was *unable* to reproduce the problem. For me, jump list had always been working from the beginning of LO (when it forked from OOo) up to 3.5. I don't think you would need to go back to 3.3 (and I cannot find the bug report for 3.3.4). So, here is the list of versions I tested and the results: * 3.4.5.2 | LibO_3.4.5rc2_Win_x86_install_multi.exe ok * 3.5.7.2 | LibO_3.5.7rc2_Win_x86_install_multi.msi ok * 3.5.99.1 | LibO-Dev_3.6.0beta1_Win_x86_install_multi.msi ok * 3.6.0.0.beta2 | LibO-Dev_3.6.0.0.beta2_Win_x86_install_multi.msi ok * 3.6.0.1 | LibO_3.6.0.1_Win_x86_install_multi.msi not ok * 3.6.0.4 | LibO_3.6.0.4_Win_x86_install_multi.msi not ok * 3.6.3.2 | LibO_3.6.3.2_Win_x86_install_multi.msi not ok * 4.0.0.1 | LibreOffice_4.0.0.1_Win_x86.msi not ok
Oh, I forgot to write that I have been using clean O/S (ie newly installed O/S) inside VM to do the tests. And ver 3.5.99.1 and 3.6.0.0.beta2 showed me that having file association or not does not affect jump list.
Created attachment 77507 [details] 3.5.7.2 build verbose install log
Spent some time with this as well, and got slightly different results. The LibreOffice 3.5.7.2 Jump List under Windows 7 seems exactly correct. When launcher for any component is Pin'd to Start Menu I get the right triangle pop-up of recent items, and if Pin'd to the Task Bar a <right mouse> context menu will show the same Recent items for that component. But with the 3.6.0.0beta1 (listed as 3.5.99.1) 3.6.0.0beta2, 3.6.0.0beta3 and 3.6.0.1 (rc1), 3.6.0.2 (rc2), 3.6.0.3 (rc3) and 3.6.0.4 (rc4 and final 3.6.0) I can not get correct Jump List behavior. Starting with the 3.6.0 beta1, while a component is running (or just soffice.exe start panel) a <right mouse> context menu of its task bar button displays Recent listing (same formattaing as Jump List)--the behavior for all builds through 4.0.3 Possibly why my result was a little different is that I did install the beta1, 2 & 3 with WRITE_REGISTRY=1 value. So, it really looks like the issue is somewhere in the early 3.6 work on the Windows build. And it is still not clear about the issues folks saw at the 3.3.4 and 3.4.5 builds. Not sure it helps, but I captured verbose install logs of the betas along with a log of the 3.5.7.2 install.
Created attachment 77508 [details] 3.6.0.0beta1 build verbose install log Not uploading the beta2 or beta3 install logs, but will set aside if anyone needs them. Each log expands to about 30MB.
(In reply to comment #12) > This problem is probably related to: > > set explicit Application User Models IDs in the native Windows launchers > 776db316d271d14e653426e21e66b983ec52100a > > To restore the old behavior, this could be partially reverted in the > LibreOffice 4.0.x branch and then fix properly for 4.1, as it requires some > work. @Jesús Time frame for appearance in 3.6.0beta1 certainly looks to match the commit dates (5/24/2012 & 6/4/2012) for your work on the applauncher at 3.6. But I get sooo lost, how would the AppID and SHAddToRecentDocs or ICustomDestinationList needed for Windows 7 Jump List be handled? I don't see AppID called in the /core/desktop/win32/source/applauncher/launcher.cxx code just the APPUSERMODELID in line 75.
OK, I missed the 3.6.0.0beta3. I have just redone the test and it has the same behavior as 3.6.0.0.beta2. So for me, the conclusion is the same: breaking point is 3.6.0.1. (In reply to comment #27) > But with the 3.6.0.0beta1 (listed as 3.5.99.1) 3.6.0.0beta2, 3.6.0.0beta3 > and 3.6.0.1 (rc1), 3.6.0.2 (rc2), 3.6.0.3 (rc3) and 3.6.0.4 (rc4 and final > 3.6.0) I can not get correct Jump List behavior. > > Starting with the 3.6.0 beta1, while a component is running (or just > soffice.exe start panel) a <right mouse> context menu of its task bar button > displays Recent listing (same formattaing as Jump List)--the behavior for > all builds through 4.0.3 I don’t see how this can be interpreted as “incorrect jump list behavior”!? Do you, yes or no, have the right-pointing triangle for LO app icons inside Start Menu? > Possibly why my result was a little different is that I did install the > beta1, 2 & 3 with WRITE_REGISTRY=1 value. I could try to use this parameter, but where or how am I supposed to use this parameter when I launch the setup? > ... And it is still not clear about the issues folks saw at the > 3.3.4 and 3.4.5 builds. Personally, I would consider those reports as false negative: they might mix up versions. There’s another possibility: jump list is clear when we uninstall LO. So after they reinstalled a new version (eg 3.4 or 3.5) of LO and they can’t see the jump list, they might conclude that jump list was broken in those versions.
(In reply to comment #30) > > > Starting with the 3.6.0 beta1, while a component is running (or just > > soffice.exe start panel) a <right mouse> context menu of its task bar button > > displays Recent listing (same formattaing as Jump List)--the behavior for > > all builds through 4.0.3 > > I don’t see how this can be interpreted as “incorrect jump list behavior”!? > Do you, yes or no, have the right-pointing triangle for LO app icons inside > Start Menu? > No. The Jump list (right-pointing triangle) does not appear for LO apps in the start menu. Simply noting the behavior above is from ver 3.6.0 beta1 onward, where the recent documents (formated as a Jump list "Recent" entry) are exposed by a running LO app. Same behavior you note in https://bugs.freedesktop.org/show_bug.cgi?id=45600#c25 > > Possibly why my result was a little different is that I did install the > > beta1, 2 & 3 with WRITE_REGISTRY=1 value. > > I could try to use this parameter, but where or how am I supposed to use > this parameter when I launch the setup? > Available when installation is run from the command window. E.g., msiexec.exe /i LibO-Dev_3.6.0beta1_Win_x86_install_multi.msi /L*v install.log WRITE_REGISTRY=1
(In reply to comment #29) > (In reply to comment #12) > > This problem is probably related to: > > > > set explicit Application User Models IDs in the native Windows launchers > > 776db316d271d14e653426e21e66b983ec52100a > > > > To restore the old behavior, this could be partially reverted in the > > LibreOffice 4.0.x branch and then fix properly for 4.1, as it requires some > > work. > > @Jesús > > Time frame for appearance in 3.6.0beta1 certainly looks to match the commit > dates (5/24/2012 & 6/4/2012) for your work on the applauncher at 3.6. > > But I get sooo lost, how would the AppID and SHAddToRecentDocs or > ICustomDestinationList needed for Windows 7 Jump List be handled? I don't > see AppID called in the /core/desktop/win32/source/applauncher/launcher.cxx > code just the APPUSERMODELID in line 75. the problem is when these AppID are used, Windows 7 sees LibreOffice not just as an old SINGLE application anymore (and uses its fallback behavior to handle old applications with LibreOffice) but as several new applications (Writer, Calc, Base, etc.) as each application has its own AppID. So now you have to add the document to it's new application (calling SHAddToRecentDocs and saying you want to add an ods to "Calc") as the old fallback mechanism doesn't exist anymore. I think it's probably a good idea to revert this and then only commit the changes when all the parts are ready as half work only makes things worse, IMHO.
(In reply to comment #31) > msiexec.exe /i LibO-Dev_3.6.0beta1_Win_x86_install_multi.msi /L*v > install.log WRITE_REGISTRY=1 OK, I can confirm that if I use the command above, I do NOT have jump list either. (And of course, if I double-click the MSI file to launch installation, jump list is working normally after a manual file association as I stated earlier) Note that I only did the test with 3.6.0beta1
Went back and did installs of 3.3.2, 3.3.4 and then 3.4.5rc2 all functioned correctly delivering Windows 7 "Jump lists" functionality. That is, I was able to pin app icon to start menu, and to task bar where recent documents show correctly on jump lists. Had to fight a little bit with file associations with 3.4.5 (had Office 2007, ApacheOpenOffice 4.0, and LibreOffice 3.3/3.4 resident) but once an association could be established, the LibreOffice 3.3.2, 3.3.4 and 3.4.5 jump lists all kept track of files they'd opened. Can't be 100% certain, but I suspect the earlier reports are all file association related issues. Comfortable saying problems with jump lists start with 3.6.0beta1.
Jesús, if you think reverting 776db316d271d14e653426e21e66b983ec52100a "partially" is best, could you please do that then? Thanks.
Jesus Corrius committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=64dafbe584fe7644ec29b96b6a9a9588ba4619bd Fix fdo#35785: recent documents feature of the Windows 7 Start menu broken 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.
*** Bug 57482 has been marked as a duplicate of this bug. ***
*** Bug 64012 has been marked as a duplicate of this bug. ***
I have just tested the beta version 4.0.4.0+ and it works. The shortcuts to recent documents in "windows 7" start menu are back are back. Thank you
whom I thank them very much. thank you From: bugzilla-daemon@freedesktop.org Sent: Sunday, April 28, 2013 6:15 PM To: carlosdaterra@ig.com.br Subject: [Bug 35785] LibreOffice's support of the "recent documents" feature of the Windows 7 Start menu broken Comment # 39 on bug 35785 from andrej8anubis@gmail.com I have just tested the beta version 4.0.4.0+ and it works. The shortcuts to recent documents in "windows 7" start menu are back are back. Thank you -------------------------------------------------------------------------------- You are receiving this mail because: a.. You are on the CC list for the bug.
Jesús, Tor So, with the 64dafbe584fe7644ec29b96b6a9a9588ba4619bd commit done to back out the start of an individual APPUSERMODELID for each component, what should now happen with applauncher and handling of APPUSERMODELID as AppID in Windows? I just got a chance to do a complete install of todays TB 6 build of master which includes the above commit. tinderbox: administrator: Tinderbox <l.lunak@suse.cz> tinderbox: buildname: Win-x86@6 tinderbox: tree: MASTER tinderbox: pull time 2013-04-29 04:16:17 tinderbox: git sha1s core:e986d3e396174096abb46075bf7488677b9a35f9 Before starting, I'd cleaned all LibreOffice and Apache OpenOffice off. I installed the TB build of master with a command line WRITE_REGISTRY=1. I have verified file associations were made against todays TB build. Unfortunately at this point I am NOT seeing correct Windows 7 "Jump list" behavior, do you think we should be?
(In reply to comment #41) > Jesús, Tor > > So, with the 64dafbe584fe7644ec29b96b6a9a9588ba4619bd commit done to back > out the start of an individual APPUSERMODELID for each component, what > should now happen with applauncher and handling of APPUSERMODELID as AppID > in Windows? > > I just got a chance to do a complete install of todays TB 6 build of master > which includes the above commit. > > tinderbox: administrator: Tinderbox <l.lunak@suse.cz> > tinderbox: buildname: Win-x86@6 > tinderbox: tree: MASTER > tinderbox: pull time 2013-04-29 04:16:17 > tinderbox: git sha1s > core:e986d3e396174096abb46075bf7488677b9a35f9 > > Before starting, I'd cleaned all LibreOffice and Apache OpenOffice off. I > installed the TB build of master with a command line WRITE_REGISTRY=1. > > I have verified file associations were made against todays TB build. > > Unfortunately at this point I am NOT seeing correct Windows 7 "Jump list" > behavior, do you think we should be? I decided to fix the bug in a slightly different way. As I wasn't very satisfied with the idea of just getting rid of the code. Wait for a couple of commits to be merged into master and then test it, please. https://gerrit.libreoffice.org/#/c/3638/ https://gerrit.libreoffice.org/#/c/3639/ I find very curious that it has been reported working on 4.0.4 as the fix is not in this branch. AFAIK if the user *always* clicked in the document in Explorer to open it, the result should be reasonable. It may be the case?
Jesus committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8d9337326745f3cd3ade623b3c01ad6e8e3e590d fdo#35785: LibreOffice is One for now 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.
Jesus Corrius committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6c670f63a7859e24bdfa20759bd8b7c3b4a911ef fdo#35785: don't rely on the old apps fallback mechanism to fix this bug 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.
@Jesús, Was looking forward to testing the outcome today, unfortunately the Windows TB 6 has gone off line again with a couple of build issues: ... unotest/bootstrapfixturebase.hxx(19) : fatal error C1083: Cannot open include file: ´cppunit/TestAssert.h´: No such file or directory ... [C:/cygwin/home/tinderbox/master-build/workdir/wntmsci13.pro/CxxObject/sdext/source/pdfimport/test/pdf2xml.o] Error 2 So maybe in a few days... Meanwhile, will you be looking to integrate into the Windows ApplicationID hooks Caolán had left for future development in http://cgit.freedesktop.org/libreoffice/core/commit/?id=e9daae2025279d04155ddeb794bb35952e627ed7 and http://cgit.freedesktop.org/libreoffice/core/commit/?id=2aee1633048bcb732a5c1917580d305afa54e5ef during spin-up? But guess that should be opened as its own issue. Stuart
*** Bug 64167 has been marked as a duplicate of this bug. ***
Hi Stuart; thanks for testing this - there are build now it seems from Win-86@6 or somesuch :-) looking forward to an ack & back-port to -4-0 :-)
@Michael Sorry, I'd grabbed the 2013-05-01 TB 6 build ( 35583e02020326eae206c16c89e9e5eaf5f580b ) and done a command line install with WRITE_REGISTRY=1, but didn't get results posted up before the weekend. Unfortunately, we were still not there yet with no Jump lists present for individual component start list launchers or for the Start Center. Have grabbed todays 2013-05-06 00:22:57 TB 6 build ( 9a8f125fa7e63b829471a6722dae3006bb1f57d2 ) and will set that up. But not expecting it will be that different since I'm pretty sure the 05-01 build already had Jesús's and Tor's commits posted.
(In reply to comment #48) > @Michael > > Sorry, I'd grabbed the 2013-05-01 TB 6 build ( > 35583e02020326eae206c16c89e9e5eaf5f580b ) and done a command line install > with WRITE_REGISTRY=1, but didn't get results posted up before the weekend. Simple users would simply double-click on the setup and would never use WRITE_REGISTRY=1, so does it matter?
Created attachment 78938 [details] screenshot of LibreOffice Start Menu w/o Jump list capabilities So with the 2013-05-06 build (and also the 2013-05-01), it seems it is now . 1) none of the components, including the Start Center can be "pinned" to the start menu or the task bar. Each "launcher" 2) when running, and showing as running in the task bar, no documents are listed. Instead the task bar icon for each running component shows a list of the other running components with just a close X action for each. It seems as if rather than exposing each component individually, all of LibreOffice is now being treated as one within the Windows shell and "Jump list" handling. Have attached a screen clip of the Start Menu options for Writer...
(In reply to comment #49) > > Simple users would simply double-click on the setup and would never use > WRITE_REGISTRY=1, so does it matter? Absolutely, when Windows builds are finalized as RC the configuration for the MSI installer package gets toggled such that WRITE_REGISTRY value gets changed from 0 -> 1. When not set, all Dev builds of Master and the Dev builds for each of the branches will not make ANY changes to the MS Windows registry. Since we are looking at issues of LibreOffice integration with MS Windows shell, specifically the > Win7 Jump Lists, we have to force the install to register--can only be done with a command line install using msiexec.exe /i syntax and a WRITE_REGISTRY=1 switch. Andras any additional comment? Stuart
@Stuart: you are right. (In reply to comment #51) > Andras any additional comment? It was a correct explanation. BTW I also tried the patches, both in master and in 4.0, but I did not see any difference. I mean I did not see that they fixed anything. Maybe I'm wrong. It seems you understand the problem better, so basically we are waiting for your judgment if these 3 patch should be backported to 4.0, or not.
(In reply to comment #52) > waiting for your judgment if these 3 patch should be backported to 4.0, or > not. I certainly can test it, and can tell what is working and what is not. And at this point, I'd say not to backport as I don't think everything needed is in place, YET. But it is really Jesús who has the concept of how to structure the component launchers. We'll either use the SHAddToRecentDocs for default handling of each. Or will get creative and use the ICustomDestinationList handlers for a tailored menu experience in Windows. Jesús, your thoughts/comments on where this still needs to go? Can we help in any way?
*** Bug 64340 has been marked as a duplicate of this bug. ***
*** Bug 64369 has been marked as a duplicate of this bug. ***
Not yet corrected for the 4.1.0.1 RC, so setting whiteboard target forward to 4.1.1 Jesús, any thoughts for handling components with discrete ApplicationID in launcher.cxx as you'd envisioned?
Jesus Corrius committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=19f3d9310caef84fe2815eb89af448a81937bddd fdo#35785 LibreOffice's support of recent documents in Windows 7 broken 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.
(In reply to comment #56) > Not yet corrected for the 4.1.0.1 RC, so setting whiteboard target forward > to 4.1.1 > > Jesús, any thoughts for handling components with discrete ApplicationID in > launcher.cxx as you'd envisioned? I think this patch finally fixes this. Any help checking next days master builds to make sure that everything is working right will be greatly appreciated.
I have tried ...archive.zip on site: http://dev-builds.libreoffice.org/daily/master/Win-x86@6/2013-07-11_04.05.08/ but it does not start. It just shows the message that some folder could not be created. It is version: 4.2.0.0.alpha0+ then I have tried ...x86.msi on site: http://dev-builds.libreoffice.org/daily/master/Win-x86@6/2013-07-11_04.05.08/ but there are no recent start menu shortcuts. They are also gone on task bar now that are on version 4.0.3.3. Just the opposite that I would like. I also noticed that open format documents by default opens ms office, instead of libreOffice. In the installation process I selected for ms documents to be opened with libreOffice but it seem to me that did not take effect.
(In reply to comment #59) > I have tried ...archive.zip on site: > http://dev-builds.libreoffice.org/daily/master/Win-x86@6/2013-07-11_04.05.08/ > but it does not start. It just shows the message that some folder could not > be created. It is version: 4.2.0.0.alpha0+ > > then I have tried ...x86.msi on site: > http://dev-builds.libreoffice.org/daily/master/Win-x86@6/2013-07-11_04.05.08/ > but there are no recent start menu shortcuts. They are also gone on task bar > now that are on version 4.0.3.3. Just the opposite that I would like. > > I also noticed that open format documents by default opens ms office, > instead of libreOffice. In the installation process I selected for ms > documents to be opened with libreOffice but it seem to me that did not take > effect. The builds should be at least from 2013-07-20, older builds don't have my latest fix.
Jesus Corrius committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f7d410edfa0866bd7759b2b977800d5744d8b544&h=libreoffice-4-1 fdo#35785 LibreOffice's support of recent documents in Windows 7 broken It will be available in LibreOffice 4.1.1. 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.
@Jesús, Thanks for keeping after it! Reads to be an elegant solution, and would love to test it, but waiting for it to cycle through either the 4.1 or master TB daily's. Unfortunately Master TB builds have stalled--although maybe a debug build will roll round first. And will for sure need another 24hrs til available against the 4.1 branch. But even if not widely tested, probably the correct move to push it down for 4.1.1 now. And for anyone testing--remember to run the MSI from a command prompt and set the WRITE_REGISTRY=1, but you may have to clean profile and Windows Regsitry up prior to install.
(In reply to comment #62) > @Jesús, > > Thanks for keeping after it! > > Reads to be an elegant solution, and would love to test it, but waiting for > it to cycle through either the 4.1 or master TB daily's. Unfortunately > Master TB builds have stalled--although maybe a debug build will roll round > first. And will for sure need another 24hrs til available against the 4.1 > branch. But even if not widely tested, probably the correct move to push it > down for 4.1.1 now. This patch improves the Windows 7 integration quite dramatically but further work is still necessary to finish this once and for all. The tentative release for all the required fixes will be 4.1.1. Further Windows related improvements will be made only on the 4.2 branch.
@Jesús, Commits finally rolled around to a 4.1.1.0+ TB build delivering a .MSI installer to be able to force Windows registry updates. I'm testing on Windows 7 sp1, 64-bit Ultimate. Version: 4.1.1.0.0+ Build ID: fb479f1b707478708b8ab8b09af994bd4e1759d TinderBox: Win-x86_9-Voreppe, Branch:libreoffice-4-1, Time: 2013-07-23_07:34:22 Performed command line msiexec.exe install with WRITE_REGISTRY=1 flag. Disable Quicklaunch and Auto Update, but enabled Windows Explorer integration, associated MS Office programs with LODev. At, first blush I am not seeing any change to Start menu or Task bar handling of the components. When individually pinned, do not see either the Start menu with a Jump list "triangle" or a "Recent" jump list for components on the Task bar. Am I missing something, was there something we needed to do to activate this feature?
Created attachment 82946 [details] Zip'd msiexec installer verbose log of LODev 4.1.1.0+ with 2013-07-20 recent documents commit applied Attaching verbose log (zip'd) of command line install with WRITE_REGISTRY=1 value set. Verified in Windows registry and an Orca edit session of the installer that registry elements were created as indicated. On this 64-bit Windows 7 system, resultant Windows registry entries made to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\The Document Foundation\LibreOfficeDev\4.1\Capabilities and to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\LibreOffice However, on user launch no apparent HKEY_CURRENT_USER\Software registry entries are made. Am I missing something, it seems like some Windows configuration details of the the per user state of Start menu/Task bar Jump lists should be reflected there.
Created attachment 82947 [details] Zip'd msiexec installer verbose log of LODev 4.1.1.0+ with 2013-07-20 recent documents commit applied Setting content type correctly, obsoleting 82946 which has incorrect type set.
Fridrich Å trba committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0fa175d2ce8a0d21fced2c5f61528797d919c0fa&h=libreoffice-4-1 fdo#35785: Add MsiShortcutProperty table to the installer It will be available in LibreOffice 4.1.1. 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.
This will be fixed in LibreOffice 4.1.1. I am pretty confident the code works finally :)
I have just try the libreoffice-4-0~2013-07-25_11.42.42_LibO-Dev_4.0.5.0_Win_x86.msi 25-Jul-2013 14:12 121M on http://dev-builds.libreoffice.org/daily/libreoffice-4-0/Win-x86@6-debug/2013-07-25_11.42.42/ Recent document in start menu are present again :) Thank you
Great news...thanks Jesus. :-) According to comment 69, so we can see that fix on 4.0.5?
(In reply to comment #70) > According to comment 69, so we can see that fix on 4.0.5? I don't understand what that comment speaks about, but the work we did with Jesus on the Windows 7 and 8 shell integration cannot be in 4-0 branch. The next release that will have those goodies is 4.1.1 that is due from now 3 weeks. The next windows test build in a quasi-release configuration that will have those fixes will be the build that will be uploaded tomorrow here http://dev-builds.libreoffice.org/daily/libreoffice-4-1/Win-x86_9-Voreppe/ Since the tinderbox has a build-time of a full multilanguage build of around 20-22 hours, the build that was uploaded on 25th does not have all the installer modifications that allow the jump-lists.
I have redone the test on another machine (win7) that had not any kind of LibreOffice yet at all. I have installed the libreoffice-4-0~2013-07-25_11.42.42_LibO-Dev_4.0.5.0_Win_x86.msi and restarted the machine =========== result : after opened some documents, recent documents in start menu appeared, but no recent documents in task bar (not so happy about that) uninstalled LOdev, restarted the machine and installed LibreOffice 4.0.3.3 and restarted the machine =========== result : after opened some documents, recent documents in start menu are not present, but they are in task bar (as expected) uninstalled LibreOffice, restarted the machine and installed previous LODev 4.0.5 back on again and restarted the machine =========== result : after opened some documents, recent documents are present (in start menu and task bar - weird) uninstalled LOdev 4.0.5, restarted the machine and installed LibreOffice 4.0.3.3 back on and restarted the machine =========== result : after opened some documents, recent documents are present in task bar, but not in start menu (again, as expected) For final round I tested the libreoffice-4-1~2013-07-25_04.12.10_LibreOfficeDev_4.1.1.0.0_Win_x86.msi 26-Jul-2013 02:45 207M that I get from http://dev-builds.libreoffice.org/daily/libreoffice-4-1/Win-x86_9-Voreppe/2013-07-25_04.12.10/ I uninstalled the LibreOffice 4.0.3.3, restarted the machine and installed LibreOfficeDev 4.1.1.0 and restarted the machine =========== result : after opened some documents, recent documents are present in the task bar, but not in start menu Questions?
Seems to work fine on Windows machines where LibreOffice has never been installed before, but i am also experiencing weird things on machines where multiple versions of LibreOffice have been installed previously. On the other side, the recent documents menu in the taskbar seems to work as expected, which is good.
@Jesús, Fridrich So the only TinderBox nightlys we have are Voreppe for the 4.1 branch, and Lubos's TB-6 which have been converted to building debug versions. The latest: tinderbox: administrator: fridrich.strba@bluewin.ch tinderbox: buildname: Win-x86_9-Voreppe tinderbox: tree: libreoffice-4-1 tinderbox: pull time 2013-07-25 04:12:10 tinderbox: git sha1s core:703cf9193e7fa345f9535045bd0dbcacbfa026d8 does not look to have any of Fridrich's ongoing work on the MSI installer tables. And while Lubos has converted the TB-6 systems to building debug versions for 4.0, 4.1 and master branches, the 4.1 branch gets spun as an /Administrative install, so can't test the MSI installer work when it posts. tinderbox: administrator: Tinderbox <l.lunak@suse.cz> tinderbox: buildname: Win-x86@6-debug tinderbox: tree: libreoffice-4-1 tinderbox: pull time 2013-07-26 07:40:26 tinderbox: git sha1s core:80328f390eceb32e1530ca182e6b135c3a0b0264 So for this round of development, I've really not been able to do much reliable testing. I did install yesterdays TB-6 debug build of master with a WRITE_REGSITRY=1 switch tinderbox: administrator: Tinderbox <l.lunak@suse.cz> tinderbox: buildname: Win-x86@6-debug tinderbox: tree: MASTER tinderbox: pull time 2013-07-25 22:29:07 tinderbox: git sha1s core:bfa3f8584b2f2492f5c0573f22e4ebd96d9a8af5 it is sort of working--can pin to StartMenu or TaskBar, but the Jump lists are not picking up documents as a Recent list. Also, the Windows registry shows Keys: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\LibreOffice HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\tinderbox\LibreOfficeDev\4.2 The second could be causing issues, but I think commit f277d2a8caee4b15a518a26a3d1c064a9a3a1a62 fixes that. Will have to wait for it to roll through another build cycle. I know I really should start building these myself ;-)
(In reply to comment #74) > does not look to have any of Fridrich's ongoing work on the MSI installer > tables. Voreppe should be ok within 4-5 hours. And your test looks consistent with what I have here. Otoh, on the start-menu pinned writer I have the jump-list, on calc, impress and draw, only the arrow, but no documents.
Created attachment 83119 [details] Zip'd msiexe installvervose log LODev 4.1.1.0+ of 203-07-26 TB-9 Still having issues with the LibreOffice Jump Lists appearing when launcher pinned to Start menu or populating with "Recent"--right triangle on Start menu, or in context menu of a Task bar pinned launcher. Documents created, or edited in LibreOffice 4.1.1 are appearing in the Windows Start menu "Recent Items" list, as well as the LibreOffice registry as history entires--showing in LibreOffice Start Center Open menu, or File -> Recent Documents. Pulled the lastest TB-9 Voreppe build: Version: 4.1.1.0.0+ Build ID: b407b33e3e00a54796abc3307dc7f123ce958e7 TinderBox: Win-x86_9-Voreppe, Branch:libreoffice-4-1, Time: 2013-07-26_22:16:17 Cleaned out Windows registry and user profiles from %APPDATA%\LibreOfficeDev, rebooted and then installed with msiexec.exe from a command prompt "Run as Administrator" "msiexec.exe /i libreoffice-4-1~2013-07-26_22.16.17_LibreOfficeDev_4.1.1.0.0_Win_x86.msi /L*v LODev411_20130726.log WRITE_REGISTRY=1" Install log attached. Windows registry is now correctly showing HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\LibreOffice HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\The Document Foundation\LibreOfficeDev\4.1 But just not seeing correct Jump List behavior.
(In reply to comment #76) > But just not seeing correct Jump List behaviour. OK, we followed scrupulously the MS documentation about the mapping between shortcut and the application ID and we set properly the IDs for each link we have, but the jump-lists worked only for Writer. We examined then the different shortcuts in a stock Windows 7 installation and we realized that all the links where the jump-list worked either had the jump-list created by custom actions inside the application or had non-advertised shortcuts. Nothing in the documentation was indicating that, but once we switched to the non-advertised shortcuts in our installation, we got the pinning and jump-lists working pretty well. For those whose mission critical features depend upon advertised shortcut, the behaviour can be restored to the previous default by a variable DISABLEADVTSHORTCUTS=0 when running msiexec from command-line. I am restarting the Voreppe tinderbox, so when it produces an upload starting now, it should have those changes. I tried it on Windows XP, Windows 7 and Windows 8 Enterprise and it looked pretty good.
Uninstalled and ran a command window msiexec.exe install using the "DISABLEADVTSHORTCUTS=0" value in addition to a "WRITE_REGISTRY=1" for prior build Version: 4.1.1.0.0+ Build ID: b407b33e3e00a54796abc3307dc7f123ce958e7 TinderBox: Win-x86_9-Voreppe, Branch:libreoffice-4-1, Time: 2013-07-26_22:16:17 Have to admit, I'm confused in that I've run with the additional command line value DISABLEADVTSHORTCUTS set "0", or false--enabling advertised shortcuts. But now Windows 7 "jump lists" are fully populating--Start menu "right triangle" list, and Task bar "Recent" items--Calc, Writer, Impress, Draw all consistent. While the LibreOfficeDev shortcut receives no jump list "recent" items, what I'd expect if the individual launchers are in effect. But looking at https://gerrit.libreoffice.org/#/c/5196/ for commit 124daa15861775c582164677377f9f7cbba54dc0 DISABLEADVTSHORTCUTS is going to be set true, "1" for the build--disabling advertised shortcuts. Not to be difficult, but what is happening now that I've set it false? Does the false value somehow touch the Windows shell handling of the LibreOffice shortcuts? Is what I'm seeing just "default" jump list behavior that should have been present all along? Or, is setting it false a better way to make the UI consistent--leaving all advertised shortcuts untouched?
(In reply to comment #78) > Not to be difficult, but what is happening now that I've set it false? Does > the false value somehow touch the Windows shell handling of the LibreOffice > shortcuts? Is what I'm seeing just "default" jump list behavior that should > have been present all along? Or, is setting it false a better way to make > the UI consistent--leaving all advertised shortcuts untouched? The problem we saw is that your outcome can happen but it is not consistent. The problem might be that the advertised shortcuts can be installed before the feature is, whereas the non-advertised cannot. I was always getting the jump-lists populated for writer but never for anything else in my Windows 7 virtual machine, but I was getting the arrow on all of the pinned shortcuts. With the change to non-advertised, I get consistently pinnable shortcuts and jumplists for all components pinned to the start menu.
Stuart, according to the documentation, this non-advertised links hack should not be necessary and I don't need it in Windows 8 in order to pin for instance Calc to taskbar without having to run it beforehand. Nevertheless, only with them not being advertised, I achieved consistent behaviour in Windows 7. Windows XP works its own way and I did not see any regression. We actually came with this solution by mimicking a stock windows applications like Internet Explorer. It might be that this variable defined is enough for that to be consistent. But, if the non-advertised state does not bother anybody, I would just leave it enabled, since it gave me consistent results. OTOH, opinions are welcome.
I found several little problems. For example, Base documents are not added to recent documents (Base uses an alternative code path for this?) Also xlsx documents are not added to Calc.
(In reply to comment #81) > > Also xlsx documents are not added to Calc. On Windows 7, it seems that none of the Microsoft Formats -- xls/xlsx or doc/docx that do have system file associations to open with a LibreOffice component are associating with the corresponding LibreOffice Jump lists. Documents do show in the Start menu --> Recent Items list, and will associate with a jump list for a pinned MS Office 2007 component. But not with the expected LibreOffice component where associated. In other words, at this point the LibreOffice jump lists seem to only pick up the ODF documents. So while related, really is a different aspect of recent documents to now have to resolve. So, keep with this issue, or move to a fresh one?
(In reply to comment #81) > For example, Base documents are not added to recent documents (Base uses an > alternative code path for this?) I opened a new Base document and saved it. It did not show up initially on the Start Menu --> Recent Items list, or as a jump list for a Start Menu pined Base shortcut. But then I launched it from its directory in Windows Explorer, the .odb file showed in the Start Menu --> Recent Items list, as well as populating the Jump list for Base pined to Start Menu. And, when I then pinned the launcher to the Task bar, the .odb file showed in the "Recent" jump list. So WFM, but not sure why the hickup on initial .ODB file creation.
I would just like to note that shortcuts in start menu worked fine in windows 7 as it was in 3.5.x version. Somebody should maybe make it as it was?
I know my idea may not bee achievable, but I am just trying to help.
(In reply to comment #83) > (In reply to comment #81) > > For example, Base documents are not added to recent documents (Base uses an > > alternative code path for this?) > > I opened a new Base document and saved it. It did not show up initially on > the Start Menu --> Recent Items list, or as a jump list for a Start Menu > pined Base shortcut. > > But then I launched it from its directory in Windows Explorer, the .odb file > showed in the Start Menu --> Recent Items list, as well as populating the > Jump list for Base pined to Start Menu. And, when I then pinned the launcher > to the Task bar, the .odb file showed in the "Recent" jump list. > > So WFM, but not sure why the hickup on initial .ODB file creation. Yes, because the values in the registry are good and Windows reads them to associate the documents with the recent documents list. LibreOffice is not really involved (if you understand what i mean) when you click in a document. I saw the installer doesn't really honor DISABLEADVTSHORCUTS and always does it whatever you say 0 or 1.
(In reply to comment #84) > I would just like to note that shortcuts in start menu worked fine in > windows 7 as it was in 3.5.x version. Somebody should maybe make it as it > was? The problem is that there are many things related to this. For example, the changes we did allow us to have different windows for the applications in the taskbar, pin the applications in Windows 8, etc. If we revert everything we need to restore the old behavior is going to be a big step backwards. That's why we are trying to fix it instead of just reverting.
Grabbed yesterdays TB-9 Voreppe build of 4.1.1 Version: 4.1.1.0.0+ Build ID: dcb4053a43fc71841abcb25ebde90555c36f2bf TinderBox: Win-x86_9-Voreppe, Branch:libreoffice-4-1, Time: 2013-07-27_22:35:54 Installed on another Windows 7 sp1 64-bit system--from msiexec.exe command line, run as administrator with WRITE_REGISTRY=1, and DISABLEADVTSHORCUTS=0 Again, I am getting consistent Jump List behavior for the ODF formats. But as earlier, other formats MSO doc/docx, xls/xlxs and also including CSV show in the Windows shell Start Menu --> Recent Items, but do not get picked up in the Jump List for the Libre Office components. This system has MS Office 2013, and Apache Open Office 4.0.0--but the file association for the document formats had all been set to open with LibreOffice. So for some reason, they are not being associated to the LibreOffice component, nor showing in the corresponding Jump List where they had been opened. (In reply to comment #80) > We actually came with this solution by mimicking a stock windows > applications like Internet Explorer. It might be that this variable defined > is enough for that to be consistent. ... Other than not handling the non-ODF formats, the Jump Lists do seem to be behaving simply with establishment of the DISABLEADVTSHORCUTS variable, set false. I'll try another round of install while waiting for the current build of TB-9 to finish, but this time I'll set the DISABLEADVTSHORCUTS=1 and see that has any impact. >... But, if the non-advertised state does > not bother anybody, I would just leave it enabled, since it gave me > consistent results. Only question I'd have is if the DISABLEADVTSHORTCUTS setting would affect any applications other than LibreOffice?
So loaded the TB-6 debug version on Windows 7 sp1, 64-bit from a command window with WRITE_REGISTRY=1 Version: 4.1.1.0.0+ Build ID: 2f9c340b4f8f54872eb97880d03c802a1620a1b that included the https://gerrit.libreoffice.org/5196 patch setting the MSI installer variable DISABLEADVTSHORTCUTS true. All Start Menu jump lists (right triangles) and Task bar "Recent" items are all functioning correctly. Expect to have similar results with a TB-6 debug build of master. Will also test it on Windows 8. As well as will check inpact with DISABLEADVTSHORTCUTS set false from a command windows msiexec install. For now though, looking to be truly fixed.
(In reply to comment #89) > Will also test it on Windows 8. As well as will check inpact with > DISABLEADVTSHORTCUTS set false from a command windows msiexec install. > Working correctly on Windows 8. Also, have consistent behavior if the DISABLEADVTSHORTCUTS MSI variable set False, or when leaving it the now default True. So just setting it during install seams to have corrected things. I was unable to force MSO formats (doc/docx, xls/xlsx, ppt/pptx) onto the LO Jump lists, even when no MS Office product is installed. Another issue?
I will try to fix the issue this weekend. There's no need to open a new bug for now. Cheers!
Jesús, tested on Windows 7 sp1, x64 with today's 2013-08-19_06.06.16 TB-39 build Version: 4.2.0.0.alpha0+ Build ID: 9a1aca007fd06f3f8223ee02a79e44099d778b51 JumpList handling of ODF documents again seems correct with revert of regression causing patch of bug 68202. But, still not seeing .XLS/.XLSX or .DOC/.DOCX file association with JumpLists. These and other ODF documents show in LO Save to File --> Recent documents menu, as well as to the Windows 7 Start Menu --> Recent Items lists. Was it expected to be correct, or does our LO JumpList handling these non-ODF document types need additional work? Looks like CR https://gerrit.libreoffice.org/5274 commit was just part of the needed adjustments?
(In reply to comment #92) > > Was it expected to be correct, or does our LO JumpList handling these > non-ODF document types need additional work? Looks like CR > https://gerrit.libreoffice.org/5274 commit was just part of the needed > adjustments? This bug is the never ending nightmare. The values are correct in the MSI but they are never written in the registry, that's why it doesn't work. I'll take a look but it should be something very stupid (and more than probably my fault).
Jesús, Sorry, I know you've been hard after this and other aspects of the Windows builds, it's great we've gotten this far! And, should anyone be following along--you have to install the TB builds of Master as an administrator and issue a WRITE_REGISTRY=1 value from a command window msiexec.exe /i install.
Missed this on my QA to do list, but Jesús's last commits Aug 20th and 22nd, https://gerrit.libreoffice.org/#/c/5529/ https://gerrit.libreoffice.org/#/c/5587/ have got this all functioning correctly on master. Version: 4.2.0.0.alpha0+ Build ID: 5b74c6563cfc802b5330fb82500be9d6cd835fe2 TinderBox: Win-x86@39, Branch:master, Time: 2013-09-09_18:53:01
*** Bug 69927 has been marked as a duplicate of this bug. ***