Start new session...

[Martijn Klingens]

On Sunday 13 October 2002 22:57, Oswald Buddenhagen wrote:
> > With that default value changed the KDE 3.0 behaviour is much less
> > dangerous, no?
>
> it is way more "dangerous". you probably weren't "hit" by it, otherwise
> you would know. the old behavoiur was simply starting a new xserver
> without any feedback or additional actions required, when the screen was
> locked. this can be cool, but mostly it's only very irritating and
> annoying, even if you know what is going on.

I use it at work with KDE 3.0 so I know what I'm talking about. What I meant 
is that now you disabled it by default you can only hit this problem by 
explicitly turning it on, removing most of the danger from it. And not having 
a kicker/kdesktop GUI to activate it hides it even more from the people that 
don't know exactly what they are doing.

> the problem is, that when i removed this auto-start and did not add an
> explicit way to request a new screen, the feature would be effectively
> gone alltogether. i don't know how many users already enjoy it, but from
> what i've heard, there are quite some.

I am one of them. But I can enable it myself if it's not on yet.

> hey, we are not releasing tomorrow. :}

We are deep into feature freeze and the release comes rather close already 
though.

> from the stability point of view i have no concerns. i'm confident that
> the probability that i broke something is much lower than that some
> grave bugs are in kdelibs. it's simply close to impossible (even for me
> :) to put bugs in that few lines of that simple code. yeah, yeah, famous
> last words ... :)

Would you take the risk? Really? I definitely wouldn't. There are not many 
features that justify ignoring feature and string freezes, especially if the 
code is more than a simple oneliner (and it definitely is a rather large 
addition).

> that depends on the definition. sure, for kicker & kdesktop this is a
> new feature, but for kdebase it's just a moved and usability-wise much
> improved feature.

Sure, but you bring the feature now to a large audience, several orders of 
magnitudes larger than you used to. And the feature is potentially dangerous 
or even disastrous, so either you bring it out perfectly to the general 
public or not at all. There's too much at stake for this feature.

> this is simply not true. only users that already knew the feature will
> be faced with it (and its much improved usability). it's disabled by
> default - and as opposed to before, _no_ new user will ever notice it,
> if he does not read the kdm readme.

I'm afraid distros will enable it nevertheless. Better don't ship it at all to 
avoid that so your above statement is true. If indeed you explicitly need to 
read the readme file before enabling it I consider it safe enough, but if 
there is a chance that a fresh install of distro xyz has this feature enabled 
all hell will break loose and I rather want to stay away from that.

> well, i tried it without a gui ... but this turned out to be
> inacceptable. we need this user's-will-detecting device finally. :)

With 'none at all' I meant 'not activated unless one changes config files 
manually, knowing what one's doing'.
-- 
Martijn