Community
Participate
Working Groups
I20080219-1124 We can add an action in the toolbar or a link in the hover to open the properties file and go to the key. Same action as Ctrl-Alt-Click. But Ctrl-Alt-Click is not easy to discover. With the new AbstractInformationControl this should be almost trivial to implement.
>Same action as Ctrl-Alt-Click. But Ctrl-Alt-Click is not easy to discover. This is better now.
Created attachment 127302 [details] Added the toolbar and "open in properties file" action for NLS hover.
Comment on attachment 127302 [details] Added the toolbar and "open in properties file" action for NLS hover. Copying large code sections always leads to maintenance problems. You should not copy NLSKeyHyperlink.open(), but extract the reusable parts and call them from both NLSKeyHyperlink and NLSStringHover. In this case, I would extract the common code into a public OpenPropertiesFileAction. The static fields in NLSStringHover are clearly a no-go. The right way to transfer the necessary information to the hover is via ITextHoverExtension2#getHoverInfo2(..). NLSStringHover should implement this extension interface. To fulfill the Javadoc of getHoverInfo2(..), you have to extend DefaultInformationControl, implement IInformationControlExtension2, and create a container class that holds the hover text and the additional information (similar to BrowserInformationControlInput). In OpenPropertiesFileAction, you should not write exceptions into the log when they are to be expected in simple scenarios (e.g. remove the properties file and then show the hover and click the button): try { editor= EditorUtility.openInEditor(propertiesFile, true); } catch (PartInitException e) { JavaPlugin.log(e); return; } Should behave like the hyperlink in the same situation (show the message in the status line). I think you should even try to avoid getting into these situations: Simply don't create the toolbar when the property or the properties file is not available. You already know this when you calculate the hover text. A little style problem in NLSStringHover.propertiesFile: Javadoc main comments should be full sentences (ending with '.'), see http://java.sun.com/j2se/javadoc/writingdoccomments/index.html
Created attachment 128087 [details] Patch with review changes.
Moving to M7 as this is a new feature that needs test pass coverage.
Created attachment 128760 [details] Patch 3 Released this version, with the following changes: * NLSKeyHyperlink: - It's quite an overkill to create a new NLSHoverControl just to pass it to the OpenPropertiesFileAction and then not even use it. Even if you had to create an NLSHoverControl you would also need to dispose it eventually. - I made calculateRegionInPropertiesFile(..) static and moved it back to NLSKeyHyperlink to make the patch significantly smaller and to preserve the history of that code. The method not only calculates a region but also opens the file. Renamed to openKeyInPropertiesFile(..) to avoid confusion due to the wrong name. - I don't see why showErrorInStatusLine(..) should be public. Made private again. - When you write Javadoc for an @param or @return tag, always mention when the value can be null (fixed for propertiesFile in openKeyInPropertiesFile(..)) - NLSStringHover.getHoverInfo(..) is deprecated, but it should nevertheless do something that works. Casting an NLSHoverControlInput to String always fails. - removed unused constructor of NLSHoverControl - made NLSHoverControl.setInput(..) only accept NLSHoverControlInput and documented this - improved naming and Javadoc of parameters in constructor of NLSHoverControlInput * NLS - fixed typo in NLSStringHover_open_in_properites_file=Open in properties file and made message title case (it's a tooltip text)
.
Verified in I20090428-0100.
