[Compcomm] My ideas (for the record)

[Mike Dransfield]

Danny Baumann wrote:
> Hi,
>  
>   
>> Maybe I really just don't understand the "magic" behind the libbs - and
>> maybe an informative forum-post under "Application Development" would
>> have made me understand better? Who knows. 
>>     
>
> I will try to write such an explanation within the next few days. I'm
> not very good in writing such explanations, so please bear with me ;-)
>
>   
>> But there was close to no
>> effort to do so. That should change. We need to talk to each other to
>> avoid duplication of things. Actually, we should talk _before_ we
>> act ... even if it may appear to take longer, in the end it doesn't.
>>     
>
> ACK in principle, but there's always the risk that we "discuss things to
> death" (such as the project name...) and in the end nothing will be
> done. I'm not saying that this will happen everytime something is
> discussed, but we should not forget that risk.
>   

We need to at least know what the issues are, coming up
with nothing IMHO is better than coming up with 2 competing
solutions that each dont really fill everyones needs.

>   
>>> libbs/libccs/libcompizconfig has been criticised more times than anyone 
>>> can be bothered to count. Many Beryl plugins have been said to be 
>>> impulsive, poorly thought-out, and unmaitainable.
>>>       
>> Yes, but now they have been rewritten and redesigned several times 
>>     
>
> Hey hey hey, it was rewritten exactly 1 time - from libberylsettings to
> libbs. The reset were just name changes.
>   

Only if you include the library.

If you include the entire settings 'ecosystem' which includes
the plugin, the library, the bindings and the gui then it has
had many many lives over the last year.  I challenge anyone
to list all the names of each settings gui since compiz-quinn.

Most name changes went with a 'total rewrite' (although after
hearing the zoom changes described as that, I'm not sure what
it means anymore)

>   
>> and I
>> could imagine that it is getting better and better (but I don't really
>> know for sure due to the above reasons). Since Danny, Dennis and the
>> other beryl-devs now work closer with David, there has been some effort
>> to find well-designed alternatives to several rather "hackish"
>> approaches.
>>     
>
> Exactly, that was the main motivation behind rewriting it.
>   

Isn't it better to design requirements before starting coding?

Rewriting anything is a very bad because it is admission that
your original design was totally wrong and unworkable.  It also
means that a lot of time is wasted.

For some reason you think something being 'completely rewritten'
is a good thing.

>   
>> beryl? The better solution would be to let the users select from a set
>> of small sub-projects which are each easy to install and ready to use. I
>> think the separation Mike proposed would be best (configuration, bling,
>> usability, ...).
>>     
>
> Hmm, but there's one problem again: You will have stuff that doesn't fit
> into one category entirely - so what to do with that stuff? ;-)
> E.g. is the ring switcher plugin usability (as you can see more windows
> while switching) or bling? That's why I'm not convinced of this category
> idea yet...grouping them by author (group) (i.e. having a 'compcomm'
> subproject) could have the advantage that people already know 'ok, I
> know these guys, I can safely install that stuff' (or vice versa :-P ).
>   

Couldn't these should just go into a general improvements, or
(dare I say it) an extras package?  I assume you are talking
about packaging?

The development and announcements does not need a separate
project because as you say its not really a niche, its just an
enhancement (like scaleaddon).  There are a few plugins I have
which would be good in that group.

I think that grouping people based on what cult they belong to
is very damaging and segregates things on grounds which
make no sense to the average user.

What would compcomm stand for in this instance?

I thought it was short for Comp(osited|iz) Community?

> Regards,
>
> Danny
>
> _______________________________________________
> CompComm mailing list
> CompComm at Rock3d.org
> http://www.ubaight.com/mailman/listinfo/compcomm
>