[Compcomm] My ideas (for the record)

Sat Jun 16 16:45:44 EDT 2007

Franz Rogar wrote:
> I didn't want to reply to this thread because it went in a good shape.
> I say sorry for been rude, but I can't close my mouth.
>   
Don't worry about it ;)
> 2007/6/16, Mike Dransfield <mike at blueroot.co.uk>:
>   
>> 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.
>>
>>     
>
> I must say that 100% of spanish ppl on forum use only ccp (so I think
> < 30% is a FUD). Why? Because:
>   

That is my point.  Only people who manually download (ie
seek out the extra packages will have ccp installed).

So you WILL see that high percentages of your users use it,
what I am saying is that a large percentage of the non-forum
using public will use either gconf or ini.  This will lead to a
distorted view, but I can assure you it is not correct.

> 1 - About gconf: There're many KDE users and they don't need/want at
> all to install  the gconf depencies. Meanwhile, ccp has no
> dependencies at all. Also, gconf-editor is a pain.
>   
No dependencies?  Really?

This is confusing the GUI with the backend storage.  Its
the usual confusion.

Gconf is just the storage mechanism, its not the GUI.

> 2 - About ini: if gconf-editor is a pain, ini is the Hell for
> end-users. Also, I runned it only one time and dropped it to the
> forgotten. If there's any non-human-alike way to configure Compiz,
> this is it.
>   

Again it was never designed to be manually edited - its
just a storage plugin.

Any GUI can be run over the top of this, but you can still
edit the files manually if you want.

> 3 - About ccp: you can load any of gconf or ini backends (if you
> want), so you can use any of them. ccp works out-of-the-box and have a
> nice gui backend which works, because it's python-based.
>   

No dependencies?

>   
>> 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.
>>
>>     
>
> So far I've seen, this is the only solution to end-users that fit
> their long shot. Also, there're many advanced users that doesn't like
> neither gconf nor ini, so why do you want to restrict their freedom to
> choose the way they want to configure Compiz?
>   
Anyone who says they do not like to use gconf or ini is
just confusing the backend storage with the GUI.  They
should not be linked.
>   
>>>>> 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.
>>
>>     
>
> The way it's now, the best approach would be fixing known issues and make this:
> - Dependencies graph (source code level)
> - Mindstorm to make it better
> - Implement new features suggested on mindstorm
>
> The worst way would be dropt it away and say to users: you can't
> 'cause we dropped it away. That's a nonsense.
>   
Whats the point of developing something which
by definition will not be used by the majority of
users?

Isn't that a bit exclusive?

>   
>>>> 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
>>>
>>>       
>> _______________________________________________
>> CompComm mailing list
>> CompComm at Rock3d.org
>> http://www.ubaight.com/mailman/listinfo/compcomm
>>
>>     
>
>
>   