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.
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.