[Compcomm] My ideas (for the record)

[Mike Dransfield]

Franz Rogar wrote:
> 2007/6/16, Mike Dransfield <mike at blueroot.co.uk>:
>   
>> Alyssa Hung wrote:
>>     
>>> Mike Dransfield wrote:
>>>
>>>       
>>>> Alyssa Hung wrote:
>>>>
>>>>         
>>>>> 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.
>>>>>>
>>>>>>
>>>>>>             
>>>>> Indeed. Many, many users are grateful for having access to tools that
>>>>> make the mystique of configuration comprehensible to them. Many, many
>>>>> users also appreciate having access to plugins that are CLOSE ENOUGH to
>>>>> do what they wish, even if there are technical limitations that can only
>>>>> be properly addressed at a much later time.
>>>>>
>>>>>
>>>>>           
>>>> This is my problem, it is not necessary to design a different
>>>> configuration system just to have a user friendly GUI.
>>>>
>>>> Users do not understand this distinction so when they hear
>>>> about people saying libbs is crap then they hear 'gui tool is
>>>> crap', thats not the case at all.
>>>>
>>>> I am fairly sure we have been saying this for a long time.
>>>>
>>>>         
>>> I admit to not having researched grahpical Compiz configuration tools
>>> extensively, but at the time I started with compiz-quinnstorm, the most
>>> graphical tool available was gconf-editor. And that was confusingly
>>> divided into settings for "all screens" versus "screen0". There was no
>>> plugin dependency resolution.
>>>
>>>       
>> You can still use this as a fallback in compiz, but it is not
>> the only means.
>>
>> I think it is very important to have a fallback because there
>> have been a few notible cases where people are left without
>> without features because of a bug in the settings manager.
>>
>> Editing libbs config files is not user-friendly.
>>
>>     
>>> I don't doubt that better solutions now exist for Compiz. If I recall
>>> correctly, the latest generation of beryl-settings was partly inspired
>>> by screenshots (or mock-ups?) of a Compiz configuration tool.
>>>
>>>       
>> Yeah - I forgot that :)
>>
>>     
>
> Nope, you both are wrong. I was the one who did the mockups of
> beryl-settings. And I did them FOR BERYL not for Compiz.
>   

Yeah - but he was saying that it looks like this

http://forum.compiz.org/viewtopic.php?t=153

I dont know either way, all I remember was users saying
how nice the new compiz config tool was.

Then some peoples mouths slipped and the rest is history.

