Qt-Bibliotheken bald auf der Installations-CD?

Bisher setzte Ubuntu stets auf die von GNOME benutzten GTK-Bibliotheken. Dies kann sich vielleicht teilweise mit einer zukünftigen Version ändern.

Qt-Logo

Mark Shuttleworth (Gründer und Hauptsponsor von Ubuntu) schreibt 🇬🇧 in seinem Blog über die mögliche Integration von Qt-Anwendungen in Ubuntu. Qt ist ebenso wie GTK eine Programmierschnittstelle, mit der man grafische Anwendungen erzeugen kann, während Qt primär bei Kubuntu, GTK hingegen bei allen anderen Ubuntu-Derivaten Verwendung findet.

Diese klare Trennung der GUI-Bibliotheken will Mark Shuttleworth in einer zukünftigen Ubuntu-Version (zeitlich nach Version 11.04) nun aufheben. Damit ist jedoch nicht gemeint, dass Ubuntu nun KDE-Programme standardmäßig ausliefert, sondern vielmehr, dass die Qt-Bibliotheken zum Entwickeln von GNOME-Anwendungen eingesetzt werden können.

Bei der Auswahl einer Anwendung für die Standardinstallation von Ubuntu, muss man sich nach Shuttleworth die folgenden Fragen stellen:

Ist sie freie Software?
Ist sie die Beste ihrer Art?
Integriert sie sich in den Systemeinstellungen?
Passt sie zu anderen Applikationen?
Unterstützt sie Barrierefreiheit?
Sieht sie genauso aus, wie der Rest des Systems?

Während die Wahl, welche GUI-Bibliothek zum Einsatz kommt, keine Auswirkungen auf die ersten beiden Punkte hat, wird dies ab dem dritten bereits schwieriger: Eine unvollständige Integration von Qt-Anwendungen in den GNOME-Desktop wäre schädlich für Ubuntu und dessen Aussehen. Derzeit ist es allerdings leider noch so, dass Qt-Anwendungen beispielsweise andere Einstellungsdateien als GTK-Programme verwenden. Um dieses Problem zu beheben, treibt Canonical nun die Entwicklung des Konfigurationssystems dconf 🇬🇧 voran, mit welchem eine Integration unterstützt werden soll.

Kubuntu-Anwender, die nun gehofft haben, dass man Amarok bald von Haus aus bei Ubuntu finden wird und es Banshee ersetzt, werden jedoch enttäuscht. Es werden einzig die Qt-Bibliotheken ihren Weg auf die Installations-CD finden, da dconf nur auf diese ausgelegt ist - und nicht etwa auf Kubuntu-Anwendungen. Eine Integration von Amarok und anderen KDE-Programmen wird also nicht erfolgen.

Weiterhin soll die Entscheidung, offen für Qt zu sein, keineswegs Kritik an GNOME ausüben. Shuttleworth schreibt, Canonical wird auch weiterhin den Fokus auf GNOME setzen.

Ein großes Dankeschön an Lignux für die Einsendung dieses Artikels!

Veröffentlicht von UbuntuFlo | 18. Januar 2011 23:30 | Kategorie: Rund um Ubuntu | # Fehler im Artikel melden

