Syntax-Highlighting in Browser-Textarea

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Montag 2. Juni 2008, 13:43

jens hat geschrieben:Genau. In den Brwosereinstellungen kann man nur global die Sprache umstellen. Wenn man auf einer Webseite auf die Fahne klickt, ist die Sprache nur auf der Webseite geaendert.
Ja und? Wenn das Leute nutzen würden, dann würde das schon eine prominentere Stelle bekommen. Siehe Cookies, da kann ich auch Ausnahmen definieren. Oder NoScript, da kann ich auch sagen, wo JS gehen soll und wo nicht, noch dazu ist es im Browser ja auch nur eine globale Einstellung.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Mittwoch 4. Juni 2008, 08:02

Wow, da schaut man ein paar Tage nicht ins Forum und dann so viele Reaktionen. Dafür erstmal danke, auch wenn die Antworten nur um das Thema drehen, ob das sinnvoll ist oder ob Google böse ist oder sonstwas.

@audax: Ich werde nicht den Browser wechseln, sondern die Software hat gefälligst mit meinem System zu funktionieren und nicht umgekehrt. Daher suche ich ja Software und habe nicht gefragt, mit welchem Computer und Betriebssystem wohl CodePress und Co funktionieren.

@die anderen, die Browser-basierte Anwendungen nicht mögen: Niemand zwingt euch, das auch zu benutzen. Derartige Anwendungen sind in der Regeln geringer im Funktionsumfang, was häufig als Vorteil angesehen wird. Sie sind immer (wo ein Netz ist) verfügbar und brauchen keine Installation (außer einem Browser). Sie müssen auch nicht extra geladen werden. Auch dies sind Vorteile. Ich beginne zunehmend Google Docs gut zu finden, weil mir dass das Jonglieren mit 5 Computern an unterschiedlichen Orten einfacher macht. Eigentlich will ich das aber gar nicht diskutieren.

Die Aussage "der Browser ist nur zum Surfen da" kann ich nicht unterstützen. Der Browser ist in meinem Augen eben eine Plattform für Anwendungen. Noch nie war es so einfach, neue Anwendungen zu schreiben, zu verteilen und vielen Leuten zur Verfügung zu stellen, wie durch das Web und Webbrowser. Das halte ich für eine gute Sache. Entscheidend ist jedoch, dass keine Software installiert werden muss, nichts betriebssystemspezifisches getan werden muss (neben dem Browser würde ich vielleicht noch Flash als nahezu allgegenwärtiges Plugin akzeptieren, bereits Java ist diskussionswürdig und Silverlight spielt noch keine Rolle).

Ich merke aber, ich habe da in der falschen Gruppe gefragt :)

Bzgl. Gooby: Die Textverarbeitung von Google Docs erlaubt es übrigens ebenfalls, dass mehrere Leute gleichzeitig an einem Textdokument arbeiten. Sie können allerdings im Gegensatz zu der Tabellenkalkulation aus dem selben Paket nicht gleichzeitig in der Anwendung chatten. Das wiederum geht wohl bei Gobby.

Stefan
burli
User
Beiträge: 1116
Registriert: Dienstag 9. März 2004, 18:22

Mittwoch 4. Juni 2008, 08:23

sma hat geschrieben:Die Aussage "der Browser ist nur zum Surfen da" kann ich nicht unterstützen. Der Browser ist in meinem Augen eben eine Plattform für Anwendungen.
Genau das sehe ich anders. Damit solche Anwendungen funktionieren muss der Funktionsumfang des Browsers erweitert werden und der Browser benötigt mehr Rechte beim Zugriff auf den PC.

Was dabei herauskommt hat die Vergangenheit doch gezeigt: Sicherheitslöcher und fluchende Menschen. Das ganze gabs schonmal und keiner hat was daraus gelernt :!:

Es gibt andere Möglichkeiten platformunabhängige Programme zu schreiben, zb Python und wxPython. Also nutzt lieber das :roll:
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Mittwoch 4. Juni 2008, 08:30

burli hat geschrieben:Damit solche Anwendungen funktionieren muss der Funktionsumfang des Browsers erweitert werden
Muss? Damit ich dieses Forum benutzen kann, musste gar nichts erweitert werden. Gleiches gilt für die schon erwähnten Anwendungen von Google.

In einigen Fällen wäre es wünschenswert, wenn der Browser (noch) mehr könnte (und da greifen dann Gears, Flash, Silverlight oder auch Java an) aber eine zwingende Notwendigkeit sehe ich nicht.

