ubuntu-l10n-de-community team mailing list archive

[Gustav Sony <sony-qs@xxxxxxx>]

Wie der Betreff schon sagt, bin ich der Meinung in der Launcher 
Quicklist (Kontextmenu des Starters) sollte statt "Schließen" in Zukunft 
"Beenden" stehen. Ausgangspunkt ist "Quit" was im Regelfall das Beenden 
eines Programms  veranlasst. Die Inkonsistenz ist mir aufgefallen als 
vor kurzem in der Unitiy-Design (früher Ayatana) Liste darüber 
diskutiert wurde, ob "close" oder "quit" besser ist.

Unter anderem war auch Mark Shuttleworth derselben Meinung wie ich, dass 
man mit dem Starter eine Anwendung auch Beenden können sollte, undzwar 
vollständig. Wer noch etwas mehr lesen möchte, ... ich habe einen Teil 
der Diskussion angehängt.

> Am 26.02.2012 22:53, schrieb Gustav Sony:
>> Great decision! If the user "quits", the app has the duty to obey! 
If that wasn't users' will next time he knows the consequence! Also it 
should be possible for developers to add a "hide to tray/panel" like 
"Open new Window" (e.g. Firefox does it). That could resolve the 
"Transmission"-thing ...
>>
>> In my opinion the launcher should work with a higher priority like a 
"task manager" to be able to kill non-responding apps.
>> For Example: If a (self written) script, tool or program running in 
a closed loop it's hard to open the "system monitor" or "htop" ... 
right-click the launcher and quit!
>>
>> Am 26.02.2012 08:26, schrieb Mark Shuttleworth:
>>> No, "Quit" should quit. It might do so graciously, offering you the 
chance to save files, but the end result should be that the little 
triangle disappears altogether; the app is stopped.
>>
>> Am 26.02.2012 10:02, schrieb Paul Sladen:
>>> On Sun, 26 Feb 2012, Jo-Erlend Schinstad wrote:
>>>> Or will the launcher wait a certain amount and then kill it,
>>> Waiting, then killing, is generally how forcible-quit systems work.
>>> You send the application a (polite) signal/request, and if it is not
>>> effected during some $timeout you forcibly terminate the list of
>>> processes belonging to that application.
>>>
>>> You may have seen sometimes that when an application stops responding,
>>> its window is faded to grey.  This detection is already there to some
>>> extent.
>>>
>>>> updates to be sent, etc. This can take some time.
>>> The design desire is likely to be "make this closure process faster
>>> than the Quit threshold".  These closure updates are a nice-to-have;
>>> If the power goes off, the kernel crashes, or a digger goes through
>>> the ADSL connection, the closure updates would not be sent either.
>>>
>>> If the user has asked that the application to Quit, that's probably
>>> what they should be getting.  At the very least I'd expect eg.
>>> Transmission, to stop tying up resources (screen real estate and
>>> disk/memory).
>>>
>>> If applications avoid that request still further, by forkbombing new
>>> copies of themselves against the user's will, then I can foresee a
>>> situation where you'd ultimately enforce it with individual sandboxes.
>>>
>>> That said, the user is in control here, and applications really should
>>> be designed to respond to the users' wishes, within the temporal
>>> expectations of those users'.
>>>
>>>     -Paul
>>>Am 23.02.2012 21:49, schrieb Gustav Sony:
>>>> You talk about the quick-lists in the launcher?
>>>> It does not make sense to "close", because after closing the 
program can still run and the launcher can not decide which window to 
close. In the quick-list should only be "quit", which makes the program 
shut down.
>>>>
>>>> Ctrl+W is the short-cut to close (a window)
>>>> Ctrl+Q is the short-cut to quit the whole application.
>>>> ALT+F4 is using the close (x) of the window I think
>>>>
>>>> !!!
>>>> Please change it in the German Translation from "Schließen" to 
"Beenden".
>>>> !!!