[Compcomm] Kde composite manager...
Dennis Kasprzyk
onestone at opencompositing.org
Wed May 30 16:47:55 EDT 2007
Am Mittwoch, 30. Mai 2007 19:18:43 schrieb RYX:
> Am Donnerstag, den 31.05.2007, 01:26 +1000 schrieb Andrew Wedderburn:
> > so maybe compiz/beryl should be tightly intergrated with gnome since
> > kde has its own tightly intergrated system(that most users will use)
> >
> > you can get a better product when you're dealing with only one de.
>
> Compiz already deals well with both, doesn't it? I guess if the gnome
> devs want they are free to switch to compiz as their WM/CM (and I
> personally think if they are smart, they'll do it). Compiz is intended
> to work with any (or even no) DE and I am pretty sure that there are
> many KDE users that will still prefer using compiz instead of kwin (e.g.
> because kwin will likely be slower and more ressource intense due to its
> C++ nature).
>
> But maybe the best and most important side-effect for compiz and the new
> project is the competition we get. We now have a "competitor" which will
> raise much attention due to the popularity of KDE. Will compiz and the
> new community-driven project around compiz (which was aimed at being a
> lighweight DE if I remember correctly) be able to face the speed and
> quality of the KDE developer- and user-base? This is going to become a
> tough challenge and I hope we are all willingly accepting it :D ...
>
The only thing that compiz can't offer it a "non composited" window manager
mode. Even if KDE/GNOME would decide to use compiz, then they still would
need to maintain kwin/metacity. And compiz will never act exactly the same
like kwin/metacity.
My tests showed that it would be relative easy to disable the
composite/painting code in compiz. Compiz then acts like a normal window
manager. The problem is that we would need to rewrite the window decorators
to create "reparented" window decorations in the 2d mode. A new (or an
extended version of the current) decoration plugin would handle then the
reparenting of the decorations.
Maybe someone should convince David that we need a "2d only" window manager
mode. Such mode should increase the chance to get accepted by the desktop
environments, because they could then drop their normal window manager.
> > On 5/31/07, Wesley S. <wesley at ubuntu-nl.org> wrote:
> > > 2007/5/30, Guillaume Seguin <guillaume at segu.in>:
> > > > 2007/5/30, Erkin Bahceci <erkinbah at gmail.com>:
> > > > > Wow, that was some serious duplication of effort to watch. I wish
> > > > > they had used compiz and spended the time they put into coding the
> > > > > same stuff all over again to improve compiz instead. Lack of
> > > > > intention to collaborate and communicate, I guess. Or just that
> > > > > they wanted it tightly integrated into KDE, and written in C++
> > > > > instead. Sigh.
> > > >
> > > > They asked us once. They said that they were willing to keep as much
> > > > control as possible on what plugins could do so that using compiz
> > > > wasn't possible for them.
> > >
> > > The KDE guys did review all options, but they thought it was better to
> > > write their own stuff after carefully examining everything. I remember
> > > the opted idea for compatibility with compiz/beryl plugins, but it was
> > > too hard to manage and they decided to keep working with their own API
> > > instead.
> > >
> > > --
> > > Wesley Stessens <wesley at ubuntu-nl.org>
> > > Human Knowledge Belongs To The World - Antitrust (2001)
> > > http://wesley.debianbox.be
> > > _______________________________________________
> > > CompComm mailing list
> > > CompComm at Rock3d.org
> > > http://www.ubaight.com/mailman/listinfo/compcomm
> >
> > _______________________________________________
> > CompComm mailing list
> > CompComm at Rock3d.org
> > http://www.ubaight.com/mailman/listinfo/compcomm
>
> _______________________________________________
> CompComm mailing list
> CompComm at Rock3d.org
> http://www.ubaight.com/mailman/listinfo/compcomm
More information about the CompComm
mailing list