Community
Participate
Working Groups
We should order the EE's in the product editor in some order. The easiest seems to be alphabetical order. Whatever we do we should try to make the list in the Product Editor in the same order as the Eclipse Launcher.
Created attachment 89201 [details] mylyn/context/zip mylyn context
Created attachment 89203 [details] proposed patch Please have a look at what i've changed into the refresh() method. I think there was a bug I've fixed, but I'm not 100% sure!.. :)
I will take a quick look :)
Quick question for you Benjamin, was there a reason you do a binary search each time you add an element instead of using Arrays.sort(Object[], Comparator) to sort the array at one time?
Well, it's a bit nasty, but since we have both the combo elements (sorted alphabetically) and the corresponding arraylist of EE, we just can't sort the combo since we would then lost the "sync" with the EE array. It's still cleaner (IMHO) than in the PDE Launch dialog where there's only the combo and no EE array. So as soon as a selection is made, the combo text is parsed and "decoded" into an EE ! :s The best solution would be to have a comboviewer (sorting, selection retrieving... everything would be better ... :) )
Brian, do you want me to try to clean code a bit and replace combos with comboviewers ?
I'd assume that's a yes from Brian ;d
ok :p what are your recommendations for the location of LabelProviders/ContentProviders classes ? Inner classes ? Somewhere else, if so, ... where? :)
simple inner classes are fine
Created attachment 90782 [details] Let's say goodbye to ComboPart :op Here is a patch providing a brand new ComboViewerPart. I would like this class to simply replace the ComboPart to ease labels/selections/sorting/... handling. ComboViewerPart doesn't inherit from ComboPart (it could have...) because ComboPart should just disappear ;-) The API of ComboViewerPart is not yet frozen. I can provide fixes to replace every call to the old "ComboPart" ; even if doesn't concern a lot of classes (about 10), it would clean the code alot (imho). I've kept a behaviour that looks like a bug : the JRE combo's first entry is an empty string that looks useless. The old code, and my new code, both can't do anything with this "empty" JRE ; it is not even used to unset the JRE!
Created attachment 90783 [details] mylyn/context/zip
before I head on vacation, one thought I had is that what happens when you go and export a product? For example, I think the logic checks what values are in the fields and doesn't care whether they are enabled or not. So if you have an EE and JRE setting I don't know what happened. I don't know if I'm making sense here but I think that's why we had empty values. They were used as an indicator on what to do. I'll have more time to look at this towards the end of next week when I come back refreshed.
Yap the behaviour should probably be what you are describing but, at the moment, choosing "" in the JRE combo doesn't set the value to "null" ... :/ ... have a nice week! :op
(In reply to comment #13) Ok, finally caught up with everything and had time to review. 1) there needs to be a way to express that a user doesn't want a JRE or EE. This is a bit confusing with the current layout. I believe the current intention is to just select nothing in one of the JRE or EE combos... this is bad... we should really have another option that just says "None" SO there would be three radio boxes: * None * JRE [combo] * EE [combo] You can get rid of the empty string in them then... 2) make sure when switching tabs, all is good. I noticed some weird behavior in the current implementation where combos wouldn't get cleared out. Thanks for the work Benny, this is cool stuff and should simplify things!
okidoki
Created attachment 91896 [details] Updated patch I tried to implement the most userfriendly behaviour in terms of whether combos are cleared or not when you change radio buttons selection or when you switch tab... Feel free to tell me if you still have any remarks ;-)
Thanks Benny, top notch stuff!
