<?xml version="1.0" encoding="utf-8"?>
<page xmlns="http://projectmallard.org/1.0/" type="topic" id="dialogs" xml:lang="de">

  <info>
    <link type="guide" xref="patterns#primary"/>
    <desc>Sekundäre Fenster, die über primären, übergeordneten Fenstern erscheinen</desc>  
    <credit type="author">
      <name>Allan Day</name>
      <email>aday@gnome.org</email>
    </credit>
    <credit>
      <name>Calum Benson</name>
    </credit>
    <credit>
      <name>Adam Elman</name>
    </credit>
    <credit>
      <name>Seth Nickell</name>
    </credit>
    <credit>
      <name>Colin Robertson</name>
    </credit>
    <include xmlns="http://www.w3.org/2001/XInclude" href="legal.xml"/>
  
    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
      <mal:name>Christian Kirbach</mal:name>
      <mal:email>christian.kirbach@gmail.com</mal:email>
      <mal:years>2014</mal:years>
    </mal:credit>
  
    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
      <mal:name>Mario Blättermann</mal:name>
      <mal:email>mario.blaettermann@gmail.com</mal:email>
      <mal:years>2016</mal:years>
    </mal:credit>
  </info>

<title>Dialogfenster</title>

<p>Dialoge sind sekundäre Fenster, die über einem primären, übergeordneten Fenster angezeigt werden. Sie stellen zusätzliche Informationen oder Bedienelemente dar, wie Einstellungen und Eigenschaften, oder zeigen Meldungen oder Fragen an.</p>

<p>GTK+ liefert bereits eine Anzahl vorgefertigter Dialoge mit, die Sie verwenden können, wie beispielsweise zum Drucken oder zur Farbauswahl.</p>

<p>Es gibt drei grundlegende Typen von Dialogen.</p>

<section id="when-to-use">
<title>Anwendungsfälle</title>

<p>Dialoge sind ein häufig verwendetes Designmuster. Es gibt etablierte Konventionen für den Einsatz der verschiedenen Dialogtypen, die Sie verwenden können. Die Richtlinien zu jedem der Typen vermitteln weitere Informationen hierzu.</p>

<p>Während Dialoge einerseits eine effektive Möglichkeit bieten, zusätzliche Bedienelemente oder Informationen bereitzustellen, können Sie beim Benutzer andererseits Unterbrechungen des Arbeitsablaufs verursachen. Stellen Sie sich deshalb immer die Frage, ob ein Dialog erforderlich ist, und versuchen Sie solche Situationen zu vermeiden.</p>

<p>Es gibt viele Wege, Dialoge zu vermeiden:</p>

<list>
<item><p>Ordnen Sie neue Nachrichten, Kontakte und Ähnliches eingebettet an.</p></item>
<item><p>Eingebettete Benachrichtigungen sind eine Alternative zu Meldungsdialogen.</p></item>
<item><p><link xref="popovers">Einblenddialoge</link> können zusätzliche Bedienelemente oder Optionen auf eine weniger unterbrechende Weise anzeigen.</p></item>
</list>

</section>

<section id="message-dialogs">
<title>Meldungsdialoge</title>

<media type="image" mime="image/svg" src="figures/patterns/message-dialog.svg"/>

<p>Meldungsdialoge sind der einfachste Dialogtyp. Es werden Meldungen oder Fragen angezeigt sowie 1 bis 3 Knöpfe, über die der Benutzer antworten kann. Sie sind stets modal, was bedeutet, dass der Zugriff auf das übergeordnete Fenster durch sie verhindert wird. Meldungsdialoge sind eine gute Wahl, wenn es darum geht, dass dem Benutzer eine Meldung angezeigt und eine Antwort angefordert wird.</p>

<section id="message-dialog-examples">
<title>Beispiele</title>

<p>Bestätigungsdialoge verwenden oft einen Meldungsdialog, um zu prüfen (oder bestätigen zu lassen), dass der Benutzer eine Aktion ausführen will. Sie enthalten zwei Knöpfe, einen zum tatsächlichen Ausführen und einen zum Abbrechen der Aktion.</p>

<note style="tip"><p>Bestätigungsdialoge werden oft unabsichtlich oder automatisch »abgenickt«, wodurch Fehler nicht immer vermieden werden. Oft ist es besser, eine Routine zum Zurücknehmen von Aktionen anzubieten.</p></note>

<p>Fehlerdialoge zeigen dem Benutzer eine Fehlermeldung an. Sie enthalten oft einen einzelnen Knopf, mit dem der Benutzer bestätigt, dass er die Fehlermeldung gelesen hat und den Dialog schließen kann.</p>

<note style="tip"><p>Fehlerdialoge sollten generell der letzte Ausweg sein. Sie sollten Ihre Anwendung so gestalten, dass keine Fehler auftreten und dafür sorgen, dass eine automatische Wiederherstellung möglich ist, wenn dennoch etwas schiefgeht.</p></note>

</section>
</section>

<section id="action-dialogs">
<title>Aktionsdialoge</title>

<media type="image" mime="image/svg" src="figures/patterns/action-dialog.svg"/>

<p>Aktionsdialoge stellen Optionen und Informationen zu einer spezifischen Aktion bereit, bevor diese ausgeführt wird. Sie haben eine Überschrift (die typischerweise die Aktion beschreibt) und zwei primäre Knöpfe – einen zum Ausführen und einen zum Abbrechen der Aktion.</p>

<p>Gelegentlich ist es notwendig, dass der Benutzer Optionen auswählen soll, bevor eine Aktion ausgeführt wird. In diesen Fällen sollte der bestätigende Dialogknopf ausgegraut werden, bis die benötigten Optionen ausgewählt wurden.</p>