>   
>>> But the fact is that Beryl got it done FIRST. Perhaps it's not a fair
>>> way of passing judgment, but you know that users and developers don't
>>> necessarily share the same perspective.
>>>
>>>       
>> Technically it was done first in compiz-quinn, but if
>> the fork had not happened it would have been done
>> in the same time for Compiz.
>>
>>     
>>> Beryl also got an assortment of much-requested plugins done first, such
>>> as inputzoom, which cleverly circumvented the need for proper input
>>> transformation.
>>>
>>>       
>> For a moment then, I thought you were going to mention
>> plugins like animation and group.  You need to work on
>> identifying your strengths better ;)
>>
>> Where is inputzoom now?
>>
>>     
>>> "Usable" and "first" make bigger waves amongst the users than "process"
>>> and "maintainable". It's perfectly fine for better solutions to
>>> supersede obsolete solutions. As long as there's an immediate solution,
>>> it's easy to be patient.
>>>
>>>       
>> Yes - This is perfectly valid, it all really depends on a
>> case-by-case basis as to what is 'worth it'.
>>
>>     
>>>> This does not make sense at all.  The backend was already
>>>> ready.  This is a case where it would actually be faster AND
>>>> produce a better result to use dbus for communication.
>>>>
>>>> Have a look at compiz-settings.  IMHO it was way better than
>>>> anything else I have seen so far.  It took a fraction of the time
>>>> to produce libbs/ccsp/ppsc-settings etc etc.
>>>>
>>>>         
>>> I am no authority on these subjects, but as a user, I have never managed
>>> to get DBUS to work. Beyond prepending dbus-launch to the compiz command
>>> line, dbus-send and the rest never worked for me. Given enough effort, I
>>> can definitely solve the problem.
>>>
>>>       
>> I expect you are using an old distro, the gnome/kde
>> session needs to be started with dbus-launch.
>>
>> The alternative would be to access the backend directly,
>> even that (which is used by gnome-compiz-settings) is a
>> better solution than libbs.
>>
>>     
>>> But because libbs was both available and simple (just one more thing to
>>> compile; no system-wide configuration, no chance of inadvertently
>>> breaking other packages), and because Compiz was the only thing that
>>> required DBUS on my system, I haven't been suitably motivated to get to
>>> the bottom of my DBUS woes. This will change, too; KDE4 is coming and
>>> it's all about DBUS.
>>>
>>> But you see what I'm saying about immediate solutions versus proper
>>> solutions? Users are not going to jump through hoops to accommodate one
>>> program, especially if there's another one that does the same thing, but
>>> more easily.
>>>
>>>       
>> Nobody ever said you can never work on short-term hacks.
>> Just dont be upset if they have lots of bugs and other problems
>> and they are thrown away eventually (possibly before the real
>> solution arrives)
>>
>> Other developers will point this out but everyone is free to do
>> what they like.
>>
>>     
>>>> The side effect of using the proper methods is that everyone
>>>> will be able to use it, not just the small few who install all the
>>>> dependencies and change their start script.
>>>>
>>>>         
>>> Yes. DBUS will become critical to many systems in the near future, and
>>> is surely the way to go moving forward. But the near future is not
>>> today. Frustrating, isn't it?
>>>
>>>       
>> I have not seen anyone with major problems with dbus,
>> it is used in KDE 3.5 too.
>>     
>>> It's ironic how Beryl accumulated so much mind share precisely because
>>> it did things impulsively. Compiz was a critical part of the equation
>>> even then; if the Compiz developers had quit while Beryl was ahead,
>>> where would we be today?
>>>
>>>       
>> You don't think that possibly some of the 'mindshare' came
>> because of effects 'inherited' by Compiz?
>>
>> A lot of heartache was caused because things were not
>> thought through properly (that includes beryl AND this
>> merge)
>>
>>     
>>>  From a user's perspective, it may be best for immediate solutions and
>>> proper solutions to be developed concurrently.
>>>
>>>       
>> Yes, nobody has a problem with that.  Its often the
>> case that the proper solution cannot be done by the
>> developer doing the quick solution.
>>
>> Look at my scripting plugin, its the definition of hacky
>> but I made that clear to people.
>>     
>>>>> Not cult. Culture. ;) Some of us users feel threatened by the notion
>>>>> that we'll have to change, maybe change a lot (our posting habits,
>>>>> expectations of the sorts of responses we will receive, etiquette, ways
>>>>> of eliciting meaningful responses, verboten subjects, dress codes,
>>>>> etc.), to integrate well into the Compiz society. Please show me that
>>>>> these fears are unjustified.
>>>>>
>>>>>
>>>>>           
>>>> Who said you had to change any of those?
>>>>
>>>> The whole point of these discussions is so that we can
>>>> find a way to accomodate everyone in one place working
>>>> towards common goals (or something like that).
>>>>
>>>> The only rule would be post in the right category, but I
>>>> think you have that rule on all forums.
>>>>
>>>>         
>>> A cursory glance at forum.compiz.org shows an abundance of posts that
>>> are well-researched, concise, and evidential of the poster's
>>> professionalism. This is, how do I say... Intimidating? When the
>>> majority is so sophisticated, it makes ordinary people feel unfit.
>>>
>>>       
>> I am sorry to hear that, I am not sure what to say other
>> than delflick posts there, and I dont *think* he feels
>> intimidated.
>>     
>>> And though the aesthetics of the visual style have clearly been thought
>>> through, it's too clean. Always pristine, as though uninhabited. Do you
>>> ever have a feeling, when walking into an extravagant citadel, that you
>>> shouldn't touch anything? That's a bit like how forum.compiz.org's theme
>>> feels.
>>>
>>>       
>> Yes maybe you are right, I remember RYX mentioned at
>> the time that maybe it could do with a bit more colour.
>>
>> The way to change it would be to post a request for a bit
>> of a facelift.  If you can help with some mockups then all
>> the better.
>>
>> LOL :)))  :!!!1 :D
>>     
>>> Unintentional, perhaps. But implied nonetheless.
>>>
>>>
>>> ~Alyssa
>>> _______________________________________________
>>> 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
>>
>>     
>
>
>