Community
Participate
Working Groups
build i820. I opened the Help Contents and did a search. In the search results the search terms are high-lighted. But if there are a lot of matches, I would like to turn off this high-lighting to make the relavent documents easier to read.
Yes, this is a good idea. For the time being, you can synchronize with the table of contents, and, assuming the topic exists in the tree, click on it. This will reload the document without the highlighting.
I think highlighting should be turned off by means of some button, not a preference settings. It is not a good idea to put the button in the toolbar on the right, since the button should appear only when document displayed is from search results. I think it might be enough to add a button to search view toolbar (a toolbar on the left, only when search tab is active). The button would control whether clicking on search results displays documents with highlighted keywords or not, and would not affect the document that is already displayed.
*** Bug 48813 has been marked as a duplicate of this bug. ***
I agree that this should be a button, not a preference, but I think it would be better if you could turn off the highlighting after a search has been performed. Whether you want the highlighting on or off will depend very much on the page, and you'll only know after you've seen it. Or I guess there could be a threshold density of highlights above which they are automatically turned off -- or they could be gradually lighter and less obtrusive the denser they are (such that the total color density they contribute to the page remains constant :-)
IMHO, in this case, the simpler, the better. An on/off button seems to fit the bill.
Well, I admit that my proposal of constant color contribution was a bit fanciful :-) My main point was that the on/off button should apply to the search results after they've been obtained; otherwise I think one would often end up toggling the button and then redoing the search.
Another thing related to the search highlighting currently is that if I do a search and the topic has the highlighting and then I print the topic, all of the highlighting gets printed as well. This means that all of the terms that I searched on are printed as black blocks. :-/
If possible, can you consider doing this in two phases: 1. Ability for the user to specify "No search highlighting" in Search window before initiating a search. Have a string in the banner reflect "Search highlighting off" (like it reflects the scoped search today). 2. Ability for the user to turn off the search highlighting after doing a search and loading the page, to turn off the black highlighting in the result page. Phase 2 would require reload of the page, so as a first step, it would be easier to do Phase 1 first. Thanks for the consideration, --Lee Anne
*** Bug 103210 has been marked as a duplicate of this bug. ***
I would like to express interest in seeing this feature added so we can benefit from this in our RCP product.
I would like to see this as well, but unfortunately this week is milestone week for M6 which is feature freeze, so unless someone can supply me a good patch today we will have to defer until next release.
Created attachment 37273 [details] highlight switch code patch
Created attachment 37274 [details] highlight switch button icon This icon should be put in dirctory: <<eclipse_home>>\plugins\org.eclipse.help.webapp\advanced\images
I tested the patch (thanks Jiang) but I ran into a few problems while doing so: - By default I could not get the button to ever show up, even though cookies are enabled. I'm not sure exactly where it's failing, but it's either in UrlUtil.isHighlight() or in the cookie check. I was able to get it to show up by commenting out those parts in contentToolbar.jsp. - The content pane seems to refresh completely when turning on/off the highlighting, so there's some flashing and worse the page scrolls to the top of the document, so you lose your frame of reference. I'm not an expert in javascript, do you know if it's possible to do this without the flashing and scrolling?
Thank you for testing the patch. 1, The patch works weel in my laptop, I have no idea about why the button could not show up even you cookies are enabled. The cookie checking is required, if no checking, when you disabled your browser cookie, you still could see the button with no clicking effect. That's strange for user. 2, Because the highlight code is trigered by onload() handler of whole page, So it's impossible to do this without the flashing. For the scrolling, If you could use a parameter to store the current user browsing position. After the switch on/off, the page should be able to sroll to the original position user are borwsing. But I don't think it's a good Idea because we have another "automatically scroll to the first occurrence" function when user clicks the search results.
Hi Jiang, I did a little research and it does seem possible to do this without refreshing. There are several approaches I can see: 1. Write javascript that goes through the DOM and highlights certain words, for example see http://www.nsftools.com/misc/SearchAndHighlight.htm 2. Switch the entire CSS on the fly, without sending a new request and reloading. This example shows switching page themes and does it without losing it's place on the page: http://www.dynamicdrive.com/dynamicindex9/stylesheetswitcher.htm 3. My preferred approach would be to target a specific (known) CSS rule and change it on the fly using javascript. So where the highlighting is added, it should do it via CSS using a span and a specific class. Then to turn it on and off, just toggle the CSS rule (i.e. change background color) back and forth. No markup changes or reloading needed. See: http://www.javascriptkit.com/domref/style.shtml Do you think #3 is doable?
Actually, #1 is using the same mechanism as the highlight method of current highlight.js I've tried #3, it really works well ! And I have following concerns for #3: 1, We'll inject a CSS style to the result page in HighlightFilter.java. And because the CSS style reference is gotten from "document.styleSheets[0].rules[0].style", We must inject the CSS as the first style occured in the result page. 2, The style name could not overlap with the css name what have been existed in result page. Or there must be some weird diplay effect.
They are both valid concerns. For #1 this may cause problems if someone uses javascript to do the same thing in their documents, and makes assumptions about the index. If we inject our own CSS with a single known rule, we could iterate through the stylesheets until we see one with only one rule that has our name (if this is possible, I don't know if it is). As for the name, we could use something long like org_eclipse_help_webapp_highlight to avoid conflicts.
Adam, see if we can do approach 3 I mentioned in comment 16. Ideally it should not have to refresh the document in order to toggle the highlighting, we should only toggle a CSS rule and the browser will do the actual work.
Created attachment 47240 [details] Only works in IE and Firefox The feature is implemented in the full help system only. There is currently no support in the help view. A button has been added to the ContentToolbar. It is hidden and shown dynamically based on whether or not the current document is a search result or not. The state of the button is persisted as a cookie. Thus it is browser specific and will persist across multiple workspaces. This has only been tested in IE and Firefox. The implementation of the actual highlighting was achieved by using classes on the spans instead of directly using style attributes when highlighting initially. When the highlight option is toggled, the CSS class is dynamically updated (removing or re-adding the highlight style information). This, in turn, affects all spans using the class without refreshing the page. Plans from here include adding support for Safari and adding the functionality to the help view. Ideally I would also like to stop using cookies in the full help system when it is running from the workbench (i.e. only use cookies when running as an infocenter). The button's persistent state should match the state of the, to be added, help view button if we are in workbench mode.
Wouldn't we still need cookies for the standalone help mode? I have a lot of teams using that (not full workbench, but also not strictly "infocenter" mode). --Lee Anne
Created attachment 47301 [details] Fully Functional - Untested Works in IE, Firefox and Safari and is supported in both the help window and the help view. Currently the toolbar button is not hidden for "non-search-result" documents in the help view. It is disabled instead. To address the concern made by Lee Anne, the help window is currently using cookies to persist the button state regardless of the mode. This means that the help window button maintains a seperate state than the help view button. In the future I may still look into sharing the button state with the view when in workbench mode (i.e. not in infocenter or standalone mode). Thanks for your input Lee Anne.
Created attachment 47302 [details] Icons for the patch The zip file contains the icons for the patch. The paths they need to be placed in are included in the archive.
Patch submitted. A few minor changes: - Set default enablement for view highlight button to on for consistency with help window and previous behavior. - Renamed help window button's tooltip to match view's ("Highlight search terms").
*** Bug 179357 has been marked as a duplicate of this bug. ***
Verified in I20070608-1718.
