Re: [handly-dev] Enabling working sets breaks the navigator

[Vladimir Piskarev <pisv@xxxxx>]

Hi Vlad,

 

Thanks for reporting it!

 

I can reproduce this issue. Unfortunately, it cannot be easily solved (as far as I can see). This working set support in o.e.ui.navigator.resources is designed to work (only) with the resource-based ProjectExplorer (a subclass of CommonNavigator). For Handly-based content, we need something along the lines of working set support in JDT's PackageExplorerPart (see WorkingSetModel). I hope to come up with a solution for that in Handly 0.3. Meanwhile, you can exclude org.eclipse.ui.navigator.resources.WorkingSetActions as a workaround.

 

In particular, these action extensions from o.e.ui.navigator.resources are known to work well with Handly-based content:

 

            <actionExtension
                  pattern="org.eclipse.ui.navigator.resources.UndoRedoActionProvider">
            </actionExtension>
            <actionExtension
                  pattern="org.eclipse.ui.navigator.resources.PortingActions">
            </actionExtension>
            <actionExtension
                  pattern="org.eclipse.ui.navigator.resources.ResourceMgmtActions">
            </actionExtension>
            <actionExtension
                  pattern="org.eclipse.ui.navigator.resources.PropertiesActionProvider">
            </actionExtension>

Best regards,
Vladimir

 

Hi,

If adding to the navigator (as implemented in the examples) an actionExtension to "org.eclipse.ui.navigator.resources..*", which among other things enables working sets in the view, this extension resets the navigator's content provider input to the workspace. This means that the navigator loses all Handly-based content because that depends on the model being the navigator's input.

Do you have any suggestion about how to handle this? I tried different combinations of adapters (because I feel that being able to adapt IResources to IFooElements should be a solution), but couldn't make it work -- either it's not a good solution, or I did it wrong... 

At some time in the future, one will probably want to support working sets anyway, so removing these extensions is only a temporary solution.

best regards,

Vlad