Mit der Anwendung zusammen will ich ja auch meine Datenlagerung ins Netz verlagern. Zugriff auf die lokale Festplatte ist daher IMHO nicht zwingend notwendig. Gerade für eine IDE, wo ich meinen Quelltext sowieso schon in einer Versionsverwaltung irgendwo im Netz (sourceforge, google code, github usw.) lagere, sehe ich keine Notwendigkeit für den lokalen Zugriff.

Stefan
BlackJack

Mittwoch 4. Juni 2008, 11:05

Die Einstellung das man nicht den Browser wechseln will, sondern sich die Software gefälligst dem Browser an zu passen hat, kann man sich aber auch nur leisten, wenn man zufällig einen Browser verwendet, der von der Software unterstützt wird. Denn letztendlich wird das darauf hinaus laufen, dass die Software nur unter IE und Firefox vernünftig läuft. Google als Beispiel nölt gerne mal rum das Konqueror nicht zu den unterstützen Browsern gehört.
burli
User
Beiträge: 1116
Registriert: Dienstag 9. März 2004, 18:22

Mittwoch 4. Juni 2008, 11:46

Eben, ob man jetzt eine Software an 20 Browser oder 3 Betriebssysteme anpasst ist wohl eindeutig. Die 3 Betriebssysteme sind mit der richtigen Software einfach. Aber eine relativ komplexe Sache wie eine IDE an verschiedene Browser anzupassen... viel Spaß. Das nervt ja bei relativ "normalen" Webseiten schon
lunar

Mittwoch 4. Juni 2008, 13:23

sma hat geschrieben:@die anderen, die Browser-basierte Anwendungen nicht mögen: Niemand zwingt euch, das auch zu benutzen. Derartige Anwendungen sind in der Regeln geringer im Funktionsumfang, was häufig als Vorteil angesehen wird.
Ich persönlich sehe es nicht als Vorteil, wenn ein Webmailer weder HTTPS noch GnuPG bietet.
sma hat geschrieben:Der Browser ist in meinem Augen eben eine Plattform für Anwendungen. Noch nie war es so einfach, neue Anwendungen zu schreiben, zu verteilen und vielen Leuten zur Verfügung zu stellen, wie durch das Web und Webbrowser.
Bitte vermische nicht das Web als Plattform für Softwareverteilung mit dem Web als Plattform für die Software selbst!

Ich schätze das Internet für seine Kommunikationsmöglichkeiten und die Möglichkeiten, Code zu veröffentlichen und Code zu entwickeln, genauso wie du. Ein freies Projekt zu starten, ist dank SourceForge und Konsorten so einfach wie noch nie, zumal es mittlerweile auch tolle Software gibt, um Projekte auf eigenen Servern voranzutreiben.

Das alles hat aber nichts mit dem Web als Anwendungsplattform zu tun. Das ist keineswegs "leicht", weder bei der Entwicklung noch bei der Verteilung bzw. dem zur Verfügung stellen.

Um dein erstes Posting aufzugreifen: Es gibt eine unüberschaubare Anzahl von Entwicklungsumgebungen für den Desktop. Die Entwicklung solcher Programme ist denkbar einfach: Eric 4, eine der besten freien IDEs für Python, wird beispielsweise fast ausschließlich von einer einzigen Person entwickelt. Diese Produktivität erreicht man, weil moderne Frameworks viel Arbeit abnehmen, beispielsweise durch fertige Editor-Kompontenten wie QScintilla.

Eine solche IDE als Webanwendung ist für einen Entwickler nicht zu verwirklichen: Es existieren kaum fertige Komponenten, von vollwertigen GUI-Frameworks ganz zu schweigen. Zudem muss man sich um so viel mehr Dinge kümmern, wie Authentifizierung, Sicherheit, Session- und Workflow-Managment, alles Dinge, die bei einer Desktop-Anwendung von selbst kommen oder gar nicht notwenig sind.

Die Behauptung, es wäre "leicht", Webanwendungen von großer Komplexität zu entwickeln, ist schlicht falsch.

