Das deutsche Python-Forum

Hallo,

hat irgendwer Erfahrung mit dem Desktop Framework Dabo? Gibt es eine Anleitung?

Gruß Christian

Noch nie von dabo vorher gehört, aber eine Doku in Form einer Referenz und eines sehr kurzen Tutorials sowie einer Reihe von Screencasts (unnötigerweise im zip-Format) findet man doch auf deren Homepage. Das ist mehr, als bei vielen anderen Projekten.

Mut macht IMHO auch, dass ein "paul" laut Trac-Timeline aktiv an dem Sourcecode zu entwickeln scheint. Der Screencast, den ich mir gerade anschaue, ist allerdings von 2006.

Ich frage mich nur generell, ob man heutzutage nicht neue Projekte besser gleich als Webapp (sei es klassisch mit HTML oder in einer geeigneten RIA-Form) realisiert.

Stefan

sma hat geschrieben: Ich frage mich nur generell, ob man heutzutage nicht neue Projekte besser gleich als Webapp (sei es klassisch mit HTML oder in einer geeigneten RIA-Form) realisiert.

Stefan

Ich denke nicht das man unbedingt alles als WebApp versuchen sollte.
Alles was eine komplexe, dynamische gui braucht ist bei WebApp schlecht aufgehoben.
Und man muss nicht für jeden Browser andere Bugs umgehen .

Und Java Webstart ist auch nicht so das wahre.
Siehe unmengen von müll-sap Anwendungen.

@ Byte:
Aber warum nimmst du nicht gleich wxPython?

Mad-Marty hat geschrieben:Aber warum nimmst du nicht gleich wxPython?

Damit arbeite ich zur Zeit, da ich kein Ahnung vom Programmieren habe dauert das aber ziemlich lange, bis ich zu dem Ergebnis komme das ich mir vorstelle. Ich wollte nur eine GUI für eine Datenbankanwendung und dafür soll Dabo sein, oder?

Gruß Christian

sma hat geschrieben:Ich frage mich nur generell, ob man heutzutage nicht neue Projekte besser gleich als Webapp (sei es klassisch mit HTML oder in einer geeigneten RIA-Form) realisiert.

Crap... ich möchte nicht jedesmal eine Browser öffnen, nur um Adressen zu suchen oder Mails zu schreiben. Sorry, aber echte Desktop GUIs sind meiner Erfahrung nach meistens das bessere Interface als irgendwelche tollen Hyper-Web-2.0 Services. Mit ein bisschen intelligentem Design packt man die Logik sowieso in ein Package, dann ist das Interface auch austauschbar.

@Byte
Wenn man keine Ahnung, sollte man nicht programmieren. Wenn man programmieren will, und keine Ahnung hat, sollte man lesen und programmieren, bis man Ahnung hat.

Und nein, DABO kann dir das Programmieren nicht abnehmen. Klickibunti und Buttons rumschieben ist zwar nett, aber so läuft programmieren eben nicht.

Edit: Ich sehe gerade, dass sich die Autoren auf VisualFoxPro berufen. Das ist nicht gerade das beste Vorbild, sondern eigentlich ein Haufen Müll.

lunar hat geschrieben:Crap... ich möchte nicht jedesmal eine Browser öffnen, nur um Adressen zu suchen oder Mails zu schreiben.

Ich bezweifle, dass die Geschwindigkeit, mit der sich die Programme öffnen, wirklich so unterschiedlich ist oder ob das wirklich ein schlagkräftiges Argument ist, möchte mich aber gar nicht auf die Diskussion einlassen.

Eine webbasierte Lösung hat den Vorteil, dass sie nicht an einen Rechner gebunden ist. Ich nutze 4+ Systeme und sehe einen Vorteil darin, eine Anwendung wie z.B. Googlemail überall und jederzeit (Internet-Anschluss vorausgesetzt) verfügbar zu haben. Vielleicht habe ich eine andere Art von Anwendung im Hinterkopf. Doch ich denke, einfache Datenbank-zentrische (Informations-)Systeme ließen sich zum Beispiel mit Django recht gut als Webanwendung realisieren. Ich halte es zudem auch für einfacher zu lernen, als ein doch recht komplexes System wie wxPython.

lunar hat geschrieben:Sorry, aber echte Desktop GUIs sind meiner Erfahrung nach meistens das bessere Interface als irgendwelche tollen Hyper-Web-2.0 Services.

