https://bugs.documentfoundation.org/show_bug.cgi?id=87686
--- Comment #12 from MartinPC <PeterCraigMartin+LO@Gmail.com> ---
I did a parallel install of
master~2016-08-13_09.30.32_LibreOfficeDev_5.3.0.0.alpha0_Win_x64_en-US_de_ar_ja_ru_qtz
in Windows 7. (I got fatal errors trying to load it with a copy of the profile
I use for my "fresh" LibreOffice 4 and 5 installs, as well as with a new blank
profile, so I had to work with UserInstallation=$ORIGIN/.. in the bootstrap.ini
file. I rely on my macros and toolbar customizations quite heavily, so I won't
be doing very much testing with this build, given that I can't use a copy of my
profile.)
The GREAT NEWS: The fix appears to work as advertised and is a DRAMATIC
improvement over the previous behavior. Thank you, Caolán. (I *believe* this is
the second time someone from Red Hat has fixed a bug I reported, and I won't
forget it or keep it to myself.)
The inevitable CAVEAT: If you leave the Insert Index Entry dialog box up, open
the Edit Index Entry dialog box, go back to edit a previous index entry -- and
don't necessarily even commit the edit; just opening an entry in the edit
dialog seems to suffice -- then close the Edit Index Entry dialog box,
highlight a new selection in the document, and click on the "Update entry from
selection" button, the contents of the Insert Index Entry dialog box's 1st and
2nd Key fields change to something different from the last entry you inserted
or edited. (I haven't identified a clear pattern for how they populate yet.) I
suppose this is a separate bug, one that I had already noticed before the
instant bug was fixed.
OBITER DICTA: As I believe I mentioned earlier in this thread, I'm not an
experienced indexer and I haven't used other indexing systems. Accordingly, I
can't say whether there are any compelling "workflow" arguments for having one
dialog for inserting new index entries and a separate dialog for navigating
between and editing or deleting them. However, although I'm also not a coder,
I'd speculate that if inserting, navigating, editing, and deleting were all
handled by a single indexing dialog, the coding might be more straightforward
and less susceptible to untoward interactions like the one mentioned in my
caveat. But I honestly don't know if it's a good idea on balance. An
experienced professional indexer would have to weigh in.
CONCLUSION: If you think it's advisable, I'll file a separate bug report for
the edit/insert interaction, but In the meantime, I'm thrilled and grateful for
your fix and look forward to a fresh release that incorporates it. Thanks
again, and all the best.
--
You are receiving this mail because:
You are on the CC list for the bug.
Context
- [Libreoffice-ux-advise] [Bug 87686] UI: Unwanted Entry and Key field repopulation behavior in Insert Index Entry dialog box when it loses and regains focus. · bugzilla-daemon
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.