Tabellenwidget für Tkinter - Spezifikation

[Michael Schneider]

Hallo allerseits,

hier also die etwas überarbeitete Zusammenfassung der bisher genannten Anforderungen: http://paste.pocoo.org/show/1596. Schaut mal drüber und kommentiert oder ergänzt. Ich denke, wir haben jetzt einen ganz ansehnlichen Funktionsumfang definiert und können dann morgen diesen Projektschritt abschließen. Ab Montag geht dann die Planung der Umsetzung und Schnittstellen los.
Da ich kein Projektplaner bin, korrigiert mich bitte, wenn ich was falsch angehe. Aber erwartet keinen MS-Project Plan von mir.

Übrigens brauche ich dann noch einen Grundstock von Programmierern, die Programmieraufgaben übernehmen würden. Ich habe das so gedacht, dass wir gemeinsam die Schnittstellen definieren, über die wir auf die Codeteile der anderen Entwickler zugreifen können, sowie die Aufgaben der einzelnen Bereiche. Sobald die Liste der Aufgaben steht, teilen wir die auf freiwilliger Basis auf die Programmierer auf. Jeder Programmierer ist dann selbst für seinen Abschnitt verantwortlich (Programmierung und Testen), auf dass er den gestellten Anforderungen entspricht.

Da die meisten von uns keine richtigen Programmierer sind, würde ich abschließend jede Implementierung hier im Forum diskutieren und optimieren, so dass letztlich ein wirklich effizientes Widget entsteht.

Ich bin sehr zuversichtlich, wenn wir das Projekt weiter so kooperativ und straff vorantreiben.

Viele Grüße,
der Michel

[Redprince]

Das Dokument sieht ja schon nach etwas aus, allerdings sind einige Features im Ansatz der Funktionsaufteilung nicht berücksichtigt bzw. es ist vollkommen offen, wie dies gehandhabt wird. Namentlich Import/Export, Verschieben per Drag & Drop - wird das in einem weiteren Widget implementiert, oder wie?
Wäre schön, wenn das aus dem Dokument hervorginge, wobei es ja ausreichend wäre zu sagen, dass nachfolgende Funktionsumfänge in einem dritten Widget untergebracht werden sollen; nur wegen der Übersicht.

Wenn es dann langsam ans Eingemachte geht, sollte man sich noch darüber im Klaren sein, wie die Kommunikation untereinander funktionieren soll. PN über das Board, e-Mail, IRC, Jabber/ICQ/..? Hier favorisiere ich definitiv den Kontakt via Mail, kleine Gespräche aber auch gern über IM.

[Michael Schneider]

Hi Redprince!

Das Dokument sieht ja schon nach etwas aus, allerdings sind einige Features im Ansatz der Funktionsaufteilung nicht berücksichtigt bzw. es ist vollkommen offen, wie dies gehandhabt wird.

Dieses Dokument ist tatsächlich noch nicht vollständig. Wie schon gesagt sollte es die erste geordnete Zusammenfassung aller bisher genannten Anforderungen sein. Wir sollten uns bei allen Beiträgen auf die genaue Itemnummer beziehen, dann ist es leichter, das upzudaten.

Ich würde als nächstes hinzufügen:

Item: mic 7 (Zellenauswahl per Maus)
Bei Klick auf eine Zelle, soll sie (wenn alle Bedingungen erfüllt sind) ausgewählt werden. Ohne Zusatztaste (Strg, Alt, Umschalt) ersetzt sie alle bisherigen Auswahlen. Ein Klick auf Spalten- oder Zeilenkopf wählt die ganze Spalte bzw. Zeile aus. Ein Klick auf den Schnittpunkt der Spalten- und Zeilenbeschriftungsreihe wählt alle Felder aus.

Item: mic 8 (Darstellung der Auswahl)
Ausgewählte Zellen werden vertieft dargestellt, als Defaultwert der Randstärke wird 3 definiert.

Sollten wir den Spalten-/Zeilenkopf der markierten Telle(n) auch hervorheben?

Item: mic 9 (Ändern des Zelleninhalts per Tastatur)
Doppelklick auf eine Zelle bzw. simple Tastatureingabe bei EINER ausgewählten Zelle startet die Eingabe von Text. Enter schließt die Eingabe ab und setzt den neuen Text ein, ESC bricht sie ab und belässt den alten String.

Item: mic 10 (Formeln)
Beginnt der Text einer Zelle mit einem "=", wird der folgende Teil als Formel interpretiert (eval?) und als Zellentext das Ergebnis ihrer Auswertung dargestellt.

Item: mic11 (Referenzen)
In Formeln (mic 10) können Referenzen auf andere Zellen vorkommen. Diese bestehen aus der Form "(Spaltenname:Zeilenname)"

Namentlich Import/Export, Verschieben per Drag & Drop - wird das in einem weiteren Widget implementiert, oder wie?
Wäre schön, wenn das aus dem Dokument hervorginge, wobei es ja ausreichend wäre zu sagen, dass nachfolgende Funktionsumfänge in einem dritten Widget untergebracht werden sollen; nur wegen der Übersicht.

Import habe ich ganz oben erklärt: Kombination aus Listen und Dictionaries. Export müssen wir noch genauer definieren (möchte wer?).
CSV Import/Export muss wirklich nicht noch vom Widget übernommen werden, wenn man diese freie Wahl der Eingabe hat - naja, eigentlich hast Du recht. Wenn das soweit was wird, dann können wir es für den DeluxeTable in den Funktionsumfang nehmen. Drag and drop ebenso.

Wenn es dann langsam ans Eingemachte geht, sollte man sich noch darüber im Klaren sein, wie die Kommunikation untereinander funktionieren soll. PN über das Board, e-Mail, IRC, Jabber/ICQ/..? Hier favorisiere ich definitiv den Kontakt via Mail, kleine Gespräche aber auch gern über IM.

Eigentlich wollte ich das hier machen, aber es wird wohl mehr Kommunikation nötig sein. Ich schlage vor, dass wir hier die Hauptthemen besprechen, einzelne Punkte per Mail (nur, wenn sich außer Dir und mir noch jemand beteiligt) und Diskussionen per Messenger.
Vielleicht sollten wir uns auch mal CVS- und weitere Team-Software ansehen, die mir damals von den Admins empfohlen wurde.

Grüße,
Michel

[Redprince]

Dieses Dokument ist tatsächlich noch nicht vollständig. Wie schon gesagt sollte es die erste geordnete Zusammenfassung aller bisher genannten Anforderungen sein.

Was mir spontan einfällt: Schön wäre für die nächste Version des Dokuments auch ein Titel sowie ein Inhaltsverzeichnis

Item: mic 7, Item: mic 8 und Item: mic 10 sind soweit OK, Item: mic 9 würde ich in dem Punkt erweitern, dass Drücken von Return bei einer Zelle mit Fokus ebenso wie ein Doppelklick in den Editiermodus wechselt.

Beim Referenzieren (siehe Item: mic11) würde ich die Form anders wählen. Referenzen dürften häufig in Verbindung mit Formeln auftreten, welche aufgrund mathematischer Gegebenheiten auch runde Klammern enthalten können. Wegen der Übersicht des Endbenutzers würde ich eckige Klammern verwenden.

Sollten wir den Spalten-/Zeilenkopf der markierten Telle(n) auch hervorheben?

Ja, aber in anderer Form, als sie beim Fokussieren einer gesamten Spalte oder Zeile stattfindet! Ich denke hierbei gerade an das Wechseln des Schrifttyps auf italic.

Import habe ich ganz oben erklärt: Kombination aus Listen und Dictionaries.

Ich meinte mit Import eher das Einlesen von Daten aus CSV-Dateien etc. Direkte Übergabe an das Widget per Liste bzw. Dictionary ist natürlich sinnvoll.

Über die Vorgehensweise beim Interpretieren von Formeln (siehe Item: mic 10) sollten wir uns nochmal ausführlich Gedanken machen, wobei ich das wegen der potenziellen Komplexität eher ans Ende stellen würde.

[Redprince]

Ich habe mir noch einmal Gedanken über das Format beim Referenzieren gemacht (siehe Item: mic 11):
Einen Zeilennamen, wie von dir erwähnt, gibt es ja eigentlich nicht - lediglich eine Zeilennummer. Es wäre meiner Meinung nach klüger, nicht den Doppelpunkt als Seperator zu nehmen, da dieser eher dafür verwendet werden sollte, Zellengruppen wie in Excel zu bilden. Dies ist für angewandte Funktionen wie Mittelwert etc. ganz praktisch, wenn man z.B. die ersten zehn Zellen von X summieren will. Der Bindestrich könnte in diesem Kontext zwar anders gedeutet werden, würde meiner Meinung nach aber nur Verwirrung stiften.
Daher würde ich den Punkt als Trenner zwischen Spaltenname und Zeilennummer verwenden, den Doppelpunkt als Indikator für gruppierte Zellen und den Bindestrich gewohnt als mathematisches Symbol der Subtraktion.
Während ich ein wenig mit der von mir entworfenen Syntax gespielt habe, ist mir aufgefallen, dass wir prinzipiell weder runde noch eckige Klammern beim Referenzieren bräuchten. Die Formel wird eher unübersichtlich, allein das Parsen wäre intern ein wenig vereinfacht.

Ferner könnte man sich jetzt noch überlegen, ob man nicht über mehrere Widgetinstanzen hinweg referenzieren könnte..

Nachfolgend mal einige Beispiele zur Versinnbildlichung der Syntax:

Code: Alles auswählen

=Mittelwert(Namen.1:Namen.10)
=Summe(SpalteA.1:SpalteC.1)

Jetzt, wo ich mir das so angucke, bitte noch dies:

Item: red 8 (Funktionsnamen in Formeln)
Sämtliche Funktionsnamen sind einheitlich in Englisch formuliert.

Es wäre an dieser Stelle ganz nett, weitere Meinungen zu hören, da es mir langsam so vorkommt, als programmierten wir Excel nach und nicht nur ein Tabellenwidget.

[BlackJack]

Sieht für mich auch schon ein bisschen nach Tabellenkalkulation statt Widget aus. Der Tabellenkalkulationsteil gehört IMHO nicht in die GUI, der muss auch ohne Grafik funktionieren.

[Mr_Snede]

Sieht für mich auch schon ein bisschen nach Tabellenkalkulation statt Widget aus. Der Tabellenkalkulationsteil gehört IMHO nicht in die GUI, der muss auch ohne Grafik funktionieren.

Dem kann ich mich nur anschließen. Was ich mir als Funktionsumfang vorstelle habe ich ja schon geschrieben.

Können wir die Planungsseite in einem Wiki ablegen. Da kann man sie dann einfacher überarbeiten. Kann ein von mir betriebenes DokuWiki anbieten oder wir nehmen das PythonWiki.de.

Eine Versionsverwaltung(svn) wäre schon nett.

Komunikation kann über dieses Forum und Jabber laufen.

[Redprince]

Können wir die Planungsseite in einem Wiki ablegen. Da kann man sie dann einfacher überarbeiten. Kann ein von mir betriebenes DokuWiki anbieten oder wir nehmen das PythonWiki.de.

Eine Versionsverwaltung(svn) wäre schon nett.

Klingt gut! Um also den ursprünglich geplanten Umfang eines Widgets nicht zu sprengen, schlage ich vor, folgende Items nicht zu berücksichtigen:

• Item: mic 10
• Item: mic 11
• Item: red 5
• Item: red 8

Wenn nichts weiter gegen den Vorschlag von Mr_Snede spricht, die Planungsdokumente zu verlagern, wäre eine neue Version in neuer Umgebung (dann mit Titel & Inhaltsverzeichnis ) wünschenswert!

[Mr_Snede]

Das ist nun die Wikiseite:
--> [wiki]ZusammenfassungPlanung[/wiki]

Vorm Schlafengehen war nichts hübscheres drin ;-)

[Michael Schneider]

Hallo,

nur kurz, weil ich etwas in Eile bin:

Erstmal vielen Dank für die schnelle Umstrukturierung. Es ist natürlich vorteilhaft, wenn alle Beteiligten selbst Hand anlegen können. In die Verwendung von Versionsverwaltungen muss ich mich noch einarbeiten, da habe ich gar keine Ahnung, wofür die gut sind und wie sie funktionieren.

Meine neuen Items (die nach der Idee des DeluxeTables kamen) sind für diesen gedacht, nicht als Element der ersten beiden Klassen!! Ich habe sie entsprechend Redprinces Anfrage aufgeschrieben, dass wir erstmal alle möglichen Requirements sammeln - wir können die Funktionsumfänge der einzelnen Klassen dann frei festlegen. In meiner Zusammenfassung habe ich das unter Item 6 schon einmal vorschlagartig aufgeteilt. Und wie gesagt kommt die Deluxe-Version erst dann, wenn das grundlegende Anzeige-Widget (Base) und die leicht editierbare Version (Editable) fertig sind. CSV Import und Export ist ein Gimmick für eine high-level Erweiterung der Klassen.

Eine weitere Frage, die ich mir stellte, war: sollte man bei der Editable Variante die Werte als Seiteneffekt direkt in der Eingabeliste /-dict ändern, so dass man von außen jederzeit ohne extra Ausgabeaufruf auf die aktuellen Daten zugreifen kann? Oder sollte man die Ausgabe strikt an eine Funktion binden, die den Inhalt der Auswahl oder einfach alles zurückgibt?
Da wir für alle Zellen Metadaten (Farbe, Schriftart, ...) benötigen, werden wir wohl ohnehin intern mit eigenen Tabellen arbeiten müssen und können nicht NUR mit den Eingabedaten operieren.

Grüße,
Michael

[Redprince]

Eine weitere Frage, die ich mir stellte, war: sollte man bei der Editable Variante die Werte als Seiteneffekt direkt in der Eingabeliste /-dict ändern, so dass man von außen jederzeit ohne extra Ausgabeaufruf auf die aktuellen Daten zugreifen kann? Oder sollte man die Ausgabe strikt an eine Funktion binden, die den Inhalt der Auswahl oder einfach alles zurückgibt?

Auch hier würde ich strikt den durch Tkinter vorgegebenen Weg folgen: Inhalte von Entrys werden via get() und insert() verändert, zwecks intuitiver Programmierung sollten wir da nicht abweichen.

[Michael Schneider]

Eine weitere Frage, die ich mir stellte, war: sollte man bei der Editable Variante die Werte als Seiteneffekt direkt in der Eingabeliste /-dict ändern, so dass man von außen jederzeit ohne extra Ausgabeaufruf auf die aktuellen Daten zugreifen kann? Oder sollte man die Ausgabe strikt an eine Funktion binden, die den Inhalt der Auswahl oder einfach alles zurückgibt?

Auch hier würde ich strikt den durch Tkinter vorgegebenen Weg folgen: Inhalte von Entrys werden via get() und insert() verändert, zwecks intuitiver Programmierung sollten wir da nicht abweichen.

Das ist Tkinters strikt vorgegebener Weg? Also ich bevorzuge bei Entries die Verwendung von StringVar Objekten. Auf die Änderung der Variable kann man per Methode warten und man kann die Variable mehrfach verwenden, z.B. in einem Label und gleichzeitig im Entry für die Änderung.

Aber für das direkte Setzen und Holen von Werten sollten wir dieser ungeschriebenen Konvention natürlich folgen.

Grüße,
Michael