Selbst Firmen, die unendlich viel mehr Ressourcen darauf verwenden können, haben noch keine vernünftige IDE als Webanwendung fertiggebraucht. Von noch komplexeren Anwendungen wie DTP, CAD oder 3D-Modelling ganz zu schweigen...
sma hat geschrieben:Das halte ich für eine gute Sache. Entscheidend ist jedoch, dass keine Software installiert werden muss
Wo ist da das Problem? Installieren musst du eh, mindestens das OS und den Browser, da kommt es auf mehr auch nicht an ;) Nicht jedes OS hat so schlechtes Paketmanagement wie Windows ;)
sma hat geschrieben:nichts betriebssystemspezifisches getan werden muss
In Zeiten moderner GUI-Toolkits wie Qt4 oder wxWidgets, plattformübergreifender IDEs, Buildsysteme, Compiler und Interpreter und gleichzeitig mitunter gravierender Unterschiede zwischen DOM- und ECMA-Script-Implementierungen verschiedener Browser wirkt Plattformunabhängigkeit als Argument für Webanwendungen reichlich lächerlich.
sma hat geschrieben:Mit der Anwendung zusammen will ich ja auch meine Datenlagerung ins Netz verlagern. Zugriff auf die lokale Festplatte ist daher IMHO nicht zwingend notwendig. Gerade für eine IDE, wo ich meinen Quelltext sowieso schon in einer Versionsverwaltung irgendwo im Netz (sourceforge, google code, github usw.) lagere, sehe ich keine Notwendigkeit für den lokalen Zugriff.
Angesichts der Tatsache, dass die meisten Leute noch nicht mal begreifen, was es bedeutet, wenn beim Webmailen am öffentlichen Hotspot die Firefox-Adresszeile nicht gelb ist, ist die Vision einer umfassenden Speicherung von persönlichen Daten im Web einer eher erschreckende ...

Dabei ist Google ja nicht mal die größte Gefahr, die haben ja sogar ein wirtschaftliches Interesse daran, diese Daten zu schützen, immerhin sind sie deren Kapital. Ich fürchte vielmehr Arbeitgeber, Banken, Versicherungen usw., die an diesen Daten interessiert sind, und angesichts des mangelnden Bewusstseins für Sicherheit und Datenschutz leicht an diese Daten kommen, wenn sie es nur wollen ...

Man muss sich nur mal die aktuellen Nachrichten ansehen, um zu sehen, wie es um den Datenschutz in unserem Land bestellt ist ... ein Detektiv, der im Auftrag deiner Versicherung deine Daten an einem Hotspot mitliest, scheint da keine so unrealistische Vision mehr zu sein.

Edit: Quotes korrigiert
burli
User
Beiträge: 1116
Registriert: Dienstag 9. März 2004, 18:22

Mittwoch 4. Juni 2008, 14:14

lunar hat geschrieben: Wo ist da das Problem? Installieren musst du eh, mindestens das OS und den Browser, da kommt es auf mehr auch nicht an ;) Nicht jedes OS hat so schlechtes Paketmanagement wie Windows ;)
Seit wann hat Windows ein Paketmanagement? ;)
lunar hat geschrieben: In Zeiten moderner GUI-Toolkits wie Qt4 oder wxWidgets, plattformübergreifender IDEs, Buildsysteme, Compiler und Interpreter und gleichzeitig mitunter gravierender Unterschiede zwischen DOM- und ECMA-Script-Implementierungen verschiedener Browser wirkt Plattformunabhängigkeit als Argument für Webanwendungen reichlich lächerlich.
Wie gesagt, bei Betriebssystemen hat man 3 wichtige Plattformen für die sich mittels Python oder sogar C/C++ und wxPy oder PyQt relativ leicht entwickeln lässt. Aber bei Browsern flucht man ja schon über die Unterschiede zwischen IE6 und IE7, von Firefox, Opera usw rede ich erst gar nicht. Wobei "normale" Webseiten für "nicht-MS-Browser", die sich weitestgehend an W3C halten, relativ einfach sind. Nur was sma da vorhat ist alles andere als "normal" für einen Webbrowser und gehört da IMHO einfach auch nicht hin. Und das Argument der Installation ist sowas von albern.

Für mich besteht ein Browser aus HTML, CSS, ein klein wenig JavaScript und, wenn absolut nicht darauf verzichtet werden kann, ein Mediaplayer. Und das ganze dient für was wozu es ursprünglich mal gedacht war: Webseiten anzeigen. JavaScript gehört, wie von Netscape ursprünglich gedacht, in eine Sandbox ohne irgendwelche Zugriffsmöglichkeiten auf den PC. Dank MS und deren Versuche JS "zum Nutzen der Anwender" zu erweitern gibts jetzt halt solche Möglichkeiten wie Viren zu installieren oder den Router zu modifizieren (Und welcher Schwachkopf hat sich eigentlich den Mist einfallen lassen JavaScript in PDF oder Flash Videos zu packen??? :evil: )
Benutzeravatar
Sr4l
User
Beiträge: 1091
Registriert: Donnerstag 28. Dezember 2006, 20:02
Wohnort: Kassel
Kontaktdaten:

