Login


 
Newsletter
Werbung

Thema: KWin will Unterstützung für OpenGL 1.x aufgeben

5 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von erik am Di, 21. Februar 2012 um 19:02 #

Ich weise an dieser Stelle noch einmal darauf hin, dass es keine Pläne für ein "KDE5" gibt.
Ich kenne die aktuelle Entwicklung diesbezüglich nicht. Heißt das, dass man innerhalb der KDE4-Linie dann die Binärkompatibilität über Bord wirft? Hat man das ernsthaft so beschlossen?

werden wir mit Qt 5 sowieso die Unterstützung von OpenGL 1.x Code entfernen müssen
Naja, "müssen"... In Zeiten von Git wäre die Pflege eines eigenen Zweiges so einfach wie noch nie zuvor. Auch wenn ich das natürlich nicht gut finde.

Es ist halt immer die Frage, ob einen alte Zöpfe wirklich Zeit kosten. Meinethalben kann man den OpenGL 1.x-Support ja deaktivieren aber drin lassen. Wer dann auf ihn angewiesen ist, muss Bugs darin fixen. Es ist in der Softwareentwicklung ohnehin illusorisch, sicherstellen zu wollen, das sämtliche unterstützten Szenarien funktionieren und bei der Weiterentwicklung berücksichtigt werden.

lg
Erik

  • 0
    Von mgraesslin am Di, 21. Februar 2012 um 21:56 #

    Ich kenne die aktuelle Entwicklung diesbezüglich nicht. Heißt das, dass man innerhalb der KDE4-Linie dann die Binärkompatibilität über Bord wirft? Hat man das ernsthaft so beschlossen?
    Wenn man die aktuelle Entwicklung diesbezüglich nicht kennt, sollte man keine Schlüsse ziehen ;-) 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. Mehr oder weniger einfach nur einmal neu kompilieren.

    Naja, "müssen"... In Zeiten von Git wäre die Pflege eines eigenen Zweiges so einfach wie noch nie zuvor. Auch wenn ich das natürlich nicht gut finde.
    "Müssen" war das falsche Wort. Es wäre sinnbefreit den Code zu behalten, da Qt 5 OpenGL (ES) 2.0 eh erfordert.

    • 0
      Von erik am Di, 21. Februar 2012 um 23:03 #

      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.


      lg
      Erik

      • 0
        Von Verdammt am Mi, 22. Februar 2012 um 01:22 #

        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?

        • 0
          Von erik am Mi, 22. Februar 2012 um 10:28 #

          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

Pro-Linux
Frohe Ostern
Neue Nachrichten
Werbung