is override a
> registry key. Other shell integration objects can even be implemented
> out-of-proc in the explorer process all this can be cleanly hidden from the
> shell32 code that uses it.
Out of process COM is never cleanly hidden; if nothing else it can cause
unexpected threads to be cr
On Thu, Jun 15, 2006 at 11:26:02AM +0100, Robert Shearman wrote:
> I don't think it is. I think it would be better to start off with by
> just doing the shell integration in shell32. If a framework like this is
> needed, then it will become obvious later on.
>
That's
Robert Shearman wrote:
I don't think it is. I think it would be better to start off with by
just doing the shell integration in shell32. If a framework like this
is needed, then it will become obvious later on.
That's true that I currently don't need it but if someones would
point forwarding every
time we add a new functions to the freedesktop driver.
Is this approach good?
I don't think it is. I think it would be better to start off with by
just doing the shell integration in shell32. If a framework like this is
needed, then it will become obvious later on
I've changed the code not to use COM. Now it loads a DLL and searches
for a GetIntegrationObject entry point. That function returns structures
with a pointer to the ops structure. This is similar to how GDI objects
are implemented.
One could also export all the function from the DLL and build
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
Segin wrote:
If this was to be done, there are a few things I suggest:
First should be everything that Freedesktop.org has laid out, and
nothing more. That does into the FD.org integration code. For a lot of
this to work, Wine may have to be ran as a system service (is that
even a good idea
Mikołaj Zalewski wrote:
I've had an idea for a SoC project and filled the application. In a
comment I was advised to discuss it on wine-devel.
The idea is to integrate the wine shell32 with the Linux desktops. The
main problem is of course that there are many desktop environments and
only s
I've had an idea for a SoC project and filled the application. In a
comment I was advised to discuss it on wine-devel.
The idea is to integrate the wine shell32 with the Linux desktops. The
main problem is of course that there are many desktop environments and
only some things are standardiz
17 matches
Mail list logo
