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%
 
Insgesamt abgegebene Stimmen: 8
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.
Benutzeravatar
Mr_Snede
User
Beiträge: 387
Registriert: Sonntag 8. Februar 2004, 16:02
Wohnort: D-Dorf, Bo

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

Mr_Snede hat 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.
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!
I am not part of the allesburner. I am the [url=http://allesburner.de]allesburner[/url].
Benutzeravatar
Mr_Snede
User
Beiträge: 387
Registriert: Sonntag 8. Februar 2004, 16:02
Wohnort: D-Dorf, Bo

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

Vorm Schlafengehen war nichts hübscheres drin ;-)
Benutzeravatar
Michael Schneider
User
Beiträge: 569
Registriert: Samstag 8. April 2006, 12:31
Wohnort: Brandenburg

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

Michael Schneider hat geschrieben: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.
I am not part of the allesburner. I am the [url=http://allesburner.de]allesburner[/url].
Benutzeravatar
Michael Schneider
User
Beiträge: 569
Registriert: Samstag 8. April 2006, 12:31
Wohnort: Brandenburg

Redprince hat geschrieben:
Michael Schneider hat geschrieben: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
Diese Nachricht zersört sich in 5 Sekunden selbst ...
Antworten