Wenn man die aktuelle Entwicklung diesbezüglich nicht kennt, sollte man keine Schlüsse ziehen
Na Momeeent, grundlegendes Verständnis über Schnittstellen und Shared Libraries besitze ich deshalb trotzdem. Nur, weil ich leider keine Zeit mehr habe, die Mailinglisten zu lesen, heißt das nicht, dass ich gleich fachlich abgebaut hätte.
Was ich aussagen wollte, ist dass es keine Pläne für ein KDE 5 wie ein KDE 4 gibt. Der einzige Unterschied ist, dass dann Qt 5 statt Qt 4 verwendet wird.
Aha, also stimmt meine Aussage, die Binärkompatibilität innerhalb der KDE 4-Reihe wird aufgegeben, da man auf Qt5 umsteigt. Das hat man bei den letzten Versionen eben so nicht gemacht, daher kam meine Frage: Hat man diesen Fakt entsprechend diskutiert und für "ist egal" befunden? Das wäre immerhin neu.
Es wäre sinnbefreit den Code zu behalten, da Qt 5 OpenGL (ES) 2.0 eh erfordert.
Nach Hauptlinie, ja. Es ist halt die Frage: Welcher Code erfordert das. Wenn man die Notwendigkeit auf Seiten KDE hätte, die Kompatibilität zu alten Grafikkarten beizubehalten, müsste man dort eben andere Wege finden. Ich sage nicht, dass man das muss, sondern dass es zur Not sicher auch anders ginge.
Die "binärkompatibilität" kann dir doch völlig wurscht sein solange nur der Compile angeworfen werden muss - Oder hast du schon mal eine Binär-Distribution gesehen die bei enem KDE-Update alte und neue Binaries mischt?
Die "binärkompatibilität" kann dir doch völlig wurscht sein solange nur der Compile angeworfen werden muss
Es ist schön, wenn man im Leben nur auf freie Software zurückgreifen muss, in der Realität ist die weit größere Menge von Software jedoch proprietär. Aus diesem Grund lassen sowohl Qt als auch die KDE-Libs es lizenztechnisch zu, in proprietärer Software gelinkt zu werden.
Darüber hinaus mag nicht immer jeder Anwender einer In-House-Lösung in der Lage sein, diese aus dem Quellcode zu bauen, nur, weil seine Distribution die darunter liegenden Qt- oder KDE-Versionen aktualisiert hat.
Deshalb haben das KDE-Projekt und Qt bislang großen Wert darauf gelegt, innerhalb einer Major-Version binärkompatibel zu bleiben. Den aRts-Soundserver hat man deshalb durch die gesamte KDE3-Linie geschliffen, obwohl man sich seiner technischen Schwächen schnell bewusst war. Das man diesen Grundsatz jetzt offenkundig aufgegeben hat, mag man als Anwender mögen oder nicht, Konsequenzen hat es jedenfalls.
lg
Erik
Die "binärkompatibilität" kann dir doch völlig wurscht sein solange nur der Compile angeworfen werden muss - Oder hast du schon mal eine Binär-Distribution gesehen die bei enem KDE-Update alte und neue Binaries mischt?
Darüber hinaus mag nicht immer jeder Anwender einer In-House-Lösung in der Lage sein, diese aus dem Quellcode zu bauen, nur, weil seine Distribution die darunter liegenden Qt- oder KDE-Versionen aktualisiert hat.
Deshalb haben das KDE-Projekt und Qt bislang großen Wert darauf gelegt, innerhalb einer Major-Version binärkompatibel zu bleiben. Den aRts-Soundserver hat man deshalb durch die gesamte KDE3-Linie geschliffen, obwohl man sich seiner technischen Schwächen schnell bewusst war. Das man diesen Grundsatz jetzt offenkundig aufgegeben hat, mag man als Anwender mögen oder nicht, Konsequenzen hat es jedenfalls.
lg
Erik