Description: In Writer, the Navigator should list hyperlinks in 3 separate groups: 1, those that point inside the current document; 2, those that point to other documents in the current file system; 3, those that point to the Internet. That would facilitate solving problems linked to corrupt paths, moved|missing documents, etc —group #2. Actual Results: All types of hyperlinks are mixed Expected Results: 3 types of hyperlink, pointing inside or outside the document, or to the Internet. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 4; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: en-CA (en_CA); UI: en-US Calc: CL threaded
Feature request is clear. Adding Jim Raykowski as expert for the navigator and design team for further input and decision. Personally I think, although there might be some advantages in documents with a lot of hyperlinks it might be a bit overengineered.
I agree that it could be useful to be able to tell the different kind, but I'm not sure how that can be done without getting too much in the way. And technically, there's 5 different kinds of links the dialog allows: - to the web - mailto link - part of current document - local file - new document Note that currently, the "Drawing objects" category doesn't even differentiate between a shape and a fontwork, and the "OLE objects" doesn't differentiate between and chart and a formula. Tagging for UX/UI team's opinion.
Some ideas: We could use underline to identify three variants: without, single, double. Would be hard to understand, has no room for more differentiation and clashes with the customization. Splitting the Hyperlinks section of the Navigator sounds wrong. But what I could imagine nice design-wise and effective is an icon next to the entry that indicates what type it is. What do you think, TAB?
We should take into account, that if we follow the suggestion, other user will ask, why we don't have differentiation for other elements (see comment 2). So we shouldn't go the first step, if we don't want to go further steps, too. And I still think this would be overengineered.
What is easy to realize, Jim?
It's not difficult to examine the url name and display an icon next to the hyperlink entry. Relevant link types I can think of are http, https, ftp, file, #(internal) and mailto. Code pointers: sw/source/uibase/utlui/content.cxx SwContentTree::InsertContent Get the url string by static casting pCnt to SwURLFieldContent* -> GetURL() then determine the url type by string comparison and set the tree entry image accordingly. The SwContentTree::InsertContent function is where an icon is set for linked image entries.
(In reply to Heiko Tietze from comment #3) > Some ideas: We could use underline to identify three variants: without, > single, double. Would be hard to understand, has no room for more > differentiation and clashes with the customization. So, not such a great idea. > Splitting the Hyperlinks section of the Navigator sounds wrong. I disagree. Or rather - I think both ways of arranging the links have merit - are useful in different scenarios. Perhaps we could have some toggle to switch between them? > I > could imagine nice design-wise and effective is an icon next to the entry > that indicates what type it is. Hmmm. Maybe. I don't know if I like the extra cluttering. Also, when I look at a link, I can tell what kind of destination it has by hovering over it. So will this be that useful?
We discussed the topic in the design meeting. We may add icons next to the hyperlink but the current tooltip seems to be informative enough. Is there any use case that makes the change - and potential cluttering - necessary?
hyperlinks that point to other documents in the current file system could be gathered in a text file that one could searched for moved and deleted files.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to TorrAB from comment #9) > hyperlinks that point to other documents in the current file system could be > gathered in a text file that one could searched for moved and deleted files. We have to balance the benefit of enhancements vs. implementation and maintenance effort and the negative impact of a cluttered UI. The existing hyperlink nodes in the Navigator show clearly where it points to. And from your reply "could be searched for" I anticipate not many users need such a feature. Of course, feel free to reopen with further details.