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

[Michael Brade]

On Monday 26 April 2004 05:46, Dawit A. wrote:
> > 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...
I don't by that---you seriously think the current solution is _optimal_? 
Fiddling around with config files?

> > 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.
C'mon, we are probably talking about a whole lot of 5 lines of code, if at 
all! Part of the cases Aaron listed are to be implemented in the 
applications, not in the lineedit, anyway.

> 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...
I'd agree if we were talking about >200 LOC.

> > 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.
hmm? Isn't this what we were arguing about and now you agree on it suddenly? I 
suspect a typo in here somewhere...

> 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 ?
Because he then checked the item "Use as Global Setting"? Or whatever it will 
be called.

> 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 guess you could ask the same question on every feature we have and then 
remove the configurability in form of a GUI for it. This is, frankly, 
ridiculous.

> > 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 ?
?!?? And I guess there is absolutely no reason to encourage normal users to 
change the window decoration, for example.

> The default completion mode chosen should 
> reflect the most effective and easy to use one, which the current selection
> is IMHO.
Yes, and this is true for the default window decoration as well, IMO. Oh, 
wait, is this about taste? Hmmm....

> So why does the completion mode menu need to be modified for the 
> few that change their completion modes ?
How many is "few"? How do you know? I don't know, but I know that the current 
solution is not optimal and this is what counts.

> 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 ?
This is a special case and not even done in KDE AFAIK. And this can as well be 
applied to any other case where an app behaves out of place. Nothing we can 
do about.

> 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...
The facts that the current solution can be improved, that there is no GUI for 
changing the default, that there is no obvious place in KControl for a config 
option, and that there is already a totally superfluous entry called 
"Default" [1]---if that is not enough to convince you, then I will simply 
give up and wait for a new maintainer in a couple of years.... ;-|

Regards,
  Michael

[1] the entry "Default" is superfluous because the user usually doesn't even 
know what the default is without clicking on it. Why would anyone want to 
click on it when all the options are readily available and much more obvious?
To think that he could change the kdeglobals file and thus make this one 
follow automatically? Hah. Sure. On top of that, the option disappears after 
clicking on it which is a short moment of surprise until this complex (!) 
behaviour is fully grasped.

-- 
Michael Brade;                 KDE Developer, Student of Computer Science
  |-mail: echo brade !#|tr -d "c oh"|s\e\d 's/e/\@/2;s/$/.org/;s/bra/k/2'
  °--web: http://www.kde.org/people/michaelb.html

KDE 3: The Next Generation in Desktop Experience
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040426/83f62b16/attachment.sig>