Shell integration idea

[Mikołaj Zalewski]

>I think the general approach is good.
>
>The way you handle the built in implementation seems odd to me. I think
>setting the registry key to make the freedesktop.org version as the default
>would be good enough.
>  
>
If we don't have built-in trash etc. objects then when we add a new 
object we will require all the implementations have it, with no backward 
compatibility. However this should not be a big problem as the 
freedesktop.org implementation can be kept up-to-date with shell32 and 
the other implementation can fallback to it if they don't support a 
specific object.

>I'm not convinced we need IWineShellIntegration. I think it would be
>cleaner to directly create an IWineTrash object.
>  
>
If we integrate more closely with the desktop environments we may need 
to have one central object that will know that e.g. KDE 3.4 uses the 
freedesktop.org Trash but KDE 3.3 has it's own Trash implementation. If 
we read the Trash CLSID from the registry such an implementation would 
require creating proxy classes or hacks in the class factory. Also by 
storing only one CLSID we don't have a problem which implementation to 
use if a new kind of objects is introduced.

Of course when we use COM aggregation instead of a factory pattern we 
will have all the interfaces visible under one CLSID so we will be able 
to construct a IWineTrash directly with the main object hidden behind 
the scene.

Mikolaj Zalewski