3.2 issues :(

[Frans Englich]

On Sunday 18 January 2004 16:11, you wrote:
> On Sunday 18 January 2004 03:08, Frans Englich wrote:
> > >   Sorry, it's a feature that I had it configured to show the date and
> > > now it decided that I shouldn't be seeing that date?
> >
> > Yes, that's pretty much it. Someone sets a default, at a later date
> > someone finds a better default and changes it.
>
>    This is not just changing a default. This is changing a user's concious
> setting.

Yes, apparently the behavior /ignores/ the user's selected value, and that is 
wrong and a bug.

>
> > I understand you want to see the date on your 2560x1024 display but the
> > defaults for KDE can't be set solely for developer's setup's. I'm only
> > judging your wording:
>
>    Nor can it be set solely on being compatible with equipment that can't
> even be purchased anymore!

Purchaseable or not, it is still very much used, and more used compared to 
2560x1024, I would say. We should also take into account developing 
countries, for example Lund's(Sweden) University ships their old computers to 
the Balticum countries - regions which open source is appealing to.

>
> > "It's a feature that I had it configured to show the date and now it
> > decided that I shouldn't be seeing that date?"
> > "has lost track of the fact that I like to see the date along with the
> > time."
> >
> > Tell me why all KDE users should use defaults which this "I" wants. Looks
> > like "developer bellybutton" syndrom to me...
>
>    No, you don't get it.  I, as a user, set a setting.  KDE came along and

Yupp, I don't get it.

> changed it on me because some deity KDE developer decided that his idea for
> that setting was better.  You tell me.......

Yes, this was no one's attempt. AFAICT, it is a "feature" of the KConfigXT 
framework, since my patch clearly only changed the default value(counting 
relevant changes). To clarify; I only wanted to change the default - not make 
the implementation ignore the user's pee-existing key's.

>
> > > If it is an issue for
> > > 800x600 displays, why not only disable it on 800x600 displays and leave
> > > it alone on 2560x1024 displays?
> >
> > You mean doing a check runtime? What an overkill for such an little
> > thing.. I don't know how KConfigXT would cope with that. It's for several
> > other reasons bad having "dynamic" defaults.
>
>    What about KPersonalizer?  That's a big reason why we have KPersonalizer
> to begin with.

If you ask me, we should only try to reduce KPersonalizer, not make it bigger. 
There's also practical problems with putting a such thing in KPersonalizer.

>
> > It is actually not that obvious the date label is wanted. The text is
>
>    It's clearly wanted by me if I set it that way.

Yes, and I think the opposite. But I didn't propose it for that reason - I 
pushed the change since there were arguments which made it apply to a 
significant part of KDE's userbase.

>
> > important because you usually only checks the date about twice a day in
> > /total/, then you know it. And if you still need to check the date(from
> > the
>
>    You mean -you- only check the date about twice a day in total.

Yes, I personally functions that way. But, then there is theoretical 
arguments(as opposed to practical examples) which indicates it applies to 
more than me. And apparently people thought so too. My case could be induced 
to a general case(and as always there's situations, like yours according to 
the reasoning behind this change, that falls outside the userbase the 
defaults settings targets).

>
> > kicker clock) it's there as tooltip, the date picker, Copy to
> > Clipboard...
>
>     Requiring multiple clicks and mouse movement for something so simple is
> horrible.

True, this change was nothing but a compromise which the selection of defaults 
always are. But, the compromisation was done since it was believed in the 
overall picture the positive outcome was bigger. I could outline the cons and 
pros of the new behavior and motivate why it's better(IMO), in case it's of 
interest(ie., if there's an interest of reverting the change).

>
> > Tell me why we should show the date, because it's not obvious.
>
>     You don't understand.  I didn't say we have to show the date for
> everyone. I said that disabling the date on a migration path, that is
> someone updating who had the date and now no longer has it, is wrong.  This
> is "KDE Developer X knows better than you about whether or not you should
> see the date."

No, it's not the situation your quote because this was all a communication 
error. In my reply to your initial message I thought you didn't like the 
default setting, when you actually refered to that it /ignored/ the user's 
setting. But, in your reply to my reply, there was no indication that I was 
wrong - instead the comment was "it's a feature that I had it configured to 
show the date" which I (again) interpreted as being about the default 
setting, and I can't blame myself for doing such an interpretation. And then 
the (FUD) machine started rolling.
I can't look into it now, but if changing defaults in the KConfigXT framework 
means ignoring the user's pre-existing key's(if this cases can be generalised 
to that) that is pretty serious, and atleast cumbersome if kconfig_update 
must be dragged in. If this is the case, <(KDE 3.2)< is probably broken in 
similar ways in other places, AFAICT.


Cheers,


			Frans