Mit Adobe Flex kann man sehr schnell sehr schöne (und skinnbare) dynamische GUIs bauen, die mit einem "klassichen" UI wie wxPython vom Umfang der UI-Komponenten bis auf einen komplexen Richtext-Editor oder einen Texteditor mit Syntaxhighlighting gleichwertig sind. Flex ist auf typische "Enterprisy-Anwendungen" zugeschnitten. Es kümmert sich nicht nur um das Layout, sondern bietet auch "Databinding", also das bequeme Verknüpfen von Modellen mit dem UI. WPF a.k.a. Avalon kann das auch, aber ist im Gegensatz zu Flex auf Windows beschränkt. Flex funktioniert dank Flash unter Windows, Linux und Mac OS X. Mit Hilfe von Adobe AIR kann man außerdem die Webanwendung zu einer Desktop-Anwendung machen.

Somit kann ich deine Erfahrung nicht teilen. Es ist wahr, es gibt sehr viel Mist - sowohl im Webumfeld als auch bei klassichen UIs, doch das liegt selten an der Technologie, sondern meist an den Leuten, die sich an dem UI versuchen.

Der Nachteil bei Flex/AIR ist natürlich: Man muss ActionScript beherrschen (ein JavaScript-Superset, welches wie Java aussieht) und kann Python nur für die Serverseite einsetzen.

Silverlight (Microsofts Angriff auf Flash) wird ja auch Python unterstützen. Wäre damit in diesem Forum vielleicht die passendere Empfehlung. Noch gibt es aber AFAIK kein vergleichbares UI-Rahmenwerk.

Vielleicht denkt dann auch Adobe darüber nach, alternative Sprachen anzubieten. Im Rahmen des Mozilla-Projekts, welches die selbe VM nutzen will wie Flash bereits nutzt, hat kann ja schon ein Projekt angekündigt, mit dem man .NET-Anwendungen wie IronPython in ABC (ActionScript Bytecode - Format der Tamarin-VM) können soll.

Leider ist der Aufwand, sich in Flex, ActionScript, HTML, CSS oder JavaScript einzuarbeiten nicht unerheblich. Vielleicht ist etwas wie Pythoncard eine Alternative. Die Screenshots (mehr habe ich mir leider nicht angeschaut) sehen aber zum Weglaufen häßlich aus ;)

Stefan

Flash läuft nicht so toll unter Linux. Gibt immer wieder Probleme, z.B. mit 64-Bit-Systemen. Man macht sich damit von Adobe total abhängig.

Mit Linux und X-Anwendungen ist man auch nicht an einen Rechner gebunden. Der Rechner wo die GUI angezeigt wird, muss nicht der sein, auf dem das Programm läuft. Auch unter Windows gibt's Möglichkeiten "grafisch" auf entfernten Rechnern zu arbeiten.

Eine GUI in einem Browser ist einfach für viele Leute ein Fremdkörper, der sich nicht ordentlich in das umgebende System einfügt. Da gibt es immer einen Bruch in der Bedienung was Tastenkürzel, Tab-Reihenfolge, Drag-N-Drop usw. angeht.

BlackJack hat geschrieben:Flash läuft nicht so toll unter Linux. Gibt immer wieder Probleme, z.B. mit 64-Bit-Systemen. Man macht sich damit von Adobe total abhängig.

Mit Linux und X-Anwendungen ist man auch nicht an einen Rechner gebunden. Der Rechner wo die GUI angezeigt wird, muss nicht der sein, auf dem das Programm läuft. Auch unter Windows gibt's Möglichkeiten "grafisch" auf entfernten Rechnern zu arbeiten.

Eine GUI in einem Browser ist einfach für viele Leute ein Fremdkörper, der sich nicht ordentlich in das umgebende System einfügt. Da gibt es immer einen Bruch in der Bedienung was Tastenkürzel, Tab-Reihenfolge, Drag-N-Drop usw. angeht.

Außerdem setzen Webanwendungen, die nicht auf einem lokalen Server laufen, immer auch funktionierende Internetverbindungen voraus. Das ist für mich persönlich schon mal ein Nachteil, meine Internetverbindung ist nämlich alles andere als stabil. Zudem hat nicht jeder da draußen DSL 16000, und gerade aufwendig Web-UIs erfordern zum Teil sehr viel Geduld. Selbst Ajax kann die Verzögerungen der Internet-Leitung nur bedingt wegmachen.

Die Abhängigkeit von Adobe mag für einen Linux-User besonders schwer wiegen, doch was genau bedeutet dies in der Praxis? Wird Adobe Flash nicht mehr unterstützen? Nicht solange es Youtube gibt. Nicht solange sie mit ihren Technologien Erfolg haben. Je mehr Nutzer es gibt, desto wahrscheinlicher ist es, dass die Technologie Beständigkeit hat.

Für die Eventualität zu planen, dass Adobe möglicherweise einmal Flash nicht mehr unterstützen wird jetzt schon zu planen, verstößt IMHO gegen YAGNI. Wenn's soweit ist, dann ist die Zeit gekommen, über Alternativen nachzudenken. Technisch und theoretisch wäre es möglich, einen eigenen Flash-Player zu bauen, jedoch behält sich Adobe bislang dieses Recht vor.

Ich bin kein Linux-Nutzer sondern abhängig von Apple ;) Eine Flash-VM für ein aktuelles 64-bit-System zu bekommen wäre da natürlich ein gewichtiger Nachteil. James Ward schrieb aber bereits 2006, dass es leicht möglich sei, die Flash-VM in Firefox zu integrieren. Er ist Evangelist. Vielleicht hat er übertrieben. Fakt ist leider, dass Adobe Air 1.0 nicht für Linux verfügbar sein wird, wie ich gerade gelesen habe. Definitiv hat Linux bei Adobe nicht den selben Stellenwert wie OSX und Windows. Das würde mich als Linux-Anwender wahrscheinlich wurmen. Sollte Byte Linux benutzen wollen, war mein Tipp nicht gut.

Dennoch, ich bin davon überzeugt, dass reine Desktop-Anwendungen immer stärker von webbasierten Anwendungen verdrängt werden. Dieses Forum ist ja auch eine Webanwendung. Das klassische Usenet, welches dedizierte Desktop-Anwendungen (Newsreader) brauchte, hat kaum noch Bedeutung. Ruft jemand nach einem Forum basierend auf wxPython? Ich glaube nicht. Selbst wenn dieses Eingabeloch hier echter Mist ist. Zwar kann ich im Safari das Textarea größer ziehen und habe auch eine Rechtschreibprüfung, doch das Einfügen von URLs und anderem Markup ist Quälkram. Dennoch... knapp 4000 Anwender lassen sich davon nicht abschrecken.

Es ist richtig, dass X "remoting" erlaubt. Für Windows und den Mac gibt es ebenfalls Lösung. Allen gemeinsam ist aber, die Betriebssystemspezifisch und nicht allgemein verbreitet sind. Ich will nicht extra unter Windows einen X-Server oder unter Linux einen Client für Microsofts Remoting-Protocol installieren müssen - vielleicht darf ich das nicht, da ich auf dem Rechner nur zu Gast bin - um an "meine" Anwendungen zu kommen. Des weiteren bieten zentral gehostete Anwendungen neben einem einheitlichen UI noch andere Vorteile: Jemand anderes kümmert sich um den Betrieb und die Datensicherung. Der Preis, den man zahlen muss ist das Vertrauen in die Seite, die diese Dienstleistung übernimmt und eine stabile und ausreichend schnelle Datenverbindung.

Ich denke wahrscheinlich mehr als Firmenlösungen ("enterprisy") oder professionelle Endanwender-Lösungen als an die erste kleine GUI-Anwendung eines Privatmanns. Da sind andere Anforderungen wichtig. Fast immer ist hier eine entferne Datenquelle vorhanden, die auf irgendeine Weise visualisiert werden soll. Wenn hier die Darstellung langsam ist, hat das weniger mit Web- oder Desktop-Technologie zu tun, sondern mit der Art und Weise, wie die Daten übertragen werden. Setzt man hier HTTP voraus, weil dies jede Firewall durchtunneln kann, ist es keine Frage der Technologie, ob nun Ajax vom Browser oder äquivalenter Code von einem wxPython-GUI träge wirkt oder nicht.

Wichtig ist hier z.B., ob die Anwendung einfriert, wenn Daten gezogen werden. Flex zwingt einen hier zu der notwendigen asynchronen Lösung, sodass das UI weiterhin reagiert. Naiv mit wxPython gebaut, hängt wahrscheinlich der Eventhandler und damit die ganze Eventverarbeitung. Ich schließe hier von jahrelang beobachteten Fehlern von Swing-Entwicklern auf wxPython.

