QSettings

[anda_skoa]

Original geschrieben von dipesh
@anda_skoa
s.o. Zunächst lediglich hierachisch strukturierte Daten in Form der Standardtypen (QColor, QString, int, bool, etc.).

Also Qt Datentypen. Das hatten wir ohnehin vor, Interface ähnlich wie KConfig.

Unter binäres] (un)marshalling kann ich mir soviel nicht vorstellen. Denke aber auch, dass solch "Präsentationskonversationscode" etwas den Rahmen sprengt

Binäre Repräsentation wäre nicht so schwer, eben aufgrund des QDataStream Mechanismus.

Ini _und_ XML? :-)

Ich bin erstmal für INI.
XML ist dann nicht mehr schwer, die Strings müssen nur anders kodiert werden, weil andere Zeichen für Struktur reserviert sind.

Von der Idee her würde ich sagen, man trennt interen und externe Repräsentation, macht also beim Einlesen die interne draus und beim Rausschreiben die externe.
Dann kann man auch von einer Repräsentation lesen und eine andere schreiben.

Hmm, man könnte auch die In-Memory Darstellung als spezielle Ausgabeform handhaben.

Sammeln wir mal Designvorschläge.

Ciao,
_

[anda_skoa]

Original geschrieben von anda_skoa
Sammeln wir mal Designvorschläge.

ich schlage vor, wir treffen uns im IRC.
#mrunix auf irc.mrunix.de

Sagen wir heute 21:00.

Ciao,
_

[TheDodger]

Mist, hab ich echt viel zu spät gelesen ...

[anda_skoa]

Ist ja nicht so eilig

Ciao,
_

[dipesh]

hi, sorry, auch zu spät gelesen. Bin dieser Tage aufgrund der enormen Temperaturen auch kaum am Rechner (bzw. kaum am surfen).

Mails checke ich aber mind. täglich; mail at dipe.org (Bitte "dipesh" irgendwo (subject, body) mitreinnehmen, sonst spamassassin

Was wäre mit morgen (06.08), 21:00 Uhr?

[anda_skoa]

Original geschrieben von dipesh
Was wäre mit morgen (06.08), 21:00 Uhr?

7.8
am Mittwoch kann ich nicht, da ist Stammtisch der Linux User Group Graz

Ciao,
_

[dipesh]

Ok, werde versuchen am Do um 21:00 Uhr im #mrunix zu sein. Kann jedoch nicht fest zusagen, da ich Donnerstag zum essen eingeladen bin und nicht vorhersehen kann wie und ob das zeitlich noch ausartet.

Wie wäre es, wenn man hier schonmal ein paar Gedankengänge austauscht. Ich dachte an etwas der Art (vereinfacht);

public:
... QString getValue(const QString& key);
... void setValue(const QString& key, const QString& value);
... readfromini(const QString& file);
... writetoini(const QString& file);

wobei key für eine Ini z.B. "mysektion/myname" sein könnte. Mittels des slashs als Trennzeichen könnte man dann auch ganz flexibel Hieraschien abbilden. Ein "main/sub1/sub2/key" könnte dann z.B. in einer Ini so abgebildet werden;
[main/sub1/sub2]
key=...

ist aber sicherlich nicht der Weisheit letzter Schluss, sondern lediglich ein "brainstorm" kurz vor dem schlafen gehen :-) Oder doch etwas QDom vergleichbares mit zahlreichen gesonderten Klassen?

[anda_skoa]

So, um das ganze nicht einschlafen zu lassen

dipesh und ich hatten eine feine Diskussion im IRC.

Meine momentane Idee ist, das ganze dreiteilig zu machen.
1) Frontend: regelt den Zugriff auf die Daten, get/set Methoden
2) Container: speichert die Daten, zb in QMaps
3) IO: konvertiert zwischen Container und Außenwelt, zb INI File, XML File, etc.

dipesh möchte die Möglichkeit haben, hierachische Keys zu verwenden und es spricht ansich nichts dagegen.
Eventuell schränken wir das so ein, dass nicht jedes IO Modul das unterstützen muss, denn sonst wird das INI Modul mit viel Zustatzarbeit belastet.

Ich schlage vor, den Container immer hierachisch zu machen (also als Baum) und zwei Frontends zu haben, eines für hierachische Keys und eines für "flache".
Dadurch wird der Benutzer von flachen Strukturen nicht zu irgendwelchen Keykonventionen gewzungen.

Wenn das IO Modul durch das Frontend gesetzt wird, hat man auch da die Möglichkeit, nur solche zu erlauben, die den jeweiligen Modus auch können.

Abgesehen von der Struktur, sollten wir uns vielleicht auf eine Menge von Datentypen einigen, außer jemand hat eine gute Idee, das mit Templates zu lösen

Mir fallen da auf die Schnelle folgende ein

QString
QStringList
QColor
QFont
QPoint
QRect
bool
int
uint
double

Wie wollen wir das Verhalten haben?
Wenn zb ein QString Eintrag mit dem Namen "abc" existiert, soll dann ein QFont Eintrag mit selben Namen
- eingetragen werden
- zurückgewiesen werden
- den String löschen und den Font eintragen
?

Von Konzept her, was sagt ihr zu solchen Methoden

writeEntry(const QString& key, const QString& value);
writeEntry(const QString& key, const QFont& value);
readEntry(const QString& key, const QString& defvalue, bool* ok=0);
readEntry(const QString& key, const QFont& defvalue, bool* ok=0);

(Bei writeEntry bräuchte man bei möglichen Zurückweisungen natürlich einen bool Rückgabewert, oder auch einen bool* Parameter)

Ciao,
_

[TheDodger]

Klingt soweit nicht schlecht.
Ich habe in meinen alten Sachen nochwas gefunden :
QmcWidgets
Vielleciht kann man sich die noch greifen und analysieren?