This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
[NB35, trunk] When you supply a clipboard convertor (as described in the O'Reilly's book pp. 486-490) the convertors are applied within the running nb instance but not for the external cliboard. I have fixed it by modifying NbCliboard line 82 - instead of systemClipboard.setContents(contents, owner); it should read systemClipboard.setContents(convert(contents), owner); I have tested the change and it works ok for me after this fix. The only disadvantage of this fix is that the contents of the external clipboard might get converted more than once. Please review - if there is no objections I would apply the patch to the trunk. Any chance to put anything to the release35?
The diff has been checked in on a branch platform_32247 as Checking in NbClipboard.java; /cvs/core/src/org/netbeans/core/NbClipboard.java,v <-- NbClipboard.java new revision: 1.8.14.1; previous revision: 1.8 done
Both line 82 and 79, I guess you mean; i.e. simply first line of setContents method should be contents = convert(contents); But this is not quite right as you say since then getContents may produce a double-converted transferable. You would need to actually wrap the Transferable in a special proxy interface that marked it as having been converted already, then check for this marker in getContents. The interface would extend Transferable and delegate all methods to an original one; setContents would run convert then store an instance of the proxy wrapping the result; getContents would check instanceof ProxyTransferable, if so return as is (or the wrapped transferable, either way), if not run convert. Do not recommend this for 3.5. Convertors did not even work at all in 3.4 and no one seemed to notice for a long time (see issue #30923 and nbdev around that date), so it does not seem like high-priority functionality.
It probably is not clear to everyone what the implications of not fixing this are. I ran some tests, and it appears that, for example, the plain NetBeans editor (org.netbeans.modules.editor.plain.PlainKit), as well as JTextPane do not trigger a call to NbClipboard.getContents() (I guess they access the system clipboard more directly). Pasting in the Netbeans editor seems pretty essential to me, don't you agree? Without it I would hardly consider Convertors a working piece of functionality. If the effort of fixing Convertors seems too much of an effort, throw it out and remove all references to it from the documentation. But don't let innocent souls like me stumble over it and waste their day away trying to understand how Convertors work (this is the second time this week that this happened to me; earlier I stumbled over the documented yet unavailable startup folder). Anyway, I think it's quite fixable. I don't consider the issue of double conversion quite so crucial. The code example in the Javadoc for Convertor suggests testing whether the DataFlavor already exists before adding a new one. So in a proper Convertor implementation, double conversion should cause no problems. If you think in terms of overhead of calling an extra convert(), there is little to be concerned about comparing to how often it is called already. According to my traces, if I copy a Node, NbClipboard.getContents() is called four times, meaning four calls to convert(). A fifth call doesn't make a big differene IMHO. Actually, considering how often getContents() is called, I would consider it wise to not call convert() repeatedly in getContents(), but to only call it in setContents(), as convert() could be a little expensive depending on how many convertors there are. Isn't there some way to trap other modifications to the clipboard and have them followed up by a convert() operation?
Probably the simple patch is good enough for the trunk for now, so long as you leave in an XXX comment reminding us that it would be nice to avoid potential double conversion in the future. (Not so much for performance reasons, which I agree are probably negligible, as to avoid potential behavioral problems from oddly-written convertors.) Yes, Swing components directly access the system clipboard, since they cannot know about NbClipboard. Re. Startup folder - not sure what you're talking about; please file any complaints in a separate bug report.
Checking in src//org/netbeans/core/NbClipboard.java; /cvs/core/src/org/netbeans/core/NbClipboard.java,v <-- NbClipboard.java new revision: 1.10; previous revision: 1.9 done Processing log script arguments... More commits to come... Checking in test//unit/src/org/netbeans/core/NbClipboardNativeTest.java; /cvs/core/test/unit/src/org/netbeans/core/NbClipboardNativeTest.java,v <-- NbClipboardNativeTest.java new revision: 1.2; previous revision: 1.1 done
FYI, this may need to be rolled back or modified - it looks issue 38441 - if you press printscreen on windows and put a screen shot on the system clipboard, navigation in TreeTableView becomes very slow, and the problem seems to be updating the state of the paste action.
Hi, I might be a bit slow but could you please tell me what does this diff http://www.netbeans.org/source/browse/core/src/org/netbeans/core/NbClipboard.java.diff?r1=1.9&r2=1.10 has to do with 38441? I don't see the relevance. Nor do I see a reason to rollback this fix. I have changed setContents and not getContents --- could you please elaborate a bit more how this could slow things down?
You may be right, I may have read over the patch too quickly, and thought it was in getContents(). What seems to be the issue is that we appear to be fetching and performing some operations over a fairly large bitmap every time the selected node changes.
I think Trung was the right person to Cc: with that one - he was fixing similar issue as far as I remember.
this fix does not cause bug 38441, see my comment there
closed