Will sagen: Eure aufgeführten Nachteile bestreite ich nicht, halte sie aber nicht für wichtiger, als die von mir aufgeführten Vorteile. Am stärksten spricht aus meiner Sicht gegen webgestützte Anwendungen, dass man auf einmal mit einem recht komplexen Technologiemix konfrontiert wird und es deutlich schwerer wird, eine gute Anwendung zu bauen als was z.B. Microsoft bereits vor vielen Jahren mit VisualBasic als state-of-the-art geschaffen hat. Seit den frühen 90ern ist hier eigentlich nichts wirklich besser geworden sondern eher schlechter.

Stefan

Hallo!

Ich hatte mal die Vision, mein Kassenprogramm mit einer Webanwendungs-Schnittstelle auszustatten und es damit jedem zu ermöglichken, das Programm mit HTML- und ein paar SQL-Kenntnissen zu erweitern.

Das ging total in die Hose. Kleine Zusatzprogramme, wie z.B. ein zusätzlicher Tischplan, eine besondere Auswertung oder eine angepasste Eingabeoberfläche für Adressen, waren als Webanwendung erheblich aufwändiger zu erstellen als sie jetzt mit wxPython sind. Schon solche Kleinigkeiten, wie z.B. einen Dialog systemmodal aufpoppen zu lassen oder globale Tastenkombinationen abzufangen oder einfach nur ein Symbol in der Taskleiste unterzubringen, sind in einer Webanwendung schon vorab zum Scheitern verurteilt.

Was ist, wenn ich eine Bildvorschau haben möchte, bevor eine lokale Datei in der Webanwendung geöffnet werden soll? Und so weiter und so fort... Ich könnte jetzt Stundenlang die Dinge aufzählen, die in Verbindung mit einer Webanwendung nicht wie gewünscht funktionieren. Außerdem halte ich es für problematisch, berechtigte Sicherheitsmaßnahmen des Browsers, über fünf Ecken mit Webanwendungen umgehen zu müssen.

Ein Kunde wollte von uns eine Website in der Bilder gescannt und der Bildausschnitt angegeben werden kann. Die Daten werden online an die Druckerei übermittelt um damit Ausweise zu drucken. Dieser Kunde beharrte darauf, dass alles im Browser funktionieren muss. Gut, jetzt habe sie eine Lösung, die nur unter Windows (weil ActiveX) und nur im InternetExplorer funktioniert. Um die Sicherheitsbestimmungen des InternetExplorers zu umgehen, muss jetzt trotz Webanwendung lokal ein Setup ausgeführt werden, welches ein paar Registry-Einträge setzt. Natürlich funktioniert alles wie gewünscht -- aber ich kann in diesem Fall keinen Vorteil einer Webanwendung erkennen. Das gleiche Programm hätte als "normale Anwendung" in der Hälfte der Zeit, mit weniger Problemen und mit weniger Abhängigkeiten erstellt werden können.

Oft müssen in einem größeren Programm auch andere Programme mit eingebunden werden. Man will ja nicht ständig alles neu erfinden. Oder wie druckt man über eine Webanwendung Barcode-Etiketten? Zehn, zwanzig, hundert verschiedene Barcodes an einen Etikettendrucker! Ja, das könnte man als Webanwendung sicher realisieren. Aber kann man auch vom Browser aus, automatisch den Etikettendrucker auswählen und ohne Drucker-Auswahldialog drucken lassen?

Ich muss es jetzt lassen, sonst wird dieser Beitrag noch fünf Seiten lang.

Meine Meinung: Es gibt ein paar Dinge, für die Webanwendungen interessant sind. Z.B. dann wenn ich eine Community aufbauen und miteinander verbinden möchte. Aber man sollte sich vorher immer gut überlegen, ob man dem Benutzer mit einer Webanwendung wirklich einen Gefallen tut oder ob diesem mit einem normalen Programm nicht besser geholfen wäre.

mfg
Gerold

Gerold, du redest von einer anderen Art Software wie ich. Ich möchte und brauche in der Regeln nicht, dass eine Anwendung direkt auf mein System zugreifen kann. Ich möchte im Gegenteil, dass die Anwendung unabhängig vom Betriebssystem läuft. Hardware wie spezielle Drucker habe ich nicht auf dem Radar.

