Völlig richtig. Aber brauche ich wirklich ein Mailprogramm für Gnome und eins für KDE als einfaches Beispiel? In der heutigen schnelllebigen Zeit vielleicht etwas redundant? Klar ist es gut, wenn Alternativen entwickelt werden - davon lebt schließlich auch die Innovation - aber möglicherweise ist es dennoch sinnvoll, sich zumindest auf ein Hauptprodukt zu konzentrieren?
aber möglicherweise ist es dennoch sinnvoll, sich zumindest auf ein Hauptprodukt zu konzentrieren?
Ich bin selbst kein Ubuntu Benutzer, aber ich dachte immer, dass praktisch in allen Variationen eben immer nur ein Produkt für einen bestimmten Einsatzzweck vorausgewählt ist. D.h. ich wäre daher im Falle des Mailprogramms davon ausgegangen, dass, speziell im Hauptprodukt Ubuntu, im Standardumfang nur das ein Produkt eines ausgesuchten Herstellers inkludiert ist.
Wenn nun gleichartige Produkte anderer Hersteller doch auch angeboten werden, wird man dafür vermutlich einen guten Grund haben, d.h. irgendeine Art von Vorteil oder Bonus die den Mehraufwand für das zusätzliche Bereitstellen von Alternativen wieder wettmacht.
wenn Du von "gleich gut abdecken" sprichst, und dann von Thunderbird, Kmail, Evolution und Mutt, fehlt noch ein "quasi unbrauchbar".
Ohne provozieren zu wollen, frage ich mich als treuer KDE Nutzer ernsthaft, warum kmail in einem dermaßen katastrophalen Zustand ist. Selbst Debian unstable hat noch die 4.4.11er Version der gesamten kontact Suite, Nutzer anderer Distributionen, die kmail2 haben, steigen auf Thunderbird um.
Ich traue mich kaum, kmail2 mal wieder eine Chance zu geben, bei den letzten Versuchen war hinterher meine Imap Ordner Struktur zerhauen, Thunderbird zeigte doppelte Ordner an, Mails fehlten u.s.f.
KDE hat viele gute Ansätze, ich nutze es auf siduction und auf OpenSUSE12.1. Da in OpenSUSE nun auch KDE4.8 zur Verfügung steht, werde ich dort dem aktuellen kmail nochmal eine Chance geben, ich befürchte allerdings, danach darf ich wieder meine Mailfächer reorganisieren.
mit kontact 4.8 haben es die Entwickler offenbar hinbekommen, dass kmail ordentlich mit Imap-Ordnern arbeitet.
Nach der Einrichtung holt kmail zügig die Imap-Ordner ab, es gibt kein langes Warten mehr "Ordnerinhalt wird gelesen" beim Klick auf einzelne Mails. Nach der Nutzung von kmail zeigt auch Thunderbird die Mails weitwerhin ordentlich an.
Meine Kritik oben gilt daher nicht mehr dem neuen kmail unter KDE4.8.
Danke an Euch Kmail- und Aconadi-Entwickler, dass Ihr das endlich hinbekommen habt.
Von Idiotenpfleger am Mi, 8. Februar 2012 um 10:24 #
Zitat: "Danke an Euch Kmail- und Aconadi-Entwickler, dass Ihr das endlich hinbekommen habt."
nein, nicht "Danke...", sondern na endlich habt ihr mal das Hinterteil hochgekriegt!
Ich gehöre ja nach anfänglich positiver Überraschung ("huch, das funktioniert ja doch") auch zu den Langzeit-Kmail2-geschädigten. Also bei mir hat es anfangs funktioniert, aber nach einiger Nutzungszeit ging es dann los... es konnten keine Mails geholt und auch keine Mails gesendet werden. Abstürze... Mails weg, Mails nicht gesendet, obwohl sie als "gesendet" angezeigt wurden... was weiß ich.
Kmail1 wiederum hat bei mir immer funktioniert (Imap bei googlemail).
Ich habe es nach einigen Stunden basteln und überlegen einfach aufgegeben, mit Kmail2. Und ich werden diesen Dreck nicht wieder anfassen.
KDE 4.8 lässt sich bei mir nicht installieren, weil es irgendwelche Konflikte gibt. Ich werde es auch nicht tun und ich werde Kmail2 auch nicht nochmal testen. Denn meine Mails sind mir zu wertvoll, als dass ich sie einem Schrott-Programm zum löschen und zerpflücken überlasse. Auch wenn es in KDE 4.8 angeblich funktionieren soll: mein Vertrauen ist weg.
Die Herangehensweise, die sich dem User darstellt, ist ja folgende: "ich will eine Datenbank und einen Server im System. Also pfusche ich mir so etwas da rein und dann bastele ich mir Anwendungsfälle dafür". Wer findet den Fehler? Richtig: wenn man normal gepolt ist, hat man zu erst seine Anwendungsfälle und baut sich dann eine Lösung dafür. Ist genau der umgekehrte Weg...
Gut ist, dass man KDEPIM einfach deinstallieren kann. Dann noch diesen Akonadi-Kram still legen... und schon rennt das KDE wie Schmidts Katze. Tja, irgendwann werden sie es schon so hinbasteln, dass wenn man KDEPIM deinstalliert, dass man dann 90% vom KDE-Desktop mit deinstalliert. Damit man den Bloat nicht loskriegt.
Cool ist aber, dass Thunderbird auch ohne Akonadi genau das macht, was das Kmail2 können soll, es aber nicht hinkriegt: Mails schicken und empfangen. Und per Add-on Lightning kann es sogar Termine verwalten. Und man kann sogar ohne elendes Gefrickel und Gemache auf die Adressdaten zugreifen, indem man auf "neue Mail" klickt und in der Adressleiste gleich den Empfänger aussucht. Das konnte auch Kmail1 nicht richtig... und Kmail2? Muhahaha. Naja, ist schon wirklich der Wahnsinn... was der Thunderbird alles kann. Scheint richtig ne innovative Technologie zu sein... was denn? Da läuft keine xy-quadzillionen Terrabyte große Datenbank im Hintergrund? Kein Server, der mal eben 5% auf die CPU packt? Glaub ich nicht!
Naja, dann ist es ja nochmal viel besser... Also ist ja der Thunderbird ein richtiges Wunderprogramm! Der kann wirklich so mir-nichts-dir-nichts, ohne Datenbank und Server-Framework... wow. Und die Einrichtung von 3 Imap-Konten dauert nur 10 Minuten... statt 1 Stunde (wie im Kmail, mit diesem Identitäten-Bullshit und diesem ganzen Mist...) Tja... na dann spende ich doch die eingeplante Spendenkohle an Mozilla, statt an KDE.
Von Idiotenpfleger am Mi, 8. Februar 2012 um 11:35 #
kaum nennt man das Kind beim Namen, kommen andere mit "Kinderstube".... lustig.
Man könnte auch schreiben:
- endlich mal dazu gekommen (es gibt ja auch ach so furchtbar viel wichtigeres als das zentrale Projekt des Kmail-Entwicklers...)
- Suboptimal
- überflüssige Software
- großer Konfigurationsaufwand, im Vergleich mit "althergebrachter" aka funktionierender Software
Und? Ändert sehr viel an den Fakten, nich wahr?
ich denke, der allgemeine User sollte endlich mal aus der Ecke heraustreten, die da bedeutet: "oh ja, ich muss dankbar sein, wenn mir jemand was kostenlos zur Verfügung stellt". Wer sagt denn, dass wenn es kostenlos ist, dass es dann nicht funktionieren muss? Ohne User ist die Entwicklung von dem, wofür wir ja ach so dankbar sein müssen (nicht können, sondern MÜSSEN) nichts wert. So einfach ist das. Und, um noch eins drauf zu setzen: von mir aus können sie ihr Kmail2 behalten. Damit ist dann jedem geholfen. Es steht keine Dankbarkeit aus, die eingefordert werden muss, und der Festplattenplatz kann anderweitig benutzt werden.
Wo bleibt die Ehre? Als Entwickler schmeiße ich irgendwas nicht-funktionierendes in die Masse und erwarte Dankbarkeit? Dafür gibt es einen Ausdruck, der heißt: Vermessenheit. Ganz einfach. Und, wenn ich so ein Entwickler wäre, ich würde mich in Grund und Boden schämen. Da gibt es Leute, die mir/meiner Software wertvolle Dinge anvertrauen und ich sorge NICHT dafür, dass sie diese wertvollen Dinge NICHT verlieren und erwarte im Gegenzug noch Dankbarkeit dafür? Gehts noch?
Von Alexander Niddel am Mi, 8. Februar 2012 um 12:02 #
Ich bin den leuten bei *buntu dankbar, dass sie mir gezeigt haben, wie ein Linux n i c h t funktionieren soll! Ich bin den Leuten von KDE dankbar, dass sie mir gezeigt haben, wie ein DE in 60-monatiger mühsehlicher Arbeit für mich u n b r a u c h b a r gemacht werden kann. So viel zu meiner Dankbarkeit!
Bitte bleib bei den Fakten, KDE3 ist immer noch da und wurde nicht unbrauchbar gemacht. KDE4-Anwendungen laufen zudem problemlos unter KDE3 und umgekehrt.
KDE 3.5.4 in RHEL5/ScientificLinux5/CentOS5 wird nun sogar noch bis März 2017 unterstützt, erhält noch Sicherheitsupdates und vereinzelt sogar noch Programmverbesserungen. Siehe: http://www.scientificlinux.org/distributions/5x/57/ http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.7
KDE3 ist freie Software, genauso wie KDE4. Macht was draus.
Von Idiotenpfleger am Do, 9. Februar 2012 um 07:59 #
Wenn ich in meinem persönlichen Fall KDE4 mit KDE3 vergleiche, dann sage ich: wird Zeit, dass KDE3 endlich wirklich mal beerdigt wird. KDE3 ist einfach viel zu alt, viel zu chaotisch und ist den derzeitigen Anforderungen an eine Desktopumgebung nicht mehr gewachsen.
Summe: KDE4 ist KDE3 um Längen überlegen. Der einzige Mangel ist Kmail2, aber Kmail in KDE3 war auch schon nix tolles.
Und: warum soll man KDE3 benutzen? Nur weil einzelne Komponenten in KDE4 nicht so funktionieren, wie gewünscht? Sollte man nicht lieber darauf hinwirken, dass diese Komponenten so weiterentwickelt werden, dass sie die gewünschte Funktion erhalten?
"Genau! Wo wären wir den wenn wir uns bei Leuten bedanken würden, die uns etwas gratis optional zur Verfügung stellen?"
Das kann nicht für das letzte Kmail gelten (aus KDE 4.7). Man muss sich schon fragen, wie es möglich ist, dass Distros einen solche unfertige Software ihren Nutzern unterjubeln. Hier gilt wirklich: Geschenkt ist noch zu teuer.
Die Herangehensweise, die sich dem User darstellt, ist ja folgende: "ich will eine Datenbank und einen Server im System. Also pfusche ich mir so etwas da rein und dann bastele ich mir Anwendungsfälle dafür". Wer findet den Fehler?
Der Fehler liegt offensichtlich in der Darstellung der Herangehensweise für den User. Möglicherweise war die entsprechende Kommunikation nicht ausreichend genug oder zu technisch.
hat man zu erst seine Anwendungsfälle und baut sich dann eine Lösung dafür.
Was ja hier auch der Fall war. Nach vielen Jahren Erfahrung mit den postiven und negativen Aspekten der vorhanden Lösung, den dadurch umgesetzten Anwendungsfällen und einer Abschätzung zukünftiger Awendungsfälle, ergab sich als neuer Lösungsansatz eine dienstbasierte Architektur.
"Nach vielen Jahren Erfahrung mit den postiven und negativen Aspekten der vorhanden Lösung, den dadurch umgesetzten Anwendungsfällen und einer Abschätzung zukünftiger Awendungsfälle, ergab sich als neuer Lösungsansatz eine dienstbasierte Architektur."
Das ist ein Satz, den hättest Du in zehn Millionen Threads in zig verschiedenen Themenbereichen immer wieder exakt so schreiben können und er hätte trotzdem immer irgendwie gepasst. Das ist wohl ein gut getarnter Trollversuch?
Hmm, vielleicht war der Satz ein bischen zu umständlich formuliert.
Ich wollte damit betätigen, dass die im Kommentar von "idiotenpfleger" vorgeschlagene Herangehensweise auch die tatsächlich umgesetzte war.
Im Detail ergab sich eben aus den Erfahrungen mit dem vorherigen Ansatz (gemeinsamer Zugriff auf Dateien mittels Plugins), dass der gemeinsame Datenzugriff über einen Dienst besser geeignet ist, die bestehenden Anforderungen zu erfüllen.
Im Rahmen der Detailüberlegungen wurde dann natürlich auch versucht abzuschätzen, ob damit mögliche zukünftigen Anforderungen ebenfalls abgedeckt werden können. Derartige Szenarien mit hoher Wahrscheinlichkeit wurden dann ählich berücksichtigt, wie bereits bestehende.
Von Idiotenpfleger am Mi, 8. Februar 2012 um 15:57 #
ich kenne mich mit Softwareentwicklung nicht aus. Aber:
- für ein Adressbuch gibts eine Textdatei. Da werden die Kontakte eingespeichert und auch bei Bedarf gelesen. Wozu brauche ich dann ein Plugin oder einen Dienst? Thunderbird hat soweit ich das bemerkt habe, keinen extra-Adressbuch-Dienst
- Kalender: da gibts eine Textdatei. Da werden die Termine eingespeichert und gelesen und wenn ein Datum mit der Systemzeit übereinstimmt, dann poppt ein Fenster auf... Wozu brauche ich da ein Plugin? Einen Dienst vielleicht, aber kein Plugin...
- für die Zugänge beim ISP/Mailprovider... da gibts Textdateien.... und da kann man drauf zugreifen... soll ich weitermachen? Da würde noch ein paar mal "da gibts ne Textdatei" kommen... hmm...
Komisch... bei den anderen funktioniert das jetzt und bestimmt auch in Zukunft. Die grundlegenden Anforderungen ändern sich auch nicht, bei einem Mailprogramm. Die sind nämlich ganz einfach: Mails empfangen und senden. Da kann man natürlich auch eine Raketenwissenschaft draus machen. Muss man aber nicht.
Und wenn man dazu noch irgendwelchen Fancy-Kram basteln will, kann man das gern tun. Aber nicht so, dass die grundlegenden Funktionen nicht mehr erfüllt werden. Oder besser noch, wo man doch so dolle auf Plugins steht: warum nicht den Fancy-Kram als einzelne Plugins machen, die der User dazu-installieren kann, wenn er sie denn braucht? Wohl, weil dann kein User den Fancy Kram installiert? Weil nur eine Minderheit sowas braucht? Und die, die es brauchen, wollen dass es funktioniert? Nee, echt... is ja n Ding!
Ach so ja, dann gibt es noch eine kleine Abhandlung darüber wie der Nutzer das Verhalten dieses ganzen Fremdschäm-Würgs... äh Frameworks sieht:
Akonadi braucht Nepomuk um zu funktionieren. Ergo: Nepomuk abschalten, aber Akonadi nicht = ganz großer Fehler. Also: Akonadi braucht die Suchmaschine. Wohl, um die ganzen Konfig-Dateien und die Dateien fürs Adressbuch auf der Festplatte zu finden. Heißt, für den User: er kann es irgendwo hinspeichern... Akonadi hat ja ne Suchmaschine. FALSCH! Sobald eine Datei nicht dort ist, wo die Durchlaucht Namens Akonadi entschieden hat, dass sie dort liege, gibt es Fehlermeldungen im Windows-Style. Und das hört selbst dann nicht auf, wenn die Datei dann endlich am geforderten Ort liegt. Der User fragt sich dann: wozu läuft da ne Suchmaschine im Hintergrund, die ZWINGEND für den Betrieb von Akonadi vorgeschrieben ist. Die Reaktion des Users, nachdem er sich das mal durch den Kopf gehen ließ, ist: Stilllegen und Deinstallieren, den Müll. Und nicht: "ah, ja ist ja verdammt nochmal ziemlich fancy, das ganze. Da geht was". Denn es geht ja nix.
- für ein Adressbuch gibts eine Textdatei. Da werden die Kontakte eingespeichert und auch bei Bedarf gelesen. Wozu brauche ich dann ein Plugin oder einen Dienst? Thunderbird hat soweit ich das bemerkt habe, keinen extra-Adressbuch-Dienst
Plugins braucht man, wenn man unterschiedliche Formen der Speicherung benutzen will. Das muss nicht für alle Benutzer relevant sein, aber manche Benutzer haben ihre Adressbuchdaten auf einem Server. Ich würde annehmen, dass Thunderbird hier ebenfalls Plugins benutzt, Evolution tut es.
Ein Dienst hilft dabei, den Zugriff mehrere Programme auf die selben Daten zu regeln. Das muss ebenfalls nicht für alle Benutzer relevant sein, aber manche Benutzer benutzen ihre Kontakte auch außerhab ihres E-Mail Programms. Thunderbird operiert unter der Annahme, dass es das einzige Programm ist, dass mit seiner Adressbuchdatei arbeitet. Evolution setzt ebenfalls auf einen Dienst.
- Kalender: da gibts eine Textdatei. Da werden die Termine eingespeichert und gelesen und wenn ein Datum mit der Systemzeit übereinstimmt, dann poppt ein Fenster auf... Wozu brauche ich da ein Plugin? Einen Dienst vielleicht, aber kein Plugin...
Da gilt im Wesentlich das selbe, d.h. Plugin wenn man bestimmte Arten der Speicherung und die dafür nötigen Abhängigkeiten nur optional haben möchte und Dienst wenn man die Daten in mehreren Anwendungen gleichzeitig haben möchte. Bei Thunderbird bzw Lightning muss ich raten, aber ich würde von Pluginunterstützung ausgehen. Bei Evolution ist Pluginunterstützung und Dienst im Einsatz.
- für die Zugänge beim ISP/Mailprovider... da gibts Textdateien.... und da kann man drauf zugreifen... soll ich weitermachen? Da würde noch ein paar mal "da gibts ne Textdatei" kommen... hmm... :huh:
Siehe oben. Die Bestrebungen bei Evolution den E-Mail-Zugriff aus der Applikation auch in den Dienst zu verlagern dürfte da ein gutes Indiz sein.
Akonadi braucht Nepomuk um zu funktionieren.
Wäre vielleicht besser gewesen, die Abhängigkeit in allen Applikationen einzubauen, statt im gemeinsamen Dienst. Die Idee war hier, dass die Suche nach PIM Dateien über die selbe API wie der Zugriff auf diese einfacher für Applikationsentwickler ist, als wenn diese dann mit zwei APIs arbeiten müssen.
Wohl, um die ganzen Konfig-Dateien und die Dateien fürs Adressbuch auf der Festplatte zu finden
Nein. Suche nach Dateien ist nur ein Teilaspekt von Nepomuk, in diesem Zusammenhang geht es um das Suche von und in PIM Daten. Zum Beispiel das Auflösen von Adressreferenzen in Kalendereinträgen, automatische Vervollständigung von E-Mail Adressen in Empfängereingabefeldern, das Suchen von E-Mails, etc.
Wie gesagt hätte man das auch an die Anwendungsentwickler schieben können, ein integrierter und einheitlicher Ansatz schien da einfach besser.
IMO fehlen aber die entsprechenden Kennzeichnungen wie Kmail2-Alpha3 oder Kmail2-Beta1, damit auch der Nutzer, der keine Mailinglisten mitliest, weiß, woran er ist. Kmail in KDE 4.7 ist wirklich nicht fertig, es ist keine finale, sondern eine verbuggte Vor-Version. Das muss man auch so kommunizieren.
Von Idiotenpfleger am Mi, 8. Februar 2012 um 14:14 #
na dann bin ich ja mal gespannt, welche großen Ziele mit dieser Herangehensweise erreicht werden sollten. Hast du diese Ziele verstanden? Kannst du sie erklären?
Was, außer Mails empfangen, Termine und Adressen verwalten soll eine PIM Software können? Welche Aufgaben, von diesen genannten, kann Thunderbird nicht? Wo versagt auch z.B. Evolution? Was ist also das "Shortcoming" all dieser Mailprogramme? Was kann Kmail2 stattdessen, außer sinnlos Festplatte und CPU fressen?
Also... dann stellt sich mir das ganze so dar: wir wollen eine Revolution unter den Mailprogrammen loslassen und bauen uns die super-duper-Maschinerie zusammen... und dann, als sie fertig war, die Super-Mailkiste... dann konnte sie nichtmal Mails empfangen oder senden... wahnsinn... ja, das ist revolutionär.
Da wäre mal das Ziel, den gleichzeitigen Zugriff auf Daten zu verbessern. Der vorher benutze Ansatz, aus allen interessierten Applikation parallel auf die selbe(n) Datei(en) zuzugreifen hat immer wieder zu Problemen geführt. Unter anderem weil das dafür nötige Sperren von Dateinzugriffen nicht auf allen Dateisystem (gleich) funktioniert. D.h. es kam schon mal vor, dass zwei Programme ihre Änderungen gegenseitig überschrieben haben.
Der neue Ansatz verbessert dies, in dem nur immer ein Programm auf die Datei direkt zugreift und alle anderen eben mit diesem Dienst kommunizieren.
Dann wäre da weiters das Ziel "Offline" Fähigkeiten für alle Datentypen zur Verfügung zu haben, nicht nur für IMAP E-Mails. Das ist natürlich interessanter für Benutzer, die serverbasierende Adressbücher und Kalendar benutzen und deren Server nicht im selben Netzwerk stehen oder die mobil arbeiten.
Auf der Anwendungsebene ist ein Ziel den Datenzugriff von der Datendarstellung zu trennen. Der Hauptgrund dafür ist, dass vorher bestimmte Funktionalität von Programmen an das Vorhandensein und Ausgeführtwerdens eines anderen Programms abhingen. Z.B.: die Möglichkeit auf Adressbücher oder Kalendar zuzugreifen, die in speziellen Ordnern auf einem IMAP Server liegen, erforderte bisher das Vorhandensein und Ausgeführtwerden von KMail, weil darin sowohl IMAP Zugriff als auch Anzeige implementiert war.
Das Ausgliedern in einen Dienst erlaubt nun Programmen solche Adressbücher oder Kalendar zu benutzen, ohne dass der Benutzer dafür KMail installiert und laufen haben muss.
Was, außer Mails empfangen, Termine und Adressen verwalten soll eine PIM Software können? Welche Aufgaben, von diesen genannten, kann Thunderbird nicht? Wo versagt auch z.B. Evolution?
Es geht da nicht darum was andere Programme können, sondern ob und wie diese entsprechende Funktionalität für anderen Programme zur Verfügung stellen. Thunderbird ist daran nicht interessiert und das kann für viele Benutzer auch ausreichend sein. Andere Benutzer brauchen die Möglichkeit auf ihre Daten, z.B. Kontakte, von anderen Programmen nicht nur auf Import-/Exportbasis zuzugreifen.
Aus diesem Grund benutzt Evolution ebenfalls einen dienstbasierten Ansatz (siehe Evolution Data Server), allerdings bis vor kurzem meines Wissens nur für Adressbücher und Kalendar (d.h. Unterstützung für E-Mail ist da auch noch relativ neu).
Von Idiotenpfleger am Mi, 8. Februar 2012 um 19:46 #
danke für die Erläuterungen. Klingt alles nach was ziemlich großem... Obwohl ich nicht ganz begreife, warum man nicht wenigstens eine Grundfunktionalität einfach so "normal" darstellen kann und wenn es wirklich DER spezielle Anwendungsfall ist, mit Dateien auf dem Server und was weiß ich - dass man dann und nur dann auf dieses große Gebilde zurückgreift... Ich meine, die Idee ist ja nicht schlecht (eigentlich verdammt faszinierend), aber man bewegt sich sehr eng an der Kante der Nicht-Akzeptanz. Vor allem bei Fehlern und wenn es kompliziert ist.
Denn es ist nunmal so: der einfache Benutzer begreift nicht, warum er stundenlang am Mailprogramm rumkonfigurieren muss... immer wieder die Meldung, dass irgendeine Migration nicht funktioniert hat und was weiß ich... der will einfach nur Mails lesen und schreiben und seine Kontakte und Termine verwalten... Also all das klingt zwar furchtbar spannend, aber es ist schwer zu vermitteln.
Und wenn man dann immer wieder in Probleme kommt und immer wieder irgendwas nicht funktioniert, dann denkt man als User: "Wisst ihr was, ihr könnt euch euren höheren Zweck sonstwo hinstecken"... das sind dann die Akzeptanzprobleme. Dann kommt das schlechte Imgage... "KDE? Kmail? der Zacker-Kram? nee, lass mal. Da bleib ich lieber beim Win, oder Unity... irgendwas". Also als User ist man schon fehlertolerant. Ich habe mir zwar kein KDE 4.0 gegeben, aber in der 4er Reihe bin ich seit 4.1 dabei und ich habe viel erlebt. Und ich bin auch verdammt stolz auf KDE, weil es in meinem Fall seit 4.2 einigermaßen gut läuft und auch generell mit jeder Version immer besser geworden ist. Wenn man dann immer wieder mal in irgendwelche Löcher fällt = irgendwas nicht funktioniert, dann ist es bis zu einem bestimmten Maß auch ok. Nur wenn man dann Daten verliert... dann hörts bei mir auf. Und Kmail2 hat mir so manchen Schaden eingebrockt. Da habe ich kein Verständnis. Auch nicht, wenn eine "große Sache" dahinter steckt. Und auch nicht, wenn es nix kostet.
Meiner Meinung nach gehört ein funktionierendes Mailprogramm zu einem anständigen DE. Heißt: es muss funktionieren. Auch wenn es kompliziert ist: dann ist es eben im Hintergrund kompliziert, aber für den User hat es einfach zu sein. Auch wenn´s geschenkt = gratis ist.
Ich stelle mir auch immer wieder die Frage: warum bastelt KDE denn an einem eigenen PIM? Warum kann man denn nicht meinetwegen Thunderbird nehmen, den ins KDE integrieren und mit Add-ons bedarfsgerecht aufmotzen?
Warum kann man denn z.B. Evolution nicht einfach nehmen und an den entsprechenden Stellen ans KDE anpassen?
Ist doch freie Software... da geht das doch! Liegts am Ego? Am NIH Syndrom? Warum macht man sich diese Arbeit, lässt die Beschimpfungen über sich wegrollen... um dann bei der nächsten Version wieder nix zum Besseren geändert zu haben... traurig.
IMO liegt es an den Distros. Die stimmen z.B. KDE- und Gnomesoftware einfach nicht aufeinander ab. Dabei sind selbst z.B. Epiphany-Browser und Evolution hervorragend unter KDE4 nutzbar, gerade wegen des mitinstallierten, funktionsfähigen Gnome-Networkmanagers.
Um den überflüssigen Bloat in Grenzen zu halten, bräuchte man halt durchgehend schlanke kde-, gtk-, qt-, gnome-Basisbibliotheken.
Was nicht passieren darf, ist, dass z.B. Tracker und Nepomuk gleichzeitig herumwerkeln, nur weil mit den entsprechenden Programmen gearbeitet wird. Eine Art Mindestabstimmung zwischen den DEs wäre also in jedem Fall vonnöten. Und das wäre die Aufgabe der Distros.
Obwohl ich nicht ganz begreife, warum man nicht wenigstens eine Grundfunktionalität einfach so "normal" darstellen kann und wenn es wirklich DER spezielle Anwendungsfall ist, mit Dateien auf dem Server und was weiß ich - dass man dann und nur dann auf dieses große Gebilde zurückgreift...
Ich denke das Hauptproblem ist den Rahmen von Grundfunktionalität wirklich gut zu stecken. Würde es nur um ein Programm gehen könnte man zum Beispiel den Rahmen so definieren, dass der Zugriff auf lokale Dateien direkt passiert. Nachdem das aber schon alleine in KDEPIM nicht der Fall ist (z.B. Zugriff auf Kontakte aus Adressbuch, Kalendar und E-Mail Programm) ist der Rahmen von Grundfunktionalität schon mal der gleichzeitige Zugriff auf lokale Dateien.
Bzw. im Falle von E-Mails ist der Zugriff auf Server schon im Rahmen der Grundfunktionalität.
Durch das sehr ähnliche Anforderungsprofil bei GNOME sieht man eigentlich ganz schön, dass man dort auf die selben Techniken setzt, um die nötige Funktionalität umzusetzen. Mozilla hat auf Grund eines einfacheren Profils weniger komplexe Problemstellungen und kann daher andere Wege gehen.
Denn es ist nunmal so: der einfache Benutzer begreift nicht, warum er stundenlang am Mailprogramm rumkonfigurieren muss... immer wieder die Meldung, dass irgendeine Migration nicht funktioniert hat und was weiß ich... der will einfach nur Mails lesen und schreiben und seine Kontakte und Termine verwalten... Also all das klingt zwar furchtbar spannend, aber es ist schwer zu vermitteln.
Da gebe ich dir natürlich recht. Hier hat der Wunsch, den Umstieg von alter zu neuer Technologie möglichst "unsichtbar" zu gestalten, genau zum Gegenteil geführt. Im Nachhinein betrachtet wäre ein expliziter "import" Prozess besser gewesen. Der hätte von den Benutzer zwar Interaktion erwartet, wäre aber daher auch besser kontrollierbar gewesen.
Meiner Meinung nach gehört ein funktionierendes Mailprogramm zu einem anständigen DE.
Ich würde jetzt nicht sagen zu einer DE, das wären eher so Sachen wie Fensterleiste, Desktop, Windowmanager. Aber durchaus zum Produktumfang eines Herstellers von Endbenutzer-Software für "alle" Basisanwendungsbereiche.
Ich stelle mir auch immer wieder die Frage: warum bastelt KDE denn an einem eigenen PIM?
Die einzelnen Programme gibt es einfach schon seit ewig, KMail gab es z.B. schon für KDE1. Im Falle der darunterliegenden Infrastruktur, z.B. dem Adressdateizugriff, weil das einfach von einer Plattform für Endanwendersoftware erwartet wird (und daher z.B. auch Bestandteil jeder Plattform für Mobilgeräte oder proprietärer Desktopplattformen ist).
Warum kann man denn nicht meinetwegen Thunderbird nehmen, den ins KDE integrieren und mit Add-ons bedarfsgerecht aufmotzen?
Ich denke das wäre nicht durchführbar. Thunderbird ist nicht als Komponenten in einem größerem System konzipiert, d.h. es ist vermutlich schwer das Programm ohne GUI zu starten bzw. zu verhindern dass es beendet wird während es von einer anderen Applikation für den Dateizugriff gebraucht wird.
Warum kann man denn z.B. Evolution nicht einfach nehmen und an den entsprechenden Stellen ans KDE anpassen?
Das ist schon eher machbar, allerdings auch nicht so einfach. Die Kommunikation zwischen Evolution Data Server (EDS) und seinen Clients funktioniert mehr oder weniger über bestimmte Bibliotheken, die zugrunde liegende Kommunikation ist nicht so fixiert und Server und Clientbibliotheken werden bei Bedarf zeitgleich verändert. Das würde das Bereitstellen von Qt-basierten Clientbibliotheken relativ schwer machen, oder auf Seiten der EDS Entwickler eine Umstellung ihrer Verfahrensweise bedeuten.
Durch die Umstellung bei KDE auf eine ähnliche (dienstbasierte) Architektur und die Erweiterung des Leistungsmfangs bei EDS (+ E-Mail) und die Umstellung auf D-Bus für die interne Kommunikation, ergibt sich schon eine gewisse Konvergenz. Es ist daher durchaus vorstellbar, dass sich in Folge daraus eine Art von Austauschbarkeit ergibt.
Von Idiotenpfleger am Do, 9. Februar 2012 um 12:36 #
Zitat: "Durch das sehr ähnliche Anforderungsprofil bei GNOME sieht man eigentlich ganz schön, dass man dort auf die selben Techniken setzt, um die nötige Funktionalität umzusetzen. Mozilla hat auf Grund eines einfacheren Profils weniger komplexe Problemstellungen und kann daher andere Wege gehen."
Zitat: "Durch die Umstellung bei KDE auf eine ähnliche (dienstbasierte) Architektur und die Erweiterung des Leistungsmfangs bei EDS (+ E-Mail) und die Umstellung auf D-Bus für die interne Kommunikation, ergibt sich schon eine gewisse Konvergenz. Es ist daher durchaus vorstellbar, dass sich in Folge daraus eine Art von Austauschbarkeit ergibt."
also, das liest sich ja so wie: "die bei Gnome haben das gleiche gemacht, nur eben auf einige Gnome-spezifische Dinge angepasst" ...
für mich als Nutzer sind hier die augenscheinlichsten Dinge:
- Einbindung in die Desktop-Uhr, zur Terminverwaltung und Benachrichtigung
- Einbindung in das User-Benachrichtigungssystem
- Anbindung an die Netzwerkschnittstelle
- Optik = GUI in GTK
- Diensteverwaltung: D-Bus und Udev
- Anbindung an den Dateimanager fürs speichern von Dokumenten und für "Rechtsklick --> senden per E-mail an..."
Der Unterschied zum Kmail2 ist, dass Evolution erste Sahne funktioniert. Und ich als User frage mich:
- Desktop-Uhr und Benachrichtigungsystem? Hat KDE
- Netzwerkschnittstelle? Hat KDE
- Optik? Qt
- Dateimanager? Hat KDE
- Diensteverwaltung: D-Bus und dieses Udev
Und weil das doch sicher alles standardkonform ist, auf Gnome und KDE-Seite, usw., frage ich mich dann wirklich: warum kann man das Evolution-Programm, das hinter der GUI steckt, nicht einfach übernehmen, an die Gegebenheiten (Netzwerk, Dateimanager, Uhr, Benachrichtigungssystem) anpassen und dann eine Qt-GUI dafür bauen? Doch wegen NIH? Bestimmt. Da bin ich mir jetzt ziemlich sicher.
Ich meine, das mit Thunderbird sehe ich ein, dass das sinnlos wäre, aber bei Evolution... da kann man Argumente noch und nöcher vorbringen: die sind für mich allesamt fadenscheinige Ausreden. Noch dazu, wo Novell, der Sponsor vom Evolution, mal die Suse-Mutter war und Suse DIE KDE-Distro ist... eigentlich sieht das aus meiner "Nutzersicht" richtig übel nach gewaltigem Irrsinn, brutaler Hochnäsigkeit und extremst übersteigertem Ego auf der KDE-Seite aus. Die Zeche zahlt der User. Na schönen Dank auch...
Und weil das doch sicher alles standardkonform ist, auf Gnome und KDE-Seite, usw., frage ich mich dann wirklich: warum kann man das Evolution-Programm, das hinter der GUI steckt, nicht einfach übernehmen, an die Gegebenheiten (Netzwerk, Dateimanager, Uhr, Benachrichtigungssystem) anpassen und dann eine Qt-GUI dafür bauen?
Man braucht dazu erst einmal den zeitlichen Kontext. Die Kommunikation zwischen EDS und seinen Clients erfolgte lange Zeit über CORBA, D-Bus stand nicht zur Verfügung und auch nicht auf der Roadmap als an den Arbeiten zu Akonadi begonnen wurde. Dazu kommt dann noch, dass bis noch vor kurzem E-Mail keiner der in EDS unterstützten Datentypen war.
D.h. auch wenn jetzt gerade diese Dinge besser sind, könnte man jetzt eine Umstellung neu evaluieren. Nur ist eben jetzt nicht 2007.
Dazu kommt dann eben noch die technische Schwierigkeit, dass die Kommunikation zwischen EDS und seinen Clients als internes Detail gehandhabt wird. D.h. eine Änderung in der Kommunikation wird einfach zeitgleich in Server und Client gemacht.
Das ist natürlich lösbar, d.h. man mit entsprechender Versionierung und Vermeidung von inkompatiblen Änderungen. Aber das erfordert eine entsprechende Änderung im Entwicklungsmodell und damit verbundenen Mehraufwand für das EDS Team.
Wie gesagt ergibt sich auf Grund von Umstellungen auf beiden Seiten (Evolution, KDEPIM) eine Angleichung der Gegebenheiten, die durchaus in Zukunft zu einer gewissen Austauschbarkeit von Komponenten führen kann, bzw. eventuell auch zu einer eigenständigen und von beiden Projekten benutzen Referenzimplementierung.
Selbst in einem viel einfacheren Feld wie dem gemeinsamen Secret Service bedeutet eine Zusammenführung einen Prozess von mehreren Jahren, denn benötigt nicht nur den neuen Dienst bzw neue Schnittstellen für einen bestehenden Dienst, sondern auch entweder entsprechende Anpassungen in allen benutzenden Programmen oder eine neue Implementierung der vorhanden APIs basierend auf den neuen Schnittstellen.
Das Anstreben solcher Universallösungen dürfte durchaus die Unterstützung vieler Entwickler geniessen, nur sind sich diese eben auch der damit verbundenen "Kosten" bewusst. D.h. man arbeitet in kleinen Schritten daran die Unterschiede zu minimieren um den Aufwand zu verringern, den eine Umstellung auf eine gemeinsame Lösung mit sich bringen wird.
Es ist denke ich verständlich, dass aus Benutzersicht diese Kosten nicht sichtbar sind oder gering erscheinen, aber leider ist die Realität aus der Entwicklersicht oft eine ganz andere.
Völlig richtig. Aber brauche ich wirklich ein Mailprogramm für Gnome und eins für KDE als einfaches Beispiel? In der heutigen schnelllebigen Zeit vielleicht etwas redundant? Klar ist es gut, wenn Alternativen entwickelt werden - davon lebt schließlich auch die Innovation - aber möglicherweise ist es dennoch sinnvoll, sich zumindest auf ein Hauptprodukt zu konzentrieren?
Ich bin selbst kein Ubuntu Benutzer, aber ich dachte immer, dass praktisch in allen Variationen eben immer nur ein Produkt für einen bestimmten Einsatzzweck vorausgewählt ist.
D.h. ich wäre daher im Falle des Mailprogramms davon ausgegangen, dass, speziell im Hauptprodukt Ubuntu, im Standardumfang nur das ein Produkt eines ausgesuchten Herstellers inkludiert ist.
Wenn nun gleichartige Produkte anderer Hersteller doch auch angeboten werden, wird man dafür vermutlich einen guten Grund haben, d.h. irgendeine Art von Vorteil oder Bonus die den Mehraufwand für das zusätzliche Bereitstellen von Alternativen wieder wettmacht.
Bestimmte Linuxanwendungen decken eben nicht alle Anwendungsbereiche gleich gut ab, siehe z.B. die Email-Clients Thunderbird/KMail/Evolution/Mutt.
Hallo,
wenn Du von "gleich gut abdecken" sprichst, und dann von Thunderbird, Kmail, Evolution und Mutt, fehlt noch ein "quasi unbrauchbar".
Ohne provozieren zu wollen, frage ich mich als treuer KDE Nutzer ernsthaft, warum kmail in einem dermaßen katastrophalen Zustand ist. Selbst Debian unstable hat noch die 4.4.11er Version der gesamten kontact Suite, Nutzer anderer Distributionen, die kmail2 haben, steigen auf Thunderbird um.
Ich traue mich kaum, kmail2 mal wieder eine Chance zu geben, bei den letzten Versuchen war hinterher meine Imap Ordner Struktur zerhauen, Thunderbird zeigte doppelte Ordner an, Mails fehlten u.s.f.
KDE hat viele gute Ansätze, ich nutze es auf siduction und auf OpenSUSE12.1. Da in OpenSUSE nun auch KDE4.8 zur Verfügung steht, werde ich dort dem aktuellen kmail nochmal eine Chance geben, ich befürchte allerdings, danach darf ich wieder meine Mailfächer reorganisieren.
Viele Grüße,
Holger
Hallo,
mit kontact 4.8 haben es die Entwickler offenbar hinbekommen, dass kmail ordentlich mit Imap-Ordnern arbeitet.
Nach der Einrichtung holt kmail zügig die Imap-Ordner ab, es gibt kein langes Warten mehr "Ordnerinhalt wird gelesen" beim Klick auf einzelne Mails. Nach der Nutzung von kmail zeigt auch Thunderbird die Mails weitwerhin ordentlich an.
Meine Kritik oben gilt daher nicht mehr dem neuen kmail unter KDE4.8.
Danke an Euch Kmail- und Aconadi-Entwickler, dass Ihr das endlich hinbekommen habt.
Viele Grüße,
Holger
Zitat: "Danke an Euch Kmail- und Aconadi-Entwickler, dass Ihr das endlich hinbekommen habt."
nein, nicht "Danke...", sondern na endlich habt ihr mal das Hinterteil hochgekriegt!
Ich gehöre ja nach anfänglich positiver Überraschung ("huch, das funktioniert ja doch") auch zu den Langzeit-Kmail2-geschädigten. Also bei mir hat es anfangs funktioniert, aber nach einiger Nutzungszeit ging es dann los... es konnten keine Mails geholt und auch keine Mails gesendet werden. Abstürze... Mails weg, Mails nicht gesendet, obwohl sie als "gesendet" angezeigt wurden... was weiß ich.
Kmail1 wiederum hat bei mir immer funktioniert (Imap bei googlemail).
Ich habe es nach einigen Stunden basteln und überlegen einfach aufgegeben, mit Kmail2. Und ich werden diesen Dreck nicht wieder anfassen.
KDE 4.8 lässt sich bei mir nicht installieren, weil es irgendwelche Konflikte gibt. Ich werde es auch nicht tun und ich werde Kmail2 auch nicht nochmal testen. Denn meine Mails sind mir zu wertvoll, als dass ich sie einem Schrott-Programm zum löschen und zerpflücken überlasse. Auch wenn es in KDE 4.8 angeblich funktionieren soll: mein Vertrauen ist weg.
Die Herangehensweise, die sich dem User darstellt, ist ja folgende: "ich will eine Datenbank und einen Server im System. Also pfusche ich mir so etwas da rein und dann bastele ich mir Anwendungsfälle dafür". Wer findet den Fehler? Richtig: wenn man normal gepolt ist, hat man zu erst seine Anwendungsfälle und baut sich dann eine Lösung dafür. Ist genau der umgekehrte Weg...
Gut ist, dass man KDEPIM einfach deinstallieren kann. Dann noch diesen Akonadi-Kram still legen... und schon rennt das KDE wie Schmidts Katze. Tja, irgendwann werden sie es schon so hinbasteln, dass wenn man KDEPIM deinstalliert, dass man dann 90% vom KDE-Desktop mit deinstalliert. Damit man den Bloat nicht loskriegt.
Cool ist aber, dass Thunderbird auch ohne Akonadi genau das macht, was das Kmail2 können soll, es aber nicht hinkriegt: Mails schicken und empfangen. Und per Add-on Lightning kann es sogar Termine verwalten. Und man kann sogar ohne elendes Gefrickel und Gemache auf die Adressdaten zugreifen, indem man auf "neue Mail" klickt und in der Adressleiste gleich den Empfänger aussucht. Das konnte auch Kmail1 nicht richtig... und Kmail2? Muhahaha.
Naja, ist schon wirklich der Wahnsinn... was der Thunderbird alles kann. Scheint richtig ne innovative Technologie zu sein... was denn? Da läuft keine xy-quadzillionen Terrabyte große Datenbank im Hintergrund? Kein Server, der mal eben 5% auf die CPU packt? Glaub ich nicht!
Naja, dann ist es ja nochmal viel besser... Also ist ja der Thunderbird ein richtiges Wunderprogramm! Der kann wirklich so mir-nichts-dir-nichts, ohne Datenbank und Server-Framework... wow. Und die Einrichtung von 3 Imap-Konten dauert nur 10 Minuten... statt 1 Stunde (wie im Kmail, mit diesem Identitäten-Bullshit und diesem ganzen Mist...) Tja... na dann spende ich doch die eingeplante Spendenkohle an Mozilla, statt an KDE.
nein, nicht "Danke..."
Genau! Wo wären wir den wenn wir uns bei Leuten bedanken würden, die uns etwas gratis optional zur Verfügung stellen?
> Hinterteil
> Dreck
> Bloat
> elendes Gefrickel
Viel besser. Nun noch Ar*chloch, Schei*se und Idiot hinzugefügt und fertig ist dein Beitrag zur Gesellschaft!
kaum nennt man das Kind beim Namen, kommen andere mit "Kinderstube".... lustig.
Man könnte auch schreiben:
- endlich mal dazu gekommen (es gibt ja auch ach so furchtbar viel wichtigeres als das zentrale Projekt des Kmail-Entwicklers...)
- Suboptimal
- überflüssige Software
- großer Konfigurationsaufwand, im Vergleich mit "althergebrachter" aka funktionierender Software
Und? Ändert sehr viel an den Fakten, nich wahr?
ich denke, der allgemeine User sollte endlich mal aus der Ecke heraustreten, die da bedeutet: "oh ja, ich muss dankbar sein, wenn mir jemand was kostenlos zur Verfügung stellt". Wer sagt denn, dass wenn es kostenlos ist, dass es dann nicht funktionieren muss? Ohne User ist die Entwicklung von dem, wofür wir ja ach so dankbar sein müssen (nicht können, sondern MÜSSEN) nichts wert. So einfach ist das. Und, um noch eins drauf zu setzen: von mir aus können sie ihr Kmail2 behalten. Damit ist dann jedem geholfen. Es steht keine Dankbarkeit aus, die eingefordert werden muss, und der Festplattenplatz kann anderweitig benutzt werden.
Wo bleibt die Ehre?
Als Entwickler schmeiße ich irgendwas nicht-funktionierendes in die Masse und erwarte Dankbarkeit? Dafür gibt es einen Ausdruck, der heißt: Vermessenheit. Ganz einfach.
Und, wenn ich so ein Entwickler wäre, ich würde mich in Grund und Boden schämen.
Da gibt es Leute, die mir/meiner Software wertvolle Dinge anvertrauen und ich sorge NICHT dafür, dass sie diese wertvollen Dinge NICHT verlieren und erwarte im Gegenzug noch Dankbarkeit dafür? Gehts noch?
Ich bin den leuten bei *buntu dankbar, dass sie mir gezeigt haben, wie ein Linux n i c h t funktionieren soll!
Ich bin den Leuten von KDE dankbar, dass sie mir gezeigt haben, wie ein DE in 60-monatiger mühsehlicher Arbeit für mich u n b r a u c h b a r gemacht werden kann.
So viel zu meiner Dankbarkeit!
KDE != Kubuntu...
Bitte bleib bei den Fakten, KDE3 ist immer noch da und wurde nicht unbrauchbar gemacht. KDE4-Anwendungen laufen zudem problemlos unter KDE3 und umgekehrt.
Siehe
http://download.opensuse.org/repositories/KDE:/KDE3/
http://www.trinitydesktop.org/
http://susestudio.com/search?q=12.1+kde3
KDE 3.5.4 in RHEL5/ScientificLinux5/CentOS5 wird nun sogar noch bis März 2017 unterstützt, erhält noch Sicherheitsupdates und vereinzelt sogar noch Programmverbesserungen.
Siehe:
http://www.scientificlinux.org/distributions/5x/57/
http://wiki.centos.org/Manuals/ReleaseNotes/CentOS5.7
KDE3 ist freie Software, genauso wie KDE4.
Macht was draus.
Wenn ich in meinem persönlichen Fall KDE4 mit KDE3 vergleiche, dann sage ich: wird Zeit, dass KDE3 endlich wirklich mal beerdigt wird. KDE3 ist einfach viel zu alt, viel zu chaotisch und ist den derzeitigen Anforderungen an eine Desktopumgebung nicht mehr gewachsen.
Summe: KDE4 ist KDE3 um Längen überlegen. Der einzige Mangel ist Kmail2, aber Kmail in KDE3 war auch schon nix tolles.
Und: warum soll man KDE3 benutzen? Nur weil einzelne Komponenten in KDE4 nicht so funktionieren, wie gewünscht? Sollte man nicht lieber darauf hinwirken, dass diese Komponenten so weiterentwickelt werden, dass sie die gewünschte Funktion erhalten?
"Genau! Wo wären wir den wenn wir uns bei Leuten bedanken würden, die uns etwas gratis optional zur Verfügung stellen?"
Das kann nicht für das letzte Kmail gelten (aus KDE 4.7).
Man muss sich schon fragen, wie es möglich ist, dass Distros einen solche unfertige Software ihren Nutzern unterjubeln.
Hier gilt wirklich: Geschenkt ist noch zu teuer.
Nie mehr Kmail.
Ruhe in Frieden.
Der Fehler liegt offensichtlich in der Darstellung der Herangehensweise für den User.
Möglicherweise war die entsprechende Kommunikation nicht ausreichend genug oder zu technisch.
Was ja hier auch der Fall war.
Nach vielen Jahren Erfahrung mit den postiven und negativen Aspekten der vorhanden Lösung, den dadurch umgesetzten Anwendungsfällen und einer Abschätzung zukünftiger Awendungsfälle, ergab sich als neuer Lösungsansatz eine dienstbasierte Architektur.
Und daher auch der benutze.
"Nach vielen Jahren Erfahrung mit den postiven und negativen Aspekten der vorhanden Lösung, den dadurch umgesetzten Anwendungsfällen und einer Abschätzung zukünftiger Awendungsfälle, ergab sich als neuer Lösungsansatz eine dienstbasierte Architektur."
Das ist ein Satz, den hättest Du in zehn Millionen Threads in zig verschiedenen Themenbereichen immer wieder exakt so schreiben können und er hätte trotzdem immer irgendwie gepasst.
Das ist wohl ein gut getarnter Trollversuch?
Ich kann dir da nicht ganz folgen.
Hmm, vielleicht war der Satz ein bischen zu umständlich formuliert.
Ich wollte damit betätigen, dass die im Kommentar von "idiotenpfleger" vorgeschlagene Herangehensweise auch die tatsächlich umgesetzte war.
Im Detail ergab sich eben aus den Erfahrungen mit dem vorherigen Ansatz (gemeinsamer Zugriff auf Dateien mittels Plugins), dass der gemeinsame Datenzugriff über einen Dienst besser geeignet ist, die bestehenden Anforderungen zu erfüllen.
Im Rahmen der Detailüberlegungen wurde dann natürlich auch versucht abzuschätzen, ob damit mögliche zukünftigen Anforderungen ebenfalls abgedeckt werden können.
Derartige Szenarien mit hoher Wahrscheinlichkeit wurden dann ählich berücksichtigt, wie bereits bestehende.
ich kenne mich mit Softwareentwicklung nicht aus. Aber:
- für ein Adressbuch gibts eine Textdatei. Da werden die Kontakte eingespeichert und auch bei Bedarf gelesen. Wozu brauche ich dann ein Plugin oder einen Dienst? Thunderbird hat soweit ich das bemerkt habe, keinen extra-Adressbuch-Dienst
- Kalender: da gibts eine Textdatei. Da werden die Termine eingespeichert und gelesen und wenn ein Datum mit der Systemzeit übereinstimmt, dann poppt ein Fenster auf... Wozu brauche ich da ein Plugin? Einen Dienst vielleicht, aber kein Plugin...
- für die Zugänge beim ISP/Mailprovider... da gibts Textdateien.... und da kann man drauf zugreifen... soll ich weitermachen? Da würde noch ein paar mal "da gibts ne Textdatei" kommen... hmm...
Komisch... bei den anderen funktioniert das jetzt und bestimmt auch in Zukunft. Die grundlegenden Anforderungen ändern sich auch nicht, bei einem Mailprogramm. Die sind nämlich ganz einfach: Mails empfangen und senden.
Da kann man natürlich auch eine Raketenwissenschaft draus machen. Muss man aber nicht.
Und wenn man dazu noch irgendwelchen Fancy-Kram basteln will, kann man das gern tun. Aber nicht so, dass die grundlegenden Funktionen nicht mehr erfüllt werden. Oder besser noch, wo man doch so dolle auf Plugins steht: warum nicht den Fancy-Kram als einzelne Plugins machen, die der User dazu-installieren kann, wenn er sie denn braucht? Wohl, weil dann kein User den Fancy Kram installiert? Weil nur eine Minderheit sowas braucht? Und die, die es brauchen, wollen dass es funktioniert? Nee, echt... is ja n Ding!
Ach so ja, dann gibt es noch eine kleine Abhandlung darüber wie der Nutzer das Verhalten dieses ganzen Fremdschäm-Würgs... äh Frameworks sieht:
Akonadi braucht Nepomuk um zu funktionieren. Ergo: Nepomuk abschalten, aber Akonadi nicht = ganz großer Fehler.
Also: Akonadi braucht die Suchmaschine. Wohl, um die ganzen Konfig-Dateien und die Dateien fürs Adressbuch auf der Festplatte zu finden. Heißt, für den User: er kann es irgendwo hinspeichern... Akonadi hat ja ne Suchmaschine. FALSCH!
Sobald eine Datei nicht dort ist, wo die Durchlaucht Namens Akonadi entschieden hat, dass sie dort liege, gibt es Fehlermeldungen im Windows-Style. Und das hört selbst dann nicht auf, wenn die Datei dann endlich am geforderten Ort liegt.
Der User fragt sich dann: wozu läuft da ne Suchmaschine im Hintergrund, die ZWINGEND für den Betrieb von Akonadi vorgeschrieben ist. Die Reaktion des Users, nachdem er sich das mal durch den Kopf gehen ließ, ist: Stilllegen und Deinstallieren, den Müll. Und nicht: "ah, ja ist ja verdammt nochmal ziemlich fancy, das ganze. Da geht was". Denn es geht ja nix.
Plugins braucht man, wenn man unterschiedliche Formen der Speicherung benutzen will. Das muss nicht für alle Benutzer relevant sein, aber manche Benutzer haben ihre Adressbuchdaten auf einem Server. Ich würde annehmen, dass Thunderbird hier ebenfalls Plugins benutzt, Evolution tut es.
Ein Dienst hilft dabei, den Zugriff mehrere Programme auf die selben Daten zu regeln. Das muss ebenfalls nicht für alle Benutzer relevant sein, aber manche Benutzer benutzen ihre Kontakte auch außerhab ihres E-Mail Programms.
Thunderbird operiert unter der Annahme, dass es das einzige Programm ist, dass mit seiner Adressbuchdatei arbeitet. Evolution setzt ebenfalls auf einen Dienst.
Da gilt im Wesentlich das selbe, d.h. Plugin wenn man bestimmte Arten der Speicherung und die dafür nötigen Abhängigkeiten nur optional haben möchte und Dienst wenn man die Daten in mehreren Anwendungen gleichzeitig haben möchte.
Bei Thunderbird bzw Lightning muss ich raten, aber ich würde von Pluginunterstützung ausgehen. Bei Evolution ist Pluginunterstützung und Dienst im Einsatz.
Siehe oben. Die Bestrebungen bei Evolution den E-Mail-Zugriff aus der Applikation auch in den Dienst zu verlagern dürfte da ein gutes Indiz sein.
Wäre vielleicht besser gewesen, die Abhängigkeit in allen Applikationen einzubauen, statt im gemeinsamen Dienst. Die Idee war hier, dass die Suche nach PIM Dateien über die selbe API wie der Zugriff auf diese einfacher für Applikationsentwickler ist, als wenn diese dann mit zwei APIs arbeiten müssen.
Nein. Suche nach Dateien ist nur ein Teilaspekt von Nepomuk, in diesem Zusammenhang geht es um das Suche von und in PIM Daten. Zum Beispiel das Auflösen von Adressreferenzen in Kalendereinträgen, automatische Vervollständigung von E-Mail Adressen in Empfängereingabefeldern, das Suchen von E-Mails, etc.
Wie gesagt hätte man das auch an die Anwendungsentwickler schieben können, ein integrierter und einheitlicher Ansatz schien da einfach besser.
IMO fehlen aber die entsprechenden Kennzeichnungen wie Kmail2-Alpha3 oder Kmail2-Beta1, damit auch der Nutzer, der keine Mailinglisten mitliest, weiß, woran er ist.
Kmail in KDE 4.7 ist wirklich nicht fertig, es ist keine finale, sondern eine verbuggte Vor-Version.
Das muss man auch so kommunizieren.
na dann bin ich ja mal gespannt, welche großen Ziele mit dieser Herangehensweise erreicht werden sollten. Hast du diese Ziele verstanden? Kannst du sie erklären?
Was, außer Mails empfangen, Termine und Adressen verwalten soll eine PIM Software können? Welche Aufgaben, von diesen genannten, kann Thunderbird nicht? Wo versagt auch z.B. Evolution? Was ist also das "Shortcoming" all dieser Mailprogramme? Was kann Kmail2 stattdessen, außer sinnlos Festplatte und CPU fressen?
Also... dann stellt sich mir das ganze so dar: wir wollen eine Revolution unter den Mailprogrammen loslassen und bauen uns die super-duper-Maschinerie zusammen... und dann, als sie fertig war, die Super-Mailkiste... dann konnte sie nichtmal Mails empfangen oder senden... wahnsinn... ja, das ist revolutionär.
Ich denke zum Großteil, ja.
Kann ich versuchen
Da wäre mal das Ziel, den gleichzeitigen Zugriff auf Daten zu verbessern. Der vorher benutze Ansatz, aus allen interessierten Applikation parallel auf die selbe(n) Datei(en) zuzugreifen hat immer wieder zu Problemen geführt. Unter anderem weil das dafür nötige Sperren von Dateinzugriffen nicht auf allen Dateisystem (gleich) funktioniert. D.h. es kam schon mal vor, dass zwei Programme ihre Änderungen gegenseitig überschrieben haben.
Der neue Ansatz verbessert dies, in dem nur immer ein Programm auf die Datei direkt zugreift und alle anderen eben mit diesem Dienst kommunizieren.
Dann wäre da weiters das Ziel "Offline" Fähigkeiten für alle Datentypen zur Verfügung zu haben, nicht nur für IMAP E-Mails. Das ist natürlich interessanter für Benutzer, die serverbasierende Adressbücher und Kalendar benutzen und deren Server nicht im selben Netzwerk stehen oder die mobil arbeiten.
Auf der Anwendungsebene ist ein Ziel den Datenzugriff von der Datendarstellung zu trennen. Der Hauptgrund dafür ist, dass vorher bestimmte Funktionalität von Programmen an das Vorhandensein und Ausgeführtwerdens eines anderen Programms abhingen.
Z.B.: die Möglichkeit auf Adressbücher oder Kalendar zuzugreifen, die in speziellen Ordnern auf einem IMAP Server liegen, erforderte bisher das Vorhandensein und Ausgeführtwerden von KMail, weil darin sowohl IMAP Zugriff als auch Anzeige implementiert war.
Das Ausgliedern in einen Dienst erlaubt nun Programmen solche Adressbücher oder Kalendar zu benutzen, ohne dass der Benutzer dafür KMail installiert und laufen haben muss.
Es geht da nicht darum was andere Programme können, sondern ob und wie diese entsprechende Funktionalität für anderen Programme zur Verfügung stellen.
Thunderbird ist daran nicht interessiert und das kann für viele Benutzer auch ausreichend sein. Andere Benutzer brauchen die Möglichkeit auf ihre Daten, z.B. Kontakte, von anderen Programmen nicht nur auf Import-/Exportbasis zuzugreifen.
Aus diesem Grund benutzt Evolution ebenfalls einen dienstbasierten Ansatz (siehe Evolution Data Server), allerdings bis vor kurzem meines Wissens nur für Adressbücher und Kalendar (d.h. Unterstützung für E-Mail ist da auch noch relativ neu).
danke für die Erläuterungen. Klingt alles nach was ziemlich großem... Obwohl ich nicht ganz begreife, warum man nicht wenigstens eine Grundfunktionalität einfach so "normal" darstellen kann und wenn es wirklich DER spezielle Anwendungsfall ist, mit Dateien auf dem Server und was weiß ich - dass man dann und nur dann auf dieses große Gebilde zurückgreift...
Ich meine, die Idee ist ja nicht schlecht (eigentlich verdammt faszinierend), aber man bewegt sich sehr eng an der Kante der Nicht-Akzeptanz. Vor allem bei Fehlern und wenn es kompliziert ist.
Denn es ist nunmal so: der einfache Benutzer begreift nicht, warum er stundenlang am Mailprogramm rumkonfigurieren muss... immer wieder die Meldung, dass irgendeine Migration nicht funktioniert hat und was weiß ich... der will einfach nur Mails lesen und schreiben und seine Kontakte und Termine verwalten... Also all das klingt zwar furchtbar spannend, aber es ist schwer zu vermitteln.
Und wenn man dann immer wieder in Probleme kommt und immer wieder irgendwas nicht funktioniert, dann denkt man als User: "Wisst ihr was, ihr könnt euch euren höheren Zweck sonstwo hinstecken"... das sind dann die Akzeptanzprobleme. Dann kommt das schlechte Imgage... "KDE? Kmail? der Zacker-Kram? nee, lass mal. Da bleib ich lieber beim Win, oder Unity... irgendwas".
Also als User ist man schon fehlertolerant. Ich habe mir zwar kein KDE 4.0 gegeben, aber in der 4er Reihe bin ich seit 4.1 dabei und ich habe viel erlebt. Und ich bin auch verdammt stolz auf KDE, weil es in meinem Fall seit 4.2 einigermaßen gut läuft und auch generell mit jeder Version immer besser geworden ist. Wenn man dann immer wieder mal in irgendwelche Löcher fällt = irgendwas nicht funktioniert, dann ist es bis zu einem bestimmten Maß auch ok. Nur wenn man dann Daten verliert... dann hörts bei mir auf. Und Kmail2 hat mir so manchen Schaden eingebrockt.
Da habe ich kein Verständnis. Auch nicht, wenn eine "große Sache" dahinter steckt. Und auch nicht, wenn es nix kostet.
Meiner Meinung nach gehört ein funktionierendes Mailprogramm zu einem anständigen DE. Heißt: es muss funktionieren. Auch wenn es kompliziert ist: dann ist es eben im Hintergrund kompliziert, aber für den User hat es einfach zu sein. Auch wenn´s geschenkt = gratis ist.
Ich stelle mir auch immer wieder die Frage: warum bastelt KDE denn an einem eigenen PIM? Warum kann man denn nicht meinetwegen Thunderbird nehmen, den ins KDE integrieren und mit Add-ons bedarfsgerecht aufmotzen?
Warum kann man denn z.B. Evolution nicht einfach nehmen und an den entsprechenden Stellen ans KDE anpassen?
Ist doch freie Software... da geht das doch! Liegts am Ego? Am NIH Syndrom? Warum macht man sich diese Arbeit, lässt die Beschimpfungen über sich wegrollen... um dann bei der nächsten Version wieder nix zum Besseren geändert zu haben... traurig.
IMO liegt es an den Distros.
Die stimmen z.B. KDE- und Gnomesoftware einfach nicht aufeinander ab.
Dabei sind selbst z.B. Epiphany-Browser und Evolution hervorragend unter KDE4 nutzbar, gerade wegen des mitinstallierten, funktionsfähigen Gnome-Networkmanagers.
Um den überflüssigen Bloat in Grenzen zu halten, bräuchte man halt durchgehend schlanke kde-, gtk-, qt-, gnome-Basisbibliotheken.
Was nicht passieren darf, ist, dass z.B. Tracker und Nepomuk gleichzeitig herumwerkeln, nur weil mit den entsprechenden Programmen gearbeitet wird. Eine Art Mindestabstimmung zwischen den DEs wäre also in jedem Fall vonnöten.
Und das wäre die Aufgabe der Distros.
Ich denke das Hauptproblem ist den Rahmen von Grundfunktionalität wirklich gut zu stecken. Würde es nur um ein Programm gehen könnte man zum Beispiel den Rahmen so definieren, dass der Zugriff auf lokale Dateien direkt passiert.
Nachdem das aber schon alleine in KDEPIM nicht der Fall ist (z.B. Zugriff auf Kontakte aus Adressbuch, Kalendar und E-Mail Programm) ist der Rahmen von Grundfunktionalität schon mal der gleichzeitige Zugriff auf lokale Dateien.
Bzw. im Falle von E-Mails ist der Zugriff auf Server schon im Rahmen der Grundfunktionalität.
Durch das sehr ähnliche Anforderungsprofil bei GNOME sieht man eigentlich ganz schön, dass man dort auf die selben Techniken setzt, um die nötige Funktionalität umzusetzen. Mozilla hat auf Grund eines einfacheren Profils weniger komplexe Problemstellungen und kann daher andere Wege gehen.
Da gebe ich dir natürlich recht.
Hier hat der Wunsch, den Umstieg von alter zu neuer Technologie möglichst "unsichtbar" zu gestalten, genau zum Gegenteil geführt.
Im Nachhinein betrachtet wäre ein expliziter "import" Prozess besser gewesen. Der hätte von den Benutzer zwar Interaktion erwartet, wäre aber daher auch besser kontrollierbar gewesen.
Ich würde jetzt nicht sagen zu einer DE, das wären eher so Sachen wie Fensterleiste, Desktop, Windowmanager.
Aber durchaus zum Produktumfang eines Herstellers von Endbenutzer-Software für "alle" Basisanwendungsbereiche.
Die einzelnen Programme gibt es einfach schon seit ewig, KMail gab es z.B. schon für KDE1. Im Falle der darunterliegenden Infrastruktur, z.B. dem Adressdateizugriff, weil das einfach von einer Plattform für Endanwendersoftware erwartet wird (und daher z.B. auch Bestandteil jeder Plattform für Mobilgeräte oder proprietärer Desktopplattformen ist).
Ich denke das wäre nicht durchführbar. Thunderbird ist nicht als Komponenten in einem größerem System konzipiert, d.h. es ist vermutlich schwer das Programm ohne GUI zu starten bzw. zu verhindern dass es beendet wird während es von einer anderen Applikation für den Dateizugriff gebraucht wird.
Das ist schon eher machbar, allerdings auch nicht so einfach. Die Kommunikation zwischen Evolution Data Server (EDS) und seinen Clients funktioniert mehr oder weniger über bestimmte Bibliotheken, die zugrunde liegende Kommunikation ist nicht so fixiert und Server und Clientbibliotheken werden bei Bedarf zeitgleich verändert.
Das würde das Bereitstellen von Qt-basierten Clientbibliotheken relativ schwer machen, oder auf Seiten der EDS Entwickler eine Umstellung ihrer Verfahrensweise bedeuten.
Durch die Umstellung bei KDE auf eine ähnliche (dienstbasierte) Architektur und die Erweiterung des Leistungsmfangs bei EDS (+ E-Mail) und die Umstellung auf D-Bus für die interne Kommunikation, ergibt sich schon eine gewisse Konvergenz.
Es ist daher durchaus vorstellbar, dass sich in Folge daraus eine Art von Austauschbarkeit ergibt.
Zitat: "Durch das sehr ähnliche Anforderungsprofil bei GNOME sieht man eigentlich ganz schön, dass man dort auf die selben Techniken setzt, um die nötige Funktionalität umzusetzen. Mozilla hat auf Grund eines einfacheren Profils weniger komplexe Problemstellungen und kann daher andere Wege gehen."
Zitat: "Durch die Umstellung bei KDE auf eine ähnliche (dienstbasierte) Architektur und die Erweiterung des Leistungsmfangs bei EDS (+ E-Mail) und die Umstellung auf D-Bus für die interne Kommunikation, ergibt sich schon eine gewisse Konvergenz.
Es ist daher durchaus vorstellbar, dass sich in Folge daraus eine Art von Austauschbarkeit ergibt."
also, das liest sich ja so wie: "die bei Gnome haben das gleiche gemacht, nur eben auf einige Gnome-spezifische Dinge angepasst" ...
für mich als Nutzer sind hier die augenscheinlichsten Dinge:
- Einbindung in die Desktop-Uhr, zur Terminverwaltung und Benachrichtigung
- Einbindung in das User-Benachrichtigungssystem
- Anbindung an die Netzwerkschnittstelle
- Optik = GUI in GTK
- Diensteverwaltung: D-Bus und Udev
- Anbindung an den Dateimanager fürs speichern von Dokumenten und für "Rechtsklick --> senden per E-mail an..."
Der Unterschied zum Kmail2 ist, dass Evolution erste Sahne funktioniert. Und ich als User frage mich:
- Desktop-Uhr und Benachrichtigungsystem? Hat KDE
- Netzwerkschnittstelle? Hat KDE
- Optik? Qt
- Dateimanager? Hat KDE
- Diensteverwaltung: D-Bus und dieses Udev
Und weil das doch sicher alles standardkonform ist, auf Gnome und KDE-Seite, usw., frage ich mich dann wirklich: warum kann man das Evolution-Programm, das hinter der GUI steckt, nicht einfach übernehmen, an die Gegebenheiten (Netzwerk, Dateimanager, Uhr, Benachrichtigungssystem) anpassen und dann eine Qt-GUI dafür bauen? Doch wegen NIH? Bestimmt. Da bin ich mir jetzt ziemlich sicher.
Ich meine, das mit Thunderbird sehe ich ein, dass das sinnlos wäre, aber bei Evolution... da kann man Argumente noch und nöcher vorbringen: die sind für mich allesamt fadenscheinige Ausreden.
Noch dazu, wo Novell, der Sponsor vom Evolution, mal die Suse-Mutter war und Suse DIE KDE-Distro ist... eigentlich sieht das aus meiner "Nutzersicht" richtig übel nach gewaltigem Irrsinn, brutaler Hochnäsigkeit und extremst übersteigertem Ego auf der KDE-Seite aus. Die Zeche zahlt der User. Na schönen Dank auch...
Man braucht dazu erst einmal den zeitlichen Kontext.
Die Kommunikation zwischen EDS und seinen Clients erfolgte lange Zeit über CORBA, D-Bus stand nicht zur Verfügung und auch nicht auf der Roadmap als an den Arbeiten zu Akonadi begonnen wurde. Dazu kommt dann noch, dass bis noch vor kurzem E-Mail keiner der in EDS unterstützten Datentypen war.
D.h. auch wenn jetzt gerade diese Dinge besser sind, könnte man jetzt eine Umstellung neu evaluieren. Nur ist eben jetzt nicht 2007.
Dazu kommt dann eben noch die technische Schwierigkeit, dass die Kommunikation zwischen EDS und seinen Clients als internes Detail gehandhabt wird. D.h. eine Änderung in der Kommunikation wird einfach zeitgleich in Server und Client gemacht.
Das ist natürlich lösbar, d.h. man mit entsprechender Versionierung und Vermeidung von inkompatiblen Änderungen. Aber das erfordert eine entsprechende Änderung im Entwicklungsmodell und damit verbundenen Mehraufwand für das EDS Team.
Wie gesagt ergibt sich auf Grund von Umstellungen auf beiden Seiten (Evolution, KDEPIM) eine Angleichung der Gegebenheiten, die durchaus in Zukunft zu einer gewissen Austauschbarkeit von Komponenten führen kann, bzw. eventuell auch zu einer eigenständigen und von beiden Projekten benutzen Referenzimplementierung.
Selbst in einem viel einfacheren Feld wie dem gemeinsamen Secret Service bedeutet eine Zusammenführung einen Prozess von mehreren Jahren, denn benötigt nicht nur den neuen Dienst bzw neue Schnittstellen für einen bestehenden Dienst, sondern auch entweder entsprechende Anpassungen in allen benutzenden Programmen oder eine neue Implementierung der vorhanden APIs basierend auf den neuen Schnittstellen.
Das Anstreben solcher Universallösungen dürfte durchaus die Unterstützung vieler Entwickler geniessen, nur sind sich diese eben auch der damit verbundenen "Kosten" bewusst. D.h. man arbeitet in kleinen Schritten daran die Unterschiede zu minimieren um den Aufwand zu verringern, den eine Umstellung auf eine gemeinsame Lösung mit sich bringen wird.
Es ist denke ich verständlich, dass aus Benutzersicht diese Kosten nicht sichtbar sind oder gering erscheinen, aber leider ist die Realität aus der Entwicklersicht oft eine ganz andere.