1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
|
<?xml version="1.0" encoding="UTF-8" ?>
<chapter id="kmdr-basics">
<chapterinfo>
<title
>&kommander;-Grundlagen</title>
<authorgroup>
<author
><firstname
>Tamara</firstname
> <surname
>King</surname
> <affiliation
><address
> <email
>tik@acm.org</email>
</address
></affiliation>
</author>
<author
><firstname
>Eric</firstname
> <surname
>Laffoon</surname
> <affiliation
><address
> <email
>sequitur@kde.org</email>
</address
></affiliation>
</author>
<othercredit role="translator"
><firstname
>Georg</firstname
><surname
>Schuster</surname
><affiliation
><address
><email
>gschuster@utanet.at</email
></address
></affiliation
><contrib
>Deutsche Übersetzung</contrib
></othercredit
>
</authorgroup>
</chapterinfo>
<title
>&kommander;-Grundlagen</title>
<!-- This chapter should tell the user how to use your app. You should use as
many sections (Chapter, Sect1, Sect3, etc...) as is necessary to fully document
your application. -->
<sect1 id="concepts">
<title
>Konzepte</title>
<para
>&kommander; wurde ursprünglich rund um ein einfaches Konzept entworfen, das sich als revolutionär unter den visuellen Entwicklungswerkzeugen entpuppt hat. Typischerweise ermöglichen diese Werkzeuge die Erstellung von Dialogen und möglicheweise von Benutzeroberflächen. So eine Benutzeroberfläche hat Menüs, Werkzeugleisten, eine Statusleiste und den Anwendungsbereich. Dialoge sind Kindfenster ohne Menüs und tragen ihren Namen weil ihr Zweck ist, <quote
>in Dialog</quote
> mit dem Benutzer zu treten oder mit ihm Informationen auszutauschen. Die Elemente auf einem Dialog werden <quote
>Bedienelemente</quote
> genannt und man verknüpft das Programm und diese Bedienelemente. &kommander; ist anders, weil es von vorneherein nicht programmiert. Es benutzt ein Konzept der Verknüpfung von Text mit den Bedienelementen im Dialog. Ursprünglich wurde dies <quote
>Assoziierter Text</quote
> genannt, nun heißt es einfach <quote
>&kommander;-Text</quote
>. Bedienelemente in &kommander;-Dialogen können den Inhalt anderer Bedienelemente durch Referenz enthalten und ein Bedienelement kann seinen eigenen Inhalt referenzieren, mittels <quote
>Anweisung</quote
>, die so aussieht: @BedienelementText. Anweisungensind Befehle mit besonderer Bedeutung in &kommander;. Es kann also, wenn ein Dialog mit zwei einzeiligen Eingabefeld-Bedienelementen, dem ersten <quote
>Vorname</quote
> und dem zweiten <quote
>Nachname</quote
>, erstellt wurde, eine Schaltfläche mit dem &kommander;-Text <quote
>Mein Name ist @Vorname @Nachname</quote
> hinzugefügt werden. Zuerst müßte Vor- und Nachname ausgefüllt werden, dann könnte &kommander; die Referenz benutzen. Von der <application
>Konsole</application
> gestartet, könnte die ganze Zeichenkette ausgegeben werden. Es würde den Vornamen so erhalten: @Vorname -> hole das Bedienelement Vorname (@Vorname) -> @BedienelementText -> hole den Inhalt des einzeiligen Eingabefeldes. Wenn dort <quote
>Eric</quote
> eingegeben worden wäre, liefert @Vorname also <quote
>Eric</quote
>. </para>
<para
>Das ist, vereinfacht, der Kern von &kommander;. Interessant ist, was man daraus machen kann. Zunächst sollte angemerkt werden, dass, verglichen mit der Art von auf Programmiersprachen gestützten Werkzeugen, &kommander; keine Programmanweisungen für solche Operationen braucht. Das macht &kommander; schnell für Entwickler. Für Endbenutzer ist es einfacher, als Programmiersprachen zu lernen. Für Jedermann bedeutet es, die Aufgabe in den Mittelpunkt zu stellen, statt die Sprachreferenz ewig mitzuführen. Anfangs, wenn Leute mit einem Werkzeug wie &kommander; in Berührung kommen, ist die erste Frage <quote
> Wofür kann ich dieses Werkzeug nutzen?</quote
> Es stellt sich heraus, dass der Umgang mit Zeichenketten allgegenwärtig ist. </para>
<para
>Also, was kann &kommander; leisten? Hier die Liste mit grundlegenden Operationen. &kommander; kann: </para>
<orderedlist>
<listitem
><para
>Zeichenketten an das aufrufende Programm über stdout weitergeben.</para
></listitem>
<listitem
><para
>Programme aufrufen.</para
></listitem>
<listitem
><para
>&DCOP; benutzen um mit &kde;-Programmen zusammenzuarbeiten</para
></listitem>
</orderedlist>
<para
>Wenn sie keine Programmierer sind, möchten Sie die Erklärung allgemein verständlich. Erstens, wenn &kommander; von der Konsole gestartet wird, ist die Konsole das aufrufende Programm. Es besteht eine Eltern-Kind Beziehung hier. Durch die Standardausgabe (stdout), so genannt, weil es auch eine Fehlerausgabe gibt, des Kindprogrammes kann eine Nachricht zur Konsole geschickt werden. Dies ist interessant, weil Programme wie &quantaplus; die Standardausgabe nutzen, um Information von Programmen, dies sie starten, zu erhalten. Auf diese Weise können &kommander;-Dialoge ihre Text-Ausgabe direkt an den Editor von &quantaplus; lierfern, wenn sie aus &quantaplus; gestartet wurden. Das bedeutet, &kommander;-Dialoge können für die Erweiterung eines Programmes genutzt werden. </para>
<para
>Der zweite Fall ist der Aufruf einer ausführbaren Datei. Jedes Programm, das auf ihrem Rechner läuft, ist ausführbar. Auch ein Skript-Programm, das von einem Interpreter ausgeführt wird, ist, technisch gesehen, ausführbar. &kommander; kann Befehle wie auf der Konsole ausführen, auch wenn vom Menü gestartet. So würde beispielsweise, wenn es &GIMP; starten soll, eine Schaltfläche die Beschriftung <quote
>The Gimp</quote
> tragen und eine Anweisung wie: @exec(gimp) enthalten. Das genügt, um bei Benutzung &GIMP; starten zu lassen. Man könnte auch <quote
>ls -l</quote
> ausführen lassen, aber das Ergebnis wäre nur von einer Konsole aus sichtbar. </para>
<para
>Der dritte Fall ist besonders interessant. &DCOP; ist die Abkürzung für &kde;s <emphasis
>D</emphasis
>esktop <emphasis
>CO</emphasis
>mmunication <emphasis
>P</emphasis
>rotocol und ist sehr leistungsfähig. Starten Sie das <application
>kdcop</application
>-Programm und sehen Sie die Liste an. Jede standardkonforme &kde;-Anwendung hat Dinge in &DCOP; und die fortschrittlich gestalteten benutzen es intensiv. Mit &DCOP; ist die Suche nach Informationen jeder Art ebenso wie die Einstellung von Bedienelement-Werten und mehr möglich. Ein Teil dieses Handbuches beschreibt die Verwendung von &DCOP;. &kommander; kann &DCOP;-Anforderungen senden als auch selbst über &DCOP; gesteuert werden. Von der Kommandozeile können &DCOP;-Anfragen an jedes &kde;-Programm gesendet werden. Wo ist also die Verbesserung? Bei einer großen Anzahl von &DCOP;-Anforderungen über die Kommandozeile wird es sehr langsam, wenn z. B. Schleifen hunderte Mal ausgeführt werden. Hier hat &kommander; eine @dcop Anweisung, weil das etwa 1000 Mal schneller läuft. Weil &kommander; &DCOP; senden und empfangen kann, ist es möglich, damit &kommander; zu skripten. Daher haben wir auch eine lokale &DCOP; Anweisung, @ldcop, um weniger für das Absetzen eines Befehls eingeben zu müssen. </para>
<para
>Sind das alle Kernkonzepte in &kommander;? Nein, aber es sollte für das grundsätzliche Verständnis, wie es funktioniert, hilfreich sein, sodass es nicht wie eine Fremdsprache wirkt. Es gibt aber noch mehr. Mit Signalen und Slots behandelt &kommander; Ereignisse. Ein Ereignis in einem Programm meint <quote
>irgendetwas geschah</quote
>, wie die Schaffung eines Bedienelementes oder die Änderung des enthaltenen Textes. Diese Änderungen <quote
>senden Signal aus</quote
>, die mit einem empfangenden Slot verbunden werden können, der dann etwas tut, wenn das Ereignis auftritt. Eine Anwendung in &kommander; ist <quote
>Population-Text</quote
>, das bei Aufruf ein Bedienelement mit Text befüllt. Ebenso wie &kommander;-Text kann Population-Text Zeichenketten oder Skripte enthalten. </para>
<para
>Das sollte die Basis für den Beginn mit &kommander; legen. Wir versuchen die Anzahl der Anweisungen niedrig zu halten und verwenden häufig &DCOP;. Die Idee ist, die Mächtigkeit von &kommander; so schlank und einheitlich wie möglich zu gewährleisten. Es kann jede Skriptsprache in &kommander; eingebaut werden, sogar mehrere gleichzeitig in einem Dialog. Im weiteren Bereich der Dokumentation wird vorausgesetzt, dass die hier präsentierten Konzepte und Begriffe bekannt sind. Sehr nützlich für das Verständnis, was mit &kommander; möglich ist, sind auch die Beispiele und Anleitungen. </para>
</sect1>
&editor; <sect1 id="executor">
<title
>Der Executor</title>
<para
>Der Executer, benannt <application
>kmdr-executor</application
>, führt &kommander;-Skripte aus. Er ladet <literal role="extension"
>.kmdr</literal
> Dateien und erzeugt dynamische, voll funktionale Dialoge. </para>
<sect2 id="executor-for-programmers">
<title
>Excecutor für Entwickler</title>
<para
>C++ Entwickler können leicht die KmdrDialogInstance Klasse in ihren C++-Programmen nutzen und damit die Funktionalität in ihre Anwendungen einbetten, sodass kein Bedarf besteht, das eigenständige Executor-Programm auszuführen. Für Standarddialoge ist der Aufwand für die Dialogerstellung minimal, aber die Erstellung der &kde;-Anwendung beim Start kann den Dialog für etwa eine Sekunde verzögern. </para>
</sect2>
</sect1>
<sect1 id="create-dialog">
<title
>Einen Dialog erstellen</title>
<para
></para>
</sect1>
</chapter>
|
