Shell integration idea
mikolaj at zalewski.pl
Fri Jun 2 13:16:25 CDT 2006
>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
>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
More information about the wine-devel