Hallo allerseits,
langsam fange ich an, dieses Qt-Problem zu hassen. Kann mir jemand einen Grund nennen, warum Qt einen setRGB-Fehler bringt? Wenn ja, kann mir jemand einen Grund nennen, warum dieses Problem auf einem Großteil der Rechner _nicht_ auftritt? Bei unserem OSS-Projekt ist jetzt schon zum zweiten Mal so ein Fehler aufgetreten. Bei einem meiner Rechner tritt dieses Problem bei 8 bit Farbtiefe auf, wenn ich KDE starte, dieses Programm läßt sich aber darunter compilieren. Die Farben werden bei dem Programm übrigens per Qt::red, RGB-Wert und über die X-Farben ("p.setPen("Brown");") zugewiesen, also alles gemixt. Liegt es vielleicht an einem dieser Methoden?
cu, Ulf
Am Donnerstag, 22. Februar 2001 20:31 schrieb Ulf Lorenz:
Hallo allerseits,
langsam fange ich an, dieses Qt-Problem zu hassen. Kann mir jemand einen Grund nennen, warum Qt einen setRGB-Fehler bringt?
Oje, Qt. Ich würde auch gerne wissen, warum einer meiner Dialoge zum Eintragen von FTP-Hosts nach dem Schließen manchmal gar nichts macht und manchmal ein paar Sekunden nach dem Schließen die ganze Applikation gen Core fährt. Mystik oder Pointerproblematik.
Wenn ja, kann mir jemand einen Grund nennen, warum dieses Problem auf einem Großteil der Rechner _nicht_ auftritt? Bei unserem OSS-Projekt ist jetzt schon zum zweiten Mal so ein Fehler aufgetreten.
*rotfl* (gibt es eine OSS-Projekte-Flamewar-Liste? Wer hat die lustigsten Bugs?)
Also muß es an der Umgebung liegen, und ich tippe mal auf X11, bzw. wie Qt dort IO-Handling betreibt.
Bei einem meiner Rechner tritt dieses Problem bei 8 bit Farbtiefe auf, wenn ich KDE starte, dieses Programm läßt sich aber darunter compilieren.
Sollte es auch, denn der gcc ist zum Glück nicht auf X11, Qt oder KDE angewiesen.
Die Farben werden bei dem Programm übrigens per Qt::red, RGB-Wert und über die X-Farben ("p.setPen("Brown");") zugewiesen, also alles gemixt. Liegt es vielleicht an einem dieser Methoden?
Tritt es nur bei 8 Bit auf? Dann ist wahrscheinlich die Tabelle oder der Algorithmus von Qt für das Mapping falsch. Wenn nicht, dann wird es schon mal schwieriger. Meinst du mit dem Projekt FreeLords? Schick mir mal was zur Probe zu, ich habe nicht die wenigste Zeit im Moment, vielleicht finde ich was. Wie immer ohne Garantie. Denken wir mal 10 bis 11 Jahre zurück: Ich tausche Sourcecode im Verhältnis 7:1 :-) (jaja, das ist die Bazaar-Methode, also Verhandlungssache)
Josef Spillner
P.S. Ich habe noch dein UF-Buch hier. Bringe ich am Mittwoch mit.
On Thu, Feb 22, 2001 at 08:41:54PM +0100, Josef Spillner wrote:
Am Donnerstag, 22. Februar 2001 20:31 schrieb Ulf Lorenz:
Hallo allerseits,
langsam fange ich an, dieses Qt-Problem zu hassen. Kann mir jemand einen Grund nennen, warum Qt einen setRGB-Fehler bringt?
Oje, Qt. Ich würde auch gerne wissen, warum einer meiner Dialoge zum Eintragen von FTP-Hosts nach dem Schließen manchmal gar nichts macht und manchmal ein paar Sekunden nach dem Schließen die ganze Applikation gen Core fährt. Mystik oder Pointerproblematik.
Veilleicht wird Qt allmählich zu umfangreich (viel Masse => viele Bugs :))
Bei einem meiner Rechner tritt dieses Problem bei 8 bit Farbtiefe auf, wenn ich KDE starte, dieses Programm läßt sich aber darunter compilieren.
Sollte es auch, denn der gcc ist zum Glück nicht auf X11, Qt oder KDE angewiesen.
Sorry, ich meinte, freelords läßt sich auf diesem Rechner mit 8bit auch starten (im Gegensatz zu KDE2).
Die Farben werden bei dem Programm übrigens per Qt::red, RGB-Wert und über die X-Farben ("p.setPen("Brown");") zugewiesen, also alles gemixt. Liegt es vielleicht an einem dieser Methoden?
Tritt es nur bei 8 Bit auf? Dann ist wahrscheinlich die Tabelle oder der Algorithmus von Qt für das Mapping falsch. Wenn nicht, dann wird es schon mal schwieriger.
Also nochmal Zusammenfassung, um sämtliche Klarheiten zu beseitigen :) Wenn ich 8 Bit Farbtiefe einstelle, lassen sich KDE2-Anwendungen nicht starten, freelords schon. Wenn ich 16 Bit Farbtiefe einstelle, klappt sowohl KDE2 als auch freelords. Bei einem Anderen hatte freelords bei 16 Bit Farbtiefe nicht geklappt :(.
Meinst du mit dem Projekt FreeLords? Schick mir mal was zur Probe zu, ich habe nicht die wenigste Zeit im Moment, vielleicht finde ich was.
Dazu gibt es cvs :).
Wie immer ohne Garantie.
Josef Spillner
Ulf
P.S. Ich habe noch dein UF-Buch hier. Bringe ich am Mittwoch mit.
Ok
On Thu, Feb 22, 2001 at 08:41:54PM +0100, Josef Spillner wrote:
Also muß es an der Umgebung liegen, und ich tippe mal auf X11, bzw. wie Qt dort IO-Handling betreibt.
Ich hab's herausgefunden (alle Qt-Entwickler mal hergehört). Nachdem ich dem ursprünglichen bug-poster mal einen kleinen patch geschickt habe, liefs. Der patch beinhaltete lediglich eine Umstellung der Farbdefinitionen auf das Setzen des RGB-Wertes. Wenn man also einem Stift eine Farbe zuweisen will, nicht
p.setPen("black");
oder
p.setPen(Qt::black);
verwenden; zumindest eines von beiden klappt nicht immer (ich vermute mal, das erstere).
p.setPen(QColor(0,0,0));
funktioniert aber.
cu, Ulf
Am Dienstag, 27. Februar 2001 16:38 schrieb Ulf Lorenz: [...]
p.setPen("black");
oder
p.setPen(Qt::black);
verwenden; zumindest eines von beiden klappt nicht immer (ich vermute mal, das erstere).
p.setPen(QColor(0,0,0));
funktioniert aber.
Das zweite müßte immer funktionieren: qnamespace.h: QT_STATIC_CONST QColor & black; Was dann bestimmt auf Qt::black=QColor(0,0,0) übersetzt wird.
In den Headern steht auch jede Menge //3.0 Information drin, so daß man quasi aufwärtskompatibel programmieren kann.
Josef Spillner
lug-dd@mailman.schlittermann.de
-
Josef Spillner -
Ulf Lorenz