After upgrading to 4.4.2.2 the behavior of Insert Hyperlink changed wrong. I select a text (i.e. a word) and I click Insert Hyperlink (Ctrl-K). A window appears. A) The window shows always "Internet" as default instead of "Document". "Document" had always showed as default (I always use it) until last 4.4.2.2 upgrade. B) the selected text (i.e. a word) is not copied in the form "Further Settings" "Text" when I change from "Internet" to "Document". to bypass A+B I need too much multiple clicks. could you please let me go back to the previous behavior? ... Then I also have a suggestion to make it even better: C) from the "Hyperlink" window under "Document" I add a "Target" to the form "Target in Document" by clicking on the bullseye. A window appears (always on the right, it was ok on the left) with all the objects (i use Bookmarks). **Here I suggest** to let a single click add the bookmark in the "Target in Document" form as "Target" (instead of double-clicking or clicking "Apply"), then clicking "OK" (instead of "Apply") closes the window; then, if we have solved A+B above, in the form "Further Settings" "Text" there already is the selected text (i.e. a word), so I only have to click "OK" to close the "Hyperlink" window with changes applied. very quick and neat. I recommend it. Thank you very much.
Your B) is a duplicate of bug 86845. I'm changing this to be about A) and propose that the dialog should remember the last used view. Please create a separate enhancement request for C) Tested on: Win 7 Pro 64-bit, Version: 4.4.2.2 Build ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6 Locale: fi_FI Version: 4.5.0.0.alpha0+ Build ID: afb82d3729bda2754d0add08cc6c4dce1dc76d59 TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2015-04-14_00:05:04 Locale: en_US
Migrating Whiteboard tags to Keywords: (needsDevEval) [NinjaEdit]
*** Bug 100557 has been marked as a duplicate of this bug. ***
*** Bug 125246 has been marked as a duplicate of this bug. ***
Question was raised again in bug 125246. If we store the last UI position it would also apply to other dialogs like paragraph style. Do we want to remember the last tab, and if so a) per document, b) session, c) workplace respectively user configuration.
(In reply to Heiko Tietze from comment #5) > Question was raised again in bug 125246. If we store the last UI position it > would also apply to other dialogs like paragraph style. Do we want to > remember the last tab, and if so a) per document, b) session, c) workplace > respectively user configuration. In some (many?) cases, the TAB of a dialog is remembered between use.
The default choice (at the beginning of a session) 'Internet' is arbitrary. After the user has chosen 'Document', it can be expected that he will choose it again during the session —in the same document, or across several of them; he can change his choice, anyway.
I prefer user configuration. What's the benefit of only session?
(In reply to Thomas Lendo from comment #8) > I prefer user configuration. What's the benefit of only session? OK. How does the user specify his/her preference?
(In reply to TorrAB from comment #9) > OK. How does the user specify his/her preference? It would be stored silently in the registry and applied when ever you open the dialog again. Per session means the default tab is reset when you restart the application. And per document is self-explaining.
Benefit of the session only solution is that different scenarios require different workflows and therefore it makes sense to start with a default. But the general rule as requested in the meta bug 109265 makes also sense. So let's remember the last used tab position and restore it at the next session.
*** Bug 136263 has been marked as a duplicate of this bug. ***
*** Bug 136264 has been marked as a duplicate of this bug. ***
I also support the dialog opening at the last user view.
Relatd to this issue: The default window size for the dialog is usually too narrow to see the heading titles. And even if you adjust the document window to make it large enough to SEE the titles … the size resets to default the next time you open it!
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a9cea0ddeb5cd51db0720f96af75af75120908d9 tdf#90496 - Remember last used view in hyperlink dialog It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Andreas, thanks for fixing this one. Verified. Solved in Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a1acc2f46cc499631d66b1d7a923ed15ab4f28de CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded Is not ok in Version: 7.5.2.1 (X86_64) / LibreOffice Community Build ID: e8bf3b441b8370f8440b0339fd9490765a8d57ca CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
Andreas Heinisch committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ebfd2f10b400ad215ccd2263267f48a79b1427ef tdf#90496 - Remember last used view in hyperlink dialog It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I changed it from user configuration to session.
I verified again, is per session now. After closing LO and opening again is the default. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d4ec4b875b952b05b8b1e0ba73dc31c1bcd27e43 CPU threads: 16; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
*** Bug 129557 has been marked as a duplicate of this bug. ***
*** Bug 155859 has been marked as a duplicate of this bug. ***