* Andreas Pakulat <[EMAIL PROTECTED]> schrieb: > On 07.03.06 08:46:32, Enrico Weigelt wrote: > > * Andreas Pakulat <[EMAIL PROTECTED]> schrieb: > > > On 06.03.06 18:04:14, Enrico Weigelt wrote: > > > > * Andreas Pakulat <[EMAIL PROTECTED]> schrieb: > > > Frag mich mal in ner Woche nochmal, dann muss ich "nur noch" fuer > > > meine Komplexpruefung lernen... > > > > hmm, was hast Du denn noch vor Dir ? > > o.g. Komplexpruefung (Pruefung im Hauptfach ueber die letzen 2 Jahre) > und dann das Diplom schreiben.
konkreter ? <snip> > > > > IMHO eine Sache die man besser bleiben lassen sollte. Diesen Anspruch > > > > kann man ohnehin nicht erfüllen, es sei denn, die Maschinen lernen > > > > denken und die Menschen hören völlig damit auf. > > > > > > Jupp. Da muss ich dir tatsaechlich zustimmen. Wobei ich da aber Gnome > > > "weiter vorne" sehe als KDE. Gnome versucht zu viele Dinge vor dem User > > > zu verstecken um ihn ja nicht zum Denken anzuregen.. Bei KDE lief vor > > > einiger Zeit eine Diskussion darueber wie man die Konfiguration von > > > Applikationen und so Dinge wie Toolbars weniger unuebersichtlich und > > > fuer Anfaenger geeignet darstellt, ohne den Fortgeschrittenen Steine in > > > den Weg zu legen. IIRC ist das ganze irgendwann mehr oder minder > > > versandet, die von vielen befuerwortete Option war nur die > > > wichtigsten/am haeufigsten genutzten Dinge direkt sichtbar zu haben und > > > fuer alles andere sowas wie einen "Advanced"-Tab (man stritt sich ueber > > > die genaue Namensgebung) einzufuehren. > > > > Ist das nicht eine Sache von Stylesheets ? > > Bei GUI's? Ich glaube da ist man noch nicht so weit... XUL ? <snip> > > Es könnte sein, daß ein Objekt mehrfach referenziert ist ? > > Das war auch so ziemlich das einzige was mir einfiel. Dann brauchst du > ja auch keine QObject-Hierarchie. Ein QObject wird ja nur automatisch > geloescht wenn es in einer QObject-Hierarchie steckt. Sobald du eines > ohne parent erzeugst musst du das selbst loeschen oder halt einen GC > drauf ansetzen (sofern das moeglich ist). Und hier führt sich das ganze wieder selbst ad absurdum. Ergo: gleich einen GC nehmen und den ganzen anderen Blödsinn weglassen. <snip> > > > > X11 ist dank der Modularisierung auf einem guten Weg der Gesundung, > > > > ich trage da auch meinen kleinen Teil dazu bei :) > > > > > > Tja, solange die nicht ihre Probleme mit dem radeon-Treiber und Xinerama > > > in den Griff kriegen kann ich davon (leider) nicht profitieren.. > > > > Gut, mit solchen Details hab ich mich noch nicht befaßt - ich seh > > erstmal zu, daß ich den Xserver in minimalster Form gebaut kriege. > > Das Problem ist da auch nicht das build-System, sondern eine Aenderung > zwischen 6.8.2 und 6.9.0. Das Auffinden ist aber wohl aufgrund des > mangelnden Interesses von upstream etwas schwierig, da man wohl den > alten nicht-modularen Tree zum testen der verschiedenen Aenderungen > nehmen muss... Hast Du schonmal in den xorg-Listen nachgefragt ? <snip> > > Oder Du nimmst eine abstrakte API. Jede nennenswerte Programmiersprache > > hat das. Für C/C++ gibts unixODBC, für perl gibts DBI, für php > > gibts PEAR::DB, usw ... > > Oder ich nehme fuer C++ Qt-SQL. Ist auch nix anderes als eine abstrakte > API. Das besondere zumindestens bei JDBC, DBI und auch bei python's > DB-API ist das sie zum Basisumfang der Programmiersprache bzw. deren > Implementierung gehoeren. Das ist bei C++, PHP, C und vllt. noch ein > paar anderen nicht der Fall. Dort muss man sich halt ein passendes > Add-On suchen, ob es nun unixODBC ist oder Qt-SQL. unixODBC ist bewärter und erprobter als Qt-SQL. Ergo sollte man das doch nehmen. Einzige Legitimation (wie ganannt): ein kleiner wrapper, der ein paar Typen (char* <->QString, ...) convertiert. <snip> > > > > Wo kann man denn bei einer SQL-Anbindung nennenswert von einem GUI- > > > > Toolkit profitieren ? > > > > > > Wenn du eine GUI baust die Daten aus einer SQL-DB holt/reinschreibt... > > > Es soll Leute da draussen geben die machen sowas ;-) > > > > Ich verstehe dennoch das Problem noch nicht ganz ... ich hole Daten > > aus der DB (odbc) und packe sie in ein widget (qt), ich reagiere auf > > Aktionen (qt) und schreibe Daten zurück (odbc). Sauber getrennt. > > Die Widgets brauchen ihre eigenen Datentypen, z.B. QDate, QString usw. Solche Basistypen haben eigentlich nichts mit den Widgets zu tun, außer daß sie von diesen verwerndet werden. Ergo: gehören in eine separate Lib, auf die dann der Widget-Toolkit aufsetzt. Auf diese darf dann auch ein kleiner Wrapper aufsetzen, der die nativen Typen von unixODBC in Q-typen umrechnet. <snip> > > Okay, ich kann mir ja vorstellen, daß man vielleicht die Ergebnisse > > in einer QList und String-Parameter im QString haben möchte, aber > > das erfordert doch wirklich nur einen mickrigen 50k-wrapper ... > > Ja, aber wieso soll der Anwendungsentwickler den selbst schreiben > muessen? Ausserdem hast du dann wieder zig-tausend Inselloesungen, weil > jeder es ein wenig anders macht... Nein, der besagte 50k-Wrapper ist dann Q-ODBC. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 --------------------------------------------------------------------- -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- ---------------------------------------------------------------------