Mittwoch 4. Juni 2008, 23:46

Einfach ausgedrückt.

Der Vorteil von Webanwendungen:
Sie laufen überall da wo ich Internet habe, ohne etwas zu installieren, nützlich weil ich das u.a. auch nicht kann bei Rechner von Arbeit, Schule, Freunden und Bekannten.

Nachteil: Man macht sich von der Internetanbindung und den Servern abhängig

Gegen eine Editor im Netz ist doch nichts zu sagen.
Ich denke da so an MS Exchange mit seinem Outlook (als Desktopprogramm) und Outlook Web Access. Solche Ansätze finde ich gut.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Samstag 7. Juni 2008, 12:04

Ich halte nochmal dagegen, es ist sowieso schon OT :)

Burli meint, drei Betriebssysteme zu unterstützen ist einfacher als 20 Browser. Meine Sicht ist eine andere. Neben dem IE (der mich persönlich gar nicht interessiert und nur wichtig ist, wenn man über Anwendungen für die Masse redet) sind IMHO noch Gecko und Webkit wichtig, wobei ich auf Webkit als letztlichen Sieger tippe, da diese Engine neben Apple von Nokia (und Trolltech), Sun, Adobe und Google unterstützt wird. Wir reden also von nur 3 Rendering-Engines bei denen Gecko und Webkit zudem noch sehr ähnlich weil standardkonform sind.

Wichtiger ist aber IMHO, dass alle drei für den User nur eine Plattform bilden - das Web. Schreibt man traditionelle GUI-Anwendungen, so muss man für Mac, Linux und Windows sehr spezielle und unterschiedliche Konventionen einhalten, damit sich die Anwendung nicht fremd und unvertraut anfühlt. Mac und Windows haben zum Beispiel unterschiedliche Konventionen, die die Schaltflächen eines Nachrichtenfensters benannt und angeordnet werden müssen.

Dies treibt meiner Erfahrung nach den Aufwand für cross-plattform-GUIs stärker in die Höhe als das Umschiffen von Browser-spezifischen Darstellungsproblemen.

Lunar hält das Web zwar für eine gute Plattform für die Anwendungsentwicklung, nicht jedoch für Anwendungen. Dazu möchte ich fragen, warum etwas zwar für Software-Entwickler gut sein darf, nicht aber auch für andere Anwender? Sourceforge ist eine Webanwendung für einen Anwendungsfall so wie es ein Tournierplanungsprogramm für eine andere Anwendergruppe sein könnte. Warum soll es dort keine webbasierte Lösung geben?

Das Argument, dass man eine Web-IDE nicht bauen kann, weil zu wenig Komponenten wie z.B. Scintilla existieren (Scintilla finde ich übrigens als beschränkt und wenig (in Python) erweiterbar und für ein Problem, warum fast all die selbstgeschriebenen IDEs Mittelmaß bleiben. Aber das ist ein anderes Thema) kann ich nicht akzeptieren, sondern nur als Appell auffassen, dann eben solche Komponenten zu schaffen.

Für Seaside baut übrigens gerade ein Entwickler von Cincom eine Web-IDE für Smalltalk - aber das mit dem einen Entwickler kann auch nicht das Maß sein. Wieviele Entwickler haben an Eclipse gearbeitet? Ich tippe auf 20 bis zur ersten Version. Inzwischen beschäftigt das Eclipse-Projekt hunderte und wächst und wächst ... bzgl. wuchert vor sich hin.

Dinge wie "Authentifizierung, Sicherheit, Session- und Workflow-Managment" erwarte ich eigentlich von einem guten Web-Rahmenwerk bereits. Mir fällt sofort wieder Seaside ein, aber es muss doch auch andere geben, die von diesen Themen abstrahieren. Zumindest die ersten drei werden doch auch von Django adressiert.

Ich habe meines Wissens nicht geschrieben, es sei leicht, solche Anwendungen zu bauen, sondern einfach (und einfach kann verdammt schwer sein) neue Anwendungen zu schreiben und zu verteilen. Dabei dachte ich insbesondere an die Google App Engine.

