Re: ein neues buildsystem --> autotools endlich abloesen
* Andreas Pakulat <apaku@gmx.de> schrieb:
> On 07.03.06 08:46:32, Enrico Weigelt wrote:
> > * Andreas Pakulat <apaku@gmx.de> schrieb:
> > > On 06.03.06 18:04:14, Enrico Weigelt wrote:
> > > > * Andreas Pakulat <apaku@gmx.de> 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: contact@metux.de
cellphone: +49 174 7066481
---------------------------------------------------------------------
-- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------
Reply to: