Community
Participate
Working Groups
Build ID: I20070621-1340 This is one of those that might get implemented by us lot in the community, if given a few pointers. In Package Explorer we have the options: Package Presentation: Flat/Hierarchical and Top Level Elements: Project/Working Set They give us interesting ways of slicing and dicing how things are grouped. I wonder how extensible this concept is, and whether one that I'd like: Top Level Elements -> Packages could be implemented. This rather simplifies the view of everything, perhaps making navigation much easier, especially in combination with Mylyn. For me, it's one where it would be great when you have different branches of a project open and want to do ad-hoc compare / merge operations. It'd be much easier having the items in the same package near each other in this use case. In that scenario, there could be a Project node below the package node, or, that node could be filtered. More information:
Did you try the Java Browsing perspective which has a Packages view? You can also just open the Packages view in another perspective and then you see all the packages of a selected Java project.
As Dani said, the package view can show you the merge of all the packages in all source folders of a project. People use projects and source folders to organize there code, I don't understand why it would be beneficial to remove this elements. We also can not merge all packages from all projects, as this projects may have nothing to do with each other. You would therefor always need project as top level elements. You can omit the source folders, which is exactly what the package view can do. Finally it sound difficult to implement and we want to keep things simple. The only thing I can think of is a menu entry in the view menu: 'Show source folder nodes' and if unchecked the source folders are omitted and the packages merged. Would that help?
Daniel: Thanks for that. That perspective would allow what I'm thinking if it allowed you to select two projects, nor does it have any Team features at all. Benno: Thanks for giving me a bit of an understanding of how things are organised within the software. It seems that I need to look to a different approach. Given that what I'm talking about is a Team function, then I think I have a different way of going about it: What I'm doing is selecting two files and doing "Compare With->Each Other". What I want to do is to compare/merge with the same file in another branch in the same workspace. What I think I'm looking for is "Compare With->Another File", which would then allow me to select that file using something like the Open Type dialog. I'm happy if you want to close this, or bump it over to the Team team. Cheers, Neale
Hey, I actualy had a similar problem this week. My use case: I wanted to compare org.eclipse.jdt.internal.ui.dnd.JdtViewerDropAdapter with org.eclipse.jface.viewers.ViewerDropAdapter JdtViewerDropAdapter is almost a one-to-one copy of jfaces ViewerDropAdapter and I want to see where they differ so I had to: 1. Open Type 2. Open JdtViewerDropAdapter 3. Show In > Package Explorer 4. Open Type 5. Open ViewerDropAdapter 6. Show In > Package Explorer 7. Select JdtViewerDropAdapter.java 8. Select ViewerDropAdapter.java 9. Compare With > Each Other... Easier would be: 1. Open Type 2. Open JdtViewerDropAdapter 3. Shown In > Package Explorer 4. Select JdtViewerDropAdapter.java 5. Compare With > Other Resource... 6. Select ViewerDropAdapter.java in an Open Resource dialog
Excellent.. that's the use case. And.. it'd be even easier, as you'd do: 1. Open Type 2. Open JdtViewerDropAdapter 3. Right-Click on editor->Compare With > Other Resource... 4. Select ViewerDropAdapter.java in an Open Resource dialog Get's my vote!
Similar to bug 73923. We'll try and find time to address this in 3.4. It would be nice to have a single menu entry that morphs it's title based on the number of resources selected (to reduce the number of context menu entries).
I also put my vote for this. I often use two and three way compare and have to select 2 or 3 files with ctrl-key. If files are in different projects you have to scroll and it happens lot of times that i wrongly selected one file without pressing ctrl-key because i wanted to expand or collapse the three in navigator view to have better overview. The function to store file for later compare would be very good for me! The context menu can be like this: Compare With -> Each Other Other Resource... Local History... --------------- Copare List Add Selected File(s) Add Other Resource(s)... Clear List --------------- Remove FileName1.cpp Remove FileName2.cpp Short description of menu entries: "Copare List": compares files in list with selected file, only available if list is not empty "Add Selected File(s)": adds selected files to list, only possible if list is not full (maximum 2 files if list is empty) "Add Other Resource(s)": adds other files with "Open Resource..." like dialog to list, only possible if list is not full (maximum 2 files if list is empty) "Clear List": clears the compare list "Remove FileNameX.cpp": shows list with files that are in the list (maximum 2 files), you can remove file from list by clicking on this entry. Any ideas?
Interesting approach... and I like it. Another UI approach which would be nice is to be able to use a derivative (/extension) of the Open Resource/Open Type dialog boxes to select the resources. For example, if I have two branches open in different projects, and use Open Type, and type FF, and I'll see my two FooFactory classes listed. If I could select both of those as a multiple selection (or select one and click add) then that would be good. A "Compare Resources" dialog of this nature might work well with Mylyn too.
(In reply to comment #7) > The context menu can be like this: > Compare With -> Each Other > Other Resource... > Local History... > --------------- > Copare List > Add Selected File(s) > Add Other Resource(s)... > Clear List > --------------- > Remove FileName1.cpp > Remove FileName2.cpp > > Short description of menu entries: > "Copare List": compares files in list with selected file, only available if > list is not empty > "Add Selected File(s)": adds selected files to list, only possible if list is > not full (maximum 2 files if list is empty) > "Add Other Resource(s)": adds other files with "Open Resource..." like dialog > to list, only possible if list is not full (maximum 2 files if list is empty) > "Clear List": clears the compare list > "Remove FileNameX.cpp": shows list with files that are in the list (maximum 2 > files), you can remove file from list by clicking on this entry. > > Any ideas? I don't like that. A menu should act like a menu, that is: entries can be selected to invoke actions. But your menu acts like a menu and a table, which is very unconventional, and we don't have something like this in the SDK anywhere as far as I know. I don't think that users will understand how to use it. It took me a while to understand it... (In reply to comment #8) > Another UI approach which would be nice is to be able to use a derivative > (/extension) of the Open Resource/Open Type dialog boxes to select the > resources. I like that much better, it's straightforward.
-1 for comment 7 +1 for: > Another UI approach which would be nice is to be able to use a derivative > (/extension) of the Open Resource/Open Type dialog boxes to select the > resources.
Created attachment 94225 [details] Beyond Compare Plugin
Created attachment 94226 [details] CodeWright diff dialog
(In reply to comment #9) > I don't like that. A menu should act like a menu, that is: entries can be > selected to invoke actions. But your menu acts like a menu and a table, which > is very unconventional, and we don't have something like this in the SDK > anywhere as far as I know. I don't think that users will understand how to use > it. It took me a while to understand it... Yes you are right menu should act like menu, but in this case i find it usable. May be, because i used "Beyond Compare" before - it use menues like i described but with static menu entries. If it's not possible with SDK to add entries dynamically, we can add two static entries and disable (gray out) them if no additional file can be stored for later compare. In attached screenshot you see menu from "beyond compare" plugin for copare two files with external program: * "Store For Later Compare": stores filename for later compare * "Beyond Compare": compares selected file with stored file It's easy to understand and can be extended for 3-way compare, combined with my suggestion: Compare With -> Each Other Other Resource... Local History... --------------- Store Selected For Later Compare Store Other Resource(s)... Clear Storage Compare With Stored File(s) After storing two files the entries "Store..." are disabled to indicate that our storage list is full. > (In reply to comment #8) > > Another UI approach which would be nice is to be able to use a derivative > > (/extension) of the Open Resource/Open Type dialog boxes to select the > > resources. > > I like that much better, it's straightforward. I like it too, but we need dialog for multiple selection of resources. Another editors like UltraEdit or CodeWright are using special dialog for compare (see Attached screenshot from CodeWright).
Andre, I see your point but I'm afraid I will need to agree with the Swiss guys :) Adding a dialog is in my opinion a much better solution. The main drawback of the "dynamic menu" idea is that you will still need to manually locate the files in PE (or anywhere else), and the only thing we gain here is the fact that the selection is remembered. Using the dialog, especially when combined with Open Type/Resource dialogs would be in my opinion much faster. Moreover, it would be easier to add some other features like browsing remote resources, d'n'd support and so on. Anyway, the reason why I jumped in here is that I would like to inform you that I submitted this bug (actually bug 224562) as a proposal for this year GSOC[1]. So keep your fingers crossed and I'm sure we'll get a fancy, hi-tech dialog by the end of the August ;) [1] http://wiki.eclipse.org/Google_Summer_of_Code_2008_Ideas
(In reply to comment #14) > Andre, I see your point but I'm afraid I will need to agree with the Swiss guys > :) Adding a dialog is in my opinion a much better solution. The main drawback > of the "dynamic menu" idea is that you will still need to manually locate the > files in PE (or anywhere else), and the only thing we gain here is the fact > that the selection is remembered. Using the dialog, especially when combined > with Open Type/Resource dialogs would be in my opinion much faster. Moreover, > it would be easier to add some other features like browsing remote resources, > d'n'd support and so on. I'm fine with it! Compare-Dialog is the best solution and i use it in CodeWright. My idea is to have menues, because it should be easier to implement - just extend menues. I started with study of documentation about writing eclipse plugins. As C/C++ developer i hope to be able to write small plugin to extend "Compare With" menue in few days :) > Anyway, the reason why I jumped in here is that I would like to inform you that > I submitted this bug (actually bug 224562) as a proposal for this year GSOC[1]. > So keep your fingers crossed and I'm sure we'll get a fancy, hi-tech dialog by > the end of the August ;) > > [1] http://wiki.eclipse.org/Google_Summer_of_Code_2008_Ideas Great, thank you for info!
Hi, recently I've (independently) added (most of + much more) the requested functionality to the AnyEdit Tool: http://andrei.gmxhome.de/anyedit/index.html The functions are: Compare / Replace With Clipboard Compare / Replace With Workspace file... Compare / Replace With External file... Compare / Replace With Opened Editor... and they are available from both Navigators / Editors context menus. The code is written by me (I own the IP), is included in the plugin jar and is provided under the (weak and therefore compatible with EPL) BSD license. Related bugs (AFAIK): bug 39126 bug 63179 bug 73923 bug 224562 Please also consider to reopen (resolved LATER) bug 39126. As proposed by some people, I offer my code for the next Eclipse release (3.4 is too late, so 3.5?), but I have to know where/how to push it etc. Regards, Andrei
Mass update - removing 3.4 target. This was one of the bugs marked for investigation (and potential fixing) in 3.4 but we ran out of time. Please ping on the bug if fixing it would be really important for 3.4, and does not require API changes or feature work.
*** This bug has been marked as a duplicate of bug 224562 ***