Zum Thema Installation: Ich denke dabei hauptsächlich an das übliche Szenario, wo es nicht erlaubt ist, irgendwelche neue Software zu installieren - wo man nicht einfach mal das GUI-Toolkit der Wahl und weitere Abhängigkeiten nachinstallieren kann (oder will). Ein Browser (in hoffentlich aktueller Version) ist in der Regel vorinstalliert. Bei uns in der Firma verbreiten sich Webanwendungen sofort - Software installieren dürfen "normale" Anwender außerhalb der Entwicklungsabteilung aber nicht. Da kann man nicht mal eben schnell ein "Goody" weiterreichen. Wenn die an einem EM-Tipp teilnehmen sollen, dann bietet sich eine Webanwendung an - die kann jeder sofort aufrufen.

Den Datenschutzaspekt möchte ich in dieser Diskussion ausklammern, da er IMHO nicht mit den Webanwendungen zu tun hat sondern in gleichem Maße auch für Desktop-Anwendungen gilt. Auch hier könnte ein Arbeitgeber, die USA, der Geheimdienst, usw. wirklich alles mitlesen, etwa in dem alle Tastendrücke und Mausbewegungen aufgezeichnet werden, indem die Datenkommunikation zwischen dem Desktop-Client und dem Server, die in beiden Fällen die eigentliche Arbeit macht, mitgeschnitten wird oder inidem Bildschirme abfotografiert werden. Es ist unabhängig von der konkreten Technologie, ob man dem System vertraut oder misstraut.

PDF kann übrigens inzwischen nicht nur JavaScript, sondern auch neuerdings Flash einbinden. Ich glaube, ein Traum von Adobe ist, dass PDF irgendwann man HTML ersetzt. Ansonsten ist Video IMHO etwas, das natürlich etwas wie Flash gehört, was ja das dröge textbasierte HTML um multimediale Fähigkeiten ersetzen sollte. Und ohne Video in Flash hätten wir jetzt nicht das Fernsehen der Zukunft - Youtube und co.

Mich freut aber, dass Sr4l meine Einschätzungen der Lage zu teilen scheint.

Übrigens, ich habe eine proof of concept mit einem Editor, der unter Safari und Firefox läuft (IE zu testen war mir zu mühsam, da ich zu dem Punkt kein Windows greifbar hatte) und wie geplant, die DOM-Knoten für einzelne Zeilen manipuliert und diese einzeln einfärbt. Was mir fehlt ist eine Selektion mittels Cursor+Shift-Tasten und das Einfärben über Zeilengrenzen hinweg. Sowas wie einen Emacs im Web könnte ich jetzt aber bauen - wäre nur noch Fleißarbeit für die verschiedenen Befehle (und den Lisp-Interpreter ;)

Beide fehlende Funktionen erfordern wohl, dass ich mir pro Zeile merke, mit welchem Zustand ich diese darzustellen beginne. Ich möchte nicht bei jedem Tastendruck immer den gesamten Text neu einfärben, in HTML verwandeln und darstellen sondern minimale Änderungen am DOM machen. Tippe ich etwa '"""' um einen mehrzeiligen String zu beginnen, soll ich dann den restlichen Text mit zum Ende als String färben, den String bis zum Zeilenende als Fehler färben, weil das Ende fehlt oder gar nichts färben? Der erste Fall wäre der langsamste, weil ich die größte Änderung hätte.

Stefan
lunar

Samstag 7. Juni 2008, 12:40

sma hat geschrieben:Wir reden also von nur 3 Rendering-Engines bei denen Gecko und Webkit zudem noch sehr ähnlich weil standardkonform sind.
Wenn du es dir leisten kannst, die Opera-Engine außen vorzulassen, ist das deine Sache ...

Wenn du aber die Zahl der zu unterstützenden Engines limitierst, dann sollten wir für einen fairen Vergleich vielleicht auch die Zahl der zu unterstützenden Desktop-Plattformen limitieren?
Schreibt man traditionelle GUI-Anwendungen, so muss man für Mac, Linux und Windows sehr spezielle und unterschiedliche Konventionen einhalten, damit sich die Anwendung nicht fremd und unvertraut anfühlt. Mac und Windows haben zum Beispiel unterschiedliche Konventionen, die die Schaltflächen eines Nachrichtenfensters benannt und angeordnet werden müssen.
Nichts für ungut, aber hast du überhaupt schon mal mit einem modernen Framework Desktop-Anwendungen entwickelt? Ich bezweifele das, sonst wüsstest du, dass solche plattformspezifischen Dinge vom Framework übernommen werden. Qt4 beispielsweise passt die Positionen der Knöpfe entsprechend der Plattform an, und erkennt dabei sogar Gnome und KDE als unterschiedliche Plattformen. Auch behandelt es beispielsweise die Menüleiste entsprechend der Plattformkonventionen.