Ich würde bei einem Kassenprogramm (ohne zu wissen, was da die eigentlichen Anforderungen sind) eher so beginnen: Damit die Bedienung, schnell und bequem die Bestellung des Gasts aufnehmen kann, hat sie ein per WLAN als Hausnetz angeschlossenes tragbares Terminal (PDA), auf dem eine Webanwendung läuft, damit ich nicht nach einem Software-Upgrade jedes Terminal neu mit Software bespielen muss. Möglicherweise kann ich den Gästen anbieten, direkt über ihr Telefon oder ein am Tisch befindliches Gerät zu bestellen - erneut bietet sich hier eine Webanwendung an. Um die Software nicht selbst betreiben zu müssen, kaufe ich diesen Service zentral ein. Kombiniert wird dies mit einer Vorrats/Lagerhaltung und einer Abbrechung sowie statistischen Auswertungen über die Umsätze der einzelnen Bedienungen, den erfolg der Gerichte usw. - weitere Webanwendungen, die im Büro im Browser betrachtet werden können.

Wie der eigentliche Bezahlvorgang abläuft, weiß ich nicht zu sagen. Vielleicht braucht dies eine spezielle Software, die mit einer Klassenhardware zusammenarbeitet, um per Mausklick die Kasse zu öffnen usw. Vielleicht können (müssen?) aber auch die Gäste auch direkt per Handy bezahlen, was dann unmittelbar über den Handybrowser zum zentralen Server geht und dort verarbeitet wird.

Ein Kunde wollte von uns eine Website in der Bilder gescannt und der Bildausschnitt angegeben werden kann. Die Daten werden online an die Druckerei übermittelt um damit Ausweise zu drucken.

Zumindest der zweite Teil ist doch machbar - Scannen kann der Browser (außer man denkt über ein Active-X-Control für den IE nach) definitiv nicht, der Benutzer müsste die Bilder ersteinmal manuell hochladen.

In den von dir geschilderten Fällen hätte ich keine Browser-basierte Webanwendung benutzt, jedoch eine auf HTTP basierte Client-Server-Lösung entwickelt, die ich als rich internet client ebenfalls als Webanwendung - im Gegensatz zu einer Webseite oder Browser-basierten Anwendung - bezeichnen würde. Man büßt hier den Vorteil der nicht vorhandenen Installation einer Browser-basierten Anwendung ein.

Bei Python würde ich - reine Theorie - über eine Architektur nachdenken, die einen Kern aus einem dedizierten Python-Interpreter und genug Code hat, um den Rest über HTTP nachzuladen. Also so etwas wie Java-Webstart. Die Schwierigkeit ist, dass sich das System nicht beim Update verklemmt und möglicherweise, dass man Updates inkrementell übertragen kann. Mein erster Ansatz wäre hier vielleicht Mercurial zu benutzen.

Stefan

sma hat geschrieben:Ich bin kein Linux-Nutzer sondern abhängig von Apple Eine Flash-VM für ein aktuelles 64-bit-System zu bekommen wäre da natürlich ein gewichtiger Nachteil. James Ward schrieb aber bereits 2006, dass es leicht möglich sei, die Flash-VM in Firefox zu integrieren. Er ist Evangelist. Vielleicht hat er übertrieben. Fakt ist leider, dass Adobe Air 1.0 nicht für Linux verfügbar sein wird, wie ich gerade gelesen habe. Definitiv hat Linux bei Adobe nicht den selben Stellenwert wie OSX und Windows. Das würde mich als Linux-Anwender wahrscheinlich wurmen.

Wie gut, dass du kein Linux-Anwender bist, sondern Windows-Programmierer, sonst müsstest du dir tatsächlich Gedanken über Portabilität machen. Schon irgendwie erstaunlich: Am Desktop setzt sich langsam die Erkenntnis durch, dass Anwendung portabel sein müssen, Trolltech öffnet Qt4 für Windows, während Microsoft mit .NET erstmals eine Technologie für Programmiersprachen entwickelt hat, die tatsächlich portabel ist. Die Webentwickler, die eigentlich auf mit die freiste aller Technologien bauen können, denken dagegen immer noch in den Kategorien "Windows, IE und Active X" und "der unwichtige Rest, der uns scheißegal ist".

