Bug 35785 - LibreOffice's support of the "recent documents" feature of the Windows 7 Start menu broken
Summary: LibreOffice's support of the "recent documents" feature of the Windows 7 Star...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.3.2 release
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: Jesus Corrius
URL:
Whiteboard: target:4.1.1 target:4.2.0
Keywords:
: 45600 56125 57482 64012 64167 64340 64369 69927 (view as bug list)
Depends on:
Blocks: mab3.6
  Show dependency treegraph
 
Reported: 2011-03-30 00:14 UTC by Jean
Modified: 2018-03-29 14:18 UTC (History)
19 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of the start menu (55.39 KB, image/jpeg)
2011-03-30 00:14 UTC, Jean
Details
picture windows start menu (48.28 KB, image/png)
2012-04-15 15:07 UTC, Cor Nouws
Details
3.5.7.2 build verbose install log (1.03 MB, application/x-7z-compressed)
2013-04-06 03:52 UTC, V Stuart Foote
Details
3.6.0.0beta1 build verbose install log (1.10 MB, application/x-7z-compressed)
2013-04-06 03:56 UTC, V Stuart Foote
Details
screenshot of LibreOffice Start Menu w/o Jump list capabilities (33.13 KB, image/png)
2013-05-06 18:42 UTC, V Stuart Foote
Details
Zip'd msiexec installer verbose log of LODev 4.1.1.0+ with 2013-07-20 recent documents commit applied (2.15 MB, application/zip)
2013-07-24 16:58 UTC, V Stuart Foote
Details
Zip'd msiexec installer verbose log of LODev 4.1.1.0+ with 2013-07-20 recent documents commit applied (2.15 MB, application/zip)
2013-07-24 17:01 UTC, V Stuart Foote
Details
Zip'd msiexe installvervose log LODev 4.1.1.0+ of 203-07-26 TB-9 (2.08 MB, application/zip)
2013-07-28 13:03 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jean 2011-03-30 00:14:07 UTC
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).
Comment 1 Cor Nouws 2011-08-17 00:18:19 UTC
.
Comment 2 Cor Nouws 2011-11-27 12:58:02 UTC
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..?
Comment 3 Björn Michaelsen 2011-12-23 11:50:38 UTC Comment hidden (obsolete)
Comment 4 Rainer Bielefeld Retired 2012-04-01 02:30:27 UTC
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)!
Comment 5 Cor Nouws 2012-04-15 15:06:51 UTC
Hi Rainer,
this is about recent document in the Windows Start menu. See picture attached
Comment 6 Cor Nouws 2012-04-15 15:07:28 UTC
Created attachment 60033 [details]
picture windows start menu
Comment 7 Roman Eisele 2012-05-15 00:22:54 UTC
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).
Comment 8 landwirt 2012-11-25 09:03:45 UTC
Why enhancement request? It was there and now it's broken!?! That's why bug 56125 seems to be exist.
Comment 9 Peter Lehmkuhle 2013-02-05 20:45:19 UTC
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?
Comment 10 Jorendc 2013-02-06 20:26:48 UTC
*** Bug 56125 has been marked as a duplicate of this bug. ***
Comment 11 Peter Lehmkuhle 2013-02-08 04:51:13 UTC
I guess the importance needs to be changed from "enhancement" to "normal".
Comment 12 Jesus Corrius 2013-02-08 09:28:09 UTC
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.
Comment 13 Peter Lehmkuhle 2013-02-08 19:31:48 UTC
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.
Comment 14 Claus Nielsen 2013-02-11 12:56:54 UTC
Jumplists used to work for me with version 3.something, but after upgrading to 4.0.0.3 I also have this problem.
Comment 15 horus 2013-02-25 17:22:42 UTC
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.
Comment 16 Julien Nabet 2013-04-03 20:24:09 UTC
(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
Comment 17 V Stuart Foote 2013-04-03 21:38:30 UTC
(In reply to comment #15)

This is probably the best source for older LibreOffice builds:

http://downloadarchive.documentfoundation.org/libreoffice/old/
Comment 18 Julien Nabet 2013-04-03 21:41:09 UTC
(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! :-)
Comment 19 V Stuart Foote 2013-04-03 23:29:50 UTC
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.
Comment 20 V Stuart Foote 2013-04-03 23:37:22 UTC
*** Bug 45600 has been marked as a duplicate of this bug. ***
Comment 21 Michael Meeks 2013-04-04 11:33:19 UTC
bug#45600 pre-dates this, has a better discussion with code pointers and was a 3.6 MAB - adjusting this to be one too.
Comment 22 horus 2013-04-04 17:44:34 UTC
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.
Comment 23 V Stuart Foote 2013-04-04 18:24:10 UTC
(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.
Comment 24 horus 2013-04-05 20:28:49 UTC
(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
Comment 25 horus 2013-04-05 20:32:51 UTC
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.
Comment 26 V Stuart Foote 2013-04-06 03:52:04 UTC
Created attachment 77507 [details]
3.5.7.2 build verbose install log
Comment 27 V Stuart Foote 2013-04-06 03:53:08 UTC
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.
Comment 28 V Stuart Foote 2013-04-06 03:56:16 UTC
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.
Comment 29 V Stuart Foote 2013-04-06 05:16:55 UTC
(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.
Comment 30 horus 2013-04-10 13:38:00 UTC
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.
Comment 31 V Stuart Foote 2013-04-10 15:13:38 UTC
(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
Comment 32 Jesus Corrius 2013-04-10 15:30:58 UTC
(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.
Comment 33 horus 2013-04-10 17:39:44 UTC
(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
Comment 34 V Stuart Foote 2013-04-11 00:22:56 UTC
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.
Comment 35 Don't use this account, use tml@iki.fi 2013-04-26 11:20:50 UTC
Jesús, if you think reverting 776db316d271d14e653426e21e66b983ec52100a "partially" is best, could you please do that then? Thanks.
Comment 36 Commit Notification 2013-04-26 12:46:25 UTC
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.
Comment 37 Samuel Mehrbrodt (CIB) 2013-04-27 23:09:30 UTC
*** Bug 57482 has been marked as a duplicate of this bug. ***
Comment 38 Urmas 2013-04-28 09:14:34 UTC
*** Bug 64012 has been marked as a duplicate of this bug. ***
Comment 39 Andrej 2013-04-28 21:15:18 UTC
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
Comment 40 Carlos da Terra 2013-04-28 23:28:43 UTC
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.
Comment 41 V Stuart Foote 2013-04-29 20:16:28 UTC
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?
Comment 42 Jesus Corrius 2013-04-29 20:34:08 UTC
(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?
Comment 43 Commit Notification 2013-04-30 10:37:25 UTC
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.
Comment 44 Commit Notification 2013-04-30 10:37:47 UTC
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.
Comment 45 V Stuart Foote 2013-04-30 14:55:33 UTC
@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
Comment 46 Adolfo Jayme 2013-05-03 18:27:14 UTC
*** Bug 64167 has been marked as a duplicate of this bug. ***
Comment 47 Michael Meeks 2013-05-06 16:53:49 UTC
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 :-)
Comment 48 V Stuart Foote 2013-05-06 17:27:11 UTC
@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.
Comment 49 horus 2013-05-06 17:45:46 UTC
(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?
Comment 50 V Stuart Foote 2013-05-06 18:42:54 UTC
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...
Comment 51 V Stuart Foote 2013-05-06 19:01:10 UTC
(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
Comment 52 Andras Timar 2013-05-06 19:09:51 UTC
@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.
Comment 53 V Stuart Foote 2013-05-06 20:51:34 UTC
(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?
Comment 54 Adolfo Jayme 2013-05-08 08:34:38 UTC
*** Bug 64340 has been marked as a duplicate of this bug. ***
Comment 55 Urmas 2013-05-09 00:17:45 UTC
*** Bug 64369 has been marked as a duplicate of this bug. ***
Comment 56 V Stuart Foote 2013-06-21 16:09:16 UTC
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?
Comment 57 Commit Notification 2013-07-20 21:08:30 UTC
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.
Comment 58 Jesus Corrius 2013-07-20 21:53:23 UTC
(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.
Comment 59 Andrej 2013-07-21 07:16:04 UTC
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.
Comment 60 Jesus Corrius 2013-07-21 08:37:14 UTC
(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.
Comment 61 Commit Notification 2013-07-22 11:02:57 UTC
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.
Comment 62 V Stuart Foote 2013-07-22 12:57:08 UTC
@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.
Comment 63 Jesus Corrius 2013-07-22 13:45:32 UTC
(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.
Comment 64 V Stuart Foote 2013-07-24 09:18:53 UTC
@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?
Comment 65 V Stuart Foote 2013-07-24 16:58:30 UTC
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.
Comment 66 V Stuart Foote 2013-07-24 17:01:49 UTC
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.
Comment 67 Commit Notification 2013-07-25 09:49:03 UTC
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.
Comment 68 Jesus Corrius 2013-07-25 15:44:54 UTC
This will be fixed in LibreOffice 4.1.1.

I am pretty confident the code works finally :)
Comment 69 Andrej 2013-07-25 18:15:26 UTC
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
Comment 70 ign_christian 2013-07-26 03:49:45 UTC
Great news...thanks Jesus. :-)

According to comment 69, so we can see that fix on 4.0.5?
Comment 71 Fridrich Strba 2013-07-26 06:50:44 UTC
(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.
Comment 72 Andrej 2013-07-26 09:39:29 UTC
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?
Comment 73 Jesus Corrius 2013-07-26 11:55:11 UTC
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.
Comment 74 V Stuart Foote 2013-07-26 16:16:12 UTC
@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 ;-)
Comment 75 Fridrich Strba 2013-07-26 17:49:24 UTC
(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.
Comment 76 V Stuart Foote 2013-07-28 13:03:09 UTC
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.
Comment 77 Fridrich Strba 2013-07-30 11:52:07 UTC
(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.
Comment 78 V Stuart Foote 2013-07-30 16:17:23 UTC
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?
Comment 79 Fridrich Strba 2013-07-30 16:54:07 UTC
(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.
Comment 80 Fridrich Strba 2013-07-30 16:59:27 UTC
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.
Comment 81 Jesus Corrius 2013-07-30 17:37:34 UTC
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.
Comment 82 V Stuart Foote 2013-07-30 17:59:25 UTC
(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?
Comment 83 V Stuart Foote 2013-07-30 18:14:28 UTC
(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.
Comment 84 Andrej 2013-07-30 20:24:34 UTC
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?
Comment 85 Andrej 2013-07-30 20:28:32 UTC
I know my idea may not bee achievable, but I am just trying to help.
Comment 86 Jesus Corrius 2013-07-30 20:54:56 UTC
(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.
Comment 87 Jesus Corrius 2013-07-30 20:58:31 UTC
(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.
Comment 88 V Stuart Foote 2013-07-30 22:35:03 UTC
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?
Comment 89 V Stuart Foote 2013-08-01 17:53:13 UTC
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.
Comment 90 V Stuart Foote 2013-08-02 02:15:06 UTC
(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?
Comment 91 Jesus Corrius 2013-08-02 10:54:14 UTC
I will try to fix the issue this weekend. There's no need to open a new bug for now.

Cheers!
Comment 92 V Stuart Foote 2013-08-19 18:21:18 UTC
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?
Comment 93 Jesus Corrius 2013-08-19 19:47:45 UTC
(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).
Comment 94 V Stuart Foote 2013-08-19 19:59:31 UTC
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.
Comment 95 V Stuart Foote 2013-09-18 04:00:05 UTC
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
Comment 96 Thomas van der Meulen 2013-09-29 15:13:21 UTC
*** Bug 69927 has been marked as a duplicate of this bug. ***