Btw, der Unterschied zwischen einer Webanwendung und einer plattformspezifischen Desktop-Anwendung ist nochmals um Welten größer als der zwischen Desktop-Anwendungen verschiedener Systeme. Plattformkonventionen sind kein geeignetes Argument gegen Desktop-Anwendungen, weil Webanwendungen diese in der Regel noch weniger einhalten (wie sollten sie auch?).
Lunar hält das Web zwar für eine gute Plattform für die Anwendungsentwicklung, nicht jedoch für Anwendungen. Dazu möchte ich fragen, warum etwas zwar für Software-Entwickler gut sein darf, nicht aber auch für andere Anwender? Sourceforge ist eine Webanwendung für einen Anwendungsfall so wie es ein Tournierplanungsprogramm für eine andere Anwendergruppe sein könnte. Warum soll es dort keine webbasierte Lösung geben?
Vielleicht weil ein CRUD-Ticket-Framework mit ein paar Mailinglisten, etc. nicht so komplex ist wie eine Desktop-Anwendung im Stil von Word oder eine IDE im Stil von Eclipse oder VS?
Dinge wie "Authentifizierung, Sicherheit, Session- und Workflow-Managment" erwarte ich eigentlich von einem guten Web-Rahmenwerk bereits.
Ein Framework erleichtert dir die Arbeit zwar, nimmt sie dir aber nicht ab. Workflow-Managment kommt in einer GUI von selbst, da man eine einzige Navigationsstruktur hat, die den Nutzer in entsprechende Wege zwingt und so Fehler verhindert.

Bei einer Webanwendung dagegen hat man zwei parallele Navigationsstrukturen, nämlich die der Anwendung selbst, und die des Browsers. Das führt entweder zu erhöhter Komplexität, weil man erkennen muss, wenn der Anwender innerhalb eines Ablaufs den Back-Button des Browsers betätigt, oder zu Limitierung einer Navigationsstruktur, was den Benutzer, der den "Back"-Button gewohnt ist, nur verwirrt. Auch muss man mit parallelen Requests des gleichen Nutzers zurecht kommen. Zwei Dinge, die bei der Webentwicklung viel Arbeit erfordern, um die Anwendung in konsistentem Zustand zu halten, bei Desktop-Anwendungen keine Probleme bereiten, da Desktop-Anwendungen eben nicht mit Parallelitäten zurecht kommen müssen.

Versuche, Webanwendungen im Framework in einen kontinuierlichen Ablauf zu zwängen, sind eher kläglich gescheitert.

Auch muss man als Webentwickler mit wesentlich mehr inkonsistenten Technologien zurecht kommen, während Desktop-Frameworks in der Regel homogen sind.

Du kannst schlecht abstreiten, dass Webentwicklung komplexer ist als Desktop-Entwicklung.
Wenn die an einem EM-Tipp teilnehmen sollen, dann bietet sich eine Webanwendung an - die kann jeder sofort aufrufen.
Ein EM-Tipp ist eine Sache, eine DTP-Anwendung oder eine IDE eine andere Sache.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Samstag 7. Juni 2008, 13:05

Oh, noch ein Nachtrag: 280Slides zeigt, was als Webanwendung möglich ist. Als ehemalige Objective-C-Entwickler haben die Autoren das Ding in Objective-J geschrieben, einem objektorientierten JavaScript-Dialekt, der ad-hoc im Client zu gewöhnlichem JavaScript kompiliert wird.

Hier ist ein Codebeispiel:

Code: Alles auswählen

- (void)themePanel:(ThemePanel)aThemePanel didEndWithReturnCode:(unsigned)aReturnCode
{
    if (aReturnCode == CPCancelButton)
        return;

    var documents = [self documents],
        count = [documents count];
        
    while (count--)
        [self removeDocument:documents[0]];
    
    [super newDocument:self];
}
Das Laufzeitsystem umfasst ungefähr 2000 Zeilen JavaScript-Code.

Stefan
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Samstag 7. Juni 2008, 13:35