Das klassische Usenet, welches dedizierte Desktop-Anwendungen (Newsreader) brauchte, hat kaum noch Bedeutung.

Uh? Die englisch-sprachige Python-Newsgroup hat wesentlich mehr Posts an einem Tag, als dieses Forum User hat.
Die deutschsprachige Java-Newsgroup ist immer noch sehr beliebt. Komischerweise liest man da dauernd Fragen irgendwelcher J2EE-Fuzzis... selbst die Java-Webentwickler ziehen das Usenet offenbar den Webforen vor. Ehrlich gesagt, ich tue das auch. Usenet-Beiträge kann ich mit Emacs verfassen, mit schönen großem Eingabefeld, hervorragenden Editing-Funktionen und schön konfigurierter GUI. Das ist tausendmal besser als dieses Minieingabefeld mit absolut limitierten Möglichkeiten, welches noch nicht mal Syntax-Highlighting für bbcode bietet.

Ruft jemand nach einem Forum basierend auf wxPython?

Nein, aber Usenet-Clients in Wx gibt es bestimmt, und das Usenet ist ehrlich gesagt wesentlich besser als PHPbb.

Ich denke wahrscheinlich mehr als Firmenlösungen ("enterprisy") oder professionelle Endanwender-Lösungen als an die erste kleine GUI-Anwendung eines Privatmanns. Da sind andere Anforderungen wichtig. Fast immer ist hier eine entferne Datenquelle vorhanden, die auf irgendeine Weise visualisiert werden soll.

Das geht auch mit Desktop-Anwendungen. Überlege einfach mal, warum Desktop-Software wie Lotus Notes oder das ganze SAP-Zeugs immer noch so erfolgreich ist. Letztendlich ist das auch nur Software, die zentral abgelegte Daten verwaltet. Aber eine echte GUI ist wesentlich angenehmer zu bedienen als Web-UIs.

Wenn hier die Darstellung langsam ist, hat das weniger mit Web- oder Desktop-Technologie zu tun, sondern mit der Art und Weise, wie die Daten übertragen werden. Setzt man hier HTTP voraus, weil dies jede Firewall durchtunneln kann, ist es keine Frage der Technologie, ob nun Ajax vom Browser oder äquivalenter Code von einem wxPython-GUI träge wirkt oder nicht.

Bei einer Desktop-Anwendung wird die GUI auf dem lokalen Rechner erzeugt, über die Leitung fließen nur harte Daten. Webanwendungen schleusen dagegen auch das HTML zur Erzeugung des UI über die Leitung. Ist die Leitung langsam, ist auch das UI langsam. Desktop-Anwendungen kennen dieses Phänomen nicht, da die GUI immer flüssig läuft. Der User muss zwar trotzdem auf die Daten warten, aber die GUI regiert schnell. Das macht einen enormen Unterschied in der Wahrnehmung der User aus.

Naiv mit wxPython gebaut, hängt wahrscheinlich der Eventhandler und damit die ganze Eventverarbeitung. Ich schließe hier von jahrelang beobachteten Fehlern von Swing-Entwicklern auf wxPython.

Schlecht programmierte GUIs können wohl kaum als Argument für Webanwendungen herhalten. Dieses Forum ist auch nicht asynchron, vergiss das nicht. Die wenigsten Webanwendung sind wirklich asynchron geschrieben, weil das bei Webanwendungen wesentlich schwerer ist als bei GUI-Anwendungen.

Will sagen: Eure aufgeführten Nachteile bestreite ich nicht, halte sie aber nicht für wichtiger, als die von mir aufgeführten Vorteile. Am stärksten spricht aus meiner Sicht gegen webgestützte Anwendungen, dass man auf einmal mit einem recht komplexen Technologiemix konfrontiert wird und es deutlich schwerer wird, eine gute Anwendung zu bauen als was z.B. Microsoft bereits vor vielen Jahren mit VisualBasic als state-of-the-art geschaffen hat.

VB ist doch schon lange tot, nicht umsonst hat MS .NET auf den Markt geworfen. Außerdem gibt es VB auch im Web unter dem Namen PHP. Ich wage zu behaupten, dass sich schlechte VB-Anwendungen für den Desktop und schlechte PHP-Webanwendungen die Wage halten.

Seit den frühen 90ern ist hier eigentlich nichts wirklich besser geworden sondern eher schlechter.

