Mikołaj Zalewski wrote:
The number of developers that understand COM aggregation and all the
baroque rules that make it up is very, very low. A simple ops struct of
function pointers as used in the wineserver or kernel would be fine here
... COM adds an awful lot of complexity that really isn'
On 6/3/06, Mikołaj Zalewski <[EMAIL PROTECTED]> wrote:
OK, I won't insist on aggregation :). As for apartments I've thought
that something like that:
HRESULT res=CoInitializeEx(NULL, COINIT_MULTITHREADED);
/* working with objects with ThreadingModel Both */
if (SUCCEEDED(res)) CoUninitialize();
The number of developers that understand COM aggregation and all the
baroque rules that make it up is very, very low. A simple ops struct of
function pointers as used in the wineserver or kernel would be fine here
... COM adds an awful lot of complexity that really isn't needed at all
(eg you mu
On Fri, 02 Jun 2006 20:16:25 +0200, Mikolaj Zalewski wrote:
> 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.
Argh
Alexandre Julliard wrote:
I think using COM for that sort of thing is overkill.
If we want to allow multiple implementations then using a structure with
callback functions is probably the easiest way. If we are using
structures with callback functions then why not to make it COM
interfaces -
Mikołaj Zalewski <[EMAIL PROTECTED]> writes:
> The main idea is not to hard-code one implementation of things like
> the Trash into shell32 - not everything is standardized by the
> freedesktop and even if it would this might not work on other systems
> like MacOS X. We should allow for many impl
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
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.
I'm not convinced we need IWineShellIntegration. I think it would be
cleaner to directly
As a SoC project I'll try to improve the integration of wine with the
Unix shells. My first step will be to implement the freedesktop.org
Trash. I've written some code that doesn't add any new features but
shows how I want to add it. I'd like to know if this is a good design?
The main idea is
