Thanks for the reply Tom.
We might have some bandwidth to help with a solution. Our next release
will likely be based on Eclipse 3.4 so any solution we would want to
pursue would have to bridge back to it. We have the expertise to do this
type of work but would like some guidance from you and your team. We are
open to (and have done so in the past) implementing our own versions of
classes in the Eclipse framework that are otherwise non-extensible or
need some modification to fit our needs. I'm not promising anything at
the moment since we have our own release schedules to manage but there
is the possibility that we can help.
By bridging back to 3.4, I mean that if we can find the right
abstractions, we would like to implement them in Eclipse 3.4 with the
expectation that some simple code changes will get us to a comparable
Eclipse 3.5 implementation when we are ready to move to it.
Our alternative to solving this the right way is to add a preference
that allows the user to toggle between multi-select mode and table
navigation mode. The issue with this is that the user will have to
restart his editor for the preference change to take effect. Then when
the feature comes out in Eclipse 3.5 we would probably have to remove
the preference. Not the best solution in our eyes but certainly doable.
Given all that, how would you like to proceed?