lunar, ich stimme dir zu, dass Webanwendungen im Vergleich zu Desktop-Anwendungen in der Regel primitiv und einfach sind. Mir war auch nicht bekannt, dass Qt z.B. Buttons tauscht und umbenennt (Was "Save" auf dem Mac heißt, soll "OK" unter Windows lauten). Meine letzte Desktop-Anwendung habe ich vor 4 Jahren geschrieben, davor aber viele Jahre mit Smalltalk und Java kommerzielle Desktop-Anwendungen gebaut. Dort mussten wir uns immer noch eine Schicht über das Rahmenwerk ziehen, um viele plattformspezifische Probleme allgemein zu lösen. Ich kenne jedoch auch die Zeit, als auch Desktop-Anwendungen primitiv waren und das textbasierte Fenstersystem Turbovision unter DOS als Neuerung gepriesen wurde.

Die Entwicklung hat IMHO gerade erst begonnen. Sie zu verlachen, kann riskant sein, denn "low-end disruptive technologies" können etablierte Technologien verdrängen, selbst wenn diese besser sind. Das klassische Beispiel sind Hydraulikbagger, die ehemals dominierende Kabelbagger verdrängt haben. Im Kampf ums Überleben wurden diese in immer kleinere Nischen verdrängt. Das selbe kann IMHO Desktop-Anwendungen passieren.

[quote=lunar]Vielleicht weil ein CRUD-Ticket-Framework mit ein paar Mailinglisten, etc. nicht so komplex ist wie eine Desktop-Anwendung im Stil von Word oder eine IDE im Stil von Eclipse oder VS?[/quote]
Word ist in der Tat recht komplex. Eine entsprechende WYSIWYG-Layout-Engine baut man nicht mal eben. Mein Gefühl sagt mir aber, dass HTML schon recht nah von einen Layout-Funktionen dran ist, sodass es eher das Problem eines Editors ist. Vielleicht kann hier Flash helfen. Hast du dir mal Buzzword von Adobe angeschaut? Das kommt Word schon recht nah. Das ganze grafische Drumherum mit Dialogen und Menüs halte ich nicht so für das Problem. Ich könnte mir vorstellen, das man ein Word 97 auch im Web realisieren kann. Es wäre für die Mehrzahl der Anwender wahrscheinlich ausreichend.

Eine IDE halte ich im Vergleich zu Word für deutlich einfacher. Die Eclipse-Jungs überlegen ja gerade aktiv, ob man für Eclipse 4 nicht eine Webvariante baut. Einen Prototyp - bei dem der Code-Editor mit Flex für Flash gebaut ist - gibt es schon. Das Eclipse Rich Ajax Platform Projekt kann bereits jetzt "instant" Webanwendungen nach dem normalen Java-Desktop-Pattern bauen und quasi automatisch webfähig machen (allerdings wohl ohne den Code-Editor).

[quote=lunar]Workflow-Managment kommt in einer GUI von selbst, da man eine einzige Navigationsstruktur hat, die den Nutzer in entsprechende Wege zwingt und so Fehler verhindert.

Bei einer Webanwendung dagegen hat man zwei parallele Navigationsstrukturen, nämlich die der Anwendung selbst, und die des Browsers. Das führt entweder zu erhöhter Komplexität, weil man erkennen muss, wenn der Anwender innerhalb eines Ablaufs den Back-Button des Browsers betätigt, oder zu Limitierung einer Navigationsstruktur, was den Benutzer, der den "Back"-Button gewohnt ist, nur verwirrt.[/quote]
Das ist alles richtig. Das von mir erwähnte Seaside erlaubt das normale ereignisgesteuerte Desktop-GUI-Anwendungsartige Muster auch für Webanwendungen zu benutzen und kümmert sich auch um den Back-Button - das macht gerade Seaside so einzigartig. Ist leider nicht Python, aber man könnte so etwas bauen, wenn man denn Continuations als Sprachmittel hätte.

Ansonsten hilft nur, entweder dem Benutzer den Back-Button abzutrainieren (ich komme ja auch in Word nicht auf die Idee, "back" drücken zu wollen und ignoriere auch 90% der anderen angebotenen Buttons) oder aber für die Navigation innerhalb von unabhängigen Teilen der Anwendung einzusetzen.

[quote=lunar]Auch muss man als Webentwickler mit wesentlich mehr inkonsistenten Technologien zurecht kommen, während Desktop-Frameworks in der Regel homogen sind.

Du kannst schlecht abstreiten, dass Webentwicklung komplexer ist als Desktop-Entwicklung.[/quote]
Das mit den verschiedenen Technologien ist richtig und das es komplexer ist, auch. Dennoch interessiert das den Anwender wenig und für ihn sind die Anwendungen leichter und das ist alles, was zählen soll.

