Make kde 1st class in fedora

Avi Kivity avi at argo.co.il
Sun Nov 19 08:53:13 UTC 2006


Nicolas Mailhot wrote:
>>> That's a common misconception.  Lots of users are perfectly ok with
>>> text configuration files, and even often like them more, because:
>>>       
>
>   
>> How many of these users are IT workers or computer enthusiasts?
>>     
>
> Yea, right, ever tried to explain a GUI procedure to someone over 40
> (aggravating factor : over the telephone) ? They don't know what
> right-click is, 

That's their first week on the computer, right?  But they've already 
mastered vi.


> they don't know conventions, they get hopelessly
> confused by renamed menu entries or new themes that change icons they're
> used to. 

Sure, an application upgrade can be confusing.  But at least the 
applications can be upgraded.  With configuration files, it's impossible 
(try to imagine a user diffing /etc/blah.conf with /etc/blah.conf.rpmnew 
to get their machine to work).

(and it seems you're advocating that applications should never change 
rather than they should use config files).

> GUI power is massively overrated (even when it's designed
> properly in the first place, which is the exception, especially for big
> proprietary offerings)
>
> (and that's not musch easier for younger people)
>
> Nobody but computer enthusiasts has the time to browse all the app menus
> and screens to find the place where the developper moved the magic
> button designed to help him not writing a text file
>
>   

Please try to watch some real users.  They can get by with menus just fine.

>>> - it's easier to find a file in a specific place than to find the
>>>   configuration-application-of-the-day
>>>   
>>>       
>> It's only easier for developers.  Users know how to open Tools|Options.
>>     
>
> 1. No they don't
> 2. when they do they recoil in horror before the mass of badly qualified
> checkboxes
>   

Sigh.  A badly designed UI is certainly worse than a good UI.  A 
configuration file is a badly designed UI.


>  
>   
>> They have no idea where the config file sits.
>>     
>
> Unlike the GUI, the config file location is usually stable.

Where is it?  My file browser doesn't show it.

It doesn't matter if its stable if I can't find it.

>  They can
> note it down. Mapping a GUI route OTOH is a disaster
>
>   

Screenshot.


>>> - it's easier to find what you want in it, especially when your setup
>>>   is nonstandard in any slight way.  Things hidden in the new tab of the
>>>   day which appears only when you click on allow advanced in a dialog
>>>   box coming from a menu can be quite frustrating.  In other words, the
>>>   interface part of a text configuration file is much harder to fuck up.
>>>   
>>>       
>> If the configuration file is of any size at all (postfix, apache) you 
>> have to read a huge text file to find something.
>>     
>
> And usually you have the text explanation right next to the config
> option. With examples even. You don't realise what a godsend it is after
> the 3-word explanation you have next to a gui checkbox
>
>   

Again you seem to think that a voyage into the application's design is 
more suitable for the user's attention span than clicking '[x] Beep when 
new mail arrives'.


>> If the configuration file omits some of the options, you have to read 
>> the manual page.
>>     
>
> Hint : do you actually think people grok GUIs without manuals or helpful
> power users to explain them what the heck the convoluted label language
> means ?
>
>   

Convoluted label language is no different than config_file_keys.  If the 
UI is bad, fix it.


>>> - you can google using its contents
>>>   
>>>       
>> Shouldn't you try the application's help first?
>>     
>
> ROTFL you're hopeless
>
>   

You mean, googling a database of all web pages, including other versions 
of the same program, other programs, to find a poor user that 
experienced the same desire as you and went to the trouble of posting to 
a mailing list is better than consulting an authoritative text that 
comes with the application?

If so, hopelessness is indeed in order.  For desktop Linux.


>>> - you often have useful comments in them, where the GUI equivalent
>>>   requires a number of manipulations to access
>>>       
>
>   
>> Context-sensitive help?
>>     
>
> Right-click, what's a right click ? What's a right-clickable object ?
>   

You seem to be against GUIs in general, not just for configuration.

People do know how to right click (or do the equivalent on Apple).

> Why do you think apple gets by with a single button mouse ?
>
>   

The option key?

>>> - it's way easier to talk about it in email
>>>       
>
>   
>> Especially for developers who dislike html mail.  Users don't want to 
>> talk about options, they want to change them.
>>     
>
> No. Users don't want to talk about options period. They don't want to
> change them be it in the config file or in the GUI
>
>   

How do I add an e-mail account?  The beep on a new mail message is 
annoying, can I disable it?  All my friends have kittens on their 
desktop background.  I want one too!

Users want different things.  That's why there are configuration options.

>> An example:  Thunderbird's Edit|Preferences|Display, "Plain Text 
>> Messages" group, 'Wrap text to fit windows width' checkbox, vs prefs.js 
>> mail.wrap_long_lines (it isn't there, you have to google for it or look 
>> in Thunderbird's config editor)
>>
>> [yes, it's easier to type in an email.  but you'd get unwrapped text 
>> much. much sooner with the GUI]
>>     
>
> That's remain to be proven. Comparing speed once users have learnt the
> GUI is cheating.
>   

With a GUI, you need a basic skill set (navigating menus) and no more.  
With a configuration file, you need a lot more knowledge and time.

>   
>> For system administrators and developers, text files are fine.  For 
>> normal users, let them have their GUI.
>>     
>
> If only it was their GUI and not some monstruosity designed to show of
> everything is GUI-accessible…
>   

I don't understand this remark.

-- 
error compiling committee.c: too many arguments to function




More information about the fedora-devel-list mailing list