[FusionComm] Truly disappointing

[Sam Spilsbury]

On 7/4/07, Alyssa Hung <deciare at isisview.org> wrote:
>
> On Tue, July 3, 2007 8:03 am, RYX wrote:
> > Hi everbody.
>
> Hello. Good to see some activity on the mailing lists again; though
> endless debate may be a bit much, complete silence isn't that much more
> savoury. ;)
>
> > Those people who cried for a combined community still prefer hanging out
> > on oc.o and still aim at having their own community where they can be
> the
> > kings - even though we finally agreed with nearly 100% of their wishes
> and
> > requests. Nobody of the so called "beryl devs", except Danny, ever came
> to
> > compiz.org for announcing new ideas or helping users - if they come at
> > all, it is for bitching, nitpicking or correcting people.
>
> I am awaiting the proper setup and announcement of the unified forum.
> Whether that is at forum.compiz.org, compiz-fusion.org, or elsewhere, I
> believe waiting for an announcement would be wiser than making
> assumptions, as many of us have been said to do in the past.
>
> Please don't interpret my patience as mere inaction. I am ready to act
> on specific implementations of the details pertaining to the forums'
> eventual future.
>
> > Users come to the compiz forums and tell me that they tried compiz and
> > beryl but nothing worked for them, so now they installed "fusion" and
> want
> > help with it - likely because of being misinformed by "other sources".
> > Seriously, this mess has created such an incredible amount of
> > confusion that especially the community has to be informed about what is
> > going on. And before that, we should create some roadmap or targets to
> > show them (hint, hint).
>
> I've been trying, and continue to try, to refer to Compiz as the one
> project. There are several structural challenges that I haven't been
> able to ignore, however.
>
> Most notably, when people make suggestions for plugins that are
> currently distributed together with Compiz-Core, such as Cube or Rotate,
> I can't help but think that the features requested may be be implemented
> for quite some time; it has traditionally been the style of developers
> who contribute to Compiz-Core to be patient and prudent about choosing
> what to implement and how to implement it. The same goes for features
> that may require Core changse to implement, such as being able to show
> thumbnail previews for minimised windows.
>
> Bug reports pertainig to components distributed with Compiz-Core are
> also tricky. Weeks ago, I filed a bug report to the freedesktop.org bug
> tracker (Bug 11331) about inconsistent key binding behaviour in the
> Scale plugin. The bug has not received any replies; was it received and
> reviewed by any of the developers involved? Bug reports to oc.o aren't
> always resolved quickly, but they _have_ been resolved.
>
> I was asked why Blur and Reflection won't work with the same hardware
> that used to work fine with BlurFX in Beryl, and after going through his
> configurartion, I had to admit that I honestly don't know. Maybe some
> combination of Beryl's plethora of allowances and workarounds made the
> hardware work without needing a "proper" fix, such as a driver-side or
> server-side correction. Is Compiz-Core ever likely to implement such
> workarounds...?


I've debated with myself to answer regarding technical details, but AFAIK,
workarounds such as these will probably be implemented in a separate plugin
level (See GrisWorlds 'Workarounds' plugin). A lot of the methods used by
beryl were somewhat slow and unstable. (Please do not take that comment too
seriously because I do not know the technical merits.)

Regarding BlurFX and reflection, they used something that avoided the use of
pixel shaders (But BlurFX used pixel shaders where they were available). The
problem with correcting rendering/ driver problems within Compiz-Core is
that they can come and bite you in the back or break something else, because
they are *workarounds*.

Again, I'm not a developer, but this is AFAIK. If any developer wishes to
correct me, please do ;-)


I want everyone to be happy with their compositing manager, and to show
> that Compiz can work for everyone, but when I'm asked questions like,
> "Why can't Compiz do ____ when Beryl can? Isn't Compiz Fusion supposed
> to be better?" It's hard to think positively when there are still
> feature regressions and compatibility regressions going from Beryl to
> Compiz (seemingly directly caused by conflicting philosophies between
> the past and the present), and there seems to be less developer presence
> than ever.
>
> The divisions between Beryl, Compiz, and Compiz Fusion don't exist
> entirely in the minds of misinformed people... To those with problems,
> those with ideas, and those on the receiving end of stymieing bugs and
> usage scenarios, the structural challenges that separate Compiz from
> Beryl are very real.
>
> I _want_ this project to succeed, and _try_ to make it successful in the
> ways I can as a user. I'm sure many users want a compositing manager
> they can be proud of and really get behind. But wanting isn't enough...
> As many suggestions as we offer and as much assistance as we provide for
> each other, there's little we can accomplish without good faith from the
> developers.


Yeah, we need to post a list of current functional regressions and what is
and what is not possible. (Technically) There is already one on
obby.opencompositing.org and functional regressions are few and far between.
I'm not a developer, but I do sort-of know that by adding hook-interfaces to
core-plugins, we can actually add these features in separate plugins,
instead of destablizing the core plugins. Hopefully, most of these will be
corrected soon.

> Let me ask you one question: what do you all expect to happen once we
> > have a combined website for the combined project? I'd (still) really
> like
> > to hear your answers on this ... We still have no goals, roadmap,
> > merge-agreement or "peace-contract". Well, as long as we have ten
> > different packages and a website the rest will come by itself, right?
> > Sure.
>
> I expect for community resources such as wikis and packages to be more
> cohesive.
>
> I wish to see more developers being accessible; whether that means more
> forays into the forum, greater participation on the non-dev IRC channel,
> a greater tendency to act on bug reports and feature requests, or
> otherwise showing the users that someone is listening, and someone cares.


Regarding IRC channels, #compiz-fusion should be split into

#compiz-fusion (For general compiz-fusion talk)
#compiz-fusion-dev (For development only) (i.e code)
#compiz-fusion-support (Obvious)
#compiz-fusion-web (For web-discussion, such as the blog / forums)


I hope that users "misinformed" about the nature of Compiz Fusion may
> truly be misinformed rather than being simply misunderstood.


Announcements FTW ;)


I would like to see Compiz thriving alongside other compositing
> managers, perhaps evolving beyond its scope as a mere compositing
> manager at some point, instead of being killed by the first serious
> competitor that comes along (read: KWin).


KWin != problem IMO ;)


> btw: I still work on the new layout, but if it means that the
> > compiz-forums have nearly no support whenever I am not around, it shows
> me
> > how interested everyone is in a "combined community" and immediately
> puts
> > my motivation back to zero ..
>
> Does that depend on which forum we consider the Compiz forum? I'd rather
> not set the mood for unifying our communities against the backdrop of
> this chilling distinction.
>
>
> ~Alyssa
> _______________________________________________
> Community mailing list
> Community at lists.compiz-fusion.org
> http://lists.compiz-fusion.org/mailman/listinfo/community
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.compiz-fusion.org/pipermail/community/attachments/20070705/56893e10/attachment.htm