nisita	1 19. Januar 2011 00:55 klingt auf jedenfall nach einer guten sache. trotzdem frag ich mich schon, was genau dahinter steckt. also warum "braucht" man das "plötzlich", hat es was mit unity-2d/qt zu tun? hat man vor in zukunft zweigleisiger zu fahren? ich selbst mag viele qt und kde programme deutlich mehr als die gtk-varianten, meistens nicht nur optisch. allerdings hat der kde-deskop für mich keinerlei reize (wenn ich nur an diese fette leiste denke, an kdm, an so manche kde widgets, ...) weshalb ich dann lieber gnome nutze und dann trotzdem so manches kde/qt programm. vielleicht dann zukünftig mit unity noch weniger gtk-programme??
basti171	2 19. Januar 2011 03:50 ich hoffe man setzt in zukunft mehr auf QT. Am besten ohne die riesigen kdelibs. ich denke den größten teil von gtk+/gobject kann man ohne schlechtes gewissen in die tonne treten. Mir würde ja QT + Creator + zusätzliche canonical unterstütze klassen(desktopkrams der noch in qt fehlt) aus entwicklersicht reichen. Dazu sollte man sich mit nokia zusammentun. da hätte man eine echte chance entwickler von spielen für symbian/maemo auch für ubuntu zu begeistern. Dann bietet man noch Softwareshop infrastruktur und die firmen können im besten fall Software einfach durch neukompilieren auch für ubuntu anbieten. sei es bejeweld oder tetris. das würde dann hoffentlich bessere anwendungen nach sich ziehen. m.m die einzige möglichkeit wie man längerfristig boden gut machen kann. apple macht das ja vor mit dem "app"store
Tids	3 19. Januar 2011 03:53 Was ich mich ja frage. Vor einiger Zeit haben sie Gimp noch wegen fehlendem Platzes auf der Disk raus gekickt und nun holen sie einfach mal so ganz Qt mit herein? Wie geht denn das?
Bauer87	4 19. Januar 2011 08:26 Die GUI zur Ubuntu-Versionsverwaltung Bazaar setzt schon länger auf Qt, der Schritt ist also naheliegend. Zudem kann Qt ja noch viel mehr als nur Grafikanzeige, zum Beispiel Netzwerk. Der Ubuntu One Client ließe sich so wohl leichter ausbauen und auch auf andere Plattformen (ARM) portieren. Apropos ARM: Vielleicht hängt die Überlegung auch mit Unity zusammen: Wenn jetzt immer mehr ARM-Netbooks kommen sollen, wäre das eine einfach umzusetzende Möglichkeit, auf allen Plattformen den gleichen Code verwenden zu können.
praseodym Supporter	5 19. Januar 2011 08:45 @1: Vermutlich deshalb. Das PPA könnte aufgenommen werden, um (proprietäre?) 3D-Treiber überflüssig zu machen, wenn sie nicht gewollt/vorhanden/funktionsfähig sind. Auf jeden Fall ein Schritt in die richtige Richtung, zumal es z. B. mit Intel-Treibern ziemliche Probleme gab. Siehe auch im Wochenrückblick
Vardamir	6 19. Januar 2011 09:10 Für diese Entscheidung gibt es sicherlich viele Gründe. Zum einen die Entwicklungen rund um MeeGo, und zum anderen der sehr behutsame und langsame Abschied von GNOME. (Wann wird es neben Ubuntu (Unity) ein Gubuntu (GNOME) geben?) War es nicht so, dass vor langer Zeit Qt nicht in Frage kam, wegen Lizenzproblemen und der fehlenden Anbindung von anderen Programmiersprachen? Ohne GTK+ näher zu kennen, glaube ich dass Qt die weitaus mächtigere Bibliothek ist, und davon will man profitieren.
Vegeta	7 19. Januar 2011 09:47 Eine sehr gute Entscheidung, dann hört vielleicht auch mal das Verunglimpfen mancher User auf, die Qt-Programme als den letzten Mist ansehen, weil sie angeblich ihr System damit zumüllen (O-Ton), und meinen Qt = KDE. Dabei ist Qt unglaublich innovativ und Gtk+ haushoch überlegen - ich programmiere gerne damit. Seitdem Qt-Programme wie native GNOME-Programme aussehen und anfühlen, gibts wirklich keinen vernünftigen Grund mehr auf ein solches Programm zu verzichten, zumal richtige Qt-Programme absolut keine KDE-Abhängigkeiten haben. Dieser Schritt wird Redundanzen verringern, endlich muss nicht mehr alles doppelt und dreifach für GNOME und KDE entwickelt werden. Hoffentlich fliegt dann dafür Mono komplett raus, wird derzeitig ohnehin nur von Banshee & Tomboy verwendet.
nisita	8 19. Januar 2011 12:09 @tids .. der hauptgrund gegen gimp war meines wissens, dass es für den user, für den user, an den sich cannonical hauptsächlich richtet zu komplex ist, bzw. es dafür einfachere tools gibt. dem kann ich nur zustimmen. und die "pro user" können es sich ja auch ohne probleme nachinstallieren. @begeta.. qt ist nicht kde, aber kde ist qt 😉 (wenn auch leicht modifiziert) fehlt nur noch, dass kde und qt wieder zusammenwachsen, was ja vor kurzem immerhin mal überlegt wurde, auch wenn ich daran noch nicht glaube. dann hätte man noch eine redunanz weniger. banshee hat momentan einen ziemlich guten lauf, wo im moment irgendwie kein anderer mediaspieler mithalten kann, leider. dabei sah es um amarok ja mal ziemlich gut aus, die haben ihren vorsprung aber leider aufgegeben...
Vegeta	9 19. Januar 2011 12:29 @8: fehlt nur noch, dass kde und qt wieder zusammenwachsen, was ja vor kurzem immerhin mal überlegt wurde, auch wenn ich daran noch nicht glaube. dann hätte man noch eine redunanz weniger. Qt und KDE werden sicherlich nicht zusammenwachsen, reines Wunschdenken und deswegen hört man von dieser Idee auch nichts mehr. Zwar werden sicherlich einzelne Bestandteile wieder in Qt von KDE fließen, aber die wollten ja mehr oder weniger ihren Bloat in Qt auslagern und das wirds sicherlich nicht geben, die wären bei Nokia schön doof.
dennda	10 19. Januar 2011 18:34 Ich als Entwickler begruesse den Schritt ebenfalls. Qt ist super.
FriedChicken	11 19. Januar 2011 20:12 Vorweg: Qt ist deutlich mehr als "nur" ein Toolkit für grafische Oberflächen. Es ist vielmehr ein Framework, dass auch für viele andere Dinge Unterstützung bietet und ist daher in vielen Punkten eher mit .Net/Mono oder Java vergleichbar als mit "reinem" GTK. Einer der größten Nachteile von GTK ist ja wohl auch, dass man einfach noch auf viele andere Bibliotheken angewiesen ist, anstatt alles aus einem Guss zu erhalten. Von daher ist es ziemlich unsinnig, ohne Weiteres GTK mit Qt zu vergleichen. @3: Mehr Platz kann man dadurch bekommen, dass man eine andere Kompression einsetzt (z.B. wird XZ als Weiterentwicklung von LZMA in Kernelversion 2.6.28 Einzug halten) oder eben noch mehr Programme rausschmeißt bzw. durch andere ersetzt, die schon vorhandene Bibliotheken mitbenutzen. @6: Qt ist schon seit Jahren (seit der Übernahme durch Nokia) als LGPL lizenziert. Das angesprochene Problem (das auch nur Closed Source betroffen hat) ist damit passé. @9: Bitte unterlasse doch derartige Spekulationen wie den angeblichen "KDE-Bloat", der in Qt einfließen könne. Es wurden bereits erfolgreich KDE-Technologien in Qt eingepflegt (z.B. Phonon) und davon profitieren beide Seiten.
berndth	12 19. Januar 2011 20:16 @6: Ohne GTK+ näher zu kennen, glaube ich dass Qt die weitaus mächtigere Bibliothek ist Dieser Kommentar ist wenigstens mal ehrlich. "Ich kenn zwar eine Seite überhaupt nicht, aber wie der Vergleich aussieht, ist mir vollkommen klar."
onkeltom67	13 19. Januar 2011 20:45 Offen für andere verbreitete freie Techniken zu sein finde ich einfach nur gut 👍 Und vielleicht gelingt es damit ja auch die ein oder andere Hürde im GNU/Linux Cosmos nieder zu reißen. Zu begrüßen wäre es alle mal 😛
mniess	14 19. Januar 2011 20:49 1. Danke für den gut geschriebenen Artikel. 2. Endlich! Qt ist für Programmierer ein Segen. Hoffentlich verschwidnet dieser Mono-Schrott wirklich.
Vegeta	15 19. Januar 2011 20:58 @11: Ich habe nicht gesagt, dass nicht gewisse Dinge von KDE in Qt zurückfließen, aber den Bloat können sie gerne behalten. Im Artikel von Pro-Linux stehts auch noch mal drin, dass die kdelibs Bereiche enthalten die nur für KDE interessant sind, sowas gehört absolut nicht in Qt.
nisita	16 19. Januar 2011 21:24 das eine hat aber ja mit dem anderen nicht unbedingt etwas zu tun. es wäre ja schon viel getan, wenn man 95% der kde-libs in qt hätte und die sachen die eben doch sehr kde-spezifisch sind, könnten weiterhin in einer extra-bibliothek sein. im übrigen weiß ich nicht von welchem bloat sie sprechen. natürlich gibt es ein paar dinge die man zurücklassen könnte, aber dafür wäre ja so eine kde-in-qt-integration doch bestens geeignet. ich fände es immer noch eine gute idee, vorallem weil dann qt programme sich in kde viel besser integrieren lassen könnten... es wäre einfach nichtm ehr soviel doppelt ☺
Vegeta	17 20. Januar 2011 09:40 @16: Hast du dir schon mal angesehen was in den kdelibs überhaupt alles drin ist? Da sind viele Sachen bei, die nur für KDE interessant bzw. benutzbar sind. Unter anderem findet man dort Kate-Komponenten oder Plasma wieder. Mit KDECore hat mein ein Gegenstück von QApplication, dessen angepasste Funktionen ebenfalls nur für KDE interessant sind und für Qt keinerlei Nutzen bringt. Das zieht sich durch die ganzen Komponenten durch. Ein ganz anderes Problem ist die fehlende Modularisierung, weswegen da unglaublich viel umgebaut werden müsste. Auch ist der Namensraum ein Problem. Bei Qt fängt alles mit q oder Q an, werden die KDE-Komponenten entsprechend geändert oder wird ernsthaft erwartet, dass in Qt ein Mischmasch eingeführt wird von Q und K? Interessant ist auch die Tatsache, dass die neuen KDE-Komponenten in Qt von der KDE-Community gepflegt werden sollen und das ist schon fast das quasi vorzeitige Ende dieser Idee. So eine Idee gab es nämlich schon einmal bzw. wurde von vielen Programmierern gewünscht. Es gab damals den Vorschlag Boost in Qt aufzunehmen. Nur zur Info: Boost ist State of the Art (im Gegensatz zu den KDE-Komponenten, wo ich noch nirgends was zur Qualität gelesen habe) und einigen Komponenten von Qt was Funktionalität wie auch Geschwindigkeit angeht stark überlegen - hier sei nur die RegExp-Engine genannt. Dafür beschränkt sich Boost, im Gegensatz zu Qt, auch nur auf einige wenige Komponenten. Obwohl von vielen gewünscht wurde dieser Wunsch mit der Begründung abgeschmettert, dass es eine unterschiedliche Philosophie bei der Benennung der Funktionen gäbe, sowie man nicht die Entwicklung so wichtiger Komponenten an eine Third-Party abgeben wolle. Sollte sich an dieser Meinung nichts geändert haben, dann kann man sich ausdenken was man bei Nokia bzw. Trolltech von dieser Idee hält. Ein Merging würde hauptsächlich KDE was bringen und nicht Qt, da man Qt mit vielen KDE-Bestandteilen anreichern würde, die für KDE interessant bzw. auch nur dort nutzbar sind, aber nicht für jemanden der mit Qt was machen will.
nisita	18 20. Januar 2011 10:07 hast du dir mal den threat dazu durchgelesen? http://lists.kde.org/?l=kde-core-devel&m=128842761708404&w=2 es geht darum kde wieder in qt zurckzuführen, natürlich müsste man die namensräume ändern, das ding modulairisieren (vorgeschlagen wurde ein kde5 in der die mudularisierung abläuft und dann ein "intigriertes kde6") -aber im grunde ist ja auch nichts klar, es sind bis jetzt ja nur gedanken. und ich finde es zumindest interessant ihn weiterzudenken. schade find ich es dagegen, dass sie als qt entwickler(?) da so ablehnen gegennüberstehen, da es ja auch für qt-entwickler vorteile mitsichbringen würde. und vielleicht(!) schafft man ja eine win-win situation. ich glaube ja auch nicht, dass es passieren wird, schade ist es trotzdem.
Vegeta	19 20. Januar 2011 10:23 Es gibt nur wenige Dinge, die ich von KDE als sinnvolle Erweiterung von Qt sehen würde - aber zugegeben, ich habe mich mit KDE niemals innig beschäftigt. So gibt es in KDE z.B. die Möglichkeit einfach über KDir Verzeichnisse kopieren zu können, so was gibt es in QDir nicht und man muss eine entsprechende Routine selber basteln. Das wäre in der Tat eine sinnvolle Erweiterung, aber die ganze KDE-Technik, die nur für KDE oder nur unter Linux läuft, das kann man nicht in ein plattformübergreifendes Framework einbauen. Btw: Wieso duzt du mich, nur im mich im nächsten Satz zu siezen und wieso schreibst du permanent deine kompletten Beiträge klein?
nisita	20 20. Januar 2011 10:28 es würde für qt-entwickler ja auch "auf einmal" eine größere userschicht angesprochen werden, was ja bestimmt auch seine reize hat. ich versuch die menschen immer im netz zu duzen (weil siezen angeblich unhöflich ist), jedoch vergess ich es manchmal. verzeihung. ich schreibe schon immer alles klein, gute frage warum.
mgraesslin	21 20. Januar 2011 19:30 @Vegeta: sorry du zeigst hier leider, dass du nicht wirklich weißt was kdelibs ist, was es kann und wozu es gedacht ist. In solchem Fall sollte man dann nicht von "Bloat" sprechen. Zum Beispiel ist Plasma nicht in den kdelibs, sondern in kde-workspace. Was in kdelibs ist, ist libplasma ein hoch flexibles Framework um auf Widget basierte Anwendungen zu schreiben. Ein Beispiel für eine Funktionalität, die sehr viel Sinn in Qt machen würde (hallo MeeGo) und auch bereits in vielen Anwendungen außerhalb des Desktops eingesetzt, bzw. eingebaut wird (z.B. Amarok, Kontakt, Skrooge...). Zum Thema Aufsplitten der KDElibs finden sich auch zwei aktuelle Blog Posts im Blog von Aaron Seigo (Plasma Maintainer): Platform 2011 sprint update thinking about library modularity
Vardamir	22 20. Januar 2011 20:11 Ich glaube, die meisten Qt Anwendungen sind KDE Anwendungen, zumindest sind mir bislang nur wenige reine Qt Anwendungen über den Weg gelaufen. Und genau das macht es ja so schwierig, diese Anwendungen auf anderen Desktop Environments oder Plattformen (z.B. Windows) zu verwenden (man muss immer das halbe KDE mitinstallieren). Wenn also die Teile, die nicht unbedingt zum DE gehören in Qt einfließen, dann ist das eine gute Sache, sowohl für Qt Entwickler (weil sie die Features bekommen, die vorher nur in KDE waren), als auch für KDE (schon allein aus dem Refactoring Gedanken) Ich kann mir vorstellen, dass das keine leichte Aufgabe sein wird, aber es wäre enorm lohnenswert.
Lignux	23 20. Januar 2011 20:38 @22: Krusader ist zum Beispiel ein Programm, was kaum KDE-Abhängigkeiten hat.
mgraesslin	24 20. Januar 2011 20:54 @23: sicher? http://packages.ubuntu.com/maverick/krusader Wirkliche Beispiele wären aber: Quassel (mit optionaler KDE Integration) Google Earth VLC Unity-2D 😉 Marble (jedoch standardmäßig mit KDE Integration) Skype Sehr viel in der Automobilindustrie Sehr viel in der Filmindustrie
Vegeta	25 20. Januar 2011 21:26 @21: Dass ich kein KDE'ler bin, hatte ich ja schon gesagt 😉 Dass ich geschrieben habe, dass Plasma Bestandteil von kdelibs ist, liegt ganz einfach daran, weil es in der Api-Übersicht dort auftaucht. ☺ An meiner Haltung ändert sich sonst aber nichts, ich sehe es als äußerst zweifelhaft an, dass Nokia Personal abstellt um die kdelibs mit Qt zu mergen. Zumal überhaupt nicht geklärt ist, ob der Code kdelibs überhaupt den Anforderungen gerecht wird, die sie bei Trolltech/Nokia haben.
mgraesslin	26 20. Januar 2011 22:04 @25: du schreibst doch selbst, dass du kein KDE-ler bist, wie kannst du dann überhaupt behaupten, dass Code Qualität ein Problem sei? Sorry aber du wertest hier KDE ohne jede Ahnung ab. Wenn du mal einen Abgleich machen würdest wie viele Committer bei KDELibs auf Nokias Gehaltszettel stehen, würdest du dir darüber keine Gedanken mehr machen.... Bitte bleibe bei Fakten: Fakt ist es gab eine Diskussion zum Mergen von KDELibs mit Qt. Fakt ist auch dass die Diskussion eingeschlafen ist und ein kompletter Merge in der Diskussion mehrheitlich von den KDE Entwicklern abgelehnt wurde.
Vegeta	27 20. Januar 2011 22:22 @26: wie kannst du dann überhaupt behaupten, dass Code Qualität ein Problem sei? Sorry aber du wertest hier KDE ohne jede Ahnung ab. Ich habe KDE nicht abgewertet, ich habe lediglich gesagt, dass, so lange der Source nicht von Trolltech/Nokia genauer analysiert wurde, wohl kaum einer offiziell sagen kann, ob deren Qualitätsansprüche genüge getan werden - denn letztendlich entscheiden die was gemacht wird oder nicht.
mgraesslin	28 20. Januar 2011 22:32 was impliziert, dass du denkst dass KDEs Codequalität nicht gut genug ist für Qt. Außerdem weißt du nicht, ob Nokia überhaupt den Code genauer analysieren würde und auch nicht ob sie entscheiden was gemacht wird (Stichwort Open Governance).
Vegeta	29 20. Januar 2011 22:39 Was ich denke ist doch total unwichtig oder hast du irgendwo eine Quelle die besagt wie toll der Quellcode von KDE im Vergleich zu Qt ist? Du kannst ja auch die These aufstellen, warum der Code von KDE zu gut für Qt ist, wenn dir das besser gefällt. Letztendlich bleibts aber dabei was ich sonst sagte, entscheiden tut Nokia was abgeht. Denen ist es egal was da irgendwelche Leute aus der KDE-Community für Ideen haben, wenn es Nokia nicht passt, wirds auch nicht umgesetzt. Da kann keiner von uns was ändern.
Ximion	30 20. Januar 2011 22:50 @29: Hast du den Blogeintrag zu Open Governance gelesen? Ich glaube wirklich, du unterschätzt die KDE-Entwicklercommunity und deren Einfluss... (obwohl Nokia natürlich immer noch die Qt Entwicklung bestimmt. Ist das Contributor Agreement eigentlich noch nötig für Qt?)
Vegeta	31 20. Januar 2011 23:04 @30: Jau, habe ich jetzt mal gemacht. Edit: Von was für einen Einfluss seitens der KDE-Community redest du? Man kann doch seitens Oracle sehen wie wenig eine Community machen kann, wenn der Konzern nicht will.
Ximion	32 20. Januar 2011 23:32 Oracle sehe ich eher als Beispiel für wie viel die Community machen kann ^^ Bis auf Java und VirtualBox wurde von MySQL (MariaDB) bis hin zu OpenOffice.org (LibreOffice) und Hilfsanwendungen wie Hudson (Jenkins) so ziemlich alles erfolgreich geforkt/umbenannt. Und die Weiterentwicklung der Software scheint auch kein Problem zu sein. Nokia wird sich hüten, die KDE-Entwickler schlecht zu behandeln. Bis jetzt hat sich es für keinen Konzern wirklich ausgezahlt, die kostenlos arbeitende, OSS-Gemeinschaft zu vergraulen. (Zudem haben Nokia und KDE überlappende Ziele)
Thorsten_Reinbold	33 21. Januar 2011 00:04 Ich mag diese Entwicklung so rein gar nicht. Hauptsächlich deshalb, weil ich ein grundsätzlicher Liebhaber von GTK und Gnome bin. Und zwar ausschließlich. Das war für mich auch einer von vielen Gründen, Ubuntu zu nutzen.Ich hoffe sehr, daß es auch weiter die Möglichkeit geben wird, auf QT zu verzichten.
Vegeta	35 21. Januar 2011 07:27 @32: Forken ist nicht unbedingt eine Lösung, man kann sich auch tot-forken. Das Problem ist doch, dass schon damals OpenOffice.org permanent über zu wenige Helfer geklagt hat. Klar kann man sagen, dass da die Lizenz von Sun das Problem war, aber selbst populäre Programme wie GIMP verfügen derzeitig nur über 2-3 aktive Mitarbeiter. Wie will LibreOffice gegen OpenOffice.org bestehen, falls Oracle richtig Geld in die Entwicklung steckt? Dasselbe Problem hat die KDE-Entwicklung KHTML auch, seitdem es von Apple geforkt wurde ist es quasi tot und spielt keinerlei Rolle mehr, ist mir schleierhaft warum die KDE-Community immer noch dran festhält, obwohl überall nur noch WebKit benutzt wird. @33: Diese Einstellung kann ich nicht nachvollziehen. Qt-Programme sind im Gegensatz zu Mono nicht langsam, haben keine KDE-Abhängigkeiten, sehen aus wie GNOME-Programme, verhalten sich wie GNOME-Programme und sind in der Regel weiter entwickelt. Wieso sollte man dann drauf verzichten? Eventuell benutzt du sogar Qt-Programme und weißt es noch nicht mal, weil es nicht dabei stand.
der_alex1980	36 21. Januar 2011 09:18 Als Programmierer freue ich mich über diese Entwicklung. Ich liebe Gnome, aber hasse GTK. ☺ Wenn es in Zukunft noch vernüftige C# Bindings gäbe, wäre die Welt für mich perfekt, denn ich programmiere gerne mit dem lahmen Mono Dreck.
Ximion	37 21. Januar 2011 16:34 @36: Bin auch anti-mono, einerseits, weil es indirekt von Microsoft kontrolliert wird, andererseits: Warum soll man die Leistung, die moderne PCs haben, für eine VM verbraten? (Oder für interpretierten Code, wenn's nicht unbedingt Sinn macht?) @35: KDE schwenkt bereits auf WebKit um. LibreOffice hat auch Unterstützung durch Firmen. Aber generell hast du Recht, forken muss nicht immer positiv sein. (gerade bei GIMP wundert mich die geringe Entwicklerzahl doch sehr) @33: Wenn Einheitliche Standards herrschen, sollte man problemlos KDE/Qt/GTK+ Anwendungen parallel verwenden können. (Leider ist das noch nicht immer der Fall)
Matthias	38 23. Januar 2011 12:54 Ich würde auch gerne z.B. Okular ohne den KDE-Desktop unter GNOME installieren. Optisch integriert sich das bereits ganz gut in Gtk-Themes, aber mehrere 100 MB an Abhängigkeiten: ich will doch nur PDF-Kommentare lesen. Es wäre schön, wenn die KDE-Programme auch abgespeckte Versionen, die nur auf Qt setzen anbieten würden.
mgraesslin	39 23. Januar 2011 13:00 @38: du brauchst nicht den KDE-Desktop um Okular zu verwenden und falls der mitinstalliert wurde, dann liegt ein packaging Fehler vor. Abgespeckte Versionen ohne KDE-Libs ist etwas schwierig, da vieles dann zwei mal geschrieben werden müsste und zum Teil die Funktionalität in Qt einfach fehlt. Es gibt aber Anwendungen, die das machen, zum Beispiel Marble.
Andi1804	40 23. Januar 2011 13:52 @6: Wann wird es neben Ubuntu (Unity) ein Gubuntu (GNOME) geben? Warum eigentlich nicht? Ich finde diese Idee super. 👍
Ximion	41 23. Januar 2011 15:08 @39: Korrekt. Es gab z.B. mal eine Zeit lang folgenden Fall: Die Installation von Amarok installiert gleich mal den KDE-Crashreporter mit. An sich kein Problem, aber in diesem Fall war der Crashreporter gegen libkpackagekit gelinkt, um mit PackageKit Debugsymbole nachinstallieren zu können. KPackageKit ist nun aber ein KDE-Control-Module, weshalb es das KDE SystemSettings-Programm zum laufen braucht. Dieses wiederum zieht dann als integraler KDE-Bestandteil wirklich fast den ganzen Plasma-Desktop mit hinein. (Was ich auch seltsam fand...) Kann also wirklich gut sein, dass ein Problem mit den Ubuntu-Paketen vorliegt. Prüfe einfach mal die Abhängigkeiten von Okular nach und erstelle einen Bugreport, wenn da was unnötiges referenziert wird.
Lignux	42 30. Januar 2011 14:25 @24: Ok,ok Ich nehm alles zurück ☺