Viel wichtiger und sinnvoller wäre es, wenn man endlich die Krücke Kmenuedit verbannen könnte und eine direkte Konfiguration wie in Windows erreichen würde.
wenn ich das richtig sehe, dann sind SVG Grafiken recht starr, wohingegen das Zeichnen mittels JavaScript in ein Canvas sehr flexibel gestaltet werden kann.
Ich sehe das Problem nicht. SVG ist ein Vektorformat, Canvas zeichnet Pixelgrafiken. Das ist nicht das selbe. Warum sollte man für ein paar einfache Linien gleich SVG bemühen obwohl das Ergebniss nicht skaliert werden können muss?
Nein, ist es selbstverständlich nicht. Das wird aber viele Menschen nicht davon abhalten, die proprietären Non-Standard-Erweiterungen anderer weiterhin zu bashen und die eigenen proprietären Non-Standard-Erweiterungen als "freien Standard" zu bewerben und von andereren zu verlangen, diese sofort auch umzusetzen und die eigenen proprietären Non-Standard-Erweiterungen aufzugeben. Möglicherweise wird auch moralisch argumentiert werden.
Jajajaaaaa. Lies bitte erstmal, bevor du was schreibst.
KHTML unterstützt also zukünftig Canvas. Prima, wenn man dann DB-Widgets verwenden kann. Das heißt aber nicht, daß man dann auch in Webseiten einsetzen soll. Und nur dafür ist das W3C als Standardisierungsgremium zuständig. Nur weil es KHTML heißt, bedeutet das ja nicht, daß es nur Webseiten darstellen darf. Solange es Webseiten korrekt darstellt ist es doch wohl scheißegal, was es sonst noch kann. Und hey, wenn Windows mit nichts anfangen kann dürfte das relativ wenige Leute stören. Das Web funktioniert auch ohne Widgets, und das ist gut so.
Wenn Windows seine proprietären Erweiterungen nur für interne Zwecke einsetzen würde hätte sicher niemand was dagegen. Was interessiert es einen Nicht-Windows-User, ob z.B. das Windows-Update nur mit ActiveX funktioniert?
Wenn diese nichtstandardisierte Scheiße aber ins standardisierte Web kommt, dann entstehen erst die Probleme. Nur ist der normale Windowsuser leider zu dumm, den Unterschied zu erkennen. Oder arrogant genug zu meinen, daß eh alle Windows benutzen.
Diese "Widgets" -- und somit auch das CANVAS Html Tag -- sollst du nicht auf deine kleine Homepage einbauen sondern die "Widgets" sind kleine Helferlein Applikationen die bei dir lokal auf dem Rechner laufen. Zur Darstellung wird die ganze GUI halt in HTML geschrieben (dafür auch das CANVAS Html Tag) und zur Programmierung wird JavaScript verwendet. Wenn benötigt kann ein "Widget" per JavaScript auch ein lokales Binary ausführen (quasi per SYSTEM Befehl wie von C bekannt). Und bevor jetzt wieder einer schreit: Guckts euch das erst mal auf einem Rechner mit MacOSX ( http://www.apple.com/de/macosx/features/dashboard/ ) an -- dort kommts her und da funktioniert das schon seit April.
OS X Dashboard-Widgets sollen in Zukunft auch unter der KDE-Umgebung funktionieren.
Wie Zack Rusin in seinem Webblog schreibt, nähert sich die Implementierung der Canvas-Bibliothek in KHTML zu Ende. Mittels der Bibliothek wird es in der kommenden Versionen des Konqueror-Browsers möglich sein, das HTML-Element anzuzeigen. Das
Superkaramba wird in Plasma aufgehen (die Entwickler von SK arbeiten bereits seit längerem an Plasma mit). Plasma soll mehr als eine Skriptsprache unterstützen (m.W. sind Python (wie bei SK), JavaScript (wie bei Dashboard) und Ruby angedacht).
Wenn Plasma jetzt die Dashboard-Dinger direkt unterstützen sollte (d.h. die Infrastruktur zur Verfügung stellt, JavaScript als Sprache ist ja ohnehin geplant), dann würde das einen netten Vorrat an bereits existieren Widgets erschließen. Was spricht dagegen?
Gar nichts spricht dagegen. Wollte nur den Hintergrund verstehen und finde diese Entwicklung unter diesen Gesichtspunkten klasse. Freue mich jetzt schon auf KDE 4. Danke für die Antwort.
Wie schon jemand gesagt hat, SK und DB unterscheiden sich konzeptionell wohl nur in Kleinigkeiten. Aber so wie ich DB verstehe erscheinen die Widgets nur, wenn man sie explizit anfordert, sie liegen also praktisch auf einer eigenen Ebene, die über dem normalen Desktop liegt. Das empfinde ich persönlich als einen großen Vorteil gegebüber SK, dessen Widgets einfach immer da sind. Und dabei meiner Meinung nach den Desktop meistens mit unwichtigen Informationen/Funktionen belegen. Deswegen benutze ich bisher auch SK nicht, alles was ich damit machen könnte kann ich auch anderweitig erreichen, ohne das es mir im Weg ist, wenn ich es nicht brauche.
Was ich mich frage ist, wie groß wohl der Aufwand sein wird, um DB-Widgets in KDE zu unterstützen. Immerhin können die ja auch Cocoa-Code enthalten, was ja ein natives OSX-Interface ist.
Interessant finde ich auf jeden Fall die Vielfalt an Sprachen, die unterstützt wird. Auch wenn ich mich mit Python und Ruby bisher noch nicht besonders anfreunden konnte. Und JavaScript ja eh jenseits von Gut und Böse ist. Aber vielleicht wird das dann ja mal ein Grund daß ich mir eine oder mehrere davon mal wieder näher ansehe
HTML-Element? Davon hätte ich noch nie gehört. Wenn ich für Firefox eine Extension schreibe, damit Firefox meine herrlichen tschibuti-Elemente, welche zB das fliegende Spaghettimonster animiert besonders schön darstellen, werden tschibuti-Elemente dann ein HTML-Element?
Canvas heißt Leinwand und ist ein gebräuchlicher Begriff für Widgets, in denen man mit Low-Level-Befehlen Punkte, Linien etc. zeichnen kann. Der Tk-Canvas wird auch sowas sein.
hab selbst ein powerboard mit tiger und somit auch dashboard, imho is dashboard aber nich so gut wie superkaramba, allein schon weil sie nur vorgelagert werden können und nicht wie karamba auch im hintergrund liegen können. sind also mehr ein gimmick. is aber trotzdem nett dass dashboard unterstützt wird.
> ... > allein schon weil sie nur vorgelagert werden können und nicht wie karamba auch im hintergrund liegen können > ...
Was meinst du damit? Die Widgets liegen bei MacOSX auf einem eigenen Bildschirmbereich (nenn ich jetzt mal "Plane"). Und dieser Bildschirmbereich wird nur bei Bedarf (= der Anwender drückt F12) eingeblendet.
Die Widgets verbrauchen auch nur dann CPU-Zeit, solange die Plane angezeigt werden. Das ist IMHO einer wesentlichen Unterschiede gegenüber Konfabulator. Bei letzerem konnte man die Widgets zwar so konfigurieren dass diese immer angezeigt oder auf einer eigenen Plane liegen -- CPU-Zeit wurde aber immer verbraucht. Hattest du mit Konfabulator genügend Widgets am Laufen (und das mussten nicht mal sooo viele sein) hat man das dann doch gemerkt dass da noch was läuft.
genau das meine ich. sie können nur eingeblendet werden, nicht parallel mit anderen programmen arbeiten. sobald man etwas anderes als die dashboards anklickt sind se wieder weg. so widgets wie wetter oder pearlyrics machen mehr sinn wenn sie nebenbei laufen. so muss man jedes mal zu itunes wechseln, das lied auswählen, dann wieder zurück zum dashboard und dann zeigt das widget die lyrics. parallel laufend würde man sich diese ganzen schritte sparen: lied anklicken und die lyrics werden angezeigt, fertig.
Also, liebe Freunde, mal schön auf dem Teppich bleiben.
wenn ich das richtig sehe, dann sind SVG Grafiken recht starr, wohingegen das Zeichnen mittels JavaScript in ein Canvas sehr flexibel gestaltet werden kann.
- Jens
>Das geht mit SVG auch über JavaScript, JSP, Perl, PHP usw.
JSP, Perl, PHP, ... aber nur serverseitig. Per JavaScript geht das auch dyn. clientseitig.
- J.
Nein, ist es selbstverständlich nicht. Das wird aber viele Menschen nicht davon abhalten, die proprietären Non-Standard-Erweiterungen anderer weiterhin zu bashen und die eigenen proprietären Non-Standard-Erweiterungen als "freien Standard" zu bewerben und von andereren zu verlangen, diese sofort auch umzusetzen und die eigenen proprietären Non-Standard-Erweiterungen aufzugeben. Möglicherweise wird auch moralisch argumentiert werden.
Versuch deine "Community"-Paranoia zu bekämpfen, auch wenn dir wieder mal deine Pillen ausgegangen sind.
KHTML unterstützt also zukünftig Canvas. Prima, wenn man dann DB-Widgets verwenden kann. Das heißt aber nicht, daß man dann auch in Webseiten einsetzen soll. Und nur dafür ist das W3C als Standardisierungsgremium zuständig. Nur weil es KHTML heißt, bedeutet das ja nicht, daß es nur Webseiten darstellen darf. Solange es Webseiten korrekt darstellt ist es doch wohl scheißegal, was es sonst noch kann. Und hey, wenn Windows mit nichts anfangen kann dürfte das relativ wenige Leute stören. Das Web funktioniert auch ohne Widgets, und das ist gut so.
Wenn Windows seine proprietären Erweiterungen nur für interne Zwecke einsetzen würde hätte sicher niemand was dagegen. Was interessiert es einen Nicht-Windows-User, ob z.B. das Windows-Update nur mit ActiveX funktioniert?
Wenn diese nichtstandardisierte Scheiße aber ins standardisierte Web kommt, dann entstehen erst die Probleme. Nur ist der normale Windowsuser leider zu dumm, den Unterschied zu erkennen. Oder arrogant genug zu meinen, daß eh alle Windows benutzen.
Wie Zack Rusin in seinem Webblog schreibt, nähert sich die Implementierung der Canvas-Bibliothek in KHTML zu Ende. Mittels der Bibliothek wird es in der kommenden Versionen des Konqueror-Browsers möglich sein, das HTML-Element anzuzeigen. Das
[mehr steht da nicht]
Gruss,
demon
Markus
Wenn Plasma jetzt die Dashboard-Dinger direkt unterstützen sollte (d.h. die Infrastruktur zur Verfügung stellt, JavaScript als Sprache ist ja ohnehin geplant), dann würde das einen netten Vorrat an bereits existieren Widgets erschließen. Was spricht dagegen?
Danke für die Antwort.
Markus
> Was für widgets gibt es denn, die man damit erschliessen kann?
>
na die hier zum Beispiel:
http://www.apple.com/de/macosx/features/dashboard/
und hier findest du noch weitere 1600+ Widgets:
http://www.apple.com/de/downloads/dashboard/
Was ich mich frage ist, wie groß wohl der Aufwand sein wird, um DB-Widgets in KDE zu unterstützen. Immerhin können die ja auch Cocoa-Code enthalten, was ja ein natives OSX-Interface ist.
Interessant finde ich auf jeden Fall die Vielfalt an Sprachen, die unterstützt wird. Auch wenn ich mich mit Python und Ruby bisher noch nicht besonders anfreunden konnte. Und JavaScript ja eh jenseits von Gut und Böse ist. Aber vielleicht wird das dann ja mal ein Grund daß ich mir eine oder mehrere davon mal wieder näher ansehe
HTML-Element? Davon hätte ich noch nie gehört.
Wenn ich für Firefox eine Extension schreibe, damit Firefox meine herrlichen tschibuti-Elemente, welche zB das fliegende Spaghettimonster animiert besonders schön darstellen, werden tschibuti-Elemente dann ein HTML-Element?
Canvas heißt Leinwand und ist ein gebräuchlicher Begriff für Widgets, in denen man mit Low-Level-Befehlen Punkte, Linien etc. zeichnen kann. Der Tk-Canvas wird auch sowas sein.
> allein schon weil sie nur vorgelagert werden können und nicht wie karamba auch im hintergrund liegen können
> ...
Was meinst du damit?
Die Widgets liegen bei MacOSX auf einem eigenen Bildschirmbereich (nenn ich jetzt mal "Plane"). Und dieser Bildschirmbereich wird nur bei Bedarf (= der Anwender drückt F12) eingeblendet.
Die Widgets verbrauchen auch nur dann CPU-Zeit, solange die Plane angezeigt werden. Das ist IMHO einer wesentlichen Unterschiede gegenüber Konfabulator. Bei letzerem konnte man die Widgets zwar so konfigurieren dass diese immer angezeigt oder auf einer eigenen Plane liegen -- CPU-Zeit wurde aber immer verbraucht. Hattest du mit Konfabulator genügend Widgets am Laufen (und das mussten nicht mal sooo viele sein) hat man das dann doch gemerkt dass da noch was läuft.