<?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>Viele der vorgefertigten GTK-Dialoge sind Aktionsdialoge. Der Druckdialog ist dafür ein gutes Beispiel: Er erscheint als Reaktion darauf, wenn der Benutzer die Drucken-Aktion anstößt und zeigt Informationen und Optionen zu dieser Aktion an. Mit den zwei Knöpfen in der Kopfleiste kann der Druckvorgang entweder gestartet oder abgebrochen werden.</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>Einstellungen und Eigenschaften sind Beispiele für Präsentationsdialoge. Beide stellen Informationen und Einstellungen in Relation zu einer spezifischen Entität dar (entweder eine Anwendung oder ein Inhaltsobjekt). Eigenschaftsdialoge sind ein gutes Beispiel dafür, wie Dialoge zur Auslagerung von Informationen verwendet werden können, die im Hauptfenster der Anwendung nicht permanent gebraucht werden.</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>Beschriften Sie den bestätigenden Knopf mit einem spezifischen imperativen Verb, zum Beispiel <gui>Save</gui>, <gui>Print</gui> oder <gui>Remove</gui>. Dies ist klarer verständlich als eine allgemeine Beschriftung wie <gui>OK</gui> oder <gui>Done</gui>.</p>

<p>Fehlerdialoge beinhalten typischerweise einen einzelnen Knopf, der den Dialog schließt. In diesem Fall braucht keine spezifische Aktion referenziert zu werden, und eine Prise Humor kann hier auch nicht schaden. <gui>Apology Accepted</gui> oder <gui>Got It</gui> sind Beispiele für passende Beschriftungen.</p>

</section>

<section id="default-action-and-escape">
<title>Vorgabeaktion und Abbruch</title>

<p>Weisen Sie die Eingabetaste dem primären Bestätigungsknopf in einem Dialog zu (zum Beispiel <gui>Print</gui> in einem Druckdialog). Diese ist dann die Standardaktion, die durch einen anderen visuellen Stil kenntlich gemacht wird. Legen Sie keinen Knopf als Standardknopf fest, dessen Aktion irreversibel, destruktiv oder in anderer Form unbequem für den Benutzer ist. Gibt es keinen passenden Knopf, dessen Aktion sich als Standardaktion eignet, sollten Sie keinen dafür festlegen.</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>