Braucht man noch was außer AB?

[Georgalt]

Guten Morgen, Forum!

Ich bin Georg und habe begonnen, mich mit Familienforschung zu beschäftigen. Ich habe mich dann für Ahnenblatt entschieden und gekauft, weil es offensichtlich viele haben und es auch dieses aktive Forum gibt.

Hier habe ich gelesen, dass manche das Programm zur Datenerfassung nehmen und in anderen Programm die Stammbäume oder Tafeln drucken. Ist das dann einfach u.U. schöner, vielfältiger, komfortabler? Welche Ansprüche bei Visualsierung und Druck erfüllt AB nicht?

Noch eine Frage: Es gibt ja auch Plug-Ins. Oder sind die nur für ältere Versionen?

Beste Grüße
Georg

[Deleted User 6561]

Hallo Georg,

willkommen im Forum und viel Spaß beim Ahnenforschen.

Da hast Du ja gleich eine ganze Menge an Fragen, ich versuch mal einige Antworten zu geben.

Erstmal kannst Du alles mit Ahnenblatt machen, jedoch sind die Anforderungen nicht bei jedem gleich und je mehr man sich mit einer Sache beschäftigt, desto mehr steigen die individuellen Wünsche.
Manche hätten gerne einen Fächer oder Kreis beim Ausdruck, so etwas kann dann bsp. Ahnenblatt nicht. Oder Du willst bestimmte Zweige im Baum verschieben und anders anordnen, eine Zeit- oder Generationsleiste anbringen, freie Graphikobjekte platzieren etc., da stößt Ahnenblatt schnell an seine Grenzen.

Auch wenn Du beispielsweise ein Kirchenbuch verkarten willst, Personen auf Gruppenbildern identifizieren möchtest o.Ä. kommst Du schnell an Grenzen. Weswegen viele Ahnenforscher mit mehreren Programmen arbeiten und Gedcom als Austauschformat verwenden.

Die Plug-Ins, sind auch so eine Sache, Du kannst nicht in die Verwaltung der aktiven Daten eingreifen, sondern diese nur abfragen. Eine saubere aktuelle Dokumentation wie man da zugreift gibt es auch nicht, nur etwas ältere Erfahrungsberichte hier im Forum. Inwiefern alte Plug-Ins mit aktuellen Programmen arbeiten musst Du selber herausfinden, dafür gibt es keine Übersicht und das alte Plug-Ins laufen keine Garantie. Aber viele laufen mit aktuellen Programmversionen.

Gruß

Martin

[Fridolin]

Hallo Georg,

ich fürchte, viele Teile deiner Fragen lassen sich nicht eindeutig beantworten.

Klar ist: Ahnenblatt bietet
a) keine Fächer-Grafik (eine Tafel, wo die Ahnen im Halbkreis angeordnet sind);
b) keine manuellen Eingriffe in das Ergebnis einer Tafel, nur ein paar Grund-Einstellungen vorab.

Aber das ist für einen Anfänger eher vorteilhaft. Das würde heißen, deine Fragen auf diesem Gebiet kannst du in einem Jahr getrost noch einmal stellen.

Ich persönlich habe mich von den Plugins mit Start von AB 3.0 verabschiedet. Aber manche funktionieren auch weiterhin mit AB 3.x. Da müssten andere dir einen Rat geben.

[Jürgen_Nordlicht]

Georg, das sehe ich ähnlich,
-arbeite erst mal mit AB und "spiele " mal mit den vielen Variationsmöglichkeiten zum Erstellen von Tafeln, Listen etc., ich nehme an, das von Fridolin benannte Jahr wird damit reichlich ausgefüllt sein
- Weiterführende Programme mögen dann durchaus sinnvoll werden, bedürfen dann aber jeweils weiterer recht intensiver Einarbeitung.
Das gilt insbesondere eben für die Erstellung von Tafeln aber auch Büchern.

[bjew]

Noch zu den Plugins.
Die vorhandenen Plugins sind von unseren Forumsmitgliedern erstellt und "nur" soweit gepflegt, wie der Entwickler hier noch aktiv ist und/oder sie selbst noch nutzt.
Schwierigkeit ist dabei nicht nur die leicht veränderte Struktur der an der Plugin-Schnittstelle bereitgestellen Daten, sondern auch die Änderungen in Windows und NET. Nicht jeder Entwickler ist jeden Schritt bei beiden Teilen mitgegangen.
Source-Code liegt meist nur bei diesen Entwicklern.

Die Plugin-Schnittstelle ist sehr wohl als ABP beschrieben, nur nicht vollständig, aber für den "Normal"-Gebrauch ausreichend. Für Spezielle Fälle gibt DirkB sicherlich Hinweise.
1066, 1067: Infos zur Plugin-Schnittstelle

Technisch: Die Plugin-Schnittstelle ist nicht gedacht, in die innere Struktur von Ahnenblatt einzugreifen, dort (in der Datenbank) Änderungen vorzunehmen - warum auch?

Die Standard-Schnittstelle gibt die Daten als csv, Gedcom oder Website aus, dort kann beliebig gebastelt werden, ggf. die Ergebnisse durch den Anwender in einem weiteren Schritt manuell(!) wieder in Ahnenblatt importiert werden.

Und noch ein Hinweis:
Genwiki - AB Store (Ahnenblatt Plugin)


Neue Plugins immer willkommen!

[Deleted User 6561]

Technisch: Die Plugin-Schnittstelle ist nicht gedacht, in die innere Struktur von Ahnenblatt einzugreifen, dort (in der Datenbank) Änderungen vorzunehmen - warum auch?

Ist nicht genau das der Sinn eines Plug Ins, die internen Daten oder deren Anzeige zu ändern und so zur Laufzeit Änderungen und Erweiterungen vorzunehmen die es nicht oder noch nicht gibt?
Ansonsten kann man ja gleich ein separates Programm schreiben das die Gedcomdaten manipuliert.
Und vielleicht ist genau das der Grund, warum es so wenig aktuelle Plug Ins für Ahnenblatt gibt.

Ich zumindest verspüre keinen Drang ein Plug In zu schreiben, dass dann nur in Ahnenblatt läuft, sonst keinen Mehrwert hat, welches ich genauso für beliebige Gedcom Dateien als externes Programm schreiben kann.

Warum sollte man sich durch eine schlecht dokumentierte Schnittstelle quälen, wenn man in einem separaten Programm alle Freiheiten hat und versionssicher ist?

Gruß
Martin

[Georgalt]

Herzlichen Dank!

Wahrscheinlich habt Ihr recht. Ich starte erstmal und sehe dann weiter.
:-)

Blicke ja bei AB noch nicht mal richtig durch. Ich habe noch eine Frage:

Bei den Optionen zum Tafeldruch heißt es:
"Anzahl der Personentexte, der verkleinert werden darf"

Was bedeutet das?

Gruß
Georg

[bjew]

Technisch: Die Plugin-Schnittstelle ist nicht gedacht, in die innere Struktur von Ahnenblatt einzugreifen, dort (in der Datenbank) Änderungen vorzunehmen - warum auch?

Ist nicht genau das der Sinn eines Plug Ins, die internen Daten oder deren Anzeige zu ändern und so zur Laufzeit Änderungen und Erweiterungen vorzunehmen die es nicht oder noch nicht gibt?

nein, nicht zwangsläufig

Ansonsten kann man ja gleich ein separates Programm schreiben das die Gedcomdaten manipuliert.

ja

Und vielleicht ist genau das der Grund, warum es so wenig aktuelle Plug Ins für Ahnenblatt gibt.

vielleicht ja, aber hier sind vermutlich nur wenige, die ihre Programmierkünste - soweit vorhanden - ausleben wollen. Sie haben vielmehr ein ganz anderes Ziel vor Augen.

Ich zumindest verspüre keinen Drang ein Plug In zu schreiben, dass dann nur in Ahnenblatt läuft, sonst keinen Mehrwert hat, welches ich genauso für beliebige Gedcom Dateien als externes Programm schreiben kann.

Warum sollte man sich durch eine schlecht dokumentierte Schnittstelle quälen, wenn man in einem separaten Programm alle Freiheiten hat und versionssicher ist?

Gruß
Martin

es zwingt dich keiner, ein Plugin zu schreiben, weder mit guter , noch mit schlechter Doku ... - ebenso zwingt dich keiner, überhaupt eines zu verwenden.
Aber du könntes es als Ansporn nehmen, die vorhandene Doku zusammenzufischen und daraus eine "gute" zu machen.


Nun ernsthaft: Die Frage, ob solch ein Plugin in die innere Struktur eines Programmens eingreifen darf oder soll, entscheidet der Entwickler. Es gibt gute Gründe, dies nicht zu erlauben! Ich würde es auch nur ungern erlauben, da selbst bei Freizeichnung beliebig Probleme auf den Entwickler zurückschlagen könnten.


Bei all deiner Argumentation hast du einen Punkt übersehen, der deinen Vorstellungen sehr nahe kommt. Wie ich geschrieben habe exportiert AB an der Schnittstelle csv- oder gedcom-Dateien. Die kannst du beliebig manipulieren und diese wieder mit AB einlesen. Bei geschickter Konstruktion deiner Schnittstellenbeschreibung (ABP) ist es vermutlich sogar möglich, das in einem Fluß wieder nach Ahnenblatt zurück zu bringen.

Einfach mal diese grottenschlechte ( ) Doku feinsinig lesen.

------------------------------

Ergänzung:
Eventuell ist dir entgangen, dass AB die Daten während des Programmlaufes im Speicher hält, diese erst auf Anforderung speichert.
Ich glaube nicht, dass es sinvoll ist, in die interne Datenstrukturen einzugreifen (soweit vom System überhaupt zugelassen). Klar, AB speichert vor dem Aufruf der plugins die Daten, müsste diese jedoch nach Rückkehr erneut einlesen. Sinnvoll?

[Fridolin]

Ich habe noch eine Frage:
Bei den Optionen zum Tafeldruch heißt es:
"Anzahl der Personentexte, der verkleinert werden darf"
Was bedeutet das?

Ahnenblatt braucht für eine Tafel ziemlich viel Platz. Damit es aber immerhin einheitlich aussieht, ist jeder Personenrahmen gleich groß.

Na gut, aber die Inhalte, die wiedergegeben werden sollen, sind mal mehr mal weniger. Wolltest du sie fürs Lesen optimieren, könntest du sagen: In jedem Personenrahmen soll die Schrift jeweils genau so groß sein, wie es nur irgend geht - das würde dann auf 99% Verkleinerung hinauslaufen und nur ein ganz kurzer Eintrag hätte eine sehr große Schrift.

Das sieht aber schon wieder nicht einheitlich aus. Gleiche Schriftgröße für alle erreichst du mit 0% Verkleinerung. Alle Namen kommen dann in einer Schriftgröße, die auch für "Antonia Elvira Mendez de Sousa Carvalho e was-weiß-ich" reicht - dann musst du eine Lupe mitliefern fürs Betrachten.

Kompromisse liegen also typischerweise dazwischen: Die längsten Namen dürfen verkleinert werden, der Rest wird in gleicher Schriftgröße dargestellt. Was da vernünftig aussieht, hängt u.a. von deiner Familie ab. Ich hab da glaube ich 15% oder so.

[Georgalt]

Herzlichen Dank, Fridolin !

[theobald]

Hallo in die Runde,

interessante Diskussion hier.

Bevor ich hier in meinem etwas lustig-ironischen Hausaufsatz einige Ansichten darlege, will ich vorausschicken, dass ich Ahneblatt als sehr gelungen ansehe. Es ist praktisch, es ist intuitiv und es ist sehr umfangreich. Das schreibe ich, damit nicht der Eindruck entsteht, dass ich hier abnörgeln will. Es ist eine prima Software! Und ich bezahle auch 59 Eur oder mehr dafür - das wäre kein Thema. Nur um das mal vorweg zu schicken. Wie sagt man so schön, achtung Spolier! Wer keine Kritik lesen möchte, bitte hier aufhören zu lesen: Jetzt kommt also etwas herzliche Kritik :

Ich möchte Martin-D zuerst einmal vollumfänglich zustimmen. Eine ähnliche Diskussion hatte sich schon hier in meinem Thred ergeben.
Ein Plugin sollte über die ihm angebotene Schnittstelle weitgehend Zugriff auf die Datenhaltung und möglw. auch auf einige Funktionen des zugrundeliegenden Systems erhalten. Das macht nun mal ein Plugin (fachlich genauer ist es ein Objekt/Dienst hinter einem Interface) aus. Im Grunde schränkt ja bereits der Entwickler / resp die Entwicklerin durch seine Gestaltung des Interfaces den Zugriff per definitionem ein. Er/sie kann durchaus wichtige Mehrwerte der Software durch das Interface verbergen und nur den Zugriff auf die Rohdaten (ich meine hier die vom Benutzer / der Benutzerin eingepflegte "eigene"! (Stammbaum-) Daten zulassen. Da wir hier aber nicht bei Microsoft sind oder über das Rippen von 4k-BlueRays sprechen, wäre das Anführen eines Grundes zum Verbergen oder Verschlüsseln von Funktionen in Ahnenblatt nicht plausibel...

(vorsicht Ironie:) Wir ich aber sehe, definieren die Experten "Plugin" und "Interface" hier aber abweichend...

Das ist kein Problem Ich bin immer offen für einen Austausch...

Technisch: Die Plugin-Schnittstelle ist nicht gedacht, in die innere Struktur von Ahnenblatt einzugreifen, dort (in der Datenbank) Änderungen vorzunehmen - warum auch?

Ist nicht genau das der Sinn eines Plug Ins, die internen Daten oder deren Anzeige zu ändern und so zur Laufzeit Änderungen und Erweiterungen vorzunehmen die es nicht oder noch nicht gibt?

(vorsicht Ironie): Ich kenne keine Interfaces, die in die innere Struktur einer Software derart eingreifen, dass sie Änderungen daran vornehmen können. Man kann über Interfaces nur bereits angelegte Funktionalitäten nach Außen öffnen, um sie anderen Softwarekomponenten zugänglich zu machen. In der Regel tut man das, damit sie der äußere Anwender / Caller / User / Dienst was auch immer, nicht noch einmal selbst implementieren muss... Es ist also eine unrichtige Auffassung aus der Sicht der Informationstechnik, dass durch ein Interface "in die innere Struktur von Ahnenblatt" eingegriffen wird. Es wird nur ein Teil der inneren Struktur (wenn ich mich dieser Terminologie hier einmal anschließen möchte ) nach Außen hin nutzbar gemacht.

Das Konzept des Interfaces wurde ja prinzipiell entwickelt (wurde notwendig), um Isoloation und Kapselung zu ermöglichen (besser, um Kapselung definiert zu durchbrechen). Ich will aber nicht ausschweifen, kann man alles im Kompendium Informatik lesen...

dann folgt aber noch ein sehr wichtiger Halbsatz:

...in die innere Struktur von Ahnenblatt einzugreifen, dort (in der Datenbank) Änderungen vorzunehmen - warum auch?

1. eine technische Rückfrage oder eine Empfehlung mit - warum auch? - zu beantworten ist grundsätzlich nicht sinnvoll...
2. und in der Datenbank Veränderungen vorzunehmen?? Also. Darum geht es ja gerade: In meinem Post oben, hatte ich ja nach einem Lesezugriff und nicht Schriebzugriff gefragt, um umfangreiche Kataloge auszuleiten. Die Antworten in dem Thread sind nun teilweise erhellend, teilweise auch wieder der Art: "warum auch??" Ich hatte ja dort geschrieben, das ich eine GEDCOM DB habe die 151.000 +-1000 Personen enthält. Der Hinweis auf einen CSV Export ist schon lustig. Der dauert auf meinem Hochleistungssystem mit 64GB RAM und vielen schnellen SSD mehr als 10min. Habe ich eine Änderung, dann gehe ich Kaffeetrinken. Nun, zugegeben! Das ist nicht die Alltagsanwendung von Ahnenblatt! und nochwas! Ahnenblatt arbeitet auch in diesem Bereich überaus stabil! Das möchte ich hier ausdrücklich lobend erwähnen!

Also ein lesender Zugriff auf den (meinen eigenen?) Stammbaum ist hier offs. nicht gewünscht?! Verstehe ich das richtig? Man nennt das in der IT auch Gatekeeper-Prinzip... Ich hoffe sehr!, dass sich Ahnenblatt nicht der verbreiteten Unsitte anschließt (die kommerzielle Softwareanbieter verfolgen), nämlich die, dem Anwender / der Anwenderin eine Plattform zu bieten, in der er/sie ihre Daten gutwillig einpflegt, um sie dann durch schrittweise Kommerzialisierung und möglw. Verschlüsselung der DB dem Anwender schließlich irgendwann zu entziehen. Das wäre der falsche Weg!

Man kann dieses Verfahren bei Android und auch bei GoPRO kontinuierlich mitverfolgen. GoPro bietet beispielsweise eine einfach Android App für seine prima Kameras. Die Android App kann auch direkt die Fotos von der Kamera herunterladen. Aber sie sind nicht mehr zugänglich (nicht ohne Tricks) und obwohl es meine Fotos auf meinem Android-Gerät sind, kann ich nur durch Zukauf eines Abo-Paketes diese Fotos von meinem Android-Gerät wieder "frei" bekommen.

Diese Unsitte ist sehr beliebt (einige Genealogie-Plattformen machen das ja so, erst haben die User kostenlos ihre Daten eingepflegt und ab 01.07.xxxx ist dann nur noch der Abo-Zugang möglich und Du bist Deine Daten los!) und nicht Benutzerfreundlich... Aber ich denke, Ahnanblatt hat das nicht geplant - oder?

Ich zumindest verspüre keinen Drang ein Plug In zu schreiben, dass dann nur in Ahnenblatt läuft, sonst keinen Mehrwert hat, welches ich genauso für beliebige Gedcom Dateien als externes Programm schreiben kann.

und

Warum sollte man sich durch eine schlecht dokumentierte Schnittstelle quälen, wenn man in einem separaten Programm alle Freiheiten hat und versionssicher ist?

Dem kann ich nur zustimmen!

Also kurz und gut:
Ahnenblatt ist gute Software, mit viel Engagement erstellt, preiswert!, mehr als preiswert!, intuitiv bedienbar und stabil lauffähig! Das sei unbestritten!

Aber es hat auch noch viel unentdecktes Potential.

Und jetzt kommen wir in das Land der Träume. Ich darf mal träumen?

1. Vielleicht könnte man es auf .NET oder C# portieren? Nicht damit Microsoft davon was hat, sondern damit man möglw. eine Desktop-Basis bekommt, die langfristig gewartet wird und professionell ist. Meinetwegen kann man auch für eine langfristige Interoperabilität / Plattformunabhängigkeit Java verwenden...
2. Vielleicht könnte man den Einbau eines professionellen modernen Interfaces zu Word/Excel/OpenOffice erwägen?
3. Vielleicht könnte man langfristig eine modernere objektorientierte dynamischere Darstellung der Stammbaumansicht in Betracht ziehen (so etwas gefällt mir sehr)
4. Das visuelle Interface könnte sich hier orientieren. Mit dieser Methode sind auch (genetisch) erbliche Properties (ich schreibe absichtlich nicht Krankheiten, man kann damit noch viel mehr vererben...) darstellbar (kann bisher keine Ahnensoftware!, wäre ein riesen Alleinstellungsmerkmal!), also Vater hatte Krebs, Kinder haben auch diese Disposition... (das ist auch nicht trivial, denn häufig fragt man sich, warum sterben alle Kinder im Alter unter 3 in dieser Stammlinie o.ä.?) Man kann damit auch nichtkrankheitsbezogene Properties vererben lassen, wie Vater war König von England, Sohn ist also Prinz von England etc.
5. jetzt was zum Forum. vllt. könnte man das Forum von Ahnenblatt etwas zugänglicher gestalten. (vorsicht Ironie!) Ich meine phpBB ist noch aus Vorkriegszeiten , most hacked und unhandlich. Da gibt es viele kostenlose, praktikablere, bessere Alternativen.
6. 2 x träum... Vielleicht könnte man das "Unternehmen Ahnenblatt" etwas öffnen. Also es gibt ja git. Heutzutage geht alles über git. Dort kann man der interessierten community möglw. durch sharing etwas Mitarbeiterplatz einräumen. Am Ende Entscheiden ja immer die Core-Entwickler über den Merge oder den Pull. Das ist bei großen Projekten wie Linux-Kernel o.ä. überall so. Teilhabe ginge meinetwegen durch ein gut dokumentiertes Interface, worauf sich die Freaks konzentrieren können. Da könnte man dann prima eigene Plugins aufsetzen. Die müssen ja nicht gleich in die DB schreiben dürfen... und letzlich wäre das aber auch kein Problem mit dem Schreiben. Mal so gesagt: Wer sich seinen Datenbestand zerschießen möchte, der darf das doch tun - oder? Wenn ich Software entwickle, oder auch nur, wenn ich Normaluser bin: Ich selbst habe immer zwei Sicherheitskopien hier liegen und nicht nur die von Ahnenblatt erstellten! Also da gibts doch eigentlich kein Problem - auch nicht mit dem Support... jedem steht es Frei den Hausgeist del C:\*.* zu rufen

Soweit mein Hausaufsatz!

Herzliche Grüße vom
Theo

[Fridolin]

Hallo Theo,

ich denke, dass deine Ausführungen für den einen oder anderen Nutzer hier sehr willkommen sind - hier gibt es einige, die technisches Verständnis haben. Ich gehöre nicht wirklich dazu. Meine einzige Programmier-Veranstaltung, die ich vor 30 Jahren an der Uni belegt habe, habe ich nicht bestanden, weil die wenigsten Programme fehlerfrei liefen.

Ich persönlich halte die CSV-Schnittstelle für überholt. Würde aktuell dazu raten, mit dem GEDCOM-Output zu arbeiten, solange kein XML oder SQL zur Verfügung steht. Einen Zugriff auf die proprietäre Datenstruktur von Ahnenblatt halte ich deswegen nicht für notwendig - und bin trotzdem begeistert von der offenen Struktur des Ahnenblatt-Ökosystems. Aber klar: Wenn man wirklich von Plugins redet, dann wäre schon die Frage, was sie können sollen.

Was das Träumen angeht: Vielleicht bietet sich ein direkter Kontakt mit Dirk Böttcher an...

[Jürgen_Nordlicht]

Theo, Dein Hausaufsatz ist aus meiner Sicht, als nicht IT-Belasteter begeisterter AB User, sehr interessant, Dank Dir für Deine Träume.
Um mich nun nicht mit Datenstrukturen etc. zu sehr bloß zu stellen greife ich 2 Dinge auf:
1.
- 5. jetzt was zum Forum. vllt. könnte man das Forum von Ahnenblatt etwas zugänglicher gestalten. (vorsicht Ironie!) Ich meine phpBB ist noch aus Vorkriegszeiten Very Happy, most hacked und unhandlich. Da gibt es viele kostenlose, praktikablere, bessere Alternativen.
2.
- Fridolins Zeile - Was das Träumen angeht: Vielleicht bietet sich ein direkter Kontakt mit Dirk Böttcher an...

Dik schein hier im Forum nur recht gelegentlich zu lesen, wer schickt ihm diesen Thread ?

Damit zum Thema Forensoftware, an anderen Stellen schon mehrfach angeklungen, diese Forensoftware entspricht ja nun überhaupt nicht mehr den heutigen Möglichkeiten eines Forums.
Allerdings kann ich dazu allenfalls eine Finanzbeteiligung anbieten.

Womöglich stößt dieser Hausaufsatz durchaus auf Herrn Böttchers Interesse.... nutze seine mailadresse mit Hinweis auf diesen Thread.

[Bernd Görtz]

So wie es ist finde ich dieses Forum sehr hilfreich. Was wird denn sonst noch für den Erfahrungsaustausch gebraucht? Soll es ähnlich wie die GEDCOM-Foren umgestellt werden, die nach der Umstellung fast nur Austritte zu verzeichnen haben. Wir sind doch Genealogen und keine IT-Experten und wollen uns nicht mühsam durch "moderne" SW-Strukturen kämpfen.