Community
Participate
Working Groups
When sharing a project using the Team/Share context menu item, I would really like it if it remembered the last repository type I selected. I would make sharing a dozen projects very easy.
Sounds like a good idea. This would be an easy change to make. Would you have the time to submit a patch?
Never done one before, but I would love to do it, because it would get me in to the process of submitting patches. Can you just point me to the correct plug-in? Do I store the changes as a non-visual system preference.
Robert, the plug-in to start with is org.eclipse.team.cvs.ui (you can check it out from Eclipse repository - :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse). Next, you should take a look at SharingWizard.java... or ConfigureProjectWizard.java (from org.eclipse.team.ui). What is worth mentioning that there is a similar wizard which seems to have this issue solved somehow - it's ModelSynchronizeWizard, which pops out from the Sync View. You could take a look at it too. If you need any help, please don't hesitate to ask. Good luck :)
One problem with installing o.e.t.ui is that it comes with a compile error: The method ChangesSection.getBackgroundColor() does not override the inherited method from Control since it is private to a different package. This applies to this line in ChangesSection.java: protected Color getBackgroundColor() { It seems that the Control class has a package-private method getBackgroundColor, and Eclipse is not happy. Any thoughts?
(In reply to comment #4) > The method ChangesSection.getBackgroundColor() does not override the inherited > method from Control since it is private to a different package. This looks like a conflict with the gtk+ implementation of the Control class because the Windows version doesn't seem to have this. GdkColor getBackgroundColor () { return getBgColor (); }
Yipe! Any advice?
(In reply to comment #6) > Yipe! Any advice? I guess you could just rename ChangesSection's method to getBackgroundColor2() for now or something. ;) In the long term, I think that Team should rename this method to bypass this issue. It is really quite an interesting problem given that the root cause is actually the implementation differences of SWT across the many platforms it supports.
Yeah, I just noticed that many other classes extend this one and depend on getBackgroundColor. Sure I can just fix this by renaming the method appropriately, but it changes the nature of the patch. I'll do that for now, just to get by, and this can be addressed separately or together.
Created attachment 84346 [details] First attemtpt at a patch
Robert this patch is out of date with HEAD. Could you update please?
This, I'm afraid, is where this starts to become a tutorial in submitting patches to Eclipse rather than fixing the bug. I'm OK with that if you are willing to help me out, you see? Alternatively, you might want to just look at the patch and possibly apply it to head for me. The thing is, now that I have pulled the code from head, I have different compiler errors, and they clearly reflect new code in other dependent bundles. For instance: 'The method "createStructureCreator(LocalResourceTypedElement) is not defined for the type CompareUI'. So if I import the bundle o.e.compare, does this become an endless cycle of imports? Or, should I have just imported all of HEAD? Thanks, Robert
(In reply to comment #11) > So if I import the bundle o.e.compare, does this become an endless cycle of > imports? It is not very common for this to go on forever. Committers and active contributors usually work off of I builds, so the plug-ins they have on their self-hosting target platform is usually up-to-date enough. Of course, sometimes some collaboration work gets going and you are forced to check out projects from components outside your original scope (like when UI added the new working set control and PDE had to keep the UI plug-ins in their own workspace). Since the Team and Compare teams are one and the same (as far as I know), it is not entirely illogical for one plug-in to depend on bleeding edge CVS stuff. I'd say give o.e.compare a checkout and see where that leads you. By the way, Robert, what build are you using for developing this patch? You're using an I or N build, right?
Created attachment 84610 [details] Patch rev 2 (against head)
First of all, thanks for the patch :) It works fine, but I've got some suggestions: 1) I would use DialogSettings to save/load selected wizard, since this is not actually a preference. And AFAIK we don't want it to be. 2) In ConfigureProjectWizardMainPage you add getter and setter for selectedWizardId, but their names are slightly different. I belive it's not a standard naming convention. 3) In ConfigureProjectWizard#performFinish method you save the selected wizard ID. It looks like it can be done no matter if the checks are true or not (i.e. can be done as first thing in the method). 4) In ConfigureProjectWizardMainPage#findWizardById you could change the first check to: if (children == null || wizardId==null) { 5) In the same method as above I would change the ConfigurationWizardElement variable name to something different. "e" is used to be use for exceptions How does is sound?
I agree with the getter/setter mismatch except that the method names sort of match the behavior in a strange way. The truth is that if I wanted an initial ID and a selected ID, I could have two String attributes, but it's not worth it, so I renamed it just straight to wizardId. I don't know enough about Dialog Settings. Right now this.getDialogSettings returns null. What should I do? I think for this one, you should just hand me the answer. :)
Created attachment 84741 [details] Third patch > I think for this one, you should just hand me the answer. :) Sure, this is how I would have used the DialogSettings. Actually, I made the whole saving/loading thing. Robert, would you mind taking a quick look at the patch and veryfing if it does what you need?
Created attachment 84742 [details] mylyn/context/zip
Yes, that looks great. Plus for some reason you don't have the same problem as I with getBackgroundColor. Thanks for giving me a chance to fix it, and for doing a better job in the end.
No problem, you did a fine job. As you probably noticed I reused some of your ideas, so I did only half the work (or even less). Feel free to pick up a different bug, I'm still eager to help you :) I'll assign this bug to me and mark it for M5, so I won't forget about it.
Teamwork! :)
The latest patch has been released to HEAD. Thanks again Robert.
Verified in I20080205-0010.
