KGlobalSettings::completionMode() can be read, is not consistent in KDE though

[Dawit A.]

On Sunday 25 April 2004 21:20, Aaron J. Seigo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On April 24, 2004 11:36, Dawit A. wrote:
> > > On Friday 23 April 2004 21:58, Aaron J. Seigo wrote:
> > > this is why i suggested what i suggested in the first place. sure, we
> > > have a "Default" option but then there is no way to easily adjust that
> > > default.
> >
> > I think you are missing the point. The reason why there is no way to
> > change the global default from individual lineedits or comboboxes is
> > intentional. Not an oversight...
>
> even though it was intentional, it presents a usability issue. not a HUGE
> one, thankfully, but not an optimal situation either =)

I guess we can agree to disagree on this point...

> > > if instead the option was "Use Desktop-Wide Setting" (or something
> > > similar) then the user would still be able to select from the list of
> > > option,s which would then set either the global setting or the
> > > app-specific setting depending on the state of this entry. this would
> > > allow making a change to one lineedit affecting ALL others in KDE,
> > > while also preserving
> > > app-specific behaviour as an option.
> > >
> > > here are the four use cases:
> >
> > [snipped]
> >
> > Too complicated. I had to read this several times to see all the
> > different combinations.
>
> don't confuse "hard to understand all the implications of the
> implementation" with "hard to use". often it's quite complex to create
> something that appears simple. humans have extremeley complex "natural"
> expectations =)

For me as a maintainer I have to understand how things work before I can even 
visualize how a user would use them. It is a matter of principle, at least 
for me, that the more complex things are the more tendency there is for them 
to fail or be hard to maintain and fix. Despite any attempt to hide such 
complexities in intuitive interfaces, such things affect the user because 
fixes for problems or changes will take time to implement and must be tested 
throughly so as not to introduce regression in other parts of the code...

> > It is just asking for trouble if the ability to modify the
> > global default is added directly to individual widgets.
>
> why? you can always easily change it back (the same way you changed it in
> the first place, no less!)
>
> the idea is to make lineedits follow a common global setting unless stated
> otherwise ("make this one edit an exception to the common rule"). 

Which is what already happens right now. There is just no GUI to change the 
default global option.

> i often  don't want the default value, and when i change it in one place
> it's a bit odd for it not to change everywhere elsewhere. haven't i already
> stated my preference?  

And that is where my usability difference with you occurs. I never expect any 
single action I think in a specific application to influence the behavior of 
any other application let alone a global setting like this.  If I modify 
something in one application, I want that change to occur in that application 
and ONLY that application. If I want a global settings change, I go looking 
for it in the control panel. 

> the need/desire to have different sorts of completion in different
> lineedits is likely the exception rather than the rule.  to the user, having  
all the lineedits follow their own completion settings by default probably  
makes it seem rather disconnected and tiresome to tweak each single one. 

Sorry, I want to see the evidence on this... I just do not buy this 
argument. :) Why should the behavior of a lineedit be treated differently 
than any of its other settings ? Case and point is the way pressing the TAB 
key works in KHTML. Users complained to no end that pressing TAB while the 
completion box is visible should select the current highlighted item and 
advance to the focus to the next widget. This behavior is completely opposite 
to what is available in the lineedit widgets by default and used in many 
places by many apps. So why would a user expect that changing the completion 
mode in a text entry widget on a web form would change the completion mode of 
the entire system ?

> i haven't done any specific testing on this, so i'm just relying on common
> sense here. =) i do know it often catches me by surprise =)

Ahh... the normal usability disclaimer :-) But many usability folks state that   
many of the so called "average users", do not change  default settings 
anyways. So why is it necessary to change the current behavior instead of 
telling the "power user" how to modify it in the config file. That is why is 
a GUI option necessary for this particular feature at all ?? Specially one 
that is supposed to be built into a building block component ?

> > I rather see some sort of GUI that allows you to modify all
> > the global settings in a central manner if possible.
>
> well, we (will) have KConfigEditor ... but that's not really a solution
> here. and placing this somewhere in KControl is unecessary when it is
> completely possible to do it from the context it matters: the Completion
> Mode menu.

Why not ? There is absolutely no reason to encourage normal users to change 
text completion modes, no ? The default completion mode chosen should reflect 
the most effective and easy to use one, which the current selection is IMHO. 
So why does the completion mode menu need to be modified for the few that 
change their completion modes ? Could they not be classified as power users ? 
Could this not be done from the Settings Wizard at the beginning ?

Another thing you did not consider is that  the programmer can disable the 
"Text Completion" mode menu option in his/her line widgets. What then ? The 
user would have no means to change the global setting if that is the only app 
(s)he uses (say a kiosk app). In order to change it they have to go and 
fiddle around with the config file just like they would have to today. 
Anyways, I object to adding this to the completion mode menu. I think this is 
the wrong place to add it and so far I have not seen anything to convince me 
otherwise...

-- 
Regards,
Dawit A.
"Preach what you practice, practice what you preach"