Most of the interface we have on the core so far have specific needs and
I'm sure future interfaces will too. This library interface would have
to be extended to support cases like that. If we do that, then this
would work as a low level interface that other interfaces can be layered
on top of an
On Wed, 2007-03-07 at 14:28 +0100, Patrick Niklaus wrote:
> Hi,
>
> some of you might noticed that there was recently some discussion on
> the Beryl ML about an interface which provides sharing functions and
> allows us to do library plugins. One example for this kind of plugins
> is text, which
Hi,
> Except from the notifications on Load/Unload it does
> not offer anything but another framework to load dlls
> at runtime. I fail to see any real benefit
Maybe I should outline the benefits a bit more:
- as you said, load/unload notifications
- library plugins can wrap into core functions,
Except from the notifications on Load/Unload it does
not offer anything but another framework to load dlls
at runtime. I fail to see any real benefit
___
Χρησιμοποιείτε Yahoo!;
Βαρεθήκατε τα ενοχλητικά μ
2007/3/7, Mike Dransfield <[EMAIL PROTECTED]>:
It could also be disabled with an option, or at compile time.
If it was a really big library then you could use dlopen, but this
is just one function.
Doing it through an option would be a real mess in the settings
manager and just removing it a
Dennis Kasprzyk wrote:
Am Mittwoch, 7. März 2007 16:59 schrieb Mike Dransfield:
Danny Baumann wrote:
What are the major pros/cons of using this method over plain old
libraries?
They plug into the normal plugin infrastructure and don't add the need
for plugin writers to mess ar
Danny Baumann wrote:
Other than being notified when it is added or removed I
don't see how it is beneficial. Using a library would mean
that the functionality could always be guaranteed.
There might be functionality which isn't needed to be guaranteed. The
animation subplugins were an exa
Hi,
> Other than being notified when it is added or removed I
> don't see how it is beneficial. Using a library would mean
> that the functionality could always be guaranteed.
There might be functionality which isn't needed to be guaranteed. The
animation subplugins were an example, the text plu
Am Mittwoch, 7. März 2007 16:59 schrieb Mike Dransfield:
> Danny Baumann wrote:
> >> What are the major pros/cons of using this method over plain old
> >> libraries?
> >
> > They plug into the normal plugin infrastructure and don't add the need
> > for plugin writers to mess around with dlopen(), d
Danny Baumann wrote:
What are the major pros/cons of using this method over plain old
libraries?
They plug into the normal plugin infrastructure and don't add the need
for plugin writers to mess around with dlopen(), dlsym() and such.
Basically, they work like normal libraries and look lik
Hi,
> What are the major pros/cons of using this method over plain old
> libraries?
They plug into the normal plugin infrastructure and don't add the need
for plugin writers to mess around with dlopen(), dlsym() and such.
Basically, they work like normal libraries and look like a plugin. A
large
Patrick Niklaus wrote:
We just want to get some feedback on these ideas. If you are
interested I can provide a patch for compiz too.
Thanks for showing us this. I have a couple of questions though.
What are the major pros/cons of using this method over plain old
libraries?
Do you have any o
Hi,
some of you might noticed that there was recently some discussion on
the Beryl ML about an interface which provides sharing functions and
allows us to do library plugins. One example for this kind of plugins
is text, which was recently ported to that system. I now want to
explain here how it
13 matches
Mail list logo
