[Compcomm] A possible forum merge proposal
Mike Dransfield
mike at blueroot.co.uk
Thu Apr 26 14:13:45 EDT 2007
Dennis Kasprzyk wrote:
> Am Donnerstag, 26. April 2007 19:38 schrieb Mike Dransfield:
>
>> Danny Baumann wrote:
>>
>>> Hi,
>>>
>>> first of all: Mike, I know you are aware of the differences of Compiz
>>> and Compiz community, and I also know that you are aware of the fact
>>> that this whole merge discussion is not about Compiz core.
>>>
>> I think this is some sort of false distinction and confusion to
>> try to sell the composited community idea.
>>
>> The post was about depreciating the compiz forums in favour
>> of some new forums for the new software.
>>
>> The whole idea that most of the compiz forum no longer applies
>> to the new software is a joke.
>>
>>
>>>>> Plugins are, libbs is being heavily worked on... It's not because you
>>>>> aren't doing anything in that sense that noone is working.
>>>>>
>>>> libbs and bcop seem to have some useful features which David
>>>> is taking on board. I do not think he is prepared to accept libbs
>>>> or bcop and he is implementing the features independently.
>>>>
>>> Libbs and BCOP obviously won't be included into Compiz core - but they
>>> are prepared for usage with Compiz. From my understanding, that's what
>>> all this stuff is about.
>>>
>> As I said before you are only interested in the headline
>> features.
>>
>> I do not really see the benefits of libbs or bcop and any benefits
>> there are seem to be getting into compiz in another way.
>>
>> I really believe that those 2 pieces of software will become legacy
>> very quickly. Not flaming, just my observations so far.
>>
>>
>>>> The two people who seem to be working on the merge are David
>>>> and onestone, but like I said, not a lot is getting through to the
>>>> core.
>>>>
>>> This is supposed to be that way. The only remaining "big parts" are
>>> BTF/FTB drawing (for 3D and transparent cube), cube and rotate plugins
>>> (and perhaps some features from scale). You might have noticed that e.g.
>>> resize is close to be done.
>>>
>> Again, just the big parts
>>
>>
>>>> My answer to 'lets create a new forum for the new software
>>>> and make all posts read-only because nothing applies to the
>>>> new software' is there is no sign that the code merge will happen
>>>> any day soon. Especially once you consider the minor fixes and
>>>> features and fixes. Everyone seems to be only concerned with
>>>> the plugins, libbs and then creating a new forum.
>>>>
>>> What is the code which is not merged that you are talking about? I don't
>>> see any big things pending except the three I mentioned above. Code
>>> merge !== Compiz core changes, you know that as well as I do. Maybe the
>>> term "merge" isn't exactly the best wording, but I'm pretty sure you
>>> already got the idea.
>>>
>> There were > 1500 commits to the beryl svn and hundreds
>> in cvs, and an unknown amount on quinns harddrive.
>>
>> Who has gone through all of them and verified and submitted
>> them to the compiz ML?
>>
>> They will mostly be lost and they will relate to edge cases so
>> will be hard to detect.
>>
>>
>>>> What about the actual reality of what this forum will be
>>>> supporting? Will it be another compiz-quinn 'branch'?
>>>>
>>> Hmm? What should be branched and why?
>>>
>> Who knows? Dennis seems to disagree with Davids decision
>> to require FBO's so unless that can be resolved there will be
>> some sort of lesser-hardware branch.
>>
>>
> This has something to do with cube were I don't see a reason to require fbo's
> to get transparent cube.
>
>
>> Non-FBO owners will already have noticed the loss of blurring
>> under windows. What will happen there?
>>
>>
> A non FBO blur is there (4xBilinar), what you are talking about is the non FBO
> non shader blur of blurfx. I don't think that it makes sense to implement it
> again because cards that don't have shaders have also to slow copy
> operations. It is possible to make also the gaussian blur without FBO's (I
> have a patch for this), but I agree here with David that cards without FBO's
> will be also too slow to do it without.
>
This is exactly the sort of thing that users need, not constantly
being told that everything is 'almost done now'.
Where is the list of features and their current status?
There are still lots of reports of 'this works on beryl, why not here?'
so there must be a some still unaccounted for.
>
>>> Regards,
>>>
>>> Danny
>>>
>>> _______________________________________________
>>> 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