I wonder myself why this clear desing bug is a WONTFIX. Several other companies realized themself a long time ago that there must be a swipe to answer when the device was locked. A device is the most time locked because of a good reason!

Look at HTC, Apple... swipe for answer, because the proximity sensor works only sometimes in this case. And Nokia themself realized this!
At their Touchscreen 5800 Mobile they have Buttons on the touchscreen. When Buttons are so good, why have they replaced this at the Nokia N97 with "swipe to answer"?

And why have we a swipe to unlock when we press the power Button instead of a simple button on the touchscreen?

This is a inconsistent design!

Hmm... it seems Nokia and the Symbian team realized this themself. Only the Nokia Team haven't unterstood that the N900 is now small enought for a pocket. It's not longer a Desktop system!

And they say themself here at Bug 5982 #3 it could get part of a future Maemo planning.

This is really disappointing. We've got the device and problems now. When there is not a solution for fremantle comming, we need a fast workaround until Maemo 6 is relased.

The call / alarm event should trigger both the main gui (i.e. the calling interface) and a parallel / consecutive secondary event.
This secondary event is just a superposing of a mask (a simple picture) that contains either a slider or two distinct buttons, say 1 and 2; in order to get an action, first you will have to move the slider on the mask or to push the buttons in order: first 1 then 2. This action would be required only to clear off the mask, not to answer the call / stop the alarm. After clearing off the screen, you can answer the call / stop the alarm.

The issue I see here is making the mask available for both portrait and landscape, then to make the mask semi transparent in order for the event behind it (be it an incoming call or an alarm) to still be visible.

I think a simple draw would be more useful than my complicated description...

Yes, you're right.
But I guess I get the point. You want a shaded block screen in front of the phone, alarm and calender when the device was locked? Am I right?

Mmmh... I'm not sure. Could I imaginate myself to like it? But my opinion doesn't matter. The Community should decide.

It seems to be very similar to the suggestion from tokag. Hmm... something like that and yours in combination could be fine.

Are you able to draw a mockup and create a Solution with a uncomplicated description at the Brainstorm?

Here is a mockup; it is similar to tokag's with only one difference: the mask is a distinct event. Thing is in the brainstorm everybody voted for a wontfix... Instead, this is a (unappealing) workaround

Mmmh... looks good. I don't know how hard it could be to program and implement it. But I guess it could work. And it should be quite easier than changing every application.

But there should, in my opinion, be a fast way to silent a event on a fast way. Think about you're sitting in a conference or in a cinema. But it could simply work only by tapping the screen with a uncovered proximity sensor. It has just to silent every sound output until the event disappears or the screen is unlocked by the user. (slider on the screen or the unlock switch at the device)

Please add it as a solution to the Brainstorm. I will vote for it!
If you don't know how, please feel free to ask.

Does someone try this packege
http://maemo.org/packages/view/call-locker/
?
How does it look like?:)

I haven't seen this before. Thank you.

I guess it keeps the screen locked when a call is comming in. But I haven't tested this myself.

It relocks the screen when it was unlocked by an incoming call, but it only does it once per call, so it will not work in a cases when the screen is a few times locked/unlocked by the proximity sensor. It also has a lag of 1-6 seconds in relocking.

Okay ...and it does not work with alarms from the calendar.

Hopefully we get swipe to answer feature soon.