Tabellenwidget für Tkinter - Spezifikation

[Michael Schneider]

Hallo Freunde des gehobenen Programmierens!

Wie der Thread http://www.python-forum.de/topic-10673.html unterschwellig andeutet, gibt es im Standard-Widgetsatz von Tkinter kein Tabellenwidget. Da es aber fast so häufig nachgefragt wird wie ein Baumwidget, sollten wir als Python-Gemeinde unseren Beitrag zur Vervollständigung leisten. Meine Meinung.

Deshalb wollte ich hiermit die Entwicklung starten und als erstes die Requirements für ein Tabellenwidget sammeln. Ich fange schonmal an und erwarte dann eure Meinung, Verbesserungs- und Ergänzungsvorschläge. Was letztlich genommen wird, können wir dann entscheiden.

Requirement (Req. #) - Beschreibung
========================
Item: mic 1
Die Tabelle muss in einem konstanten, rechteckigen Feld ausgeführt werden. Veränderungen der Spaltenbreite oder Zeilenhöhe darf das gesamte Widget weder verschieben noch in der Größe verändern (wie, wenn man eine Grid-Manager in einem Frame verwendet)

Item: mic 2
Es wird automatisch oder manuell ein Nutzungsbereich der Tabelle definiert. Der automatische Bereich umfasst die Felder A1 (oben links) und ist x Felder breit sowie y Felder hoch. x entspricht der Elementzahl des breitesten Datensatzes, y der Anzahl der Datensätze in der Tabelle.
Beim manuellen Nutzungsbereich wird der Arbeitsbereich begrenzt, so dass man nicht weiter nach rechts oder unten kommt.
Frage: kann man das so verbinden, oder sollte man es doch besser trennen, um auch für automatische Nutzungsbereichswahl einen festen Arbeitsbereich zu definieren?

Item: mic 3
Es muss "Scrollbars" am rechten und unteren Rand geben, die automatisch auf den genutzten Tabellenabschnitt dimensioniert werden. Zusätzlich müssen sie ermöglichen, wie in Excel auch über das Ende des genutzten Bereichs zu scrollen.
Frage: sollen sie immer sichtbar sein, nur wenn der Nutzungsbereich größer ist als der sichtbare Ausschnitt oder soll das als Option gelassen werden?

Item: mic 4
Spaltenbreiten sollen einen Vorgabewert haben, aber auch vom Anwender änderbar sein.

So, das ist erstmal ein erster Schritt. Ist natürlich nicht alles, was ich dazu zu sagen habe, sollte aber vorerst Stoff für eine (Grundsatz-?)Diskussion geben.

Nun seid ihr gefragt, was erwartet ihr von einem Tabellenwidget? Eure Vorschläge mit eurem Kürzel und der Itemnummer - damit sie sich nicht überschneiden. Ihr könnt die Itemnummern auch "versionieren" (mic 1.1), um die spätere Auswahl zu ermöglichen.

Gruß,
Michel

[Michael Schneider]

Hallo,

auch wenn der eine oder andere (Blackbird? ) jetzt die Augen verdrehen wird: es gibt noch einige Institutionen, die Python 2.2 verwenden und die ebenfalls von dem Widget profitieren sollten. Daher:

Item: mic 5
Das Widget soll mit Python 2.2 kompatibel sein. D.h. Vermeidung der builtin-Funktion sorted sowie aller Argumente von list.sort(), etc.
Hier bin ich aber gesprächsbereit (darum soll), wenn es zu viele Nachteile birgt. Dann muss man eben eine Extraversion für 2.2 erzeugen

Dieses Requirement wird sicher für eine heftige Diskussion sorgen.

Grüße,
Michel

[Redprince]

Warum muss es möglich sein, über den Rand des Nutzungsbereiches scrollen zu können (siehe Item: mic 3), obgleich dieser fest definiert ist (siehe Item: mic 2)? Ich muss mir doch nichts angucken können, was ich eh nicht bearbeite, oder?

Mein erster Vorschlag, bevor ich für die morgige Mathematikklausur lerne:

Item: red 1
Die (public) Widget-Methoden sollten weitestgehend die Namen derer erhalten, die schon in Tkinter implementiert sind, um eine intuitive Nutzung zu ermöglichen.

Item: red 2
Es sollten die üblichen Varianten des Exportierens bzw. Importierens ermöglicht werden, sprich CSV etc.

[Michael Schneider]

Hallo Redprince,

erstmal vielen Dank für Deine Vorschläge. Intuitive Bedienung sollte auf jeden Fall weitestgehend angestrebt werden.
Vielleicht sollten wir bezüglich der Funktionalitäten unterscheiden zwischen den grundlegenden Aufgaben des Tabellenwidgets und den Fähigkeiten eines Programms, das das Tabellenwidget nutzt. Ich finde, der CSV-Import und -Export holt an dieser Stelle etwas weit aus, da diese Funktionalität eher relativ selten benötigt wird. Es geht mir um das Widget zur Darstellung von Tabellen selbst. Wenn man das hat, sollte das Einlesen, Aufteilen und Einsetzen von CSV-Werten in wenigen Zeilen Code(vielleicht sogar einer) erledigt sein.

Viel Erfolg bei der Matheklausur!

Grüße,
Michel

[Redprince]

Vielleicht sollten wir bezüglich der Funktionalitäten unterscheiden zwischen den grundlegenden Aufgaben des Tabellenwidgets und den Fähigkeiten eines Programms, das das Tabellenwidget nutzt. Ich finde, der CSV-Import und -Export holt an dieser Stelle etwas weit aus, da diese Funktionalität eher relativ selten benötigt wird. Es geht mir um das Widget zur Darstellung von Tabellen selbst. Wenn man das hat, sollte das Einlesen, Aufteilen und Einsetzen von CSV-Werten in wenigen Zeilen Code(vielleicht sogar einer) erledigt sein.

OK, da habe ich möglicherweise zu weit gedacht. Diese Funktionalität hätte ich sowieso erst für das Ende der Arbeiten am Widget angestrebt, ist aber wohl tatsächlich hinfällig.

Item: red 3
Sortieren der Zeilen sollten Spaltenweise on the fly durch einfaches Klicken auf den Spaltennamen möglich sein. Wichtig hierbei ist meiner Meinung nach, dass man nicht nur nach einer Spalte sortieren kann, sondern zur weiteren Sortierung weitere Spalten hinzuziehen kann, wobei man sich Gedanken machen müsste, ob die Sortierreihenfolge gemäß der Anklickreihenfolge ausreichend oder eher verwirrend ist.

Wie aber siehst du den Fall mit dem eingeschränktem Scrollbereich? Habe ich da etwas übersehen, oder hast du in die falsche Richtung gedacht?
Ich bin übrigens der Meinung, dass Scrollbars nur dann sichtbar sein sollten, so sie auch gebraucht werden, da ich mich persönlich immer gerne durch solche verwirren lasse, die keinen Nutzen haben.

Eventuell wäre eine das Verschieben dieses Threads in das Ideen-Subforum sinnvoll, da wir hier ja kein explizites Problem mit Tkinter angehen, sondern aufgrund des nicht mitgelieferten Widgets eher ein implizites

Hast du dir schon den Kopf darüber zerbrochen, ob und wie eine Dokumentation des Widgets erfolgen soll? Simple Docstrings, oder die Richtung Doxygen & Co?

Viel Erfolg bei der Matheklausur!l

Danke, der sollte aber gegeben sein, da die die zwei Aufgaben lediglich die Bearbeitung einer Extremalwertaufgabe sowie der Kurvendiskussion einer Sinusfunktion mit Derive erfordern.

[Redprince]

So, nach ein wenig Sport noch zwei Dinge:

Item: red 4
Nach Markieren einer beliebigen Anzahl von Zellen sollte deren Inhalt sowohl horizontal wie vertikal per Drag & Drop verschoben werden können.

Item: red 5
Referenzieren von Zellen untereinander, sprich der Inhalt von Zelle A wird in Zelle B dargestellt; Unterstützen einfacher Formeln wie Zelle A + 5 und Implementierung einfacher Funktionen wie Summe, Mittelwert, ..

Wobei Item: red 5 erst einmal niedrige Priorität hat, aber meiner Meinung nach ein sehr hübsches Feature wäre, jedoch sollte bei einem vernünftigen Klassendesign die Erweiterung in diese Richtung keine großen Probleme bereiten.

[schlangenbeschwörer]

Hi!
Vlt. ist es etwas untergegangen, aber ich programmiere schon seit einer Weile an einer solchen Tkinter-Tabelle.
Hier ist ein Ansatz:
http://www.python-forum.de/topic-11041.html

Wobei ich jetzt schon wieder weiter bin. Ich fänds etwas blöd, wenn das jetzt so unbeachtet bleibt, und ihr das nochmal macht.
Es funktioniert jedenfalls und man kann meine Tabelle vlt. angucken, und gucken, ob man sie nicht (zumindest teilweise) weiterverwenden könnte.
Ich hab jetzt auch noch ein paar Fehler behoben...
Leider kann ich da jetzt erstmal nichts mehr zu sagen oder mithelfen, das jetzt erstmal Urlaub gibt. Ich könnt mein Script aber gerne verwenden...

Gruß, jj

[Redprince]

Ich fänds etwas blöd, wenn das jetzt so unbeachtet bleibt, und ihr das nochmal macht.

Michael hat das Widget ja als Community-Projekt geplant, und die besteht ja nicht nur aus uns beiden, also lässt sich hier bestimmt eine Lösung finden, mit der alle zufrieden sind. Ich weiß ja nicht, in wie weit deine Vorstellungen mit den bisher von uns zusammengetragenen übereinstimmen. Gedacht waren diese ja seitens Michael als Diskussionsgrundlage, also kannst du deinen Senf selbstverständlich dazugeben, sofern du magst - schaden wird es nicht.

Prinzipiell wäre es sicher ganz klug, sich deinen Code anzusehen, nachdem diese Spezifikation vorerst fertig ist. Dann könnte man abwägen, welche Teile deiner Arbeit als Vorlage oder Grundlage dienen sollen. Ich fände es schade, wenn wir deinen Ansatz über den Haufen rennen, aber am Ende sollten wir im Auge behalten, dass wir nicht Code verwenden, obschon es der Spezifikation entspricht, bloß weil der Code schon besteht.

Beim kurzen Antesten deines Widgets sind mir noch zwei Ideen gekommen:

Item: red 6
Die farbliche Gestaltung sollte variable sein und sich wiederum an den typischen Methoden- und Parameternamen von Tkinter orientieren.

Item: red 7
Man sollte auswählen können, ob und wie ein Raster dargestellt wird.

[Mr_Snede]

Ich fände es super, wenn dabei was rauskommt.

Aber ich würde nicht versuchen, von vornherein alles zu implementieren, was einem in Den Kopf kommt.
Viel mehr würde ich gerne den absolut grundlegensten Funktionsumfang definieren,
der für so ein Widget nötig ist.

Das ist für mich:

- 1. Ich möchte einfach dem Widget beim Aufruf (und nachträglich per configure)
eine Liste mit Strings für die Überschriften und eine 2-dimensionale Liste für die Daten übergeben.

- 2. Ich will einfach auf einzelne Zellen, Spalten und Zeilen zugreifen können
-- 2.1 um den Inhalt zu ändern, bzw das Erscheinungsbild zu beeinflussen
-- 2.2 um den Inhalt auszulesen (Spalten und Zeilen sond dann natürlich Listen)

- 3. Scrollbars sollen erscheinen, wenn der Tabelleninhalt größer als der Anzeigebereich ist. Eine Option für um die Scrollbars immer ein zu schalten kann ich mir auch vorstellen.

- 4. Resize sollte so funktionieren, wie der verwendete Layoutmanager es vorgibt.
-- 4.1 wird der Elternframe größer als die Tabelle gezogen werden, sollten sich alle Felder gleichmäßig vergrößern

[Michael Schneider]

Hallo!

Da sich einiges getan hat, seit heute morgen, werde ich mal pauschal antworten.

Erstmal der Nachtrag zu meiner ersten Antwort an Redprince: das automatische Vergrößern an den Grenzen habe ich von Excel. So ist es zum einen möglich, den Schlitten der Scrollbars zu ziehen, um über den aktuellen Bereich zu scrollen. Aber zusätzlich soll man auch problemlos in neue Bereiche kommen können, wenn man beispielsweise eine weitere Spalte benötigt.
Die Frage nach dem richtigen Unterforum habe ich mir auch schon gestellt. Aber ich hielt das Ideen-Unterforum entsprechend seiner Beschreibung für zu global. Es geht hier, auch wenn nur intern, um Tkinter ganz speziell und soll deshalb genau die Leute ansprechen, die damit zutun haben. Kurz: es soll auch von den Fachleuten und Hilfesuchenden gelesen werden.
Für die Doku halte ich die Docstrings für hinreichend, vielleicht ergänzt durch eine Erläuterung (Modul-Docstring).

@Schlangenbeschwörer: Dein Ansatz ist mir tatsächlich entgangen, es war also nicht böse gemeint. Es geht mir bei diesem Projekt aber, wie es eigentlich bei Softwareentwicklung sein sollte, um die Reihenfolge
Planung -> Umsetzung
Das heißt, ich wollte bei der Ideensammlung bewusst von evtl. Ansätzen Abstand nehmen und erstmal fixieren, was grundlegend benötigt wird. Mithin würden wir gern die wichtigen Aspekte Deines Ansatzes aufgreifen und je nach fertigem Spec auch auf vorhandenen Code zurückgreifen.

Prinzipiell deutet sich das Problem an, dass man verschiedene Stufen von Funktionalität unterscheiden muss. Was ist grundlegend, um möglichst schnell und einfach Zahlen in Tabellenform scrollbar auf den Bildschirm zu bringen. Ich nenne das mal "lightweight". Darauf basierend kann man dann (einfache) Funktionen einbauen wie Selektieren, Manipulieren, evtl. Verschieben per DnD usw. - die eben über die z.B. von Mr. Snede benannten Grundfunktionen hinausgehen. An dieser Stelle nochmal ein Dankeschön für die klare Übersicht.
Ich denke, das kann man sehr gut durch Klassen unterschiedlicher Ausbaustufen implementieren, ähnlich den HTTPServern (Base-, Simple-, CGIHTTPServer). Das hat auch den Vorteil, dass die einzelnen Stufen nicht durch Code überladen werden. Wenn man als Anwender nur etwas darstellen möchte, reicht das "lightweight", sonst kann man auch schwere Geschütze auffahren.

Die weiteren Ideen finde ich auch sehr gut. Vor allem für das Sortieren sollten wir uns eine einfache aber effiziente Lösung einfallen lassen, wie z.B. eine Liste von Sortierfeldern, wobei der zuletzt angeklickte Spaltenkopf vorn angefügt wird. Dann wird die Tabelle nach den Einträgen dieser Sortiertabelle sortiert, zuletzt ausgewählte Spalte zuerst.

Aufgrund der doch schon fortgeschrittenen Stunde und dem Umstand, morgen (nachher) auch arbeiten zu müssen, werde ich die Zusammenfassung aller bisher genannten Requirements in einer Liste auf morgen verschieben.

Ich danke euch allen für die rege Beteiligung, eure Ideen sind super und ich habe das Gefühl, dass dieses Projekt echt was wird.

Viele Grüße,
der Michel

ps. Man, was'n trockener Text... wenn das hier noch jemand liest, dann erhalte er/sie mein Kompliment fürs Durchhaltevermögen.

[Michael Schneider]

Warum muss es möglich sein, über den Rand des Nutzungsbereiches scrollen zu können (siehe Item: mic 3), obgleich dieser fest definiert ist (siehe Item: mic 2)? Ich muss mir doch nichts angucken können, was ich eh nicht bearbeite, oder?

Hi Redprince,

diese Bedingung habe ich irgendwie "überlesen". Das würde natürlich nur beim Autoscrolling gehen (siehe mic 2), wenn keine Maximalgröße festgelegt ist. Darum die Frage, ob man die Maximalgröße und den Scrollbereich trennen sollte. Denn es ist ja unsinn, einen Maximalbereich von 1000x10000 vorzugeben und nachher kein Gefühl mehr in den Scrollbars zu haben.

Ich denke, wir sollten uns auch schonmal erste Gedanken über die Randbedingungen machen, für die das Widget ausgelegt ist.
Als Übergabeparameter habe ich mir eine Kombination aus Listen oder Dictionaries, jeweils von Listen oder Dictionaries überlegt. Bei Dictionaries werden die Datensatznummern bzw. Spaltenbezeichnungen als Schlüssel gespeichert, bei Listen wird stumpf abgezählt.

Die einfachste Version wäre eine übernommene Liste. Deren Datensätze könnten dann bequem "in list" per list.sort(key=k, reverse=True/False) sortiert werden. Dabei wäre k ein Tupel oder eine Liste mit den Spaltenwerten, nach denen gesucht wird. So kann mit minimalem Aufwand nach mehreren Kriterien sortiert werden. Das geht aber nur, solange die Daten der Ausgangsliste ausreichen. Sobald Metadaten wie Datensatzindex oder Zellenformatierungen dazukommen, wird es ohnehin komplexer.

Zusammenfassung folgt heute Abend.

Grüße,
Michael

[Redprince]

Vor allem für das Sortieren sollten wir uns eine einfache aber effiziente Lösung einfallen lassen, wie z.B. eine Liste von Sortierfeldern, wobei der zuletzt angeklickte Spaltenkopf vorn angefügt wird. Dann wird die Tabelle nach den Einträgen dieser Sortiertabelle sortiert, zuletzt ausgewählte Spalte zuerst.

Ich halte diese Reihenfolge für falsch. Ausgehend von einer unsortieren Tabelle klicke ich doch nicht die Felder in umgekehrter Sortierreihenfolge an, oder? Ich klicke auf Spalte B, weil ich danach sortieren will. Schließlich soll noch nach Spalte C sortiert werden.

Darum die Frage, ob man die Maximalgröße und den Scrollbereich trennen sollte. Denn es ist ja unsinn, einen Maximalbereich von 1000x10000 vorzugeben und nachher kein Gefühl mehr in den Scrollbars zu haben.

Dem stimme ich zu. Eventuell wäre ein Parameter für das Widget sinnvoll, der indiziert, ob die Größe verändert werden darf oder nicht. Neben dem vom Widget festgelegtem Defaultwert für die Größe kann der Anwender darüber entscheiden, wobei die Scrollbars sich daran orientieren. Wenn angegeben wird, dass man den Bereich manipulieren darf, kann über den vorhandenen Bereich gescrollt werden.

Ich denke, das kann man sehr gut durch Klassen unterschiedlicher Ausbaustufen implementieren, ähnlich den HTTPServern (Base-, Simple-, CGIHTTPServer). Das hat auch den Vorteil, dass die einzelnen Stufen nicht durch Code überladen werden. Wenn man als Anwender nur etwas darstellen möchte, reicht das "lightweight", sonst kann man auch schwere Geschütze auffahren.

Die Idee gefällt mir sehr gut, wobei wir uns dann allerdings recht genaue Gedanken darüber machen sollten, wie wir die zu implementierenden Funktionen staffeln.

Ich danke euch allen für die rege Beteiligung, eure Ideen sind super und ich habe das Gefühl, dass dieses Projekt echt was wird.

Bis jetzt musste man ja nur schreiben, was man gerne hätte, das fällt selten schwer ins Gewicht. Gespannt bin ich auf die weitere (Zusammen-)Arbeit!

ps. Man, was'n trockener Text... wenn das hier noch jemand liest, dann erhalte er/sie mein Kompliment fürs Durchhaltevermögen.

Programme, die etwas weiter über Hello World! hinausreichen, benötigen nun einmal etwas exaktere Planung. Bloß weil man mal in einem Forum mehr als zehn Sätze pro Beitrag schreibt, sollte man sich eigentlich keine Sorgen machen müssen, ob diese noch verfolgt werden. Schließlich haben wir ja ein gemeinsames Ziel!

Ich kann momentan noch nicht absehen, ob ich heute Abend bei meiner Lebensgefährtin ins Internet komme, weshalb es durchaus möglich ist, dass ich mich erst morgen wieder melde.

[Michael Schneider]

Vor allem für das Sortieren sollten wir uns eine einfache aber effiziente Lösung einfallen lassen, wie z.B. eine Liste von Sortierfeldern, wobei der zuletzt angeklickte Spaltenkopf vorn angefügt wird. Dann wird die Tabelle nach den Einträgen dieser Sortiertabelle sortiert, zuletzt ausgewählte Spalte zuerst.

Ich halte diese Reihenfolge für falsch. Ausgehend von einer unsortieren Tabelle klicke ich doch nicht die Felder in umgekehrter Sortierreihenfolge an, oder? Ich klicke auf Spalte B, weil ich danach sortieren will. Schließlich soll noch nach Spalte C sortiert werden.

Das ist richtig und intuitiv korrekt, wenn ich eine Suchstruktur vor Augen habe. Dann kann ich aber auch einen Dialog öffnen und wie in Excel mehrere Kriterien angeben. Mein Ansatz zielte darauf ab, dass man in einer Übersicht "arbeitet". Ein Beispiel: ich habe eine Liste von Tieren. Ich sortiere nach Namen (oder suche) und finde so Felix die Katze. Jetzt möchte ich alle Katzen der Tabelle sehen, also klicke ich auf den Spaltenkopf Tierart und finde alle Kater. Jetzt sehe ich, dass ein Kater krank ist und per Klick auf den entsprechenden Tabellenkopf finde ich alle Tiere, die auch krank sind. So gehe ich zumindest bei Wikipedia vor, wenn ich einfach nur mal stöbere.
Wenn ich so darüber nachdenke, ist diese Funktion zwar in gewissen Situationen sinnvoll, kommt aber nicht so häufig vor wie Deine Variante.

Darum die Frage, ob man die Maximalgröße und den Scrollbereich trennen sollte. Denn es ist ja unsinn, einen Maximalbereich von 1000x10000 vorzugeben und nachher kein Gefühl mehr in den Scrollbars zu haben.

Dem stimme ich zu. Eventuell wäre ein Parameter für das Widget sinnvoll, der indiziert, ob die Größe verändert werden darf oder nicht. Neben dem vom Widget festgelegtem Defaultwert für die Größe kann der Anwender darüber entscheiden, wobei die Scrollbars sich daran orientieren. Wenn angegeben wird, dass man den Bereich manipulieren darf, kann über den vorhandenen Bereich gescrollt werden.

Wenn man über die praktische Anwendung nachdenkt, dann ist dir Tabellenbereich so wie so von den übergebenen Listen abhängig. D.h. man ändert die Tabellengröße meist nicht aus der Tabelle heraus, sondern über die übergebenen Updatelisten. Da reicht es aus, wenn man die stumpf anzeigt und die Scrollbars über den dargestellten Bereich dimensioniert, oder? Sollten die Tabellen doch mal dynamisch geändert werden, muss sich eben die Anwendung darum kümmern.

Ich denke, das kann man sehr gut durch Klassen unterschiedlicher Ausbaustufen implementieren, ähnlich den HTTPServern (Base-, Simple-, CGIHTTPServer). Das hat auch den Vorteil, dass die einzelnen Stufen nicht durch Code überladen werden. Wenn man als Anwender nur etwas darstellen möchte, reicht das "lightweight", sonst kann man auch schwere Geschütze auffahren.

Die Idee gefällt mir sehr gut, wobei wir uns dann allerdings recht genaue Gedanken darüber machen sollten, wie wir die zu implementierenden Funktionen staffeln.

Das sollten wir so wie so. Zum Lastenheft gehört meiner Meinung nach auch eine Interfacebeschreibung, die genau festlegt, wie die Teile der Mitarbeiter zusammenwirken.

Ich danke euch allen für die rege Beteiligung, eure Ideen sind super und ich habe das Gefühl, dass dieses Projekt echt was wird.

Bis jetzt musste man ja nur schreiben, was man gerne hätte, das fällt selten schwer ins Gewicht.

Da bin ich mal anderer Meinung: man muss von vornherein alle wesentlichen Aspekte beachten, weil eine spätere Änderung nur mit Problemen verbunden ist.

Ich kann momentan noch nicht absehen, ob ich heute Abend bei meiner Lebensgefährtin ins Internet komme, weshalb es durchaus möglich ist, dass ich mich erst morgen wieder melde.

Das überleg Dir aber nochmal. Du kannst die Zeit besser nutzen.

Bis morgen, die Zusammenfassung schaffe ich heute so wie so nicht mehr,
Michael

[hwm]

Hallo,

es gibt doch längst eine Table Widget für Tkinter:

http://sourceforge.net/projects/tktable/

[Mr_Snede]

Ja, TkTable kenne ich schon. Leider muss man auch die tcl/tk Lib installieren. ICh fände es echt schöner ein pures Tkinter Widget zu haben.

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