[Compcomm] My ideas (for the record)

[Mike Dransfield]

Danny Baumann wrote:
> Hi,
>
>   
>>> 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.
>>     
>
> Ok, that's something we disagree in then. I think it's better to come up
> with a solution that fills the needs of the vast majority than with no
> solution.
>   

The problem is that compiz is only distributed by default
with 2 settings backends, ini and gconf.

This means that anyone who installs compiz via their package
system will be starting with gconf most likely.

If your GUI app seems to work, but does not changes the settings,
it will assume it is broken.

If they do eventually work out what their 'start script' is and then
they manage to edit it correctly.  They will find out that all their
previous settings are not lost.

They will then complain that this thing broke their settings and
it does not work.

I recon that the percentage of compiz users using cpp now is
probably < 30% and in the long term (once its installed by
default on all distros) I think that the number will be much
more like 10% of the total userbase.

So your solution does not fill the needs of the majority of users
by a long shot.  Maybe amongst regular forum users the figure
is closer to 70% but you forget about the quiet ones.


>>> 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.
>>     
>
> Only the settings GUI was rewritten (too) many times, the rest was not.
>
>   
>> 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)
>>     
>
> That's not true. The libbs -> libccs and libccs -> libcompizconfig
> didn't affect the code at all besides some struct and function name
> prefixes.
>
>   
>>>> 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.
>>     
>
> That's not true. I didn't like needing to rewrite libberylsettings, but
> it was needed due to some shortcomings and dependencies we didn't want
> (glib). Unfortunately, libberylsettings was designed _before_ I and
> Dennis got involved, so those people (we two) who rewrote libbs weren't
> involved in the first design phase.
>   

Wouldn't it be good for everyone to go back to the design
phase and make something once and for all?

A post on the compiz mailing list with the details should
start the ball rolling.

>   
>> 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.
>>     
>
> Hmm, yes, might make sense.
>
>   
>> 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.
>>     
>
> ACK (besides of the wording :-P )
>
> Regards,
>
> Danny
>
> _______________________________________________
> CompComm mailing list
> CompComm at Rock3d.org
> http://www.ubaight.com/mailman/listinfo/compcomm
>