Bugzilla – Full Text Bug Listing
| Summary: | [navigation] NLSKeyHyperlink to reveal/goto the key in the properties file editor | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Michael Seele <mseele> | ||||||||||||
| Component: | Text | Assignee: | JDT-Text-Inbox <jdt-text-inbox> | ||||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||||
| Severity: | normal | ||||||||||||||
| Priority: | P5 | CC: | cw.florian.albrecht, daniel_megert, markus.kell.r | ||||||||||||
| Version: | 3.1 | Keywords: | helpwanted | ||||||||||||
| Target Milestone: | 3.5 RC1 | Flags: | markus.kell.r:
review+
|
||||||||||||
| Hardware: | PC | ||||||||||||||
| OS: | All | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Michael Seele
There are two thing involved: - detecting the key in the Java editor - navigating to it Can you provide an example of how the key in the Java editor looks like for Jinto and an example of the properties file. See also: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-text-home/development/bug-incomplete.htm Jinto is a plugin for java internationalization(www.guh-software.de/jinto_en.html) an it's properties editor is a big table which displays a column for all keys and several columns for every language. It's ok that you are detecting the key in the java editor and open the referenced editor for it. but the navigating to the key in the referenced editor should be done over a dynamic interface like IAdaptable that i can implement something into Jinto to step to the matching row in the Jinto editor! I need the key that i know where i must step to. It opens whatever editor the user has defined to open the Java properties file. I guess your editor does not implement ITextEditor? In that case it will not jump to the right location. This can be changed on our side by: 1. getting the document from the file buffer 2. search the key(s) ==> offset, length 3. use EditorUtility.reveal which will use IGotoMarker or if not implemented, sends a selection changed event to the editor yes, i don't implement ITextEditor. but i don't understand you description how i can do it without implementing ITextEditor! 1) i don't know in which document the user has been clicked on a key 2) i don't know when the user has been clicked on a key 3) the EditorUtility class is a internal class which i dosn't use can you describe more detailed what you mean!? where's the problem to implement the "hard coded" code as it should be(dynamic for every editor)? You're right, please read comment 3 again ;-) I wrote: "This can be changed on our side by:..." i.e. *we* have to change our code so that your scenario works. On your side to support the scenario better you can (if you don't do already) implement IGotoMarker or offer an adapter: public Object getAdapter(Class adapter) { if (IGotoMarker.class.equals(adapter)) return fGotoMarkerAdapter; ... } If you don't your editor will get a selection changed event. ah, i see! your seuggestion will be only an workaround until you've changed the code. sorry for my wrong reply! >your seuggestion will be only an workaround
Nope. There's nothing you can do for now except wait.
However, the IGotoMarker tip is a good one anyway since this supports scenarios
where others call IDE.gotoMarker(yourEditor, marker).
do you have any plan's for this bug? No plans to work on this. We have the same problem: A custom .properties editor which is not text based. Ctrl+Click works (opens the editor), but does not mark the key as the editor does not implement ITextEditor. The suggested solution above would be great and does not seem to be that hard to implement. Do you have an idea when this bug will be fixed? >Do you have an idea when this bug will be fixed?
When we get a good quality patch.
Created attachment 134625 [details]
Patch for using IFindReplaceTarget for non Text Editors
Well, you could do it this way: Using IFindReplaceTarget and IFindReplaceTargetExtension3 to find the key in the editor. The editor would be responsible for providing this extension and has to map a match in the .properties file to its UI. With this patch, it works for us.
Comment on attachment 134625 [details] Patch for using IFindReplaceTarget for non Text Editors The patch introduces a requirement i.e. to have a find replace adapter being present. The fix needs to be crafted along comment 3. Created attachment 134755 [details]
New patch using FileBuffers
OK, now I got the point with the file buffers... I think it could work this way (for us, it does).
Comment on attachment 134755 [details]
New patch using FileBuffers
Copy / Paste bug, do not use!
Created attachment 134757 [details]
Replaces the last patch - copied wrong patch
Sorry, copied a wrong patch. This one should do it.
I cannot apply the patch (too many conflicts). Please make sure to make the patch against HEAD and select 'Workspace' as patch root (second page of patch wizard). Created attachment 134766 [details]
Patch against HEAD and Workspace
Thanks for the patch Florian. It's almost good. Two issues: 1) please don't remove the code that uses PropertyKeyHyperlinkDetector to check the key. Leaving it in shouldn't hurt your sceario. 2) please add your credentials to the copyright notice of each file in the following form: name <e-mail> - bugzilla summary - bugzilla URL e.g. Dani Megert <dani@eclipse.org> - this is a bug - https://bugs.eclipse.org... Created attachment 134937 [details]
Patch including HyperlinkDetector again
I hope the copyright notice is OK... Haven't done this before ;-)
Committed the patch to head and then made some minor modifications: 1. make sure we connect and disconnect the file buffer 2. use document provider if it is a text editor 3. use adapter to get the IFile (is more generic) 4. refactored the code Looks good. Filed bug 275447 for API improvement in IFileBufferManager. Verified in I20090514-2000. |