Thunder Das ist nicht zu 100% korrekt, ich konnte das Problem durch Ändern der Mindestschriftgröße reproduzieren.
@adir Bitte wirklich mal die Mindesschriftgröße auf "keine" stellen und neu starten. Wenn das das Problem behebt, weiß ich wo ich ansetzen muss und kann es in der nächsten Version von TbSync reparieren.
GnOmE da muss ich passen. Ist das ein lokales "Systemadressbuch"?
TbSync kann nur mit externen Konten arbeiten, entweder via CardDAV/CalDAV oder EAS und bald hoffentlich auch EWS.
Lightning unterstützt den Discovery Service nicht, d.h. man muss die URL wissen, die zu einem Kalender gehört, um ihn einzutragen. TbSync macht genau das, es zeigt dir alle Kalender in deinem Account an und du kannst angeben, welche davon gesynct werden sollen.
Das syncen selber macht dann "wie üblich" Lightning, hier habe ich das CalDAV Protokoll nicht nochmal implementiertm sondern lasse Lightning syncen.
VG
John
Hast du TB schon neu gestartet nach der Änderung?
Kurzes Update: Der CardDAV/CalDAV support wurde jetzt auch vom Thunderbird team freigegeben und alles ist über AMO (heißt ja jetzt eigentlich ATN) verfügbar.
https://addons.thunderbird.net/addon/tbsync/
https://addons.thunderbird.net/addon/dav-4-tbsync/
Oder man sucht einfach nach "tbsync" im Thunderbird AddOn Manager.
Du hast wahrscheinlich eine Mindesschriftgröße in Thunderbird festgelegt. Einstellungen -> Ansicht -> Formatierung -> Erweitert -> Mindestschriftgröße -> Keine.
Viele Grüße
John
Genau, das sehe ich auch so.
Es gibt dann nur keinen Weg mehr zurück, d.h. wenn der User später wieder den SOGo-Connector benutzen will, dann findet der sein X-AIM Feld nicht mehr in der vCard. Ich glaube ich füge eine Migrations-Option hinzu, die dann genau das macht...
Inzwischen habe ich sehr viel Feedback und Verbesserungsvorschläge bekommen. Leider braucht das Thunderbird Team gerade wieder sehr lange, um neue Versionen zu releasen. Daher hier der Link zur Beta:
https://tbsync.jobisoft.de/TbSyncBetaInstaller.xpi
Noch offen ist die Frage, wie ich mit spezifischen Feldern des SOGo-Connectors umgehen soll, die nicht dem Standard entsprechen. Z.B der ChatName wird vom SOGo-Connector im vCard-Feld "X-AIM" abgelegt, obwohl es laut specs extra ein "impp" Feld mit zusätzlichem x-service-type identifier gibt (owncloud nutzt das). Soll ich das vCard-Feld "X-AIM" migrieren, wenn ich es finde? Oder eine "SOGo-Option" einbauen? Gibt es noch andere Felder, die ich nicht anzeige, weil SOGo sie nicht in den richtigen vCard-Feldern abgespeichert hat?
Das verstehe ich jetzt wieder nicht. Du hast gesagt
Als Benutzer bereitet es mir Sorge, dass ich keine Zukunftssicherheit habe. Ich weiß nicht, ob CardBook oder TbSync auch in zwei Jahren noch funktionieren werden.
Die Zukunftssicherheit kann dir keiner geben, du kannst dich aber selbst einbringen und eben mithelfen CardBook umzuschreiben, wenn es nötig ist. Das kannst du durch Spenden machen (Coder bezahlen) oder durch Zeit (selber coden).
Ich weiß wirklich nicht, was an meinem Vorschlag lächerlich ist. Ist doch vollkommen egal, was du in der Vergangenheit gespendet hast. Wenn dir CardBook wichtig ist, musst du es auch in Zukunft unterstützen. Und ich finde es einfacher einen kleinen Betrag monatlich wegzudrücken, als einem großen.
Wir drehen uns im Kreis, ich weiß nicht worüber wir hier diskutieren. Ich denke es ist zu dem Thema alles gesagt, oder?
Ja, daran haben wir alle zu knabbern, aber ändern können wir nichts. Jetzt geht es eben nur mit den aktuellen Technologien und irgendwann nur mit den neuen. Das gilt für alle AddOns. D.h. alle AddOns müssen irgendwann umgeschrieben werden.
Aber da ich wie gesagt die Sachen jetzt brauche, mach ich es einfach jetzt mit den aktuellen Technologien (wobei ich schon die "modernste" nutze die es gibt, TbSync ist restartless). Das ist keine Verschwendung von Resourcen, weil ich es ja jetzt auch nutzen kann.
Hier können wir nur abwarten und schauen wohin die Reise geht. Aber - und das meine ich ernst - lege doch einfach jeden Monat einen kleinen Betrag zu Seite. Wenn es dann soweit ist und alle AddOns umgeschrieben werden müssen, dann kannst du aktiv helfen.
Im konkreten Fall sehe ich, dass zwei Erweiterungen entstehen, die sich letztendlich in den Funktionen nur wenig unterscheiden werden. Das ist typisch für freie Software. Schau dir nur die vielen Derivate des Linux an. Die sind kaum noch überschaubar.
Ich empfinde das als eine Verschwendung von Ressourcen. Entwickler wie du investieren viel Zeit und Arbeit, um um Nuancen unterschiedliche Wege zu gehen. Das passiert Unternehmen wie Microsoft, Apple oder Google nicht.
Wenn es dich beruhigt, ich empfinde es nicht als Verschwendung. Mir macht das Spass und es ist gut für meinen Lebenslauf/CV. Meine Arbeit an TbSync hat zu 99% nix mit dem Adressbuch zu tun, es geht viel mehr um allgemeine Sync Prozesse und das Manager UI. Als Sync Ziel muss ich die Daten natürlich irgendwo hinschreiben und dafür nutze ich die Adressbuch API. Einzig das Hinzufügen einiger Felder ist wirklich eine aktive Arbeit am Adressbuch, aber das fällt fast nicht ins Gewicht.
Bei der Arbeit am DAV Sync gibt es in er Tat einen Überlapp mit CardBook, aber hier ist es einfach mein Konzept zu sagen, die Sync Logic gehört in den zentralen Sync Manager und nicht ins Adressbuch, das habe ich aus innerster Überzeugung heraus also so machen müssen. Ich hab glaube ich 4 Wochen für das AddOn gebraucht, das ist überschaubar.
Ich werde aber nie das interne Adressbuch an CardBook angleichen, das geht garnicht und das will ich auch garnicht. Es gibt eine Zielgruppe, die eben genau dieses einfache Adressbuch benutzen möchte und nicht CardBook. Wenn die CardBook API kommt, dann wird das noch viel offensichtlicher, das TbSync für die Kontenverwaltung und die Sync Prozesse zuständig ist und die Daten je nach Wahl des Nutzers ins interne Adressbuch schreibt, oder nach CardBook.
Bei allem ehrlich gemeinten Respekt für deine Arbeit, Erweiterungen sind an dieser Stelle Flickwerk mit unbekanntem Ablaufdatum. Als Benutzer bereitet es mir Sorge, dass ich keine Zukunftssicherheit habe. Ich weiß nicht, ob CardBook oder TbSync auch in zwei Jahren noch funktionieren werden.
Aber das ist ein allgemeines Problem und unabhängig von OpenSource. Software kann eingestellt werden. Ich trauere heute noch Micrografix Picture Publisher hinterher, ich habe es geliebt und dann ging die Firma pleite und es gab keine neuen Versionen für die nächste Windows Version. Kannst du nix machen. Bei OpenSource kannst du aber Geld in die Hand nehmen und Entwickler bezahlen, oder es selber machen. Aber eine Garantie, das Feature XY ewig in einer Software funktioniert, kann dir keiner geben.
Erweiterungen sind hier kein Flickwerk, sondern machen gerade die Stärke von Thunderbird aus. AddOn Entwickler bauen AddOns hauptsächlich für sich selbst, weil Sie eine Funktion haben wollen und alle anderen können es ebenfalls benutzen. Sollte ein Entwickler sein AddOn einstellen, dann muss die Community ran. Entweder mit Geld/Spenden oder selber programmieren.
Geld hilft immer. Aber: Es darf ja heute alles nix kosten. Die Spendenbereitschaft ist sehr gering. Und wenn ein AddOn tatsächlich eine jährliche Gebühr kostet, kannst du die negativen Kommentare nicht mehr zählen.
Die Forderung, das "wichtige" AddOns in den Thunderbird Core übernommen werden, ist leider nicht machbar, weil das Core Team dafür viel zu klein ist. Es ist schlicht keiner da, der diese AddOns dann pflegen kann.
Wenn es wirklich nur an der Zeit liegen sollte und daran, dass euch euch niemand zuhört, welche Hilfe benötigt ihr? Sollen wir eine Online-Petition starten?
Ich glaube nicht das eine Petition hilft. Geld & Zeit hilft. Was fehlt dir an CardBook? Schreibs auf, mach ein Pflichtenheft, suche Gleichgesinnte und stellt einen Entwickler an, der Philippe unterstützt.
@Solaris: Es fällt mir schwer auf deine Posts zu antworten, wir haben eine komplett unterschiedliche Herangehensweise. Ich bin froh das ich jetzt TbSync bzw. CardBook benutzten kann. Du bist unglücklich/besorgt, weil du nicht weißt, ob du es auch in zwei Jahren noch nutzen kann. Diesen Konflikt kann ich nicht auflösen.
Wenn irgendwann ein neues Adressbuch kommt, das mein AddOn überflüssig macht, wäre ich nicht traurig, denn das heißt ja: Weniger Arbeit für mich.
Ich hatte dir bereits geschrieben, dass ich direkten Kontakt mit mehreren Mitgliedern des Thunderbird Council habe und dass die alle praktisch keine Zeit haben. Hätte ich versucht irgend einen Masterplan zu entwickeln und mit irgendwem abzusprechen, gäbe es TbSync heute noch immer nicht.
Thunder: Momentan wird versucht die Richtlinien für zukünftige AddOns festzulegen. Es gibt Bemühungen XUL Overlays weiterhin zu ermöglichen. TbSync z.B. hat einen von mir entwickelten OverlayManager, mit dem ich weiter XUL Overlays benutzen kann, obwohl Thunderbird das nicht mehr unterstützt. Der Entwickler von Lightning arbeitet an etwas Ähnlichem. TB 63 ist aber nur ein Zwischenschritt, TB68 ist das nächste ESR und dann wird es spannend. Konkrete Aussagen kann aber niemand geben. Das Team ist klein und die Ressourcen beschränkt...
Ich möchte nochmal darauf hinweisen das es mir in diesem Faden nicht um TbSync vs CardBook oder allgemein um die Adressbuch-Diskussion geht. Sobald die Planungen abgeschlossen und Philippe die notwendige API in CardBook eingebaut hat, ist es für TbSync vollkommen egal, welches Adressbuch der Nutzer verwendet. Er kann einfach in TbSync festlegen, in welches Adressbuch gesynct werden soll.
Sollte sich der User dabei für das Standard-Adressbuch entscheiden, möchte ich ihm aber auch da ein paar Zusatzfelder anbieten. Daher die Umfrage, welche vCard Felder TbSync zusätzlich im Standard-Adressbuch editierbar machen sollte. Bei weiteren Rückfragen dazu stehe ich natürlich zur Verfügung, aber evtl nicht in diesem Faden, da es sonst so unübersichtlich wird?
Alles klar, hab den Post gelöscht, da sowiso OT.
Wir stehen bereits in Kontakt und wir haben grundsätzlich verschiedene Ansätze. Trotzdem wird es eine Zusammenarbeit geben, z.B. das ich in CardBook Adressbücher via EAS synce, damit auch CardBook User dieses Protokoll nutzen können. Ich will auch auf gar keinen Fall User davon abhalten CardBook zu benutzen. Wenn euch CardBook gefällt, dann benutzt es.
Dieser Faden ist explizit für Leute, die vorher den SOGo-Connector benutzt haben (warum auch immer) und weiterhin mit dem alten Adressbuch arbeiten wollen.
Nichtsdestro Trotz bietet das vCard Format mehr Möglichkeiten als das Thunderbird-Adressbuch. Da ich sowieso alle vCard Daten habe ist der Aufwand minimal im Adressbuch auch ein Feld hinzuzufügen um es nutzbar zu machen. Ich werde nicht so viele Felder hinzufügen wie CardBook (weil genau deswegen benutze ich es z.B. nicht), aber wichtige Felder schon.
Ich finde es daher legitim, die User zu fragen.
Bei dem Photo lese ich tatsächlich bei jedem Sync die locale Datei um rauszukriegen, ob sich was geändert hat. Wenn die aus externen Gründen korrumpiert ist, geht das schief. Ich denk darüber nach ...
Ich hab da schon etwas Hirn reingesteckt, z.B. halte ich die gesamte vCard des Server vor und extrahiere daraus die Daten, die in Thunderbird angezeigt/editierbar sein sollen. Beim update merge ich lokale Änderungen in die vCard und baue Sie nicht neu zusammen. So werden Reihenfolge aller Einträge beibehalten und Einträge die ich nicht benutze werden nicht verändert.
Wenn jetzt aber eine Eigenschaft, die ich synchronisiere (z.B. Fotos) auf Thunderbird-Seite verändert werden, dann muss ich das natürlich als "lokale Änderung" interpretieren und zum Server schicken. Wenn dafür ursächlich ein Fehler auf Thunderbird-Seite verantwortlich war, geht das natürlich kaputt bzw. wird gelöscht. Ich hab leider keine Idee, wie ich das verhinden kann ... *grübel*
Umfrage: Welche zusätzlichen vCard Felder müssen unbedingt(TM) über Thunderbird editierbar sein?
Bis jetzt habe ich Anfragen bzgl.
- Zweiter Vorname (is in 0.8.7 schon drin)
- Weitere Telefonnummer, weder "dienstlich" noch "privat", sondern sowas wie "bevorzugt", "Standard" oder einfach nur "Telefon" (technisch alles was nicht HOME oder WORK ist, sondern ohne Type, mit PREV oder was auch immer noch in der vCard steht).
Noch was?
Ich war mir noch nicht sicher, wie ich es machen will. Dein Posting hat aber valide Argumente und hat dann tatsächlich den Ausschlag gegeben.
Es ist auch schon durch das Thunderbird Team freigegeben worden! Meine Angst, dass updates über ATN lange dauern hat sich hier also schonmal nicht bestätigt.
Jetzt muss ich nur noch warten, bis auch die nächste Version von TbSync selbst (v0.7.11) freigegeben wird. Erst dann ist der neue Provider richtig nutzbar (oder eben mit der oben verlinkten Beta).
