Re: ein neues buildsystem --> autotools endlich abloesen
On 07.03.06 14:45:38, Enrico Weigelt wrote:
> * Andreas Pakulat <apaku@gmx.de> schrieb:
> > On 07.03.06 08:46:32, Enrico Weigelt wrote:
> > > 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 ?
Das machen wir per PM, ist ja nun doch reichlich OT.
> > > Ist das nicht eine Sache von Stylesheets ?
> >
> > Bei GUI's? Ich glaube da ist man noch nicht so weit...
>
> XUL ?
Stimmt, wobei ich das nun nicht unbedingt als Erfolg bezeichnen wuerde.
Jedenfalls soweit ich das hier und da gelesen hab gibts da mehr Probleme
als Loesungen mit.
> > > > > 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 ?
Noch nicht, noch drueckts auch nicht (aka xserver-xorg 6.8.2
funktioniert noch mit dem restlichen neueren Xorg) und ich hab da
momentan keine Prioritaet bei...
Ausserdem mag ich mich nur ungern wegen 1 Problems bei noch einer ML
anmelden. Zumal IIRC ein Upstream-Bugreport existiert.
> > > 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.
Woher weisst du das? Ich will das nicht bestreiten aber ohne Zahlen ist
sowas immer leicht dahergesagt...
> > > 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,
Nunja, Qt ist ja nun schon etwas aelter und als es entwickelt wurde gabs
eben noch keine einheitlichen Basistypen auf allen Platformen auf denen
es laufen sollte. Ich vermute heutzutage wuerde TT sich auch ueberlegen
nicht doch die STL-Typen zu benutzen. Wie gesagt teilweise ist die
Interoperabilitaet zwischen STL und QTL sogar gewaehrleistet, nur bei
QDate sehe ich da nix.
> außer daß sie von diesen verwerndet werden. Ergo: gehören in
> eine separate Lib, auf die dann der Widget-Toolkit aufsetzt.
In Qt4 sind sie in einer separaten Lib.
Andreas
--
Your life would be very empty if you had nothing to regret.
Reply to: