Tabellenwidget für Tkinter - Spezifikation

Fragen zu Tkinter.

Haltet ihr diese Art der "verteilten Entwicklung" im Forum für eine gute Idee?

Umfrage endete am Sonntag 1. Juli 2007, 07:15

Ja, das bringt was.
5
63%
Bin mir nicht sicher, mal abwarten was dabei rauskommt.
2
25%
Nein, das wird bestimmt nix (kleines vielleicht).
1
13%
 
Abstimmungen insgesamt: 8
Benutzeravatar
Michael Schneider
User
Beiträge: 567
Registriert: Samstag 8. April 2006, 12:31
Wohnort: Bremen
Kontaktdaten:

Tabellenwidget für Tkinter - Spezifikation

Beitragvon Michael Schneider » Donnerstag 21. Juni 2007, 07:15

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.
erste Requirements hat geschrieben: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
Diese Nachricht zersört sich in 5 Sekunden selbst ...
Benutzeravatar
Michael Schneider
User
Beiträge: 567
Registriert: Samstag 8. April 2006, 12:31
Wohnort: Bremen
Kontaktdaten:

Beitragvon Michael Schneider » Donnerstag 21. Juni 2007, 09:13

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
Diese Nachricht zersört sich in 5 Sekunden selbst ...
Redprince
User
Beiträge: 128
Registriert: Freitag 22. Oktober 2004, 09:22
Wohnort: Salzgitter
Kontaktdaten:

Beitragvon Redprince » Donnerstag 21. Juni 2007, 11:47

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.
I am not part of the allesburner. I am the allesburner.
Benutzeravatar
Michael Schneider
User
Beiträge: 567
Registriert: Samstag 8. April 2006, 12:31
Wohnort: Bremen
Kontaktdaten:

Beitragvon Michael Schneider » Donnerstag 21. Juni 2007, 12:36

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
Diese Nachricht zersört sich in 5 Sekunden selbst ...
Redprince
User
Beiträge: 128
Registriert: Freitag 22. Oktober 2004, 09:22
Wohnort: Salzgitter
Kontaktdaten:

Beitragvon Redprince » Donnerstag 21. Juni 2007, 13:51

Michael Schneider hat geschrieben: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?

Michael Schneider hat geschrieben: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.
I am not part of the allesburner. I am the allesburner.
Redprince
User
Beiträge: 128
Registriert: Freitag 22. Oktober 2004, 09:22
Wohnort: Salzgitter
Kontaktdaten:

Beitragvon Redprince » Donnerstag 21. Juni 2007, 17:57

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.
I am not part of the allesburner. I am the allesburner.
schlangenbeschwörer
User
Beiträge: 419
Registriert: Sonntag 3. September 2006, 15:11
Wohnort: in den weiten von NRW
Kontaktdaten:

Beitragvon schlangenbeschwörer » Donnerstag 21. Juni 2007, 19:35

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
User
Beiträge: 128
Registriert: Freitag 22. Oktober 2004, 09:22
Wohnort: Salzgitter
Kontaktdaten:

Beitragvon Redprince » Donnerstag 21. Juni 2007, 20:26

schlangenbeschwörer hat geschrieben: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.
I am not part of the allesburner. I am the allesburner.
Benutzeravatar
Mr_Snede
User
Beiträge: 387
Registriert: Sonntag 8. Februar 2004, 16:02
Wohnort: D-Dorf, Bo

Beitragvon Mr_Snede » Donnerstag 21. Juni 2007, 21:15

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
Benutzeravatar
Michael Schneider
User
Beiträge: 567
Registriert: Samstag 8. April 2006, 12:31
Wohnort: Bremen
Kontaktdaten:

Beitragvon Michael Schneider » Donnerstag 21. Juni 2007, 23:03

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. ;-)
Diese Nachricht zersört sich in 5 Sekunden selbst ...
Benutzeravatar
Michael Schneider
User
Beiträge: 567
Registriert: Samstag 8. April 2006, 12:31
Wohnort: Bremen
Kontaktdaten:

Beitragvon Michael Schneider » Freitag 22. Juni 2007, 07:20

Redprince hat geschrieben: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
Diese Nachricht zersört sich in 5 Sekunden selbst ...
Redprince
User
Beiträge: 128
Registriert: Freitag 22. Oktober 2004, 09:22
Wohnort: Salzgitter
Kontaktdaten:

Beitragvon Redprince » Freitag 22. Juni 2007, 12:46

Michael Schneider hat geschrieben: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.
Michael Schneider hat geschrieben: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.
Michael Schneider hat geschrieben: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.
Michael Schneider hat geschrieben: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!
Michael Schneider hat geschrieben: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.
I am not part of the allesburner. I am the allesburner.
Benutzeravatar
Michael Schneider
User
Beiträge: 567
Registriert: Samstag 8. April 2006, 12:31
Wohnort: Bremen
Kontaktdaten:

Beitragvon Michael Schneider » Freitag 22. Juni 2007, 21:52

Redprince hat geschrieben:
Michael Schneider hat geschrieben: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.
Redprince hat geschrieben:
Michael Schneider hat geschrieben: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.
Redprince hat geschrieben:
Michael Schneider hat geschrieben: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.
Redprince hat geschrieben:
Michael Schneider hat geschrieben: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.
Redprince hat geschrieben: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
Diese Nachricht zersört sich in 5 Sekunden selbst ...
hwm
User
Beiträge: 36
Registriert: Mittwoch 20. April 2005, 23:33

Beitragvon hwm » Samstag 23. Juni 2007, 12:40

Hallo,

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

http://sourceforge.net/projects/tktable/
Benutzeravatar
Mr_Snede
User
Beiträge: 387
Registriert: Sonntag 8. Februar 2004, 16:02
Wohnort: D-Dorf, Bo

Beitragvon Mr_Snede » Samstag 23. Juni 2007, 16:42

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.

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder