Lock/logout interactions

Michael Rudolph michael.rudolph at gmail.com
Tue Mar 11 14:01:54 CET 2008


On Tuesday 11 March 2008 01:36:21 Aaron J. Seigo wrote:
> On Monday 10 March 2008, Michael Rudolph wrote:
> > It might be hard for software engineers to see, but the absolutely
> > best solution to place these features is outside the "software" and
> > on the hardware.
>
> unfortunately we don't control the hardware.
> nor do we control the state of people's expectations.
>
> if we were starting from scratch here (with people's expectations)
> and were shipping our own hardware, i'd go along with you.
>
> sadly, the power buttons on many systems are not in easy reach (my
> desktop is waaaaay under the desktop, for instance; this is quite
> common in corporate/school envs) and many people are not comfortable
> with just hitting the power button on their machine without some
> software interaction ("will i lose any data?!")
>
> what i would suggest is that it might be nice to offer a
> (non-(main-)gui) mechanism to define which entries do appear in the
> menu, such that those who are shipping their own hardware might have
> a chance at a decent system.
>
> wanna put together a patch? =)

Hello everyone,

Marco already raised an objection along these lines. And you are of 
course both right. Honestly I didn't even think about those (ancient) 
systems under people's desks.

So what I really wanted to say was, there are two ways of doing logout 
interactions: in software, as we currently do, out of necessity or in a 
combination of software and hardware, which, as I maintain, would be 
the ideal solution.

I guess it would be a good start to offer also a solution for the latter 
option and also account for hardware interactions.
My suggestion than was, to call the common case "special case" and the 
rare case, where acpi was working correctly, the "real thing". This way 
I hoped it was possible to shift people's awareness for how a good tool 
needs to be designed; namely having the complete user experience in 
mind, where you don't distinguish between hardware and software.

As for the suggestion to provide code, I'd gladly comply, but be aware 
that my contributions might be of purely entertaining value to the 
reviewer and will not help the project along. Well seriously, I hope I 
can put my meagre python knowledge to good use once KDE4 is in the 
FreeBSD ports tree, but until then I can only hope that my 
pointy-headed comments don't get on people's nerves too much.

michael


More information about the Panel-devel mailing list