XML » SVG Presenter - Carto:net

Weitere Magazine

Empfehlungen

Info

XML » SVG PRESENTER | STRUKTURIERTE MULTIMEDIA-PRÄSENTATION IM WEB 187 Anwendung kommenden, reinen Betrachtungs-, bzw. Präsentationsschnittstelle über zusätzliche Bearbeitungsmechanismen verfügt. Aufgrund der außerordentlichen Schlichtheit des Presenter-Formates ließe sich somit auch die Anzahl der umzusetzenden möglichen Befehle auf lediglich 3 so genannte UI-Kommandos reduzieren: � Hinzufügen und Löschen einzelner Knoten. 1 � Bearbeitung des Textinhaltes der einzelnen Knoten. � Änderung des Icon-Elements einzelner Knoten. Im Zusammenhang einer Anwendungs-Suite, wie sie etwa PowerPoint darstellt, wären überdies program- matische Schritte wie das Speichern und Laden kompletter Präsentationen sowie das Umschalten vom Bearbeitungs- in den Präsentationsmodus etc. von Interesse. Aufgrund der komfortablen SVG-Schnittstelle lässt sich vorab bereits feststellen, dass die Umsetzung dieser Schritte, zumindest aus konzeptioneller Sicht, geradezu „trivial“ ausfällt und daher in der vorangegangenen Diskussion des Presenters bislang unerwähnt blieb. Die Editierung einzelner Textobjekte wäre bei entspre- chender SVG-Erweiterung demnach entweder direkt möglich [s.Abb.6.6.2], oder aber – einiges umständli- cher, wenn auch nicht sonderlich anspruchsvoll – über die event.getCharCode()-Routine auch mittels ECMAScript sehr leicht zu implementieren: Abb. 6.6.2: Auswahl eines Knoten- Textabschnitts zur Bearbeitung Auch das Löschen bzw. Hinzufügen von Knoten stellt unter diesem Aspekt keine Herausforderung dar – bei Aktivierung eines denkbaren „Bearbeitungsmodus“ würde demnach das Anklicken einzelner Item-Objekte (besser: Kontextmenü via rechter Maustaste) wahlweise zur Löschung oder aber dem Hinzufügen weiterer (Child-)Knoten führen. Abb. 6.6.3.1.1: Kontext-Sensitives Knoten- Auswahlmenü in S VG Adobe’s SVG Viewer-Implementierung erlaubt an dieser Stelle sogar die Modifikation des Viewer-eigenen Kontextmenüs [vgl. Adob02] über die DOM- Schnittstelle: So lassen sich sämtliche GUI-Elemente über das window.contextMenu-Zugriffsfeld äußerst leicht realisieren, da sämtliche Menü-Elemente ebenfalls in Form einer XML-Baumstruktur organisiert sind und sich somit sehr einfach ändern, löschen und zudem individuellen ECMAScript-Funktionen (via onactivate-Attribut) zuweisen lassen [vgl. Quin02] 1 Dies umfasst somit sowohl -, als auch - und -Elemente
XML » SVG PRESENTER | STRUKTURIERTE MULTIMEDIA-PRÄSENTATION IM WEB 188 Abb. 6.6.3.1.2: Modifiziertes, Viewer-natives Konextmenü Eine weitere Option könnte hierbei ü- berdies die Änderung des Icons über ein zusätzliches GUI-Element darstellen – die meiner Einschätzung nach sinnvollste Variante ließe sich etwa in Form eines Selektions-Menüs realisieren, das dem Benutzer wiederum eine Palette zur Verfügung stehender Bildelemente zur Auswahl stellt: 1 Abb. 6.6.3.2: Icon-Auswahlmenü (rechts) ndigsten zu realisierende Komponente einer derartigen Bearbeitungs-Schnittstelle stellt n it noch fehlende Schnittstelle zum Abspeichern dieser Daten als roblematisch. Zwar bietet die aktuelle Adobe-Implementierung provisorische Linderung durch die (nichtstandardisierte) postURL-Funktion – wie bereits beim „Overloading“ 2 Die wohl am aufwe jedoch zweifellos die „Speicherung“ der veränderte Baumstruktur dar: Obgleich sämtliche Daten durch die Echtzeit-gesteuerte Manipulation der Präsentationsdaten in Form einer verschachtelten Objektstruktur bereits im Arbeitsspeicher als lokale ECMAScript- Variablen vorliegen, erweist sich eine derze p des Viewer-Eigenen Kontextmenüs [s.Abb.6.6.3.2] besteht hier jedoch ein Konflikt hinsichtlich allgemeiner Kompatibilität, da auch diese Funktion lediglich auf Versionen des Adobe SVG Viewers anwendbar ist. Eine aus längerfristiger Perspektive interessante Alternative stellt hier die Load-and-Save-Spezifikation der DOM-Arbeitsgruppe dar [vgl. DOM02], die eine strukturell „Saubere“ Implementierung erlaubt. Da diese Funktionalität jedoch erst Working-Draft-Status besitzt, wird offensichtlich noch einige Zeit verstreichen müssen, bis diese Schnittstelle standardisiert und auch in gängigen SVG-Viewern vollständig nutzbar sein wird [s. hierzu auch Watt02:1042]. Bis dahin ist die Realisierung einer derartigen Speicher-Funktion zwar durchaus technisch möglich, gestaltet sich jedoch aufgrund der soeben angesprochenen Problematik derzeit noch recht aufwendig. Aus diesem Grunde wurde bislang von einer Implementierung dieser Funktion (und damit auch der zuvor erläuterten, hen, da entsprechende, „saubere“ Lösungswege erst liches, arbeitsaufwendiges „Work-Around“ bis zu 3 „trivialen“ GUI-Schnittstellen) abgese in einiger Zeit verfügbar sein werden und ein umständ diesem Zeitpunkt nur wenig sinnvoll erscheint. 6.6.1 GUI-Komponente und Bearbeitungs-Komfort Langfristig jedoch wird an der Realisierung einer Bearbeitungs-Schnittstelle freilich kein Weg vorbeiführen: 4 Da sich der Presenter ja vorwiegend als Alternative zum augenscheinlich mangelhaften PowerPoint positioniert, reicht der Bedienkomfort etwa mittels konventioneller XML-Editoren [ShSi99, s.Abb.6.6.1] im Hinblick auf die technisch und gestalterisch vorwiegend als „unbedarfte“ einzustufende, potentielle Anwenderschaft [vgl. Scha90, Park01, Pirn01] natürlich bei Weitem nicht aus: Die im Rahmen der Konzeptstudie 1 Die Auswahl externer oder lokaler Bilddateien wäre zwar technisch durchaus möglich, aber sowohl aus ästhetischer Perspektive (der Nutzer könnte hierbei wiederum unansehnliches Bildmaterial „hochladen“) als auch Umsetzungstechnisch problematisch und zudem weitaus umständlicher zu realisieren. 2 Mit dem „Überladen“ ist die Modifikation bzw. Ersetzung der ursprünglichen Kontextmenü-Elemente durch Bearbeitungsspezifische Kommandos des XML » SVG Presenters gemeint. 3 s. Abb. 6.6.2, 6.6.3.1.1, 6.6.3.1.2, 6.6.3.2 4 s. hierzu Kap. 2.3
Seite 1 und 2:
XML » SVG PRESENTER | STRUKTURIERT
Seite 3 und 4:
Seite 5 und 6:
Seite 7 und 8:
Seite 9 und 10:
Seite 11 und 12:
Seite 13 und 14:
Seite 15 und 16:
Seite 17 und 18:
Seite 19 und 20:
Seite 21 und 22:
Seite 23 und 24:
Seite 25 und 26:
Seite 27 und 28:
Seite 29 und 30:
Seite 31 und 32:
Seite 33 und 34:
Seite 35 und 36:
Seite 37 und 38:
Seite 39 und 40:
Seite 41 und 42:
Seite 43 und 44:
Seite 45 und 46:
Seite 47 und 48:
Seite 49 und 50:
Seite 51 und 52:
Seite 53 und 54:
Seite 55 und 56:
Seite 57 und 58:
Seite 59 und 60:
Seite 61 und 62:
Seite 63 und 64:
Seite 65 und 66:
Seite 67 und 68:
Seite 69 und 70:
Seite 71 und 72:
Seite 73 und 74:
Seite 75 und 76:
Seite 77 und 78:
Seite 79 und 80:
Seite 81 und 82:
Seite 83 und 84:
Seite 85 und 86:
Seite 87 und 88:
Seite 89 und 90:
Seite 91 und 92:
Seite 93 und 94:
Seite 95 und 96:
Seite 97 und 98:
Seite 99 und 100:
Seite 101 und 102:
Seite 103 und 104:
Seite 105 und 106:
Seite 107 und 108:
Seite 109 und 110:
Seite 111 und 112:
Seite 113 und 114:
Seite 115 und 116:
Seite 117 und 118:
Seite 119 und 120:
Seite 121 und 122:
Seite 123 und 124:
Seite 125 und 126:
Seite 127 und 128:
Seite 129 und 130:
Seite 131 und 132:
Seite 133 und 134:
Seite 135 und 136:
Seite 137 und 138:
Seite 139 und 140:
Seite 141 und 142:
Seite 143 und 144:
Seite 145 und 146:
Seite 147 und 148: XML » SVG PRESENTER | STRUKTURIERT
Seite 197: XML » SVG PRESENTER | STRUKTURIERT
Seite 231: XML » SVG PRESENTER | STRUKTURIERT
Alle anzeigen

XML » SVG Presenter - Carto:net

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?