Community
Participate
Working Groups
As mentioned in bug 73923, comment 10 it would be nice to add clipboard contens as one of the resources to compare. Suggested option is to create a temp-file from the clipboard content and add it to Compare with Other dialog just like any other resource. It should be possible, to first pass one portion of text, select the next text and create a second temp file before invoking the compare editor. The problem is: where these files should be stored? In kind of a temp-project, created and disposed with the dialog?
Well, haven't done it personally but I think you should be able to store clipboard content in the dialog. Handling multiple clipboards shouldn't be an issue either. imho, creating a temporary file or a hidden folder isn't the most sophisticated solution. I'm pretty sure, you should be able to do it with the dialog only. This way you don't have to worry about some external resources that should be deleted on the dialog disposal. The other thing is, how you are going to present this functionality to the user? Is it going to be a button named "Use clipboard" or something? Or maybe you should allow the user to paste clipboard's content somewhere? Is there going to be a preview of a clipboard? If yes, is it going to be content-aware, ie if there is a Java class in the clipboard should the preview look like a Java editor (with colored syntax)? Again, I think that the best approach here would be to implement minimum but useful functionality, create a patch and open bug(s) for any other issues/ideas.
(In reply to comment #1) > The other thing is, how you are going to present this functionality to the > user? Is it going to be a button named "Use clipboard" or something? Or maybe > you should allow the user to paste clipboard's content somewhere? Is there > going to be a preview of a clipboard? If yes, is it going to be content-aware, > ie if there is a Java class in the clipboard should the preview look like a > Java editor (with colored syntax)? I thought about an expandable section named "Clipboard content" or "Use clipboard" with a multiline Text field inside where user can paste clipboard content and maybe even make some changes to it. If this section is expanded, "file" field would be disabled.
Created attachment 109159 [details] patch #1 This patch shows what I was talking about. It's created against branch_20080710_CompareWithDialog.
Created attachment 109642 [details] patch #2
Currently clipboard preview is showed in a viewer inside a dialog. When all clipboard sections are expanded, the dialog is enlargened so that copying or dragging portions of text to the viewer is not easy. The better approach here is to use a smaller viewer and add a button which will open an editor with clipboard's content.
I had a look at the patch from a user perspective. First of all the dialog got wider, probably because of the clipboard parts. I think we should keep the dialog as compact as possible. We need to keep in mind it's not modal, so we should avoid covering the workbench window if we can. Secondly, from my observation, expanding a "Clipboard" area to trigger clipboard comparison may be cumbersome. imo too many expandable items don't make the dialog user friendly, it's the contrary. On the other hand, I'm know you would like to handle multiple clipboard contents at the same time, this is where a clipboard preview becomes very handy. However, I still think that a (radio) button which sets a clipboard content on a desired participant (left,right,ancestor) would do the job. I like the idea of a smaller viewer for a clipboard preview mentioned in the comment above, maybe even a single line (Text) would be enough for a quick preview. I would treat a button for opening an editor with clipboard's content as optional here. In the end, comparing multiple clipboard content wouldn't be a common case. ps. Please update the patch, it contains a change which is already in HEAD.
Created attachment 110561 [details] patch #3 Update and a few modifications: * only one resource can be replaced by clipboard's content * only one clipboard section (with a smaller preview) is now placed at the bottom of the dialog * I decided to add "Show in editor" button
Created attachment 110779 [details] patch #4 The previous one erases the latest changes from HEAD.
Created attachment 111072 [details] patch #5 Based on the latest changes made in bug 73923.
Created attachment 111197 [details] patch #6 In the previous one editor pages with clipboard files weren't closed after clicking Cancel.
Created attachment 111399 [details] Layout issue This is what happened after checking Clipboard on the left and then trying to resize the dialog by dragging its left side.
Couple of additional comments: 1. org.eclipse.compare.tmp project should be hidden 2. With every Refresh for a clipboard content a new file is created, even though the clipboard contains the same content. Perhaps you should check if it changed and then create a new file. btw, having 3 files should be enough, right? 3. Workspace browsing doesn't work, but I've already mentioned it in bug 73923, comment 19, 1.
(In reply to comment #7) > * only one resource can be replaced by clipboard's content > * only one clipboard section (with a smaller preview) is now placed at the > bottom of the dialog > * I decided to add "Show in editor" button My usecase for comparing multiple clipboard contents is to run a program, copy its standard out, run it again with some changes and compare the second output to the first ... Another usecase is a dump of a complex datastructure (maybe a watch-expression) to compare it before and after a step in the debugger. Being restricted to one clipboard only seriously diminishes the usability for me. The preview of clipboards is nice, but more valuable would be the exact time of the paste: "30 seconds ago" versus "2 min ago". This info could easily be displayed in a tooltip. Actually, while I think about it: normally I compare texts, that are almost the same. So a preview won't really tell me if I am watching at the first or the second. That is exactly the reason why I want to compare them, because the differences are NOT obvious. So I would start the compare right away and not bother to look at the preview again. In addition, sometimes it happens, that I did not carefully press Ctrl+C to copy the second part. It might be worthwhile to empty the clipboard on a paste, to ensure not to compare two identical pastes of the same content. Last but not least Linux offers a paste action on middle click, that circumvents the regular clipboard. But this requires a textfield, that accepts direct text-input... so if there is a preview, it should not be readonly. I really appreciate your work!
Created attachment 117986 [details] patch #7
Is one of the initial contributor still following this issue? The requested feature is actually interesting. It would be nice if the patch could be revived and submitted to Gerrit.
