and accelerated desktop standards

Carlos Eduardo Rodrigues Diógenes cerdiogenes at
Wed Dec 6 22:05:25 EET 2006

On Wed, 2006-12-06 at 00:52 +0100, Patryk Zawadzki wrote:
> Dnia 05-12-2006, wto o godzinie 21:27 -0200, Carlos Eduardo Rodrigues
> Diógenes napisał(a):
> > I don't say that the CWM couldn't implement the gnome-mag API. Doing
> > this make the magnifier inflexible and less portable. If the user would
> > like to experiment with others window managers he will not be able to
> > use a magnifier if the window manager is also a CWM.
> > 
> > This way, I think that we have two option:
> > 
> > 1. We can define a plugin architecture. Maybe the best way to do this is
> > implement the gnome-mag API in beryl or compiz, because they already
> > have plugin support, and leave to the time say if this was a good
> > decision.
> Or you can just create a libmagnifier library that iseasily pluggable to
> any compositing manager. To create a usable WM for tomorrow one has to
> integrate both composition and window management into one app (this was
> discussed since the idea of Xgl arised).

Yes, I never oppose the fact that WM and CM must be merged.

The problem IMO is that we will be putting a burden to people that need
accessibility support to experiment with new environments if the
magnifier plugin can't be plugged in some environments. From what I know
Metacity doesn't support the same plugin architecture available in
Beryl/Compiz (from the little I saw the use the same).

Despite this, I want to ask if after these discussion about integrate
composition and window management anything about replace KWin/Metacity
with Beryl/Compiz or make then support a default plugin architecture?

I think that a default plugin architecture can help us save development
effort and share more code, increasing our developers/users base.
Moreover I think that this plugin architecture can't be attached to
OpenGL or Xrender. I don't know if it's possible, but If the CWM can be
constructed as low-level composition operations and the plugins code use
them to express high-level operations, like magnification, something
similar with Xrender and Cairo.

> > 2. Have a way to change between the window manager and the magnifier to
> > be a composite manager.
> Not that easy - even Metacity is likely to become a compositing manager
> in the next release. The code is already there just a bit buggy. If you
> require each and every WM to have separate code paths for internal
> composition and no composition (external compositor is pretty much
> useless for the tasks WMs perform) you will end up ingored by the
> majority of developers and there will be no magnification at all.

Okay, it's good to know what developers will accept and technical
issues, this way we can think the best way to make the magnifier live
better between different environments.

> > If we have option 2 availabe the magnifier will be able to run
> > everywhere, but probably with some loose of functionality, since
> > composite management give us a great power to control what the user see,
> > and new HCI (Human Computer Interaction) will evolve and could benefit
> > visually impaired people too.
> Or the magnifier will run nowhere if Beryl, Metacity and Kwin decide
> they need internal composition.

and the magnifier can run only in some environments if some WM doesn't
implement the same plugin architecture that is in Beryl/Compiz.

> > I really appreciate to know if now you see a problem.
> Yes, I see a problem with the way you see things, there are two sides to
> this medal :)

I don't try to be aggresive, sorry if I was, maybe this is due to my
difficult to express myself in english.

> _______________________________________________
> xdg mailing list
> xdg at
Carlos Eduardo Rodrigues Diógenes <cerdiogenes at>

Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu celular. Registre seu aparelho agora! 

More information about the xdg mailing list