I would be usefull to have a way how to specify order of elements returned from
some methods like getPropertySet() in CompositeLook.
Set target milestone to TBD
Hmm I don't think this should be fixed in the ProxyLook. There are
some workarounds for this. You may for example create a filter look
which will take all elements from the delegate and sort them in some
way. Other workaround is to provide a look which creates something
like PropertySetBase which would be analogous to ActionBase in default
look and would allowe for sorting PropertySets using filesystem
I am not sure I understand the solution/workaround you are
proposing. I believe the basic scenario for this situation
is the following:
1. The IDE is visualizing an object using a composite
look. This look may not even be provided by end-level
modules, but by infrastructure of some kind (IDE code,
2. Modules are plugging sub-looks to this composite look.
So the Java module may add a sub-look which has
the "compile" action, and the VCS module may add a sub-
look which has the "check in" action. These modules may or
may not depend on each other.
3. Now _someone_ needs to specify that e.g. "compile"
should be in the popup menu before "check in".
I believe this bug is about allowing to specify such
ordering information at some level. This should be simpler
than by creating a bridge Java-VCS module with its own
filtering look implementation, which puts the actions in
the correct order. Can we invent some *simple* way to
cater for the scenario above ?
The problem I see here is who is the _someone_ who will decide
how the elements should be ordered. This can hardly be Looks SPI.
Registering a Look in layer and allowing other modules to plug in
own looks represents some kind of API of the module which owns the
CompositeLook, LookSelector or what ever. In case that it is not
necessary to allow other modules to plug in the module developer
should create all the Looks and Selecors in java. In this case he is
responsible for all the ordering. In case that there is a need for
other modules to plug in. The module developer can still publish a
CompositeLook and throw an Filter over it in Java. This of course
means that he needs to know how to sort the things. Yes sure, he
usualy does not. Then in case that the actions, properties or other
elements should be sorted somehow. The module which exposes the
Look as API has to expose other folder or other kind of API where
modules will explicitely state out how to sort things.
I know that it sounds strange but this is a tax for modularity. It's
the same problem as sorting Loadres, ToolsActions etc. I have no
magic solution for this problem right now. Maybe we could add some
generic SortByFolder Look, but I don't want to do it until I see
that it would really help and until I can imagine how to do it