<?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>Präsentationsdialoge stellen Informationen oder Bedienmöglichkeiten bereit. Wie Aktionsdialoge haben sie eine Kopfleiste und ein ??? Jedoch anstelle eine Aktion vorzubereiten, bezieht sich ihr Inhalt auf eine Anwendung oder ein Inhaltselement.</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>Widerstehen Sie der Versuchung, ein Einstellungsfenster für Ihre Anwendung bereitzustellen. Fragen Sie sich stets, ob zusätzliche Einstellungen überhaupt notwendig sind. Die meisten Benutzer bemühen sich nicht damit, die möglichen Einstellungen herauszufinden, außerdem machen Konfigurationsoptionen Ihre Anwendung komplizierter. Versuchen Sie, Ihr Anwendungsdesign so zu gestalten, dass jeder ohne Änderungen der Einstellungen damit arbeiten kann.</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>Meldungs- und Aktionsdialoge beinhalten primäre Knöpfe, die sich auf das gesamte Fenster auswirken. Die Anordnung der Knöpfe und deren Beschriftung nehmen innerhalb des Dialoges eine Schlüsselstellung ein.</p>

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

<p>Wenn ein Dialog einen Knopf zum Bestätigen und einen zum Abbruch enthält, platzieren Sie den Abbrechen-Knopf stets vor dem Bestätigen-Knopf. Bei Spracheinstellungen mit Schreibweise von links nach rechts ist dies die linke Seite.</p>

<p>Diese Reihenfolge stellt sicher, dass dem Benutzer zuerst die Möglichkeit zum Abbruch signalisiert wird und danach erst die Möglichkeit zum Bestätigen der Aktion.</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>Vorgabeaktion und Abbruch</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>Sie sollten auch sicherstellen, dass die Escape-Taste den Cancel- oder Close-Knopf aktiviert, sofern einer davon vorhanden ist. In Meldungsdialogen mit einem einzelnen Knopf kann diesem sowohl die Escape- als auch die Eingabetaste zugeordnet werden.</p>

<p>Die Bindung der Eingabe- und Escape-Taste auf diese Weise stellt einen voraussehbaren und bequemen Weg zur weiteren Navigation durch einen Dialog dar oder zurück zu gehen.</p>

</section>

</section>

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

<list>
<item><p>Dialogfenster sollten niemals unerwartet geöffnet werden und wirklich nur als unmittelbare Reaktion auf eine absichtliche Aktion des Benutzers erscheinen.</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>