<section id="action-dialog-examples">
<title>Beispiele</title>

<p>Many of the stock GTK+ dialogs are action dialogs. The print dialog is a good example: it is displayed in response to the user using the print action, and presents information and options for that print action. The two header bar buttons allow the print action to either be cancelled or carried out.</p>

</section>
</section>

<section id="presentation-dialogs">
<title>Präsentationsdialoge</title>

<media type="image" mime="image/svg" src="figures/patterns/presentation-dialog.svg"/>

<p>Presentation dialogs present information or controls. Like action dialogs, they have a header bar and a subject. However, instead of prefixing an action, their content relates to an application or content item.</p>

<section id="presentation-dialog-examples">
<title>Beispiele</title>

<p>Preferences and properties are both examples of presentation dialogs, and both present information and settings in relation to a specific entity (either an application or a content item). Properties dialogs are a good example of how dialogs can be used to disclose additional information which is not always needed in the main application window.</p>

<note style="tip"><p>Resist the temptation to provide a preference window for your application. Always question whether additional settings are really necessary. Most people will not bother to investigate the preferences that you provide, and configuration options will contribute to the complexity of your application. Make an effort to ensure that your application design works for everybody without the need to change its settings.</p></note>

</section>

<section id="instant-and-explicit-apply">
<title>Unmittelbares und ausdrückliches Anwenden</title>

<p>Presentation dialogs are either instant or explicit apply. In instant apply dialogs, changes to settings or values are immediately updated. In contrast, explicit apply dialogs include a button for applying changes.</p>

<p>Instant apply should be used wherever possible. Instant apply presentation dialogs have a close button in their header bar, like a <link xref="primary-windows">primary window</link>.</p>

<p>Explicit apply is only necessary if changes in the dialog have to be applied simultaneously in order to have the desired behaviour. Explicit apply dialogs include a <gui>Done</gui> and <gui>Cancel</gui> button (<gui>Cancel</gui> resets all values in the dialog to the state before it was opened and Done applies all changes and closes the window).</p>

</section>
</section>

<section id="primary-buttons">
<title>Primäre Knöpfe</title>

<p>Message and action dialogs include primary buttons which affect the whole window. The order of these buttons, as well as the labels used, are a key part of the dialog.</p>

<section id="order">
<title>Reihenfolge</title>

<p>When a dialog includes an affirmative and a cancel button, always ensure that the cancel button appears first, before the affirmative button. In left-to-right locales, this is on the left.</p>

<p>This button order ensures that users become aware of, and are reminded of, the ability to cancel prior to encountering the affirmative button.</p>

</section>

<section id="labels">
<title>Beschriftungen</title>

<p>Label the affirmative primary button with a specific imperative verb, for example: <gui>Save</gui>, <gui>Print</gui>, <gui>Remove</gui>. This is clearer than a generic label like <gui>OK</gui> or <gui>Done</gui>.</p>

<p>Error dialogs typically include a single button which dismisses the dialog. In this case, a specific action does not need to be referenced, and this can be a good opportunity to use humor. <gui>Apology Accepted</gui> or <gui>Got It</gui> are both examples of good labels.</p>

</section>

<section id="default-action-and-escape">
<title>Default action and escape</title>

<p>Assign the return key to activate the primary affirmative button in a dialog (for example <gui>Print</gui> in a print dialog). This is called the default action, and is indicated by a different visual style. Do not make a button the default if its action is irreversible, destructive or otherwise inconvenient to the user. If there is no appropriate button to designate as the default button, do not set one.</p>

<p>You should also ensure that the escape key activates the cancel or close button, should either of them be present. Message dialogs with a single button can have both escape and return bound to the button.</p>

<p>Binding return and escape in this way provides a predictable and convenient way to continue through a dialog, or to go back.</p>

</section>

</section>

<section id="general-guidelines">
<title>Allgemeine Richtlinien</title>

<list>
<item><p>Dialog windows should never pop up unexpectedly, and should only ever be displayed in immediate response to a deliberate user action.</p></item>
<item><p>Dialogfenster sollten stets ein Elternfenster haben.</p></item>
<item><p>Folgen Sie beim Entwurf von Fensterinhalten den <link xref="visual-layout">Layout-Richtlinien</link></p></item>
<item><p>Use <link xref="view-switchers">view switchers</link> or <link xref="tabs">tabs</link> to break up controls and information.</p></item>
<item><p>Vermeiden Sie die Stapelung von Dialogfenstern. Niemals sollten mehrere Dialogfenster gleichzeitig angezeigt werden.</p></item>
<item><p>Setzen Sie beim Öffnen eines Dialoges den anfänglichen Tastaturfokus auf jenes Element, von dem Sie erwarten, dass die Benutzer es zuerst benötigen. Dieser Fokus ist insbesondere für jene Benutzer von Bedeutung, die beim Navigieren durch Ihre Anwendung auf die ausschließliche Verwendung der Tastatur angewiesen sind.</p></item>
</list>

</section>

<section id="api-reference">
<title>API-Referenz</title>
<list>
<item><p><link href="https://developer.gnome.org/gtk3/stable/GtkAboutDialog.html">GtkAboutDialog</link></p></item>
<item><p><link href="https://developer.gnome.org/gtk3/stable/GtkDialog.html">GtkDialog</link></p></item>
<item><p><link href="https://developer.gnome.org/gtk3/stable/GtkMessageDialog.html">GtkMessageDialog</link></p></item>
</list>
</section>

</page>