Die Entwicklung einfacher zu machen muss ein Thema sein, welches den Anwender gar nicht zu interessieren hat und wo wir als Software-Entwickler einfach noch unsere Hausaufgaben machen müssen. Ein Rahmenwerk wie Qt ist ja auch nicht immer da gewesen, sondern über viele Jahre gewachsen. Hast du mal für Windows 3.0 pur direkt in C (noch vor MFC) Anwendungen entwickelt? Das war auch kein Vergnügen. Dagegen war zur selben Zeit Smalltalk der Himmel auf Erden.

Stefan
lunar

Samstag 7. Juni 2008, 13:46

sma hat geschrieben:
lunar hat geschrieben:Workflow-Managment kommt in einer GUI von selbst, da man eine einzige Navigationsstruktur hat, die den Nutzer in entsprechende Wege zwingt und so Fehler verhindert.

Bei einer Webanwendung dagegen hat man zwei parallele Navigationsstrukturen, nämlich die der Anwendung selbst, und die des Browsers. Das führt entweder zu erhöhter Komplexität, weil man erkennen muss, wenn der Anwender innerhalb eines Ablaufs den Back-Button des Browsers betätigt, oder zu Limitierung einer Navigationsstruktur, was den Benutzer, der den "Back"-Button gewohnt ist, nur verwirrt.
Das ist alles richtig. Das von mir erwähnte Seaside erlaubt das normale ereignisgesteuerte Desktop-GUI-Anwendungsartige Muster auch für Webanwendungen zu benutzen und kümmert sich auch um den Back-Button - das macht gerade Seaside so einzigartig. Ist leider nicht Python, aber man könnte so etwas bauen, wenn man denn Continuations als Sprachmittel hätte.
Das löst nicht das Problem paralleler Requests.
Ansonsten hilft nur, entweder dem Benutzer den Back-Button abzutrainieren (ich komme ja auch in Word nicht auf die Idee, "back" drücken zu wollen und ignoriere auch 90% der anderen angebotenen Buttons)
Es geht selten gut, gegen den Benutzer anzuprogrammieren ;)
Dennoch interessiert das den Anwender wenig und für ihn sind die Anwendungen leichter und das ist alles, was zählen soll.
Findest du? Zumindest ich persönlich sehe das anders, und mein Umfeld sagt mir, dass ich damit nicht alleine stehe ;)
Ein Rahmenwerk wie Qt ist ja auch nicht immer da gewesen, sondern über viele Jahre gewachsen. Hast du mal für Windows 3.0 pur direkt in C (noch vor MFC) Anwendungen entwickelt?
Mir hat schon C++/MFC gereicht ;) Soweit zurück kann ich gar nicht gehen ;)

Wie wär's, wenn wir die Diskussion an dieser Stelle mal pausieren, jeder von uns legt einen Bookmark ab, und in fünf Jahren treffen wir uns wieder und schauen, was draus geworden ist?

Ich persönlich habe nämlich das Gefühl, dass wir beide eh auf unserer Meinung beharren werden, und keiner den anderen überzeugen können wird ;) Warten wir also einfach ab, was die Zukunft bringt ;)
burli
User
Beiträge: 1116
Registriert: Dienstag 9. März 2004, 18:22

Samstag 7. Juni 2008, 13:59

sma hat geschrieben:Burli meint, drei Betriebssysteme zu unterstützen ist einfacher als 20 Browser. Meine Sicht ist eine andere. Neben dem IE (der mich persönlich gar nicht interessiert und nur wichtig ist, wenn man über Anwendungen für die Masse redet) sind IMHO noch Gecko und Webkit wichtig, wobei ich auf Webkit als letztlichen Sieger tippe, da diese Engine neben Apple von Nokia (und Trolltech), Sun, Adobe und Google unterstützt wird. Wir reden also von nur 3 Rendering-Engines bei denen Gecko und Webkit zudem noch sehr ähnlich weil standardkonform sind.
wenn du sowas machen willst das sollte das schon konsequent sein. Dh auch IE. Aber da der IE6 noch sehr verbreitet ist musst du sowohl IE6 als auch IE7 berücksichtigen. Hast du schonmal eine Webseite programmiert?

Du kannst derzeit mindestens von IE6, IE7, Gecko, Webkit und Opera ausgehen. Viel Spaß beim Fluchen. Ich fluche jedenfalls schon bei normalen Webseiten mit HTML und CSS
Antworten