https://bugs.documentfoundation.org/show_bug.cgi?id=129167
--- Comment #18 from Roland Hughes <rol...@logikalsolutions.com> --- (In reply to Mike Kaganski from comment #17) > (In reply to Roland Hughes from comment #16) > Sigh. > > Now take a look at the LibreOffice code, where it restores the last > position, and learn that it is implemented (from the start) to store that > information in the ODT. Using a very simple logic, the request in this bug > 129167 is exactly "implement storing last position inside docx". > > And yes, since the format is a MS format, we can't just start extending it > randomly without any need, we should stick to what MS used to store sch a > position. > > > Here they show how little they try to think about different needs. They > think about working in teams on the same file (a reasonable use case, even > though there is a different solution exist for that case, like Collabora > Online, but still having something "local" for that might be still > reasonable); but they just don't even ask "what is the use case for that > feature that we declare short sighted", they simply go ahead and declare. > Well, of course, being able to pick up working on *my* document at the point > where I left, *regardless* of which device I use at this moment (and thus, > regardless of which user profile I use at this moment) has no value for > anyone, they perfectly know that. > > MS may abandon their approach of storing the last position using the > bookmark - because they simply move to the cloud, and the last position may > be restored wherever you open the document. But LibreOffice has no central > cloud. It is not intended to push users to cloud. And thus, the storing of > the last position in the document is perfectly reasonable for a large > portion of the user base, and that doesn't exclude a potential option for a > user to choose where to store that - *if* Roland Hughes decides to file > their feature request properly. Extreme sigh. Here we see the grand delusion that storing last position inside a document file wasn't a massive architectural flaw from the beginning. Then we try to champion a use case (the only use case that wasn't thrown under the bus by this implementation) to justify a short sighted architectural decision. Then we spin a yarn about MS and cloud being the reason they ceased using the same architectural flaw. MS stopped using almost instantaneously after writing into the spec saving last position inside a document file. It was a flawed architectural design. It had nothing to do with the cloud. It had to do with Netware file servers and later Linux and Microsoft file servers. Storing inside of the document was a "last one in wins" __solutions__ that failed in a world where more than C: existed for a computer. It failed spectacularly when multiple users accounts were set up on the same physical computer using a shared data drive/partition. Once MS has published a file spec it cannot really be "fixed." Generally large portions get deprecated and go unused. Generally all editing systems, not just word processors, but IDEs and even some graphics editors solve this problem in at least one of (sometimes 2+ of) the following ways. 1.) Extended Attributes We started using these back in the days of OS/2. They are supported by every major file system today though not always supported in the same way. When you use the OS level utilities to copy the file to another drive/partition the extended attributes are copied with it. You can have user.name EA. user.Fred.LastPosition:45;3456;98765956; Been a long time since I chatted with anyone working internally on such things at MS. I believe that is how they are doing it yet today. There is a size limit which might be why there are only 4 <Shift><F5> https://legalofficeguru.com/pick-up-where-you-left-off-in-microsoft-word-with-go-back/ https://en.wikipedia.org/wiki/Extended_file_attributes https://hexdocs.pm/xattr/Xattr.html https://www.admin-magazine.com/HPC/Articles/Extended-File-Attributes https://www.delftstack.com/howto/c/getxattr-example-in-c/ Extended attributes in user.name.LastPosition: format allow every application to know what the last position was for each user to ever touch the file. The EA solution is only a "last one in wins" solution if it is poorly implemented as: user.LastPosition:4567;34987;1;32767 where it would not identify the user. 2) Application level settings file Every major cross platform library has some form of "Settings" class that does the heavy lifting of communicating with the OS to create/read/store application settings. They are stored at the user level. You've all seen .config and .local directories in your home directory under Linux. Windows tends to jamb the stuff into Registry. During the days of DOS (which includes all versions of Windows prior to Windows NT because Windows was not an OS until NT) vendors kind of rolled their own. We only had one user though. Things were really rough in early Linux days. MS Word was released in 1983 on DOS. Your Go-Back book mark is most likely an artifact of this era. It had to be abandoned once file servers entered IT departments. 3) Hidden or visible history file Many were simply filename.hist Many times they were just one type of history so they were one line records like this: timestamp|user|numeric_value The timestamp was always in YYYYMMDD:HHmmss.cc format so sort order could be maintained. When they started getting complex they took on less efficient formats. keytag|timestamp|user|numeric_or_text_value This particular debacle morphed into extended attributes For whatever reason ODT pursued a Go-Back bookmark which creates many problems and was abandoned late in the days of DOS. When I said this was short sighted I was talking about the physical implementation. It through every other use case under the bus by using a bookmark instead of EA. With EA, every user's last N positions can be saved. The UI can then offer the option of using someone else's last position or the user's own. -- You are receiving this mail because: You are the assignee for the bug.