Natürlich... der Unterschied zwischen Qt1 und Qt4, oder AWT und Swing ist ja auch soooo marginal, da lohnt es sich gar nicht darüber zu diskutieren.

sma hat geschrieben:Ich möchte im Gegenteil, dass die Anwendung unabhängig vom Betriebssystem läuft.

Mann, mit Adobe hast du dir ja genau den richtigen Partner dafür gesucht

sma hat geschrieben:Eine webbasierte Lösung hat den Vorteil, dass sie nicht an einen Rechner gebunden ist. Ich nutze 4+ Systeme und sehe einen Vorteil darin, eine Anwendung wie z.B. Googlemail überall und jederzeit (Internet-Anschluss vorausgesetzt) verfügbar zu haben. Vielleicht habe ich eine andere Art von Anwendung im Hinterkopf.

Also entwickeln tue ich meist auf dem Server via SSH, Mails lesen tue ich teilweise auch schon via Mutt - von daher kann ich meine Programme von überall erreichen. Ich kann sie sogar im Screen einfrieren und von wo anders weiterarbeiten. Klar, das geht auch mit Webanwendungen. Nur mit welchem Aufwand? Schon allein die blöden Sessions haben tausend Sicherheitsprobleme und der Krampf wird immer wieder neu erfunden.

Und ja, ich könnte mir auch ein X11 auf dem Server installieren und habe damit auch einen Online-Desktop. So ein Desktop ist von den Features jedem Web-Desktop weit überlegen. Natürlich, da gibt es keinen Standard, aber mit VNC funktioniert das zumindest auf den meisten Systemen.

sma hat geschrieben:Mit Adobe

Oh ja Adobe. Die, deren Tipp es seit Jahren ist sich auf Linux x86_64 (die zweitpopulärste Linux-Platform, ich spreche also gar nicht von Alphas, Sparcs oder so) sich einen 32-Bit Browser zu installieren, weil sie nicht in der Lage sind einen 64-Bit Port zu machen. Wenn sowas die Zukunft ist, dann wird sie ohne mich stattfinden.

Webanwendungen erfinden jetzt alles, was es schon lange gibt nur komplizierter, aufwendiger, unsicherer (24C3-Talk zu RoR-Security gesehen?) und unflexibler. Beispiel Horde. Bis ich mich bei Horde angemeldet habe, starte und beenden ich Claws Mail sieben mal hintereinander. Und ein Sicherheitsupdate geht auch automatisch via Paketmanagement. Das ist bei Webapps selten so.

sma hat geschrieben:Vielleicht ist etwas wie Pythoncard eine Alternative. Die Screenshots (mehr habe ich mir leider nicht angeschaut) sehen aber zum Weglaufen häßlich aus

Pythoncard soll sowas wie Apples Hypercard sein und verhält sich so wie VB für wx. GUIs zum Zusammenklicken und Widgets umherschieben. Ich glaube das Projekt ist auch ziemlich tot.

Warum Webapps so populär sind, ist ganz einfach zu klären. Sie sind einfach schon vorkonfiguriert. Viele der Web.de-Nutzer wären inzwischen überfordert, ihr Outlook Express entsprechend zu konfigurieren, so wie es noch vor paar Jahren gang und gäbe war.

Aber die Portabilität der Programme hat noch eine andere Lösung: portable Apps auf dem USB-Stick sind unter Windows inzwischen recht populär. Ist mir tausend mal lieber, als noch irgendein notorisch unsicheres, überlastetes Web2.0-Dingens.

Hallo,

war eigentlich gar nicht mein Anliegen, das daraus so ein Diskussion wird.
@lunar Ich will es natürlich schon lernen, aber es muss auch was draus werden. Nur so an irgendwelche Übungsaufgaben rumzubasteln habe ich keine Lust und auch keine Zeit.

Eine Webanwendung die im Browser abläuft, wollte ich nicht machen, da mir bei allen Webanwendungen die ich bisher genutzt habe, irgendwo immer der Komfort fehlt, die ich von einer Desktopanwendung gewohnt bin. Die meisten Webanwendung können eigentlich nur sinnvoll mit der Maus bedient werden und das ist bei den meisten Anwendungen ein Nachteil für die Bediengeschwindigkeit.

Da es mein Anliegen ist ein Programm zu schreiben mit dem man ein Lager verwalten und Rechnungen schreiben kann, ist *für mich* die Desktopanwendung die richtige Wahl.

Gruß Christian