Linux = Programmiererhimmel?!

[Lin728]

..................................

[jha]

moin,

also wenn du den programmierhimmel auf themes beschraenkst hast du sicherlich recht. die sache mit gtk2 ist etwas anders als dargestelt. in der tat sind viele anwendungen(freeciv, mozilla etc.) bereits auf gtk2 portiert wenn auch noch nicht immer stabil. das ganze dauert etwas laenger, da die api zwar abwertskompatibel ist, aber viele funktionen als "deprecated" gelten. gtk2 kannst du in der regel mit --enable-toolkit=gtk2 oder aehnlichem beim configuren einstellen. das dein distributor das nicht tut ist seine sache. was passiert wenn leute kde und gnome gleich aussehen lassen wollen siehst du an redhats bluecurve. imho waere es besser mal den ganzen bloat(xml guis etc) aus den desktops rauszuschmeissen.

[Lin728]

..........................

[tkortkamp]

PS: Glaubst du es hätte sinn, eine solche App zu bauen, wie ich sie oben beschrieben habe? Die Themes ganz einfach installieren und umwandeln kann?

Ich würde weiterdenken: Eine gemeinsame Theme-API für Qt und Gtk+ hätte IMHO mehr Sinn, als ein Theme-Konverter-Programm zu entwickeln.
Das was du beschreibst wäre nur eine temporäre Lösung: Man müsste dann nämlich wieder für Qt und Gtk+ insgesamt ZWEI Themes installieren, obwohl sie gleich aussehen. Ideal wäre nur EIN Theme für beide (Qt, Gtk+) installiert haben zu müssen.

c ya,
Tobias

[jha]

die pixeligen schriften sind bei falscher standart konfiguration und ahnungslosen anwendern in der tat ein problem, haben aber imho rein garnichts mit themes zu tun.

[anda_skoa]

Original geschrieben von ceisserer
Moin!

So, also ich sags jetzt gleich, der ganze Text ist eine einzige Meckerei, echt sorry, aber so muss mal raus.

Angenommen, man will unter Linux platformunanbhängig entwickeln, doch die Gui-Anwendung sollte sich gut ins System integrieren, was würdet ihr nehmen?
KDE fällt weg, und überhaupt, warum gibt es diese doofen KDE-Libs überhaupt?

Weil sie genial sind? Das Entwicklern wesentlich vereinfachen?
Die KDE libs enthalten einerseits Funktionalität, die auf verschiedenen Plattformen unterschiedlich implementiert werden müssen, und andererseits Verbesserungen/Erweiterungen.
Unter letze Kategorie fällt zum Beispiel Plugintechnologie, Komponenten, Interprocess-Kommunikation, erweitere Widgets, netzwerktransparentes IO, Printingsubsystem, MIME handling, globale Einstellungen, etc.

Es gibt doch QT, das man generell an KDE anpassen könnte.
Außerdem haben diese genialen KDE entwickler nicht eine Finger gerührt, dass die alten KDE2-Apps die neuen Themens verwenden könnte.

Vielleicht weit du das nicht, aber Qt Styles und KDE Styles sind so eine Art Plugin, kompilierter Code.
Wenn sich die API oder ABI ändert, ist man nicht mehr abwärskompatibel.

Ich entwickle doch nicht eine Anwendungm, die ich bei jeder neuen Major-KDE-Release neu anpassen und kompilieren muss, um sie so ansehnlich zu halten.

Das versteh ich jetzt nicht.
Sieht die Anwendung denn nicht so aus, wie sie vorher ausgesehen hat?
Ist da ein Unterschied, wenn ich in KDE3 den selben Style eingestellt habe, wie er für die KDE2 Apps gilt?

Wäre wirklich nicht viel dabei gewesen, die theme-engine von kde (warum verwenden die bloß nicht die QT-Theme engine) abwärtsskompatibel zu halten, auch wenn dazu code nötig gewesen wäre, der neu nach alt übersetzt.

Die KDE2 Style/Theme engine war wesentlich mächitger als die von Qt2.
Ab Qt3 können auch Qt Applikationen KDE Styles übernehmen, weil Qt da nachgezogen hat.

Wenigstens der Firma(!) Trolltech hätte ich es zugetraut, dass sie abwärtskompatibel bleiben. Die Major auf 3.0 war sowieso total für den arsc* , wegen der paar neuen features dasganze abi zu zerstören, aber naja....

Qt geht einfach nach einer anderen Prämisse vor.
Man will eine in sich konsistente API haben.
Andere Libhersteller gehen nach der Prämisse vor, dass die Lib immer Sourcekompatible bleibt.
Hat dann den Nachteil, dass es Inkonsitenzen in der API gibt (andere Parametertypen oder -reihenfolge bei Funktionen unterscheidlicer Releases, etc)

Ich weiß ja nicht wie viel du mit Qt arbeitest, aber die Qt3 ist eine wesentliche Verbesserung gegenüber Qt2.
Nicht nur die "neuen Features", die alleine schon eine neue Version rechtfertigen würden, auch die Verbesserungen an den vorhandenen Klassen.

sourcecode möglich sei. Was soll das bitte? Wenn ich unter Win95 eine MFC-App schreibe, mit dieser 7jahre alten Gui-Bibliothek(!!!!!), und ich führe das Zeugs dann unter WinXP aus, gibts da einfach keinen Unterschied! Dieser alte Mist wird integriert, als wenn es gar keinen Unterschied gäbe!

Die MFC ist ein gutes Beispiel für eine Bibliothek nach der Kompatible-um-jeden-Preis Prämisse.
Die ist so voller Altlasten, das mir schon schwindlg wird, wenn mir mein Wohnungskollege von den Problemen erzählt, die er damit hat.

Generell kann man sagen, dass ein Gui-Programm unter Linux 1 Jahr lang full-featured (Skins etc.) läuft, wenn man Glück hat, bleibt es 4-5Jahre lauffähig, danach muss man entweder Bibliotheken anpassen.

Das halte ich für eine ziemlich maßlose Übertreibung.
Es läuft eigentlich immer so full-featured, wie es am Anfang gelaufen ist.
Und wie lange gab es jetzt Gtk1?

Lösungsmöglichkeit:
Es müsste ein Programm geben, mit dem man Systemweit alle installierten Widgetsets mit ein und dem selben Theme ausstatten könnte. Natürlich kann nur das gescinnt werden, was auch von der grafikbibliothek die dann ne app darstellt, unterstützt wird.

Mal abgesehen davon, dass das nicht geht, weil Styles keine einfachen skins sind, will das ohnehin fast kein User.
Nicht umsonst hat fast jedes Windows Programm seine eigene Skin/Theme Engine

Alles mit gui und automatisch. QT Themes können in GTK1,2 themes oder auch in KDE-Themes umgewandelt werden, und mit dem Knopfdruck "Theme annhemen" werden alle widgetsets konfiguriert, automatisch antülich. Das funktioniert auch übers kreuz, also mit GTK2 oder KDE Themes.

Soweit ich mich erinneren kann, kann man GTK Pixmapthemes in KDe Pixmapthemes automatisch umwandlen.
Styles geht natürlich nicht, das würde dynamische C<->C++ Wrapper voraussetzen.

Ciao,
_

[Lin728]

..........................

[anda_skoa]

Original geschrieben von ceisserer

Dass KDE-Styles C++-klassen sind, die dynamisch geladen werden, ist zwar technisch brliant, aber naja, man siehts eben eh, nicht abwärtskompatibel.

Die Styles sind zumindest aus Qt Sicht dazu da, die Applikation auf einer Plattform immer wie diese ausehene zu lassen.
Darum gibt es eben einen Windows Style, SGI Style und Motifstyle.
Man nennt diese Art der Crossplattform GUI deshalb auch GUI Emulation.

KDELIBS:
Mir ist schon klar, dass diese dass Entwickeln sehr bescheunigen können, aber es ist halt schade, dass diese die Portablilität so einschränken. (Oder ärgert es dich nicht, wenn du wegen eines einzigen kleines Programms die ganzen GNOME-Libs nachinstallieren musst? (Geschweige denn von Windows zu sprechen)...

Für mich ist das portabel genug.
Wenn ich noch Nicht-Unix Plattformen brauche, kann ich Qt pur nehmen.
In diesem Fall merkt man dann aber, welche Funktionalität man zurück läßt.

Außerdem sind die KDE libs nur ein Paket.
Ich kenne kein größeres Programm, auch nicht unter Windows, dass ohne Plattform libs auskommt, ohne alles selber entwicklet zu haben (was wirklich nicht Sinn der Sache ist)

Für mich persönlich ist Libs nachinstallieren eh kein Thema (siehe sig )

Ja, vom Style schon. Aber es wird das farbschema von QT3 auf QT2 übertragen, was ohne gestylte widgts echt doof aussieht.

Ich verwende immer nur den Standardstyle und Standardfarbschema, darum ist mir das noch nicht aufgefallen.
Aber kann man das nicht einstellen, ob das übernommen wird?
In meinem KDE Kontrollzentrum gibt es da eine Checkbox unter "Farben" mit folgendem Text "Farben auf Nicht-KDE Programme anwenden"

API:
Natürlich, ne saubere Api kann für den Entwickler extrem erleichternd sein..
Für den User allerdings ist es eine gewisse Qual immer allle Lib-Versionen installiert zu haben...

Das ist leider auf allen Plattformen mit allen Libs so.

@Trolltech:
Die spinnen. Als ganz normaler Entwickler kann man sich doch keine Gui-Bibliothek um €3000 leisten?! Sicher für große Firmen ist das O.K., aber für ein-fünf mann firmen, die kleinserienprodukte individuell machen, ist das extremer wucherpreis!

Da muß ich dir widersprechen.
Unsere Firma ist sogar kleiner (2 Mann Vollzeit, 2 Mann Halbtags), Qt macht sich aber bezahlt.
Erstens wegen der guten Crossplattform Eigenschaften sowohl für GUI (unsere GUI läuft im Moment auf Win Clients, bei einem Kunden stellen wir aber auf Linux um) als auch für Non-GUI (unsere Serversoftware muß auf Tru64/Alpha, Solaris/Sparc und x86 laufen).
Zweitens wird auf Grund der sauberen API viel Zeit gespart.
Man muß sich mal anschaun, wie kompliziert es zum Beispiel in MFC einen Time zu verwenden, oder dass es drei (vielleicht sogar mehr) verschiedene Stringtypen gibt.

Normalerweise ist die Arbeitzeit eines Entwicklers ein wesentlicher finazieller Faktor, vorallem in kleinen Firmen.

MS hat schon erkannt, dass es wichtig ist, Entwicklerpakete kostenlos zu machen. Trollteh muss halt davon leben...

Na, die sind höchstens umsonst
Kostenlos sind sie sicher nicht.
Auf der at Seite von MS steht zum Beispiel, dass es günstige Schüler- und Studentenversionen von Visual Studio gibt.
Wenn es eh gratis ist, kann es wohl kaum günstiger sein.

Hab mal bei Geizhals nachgesehen:
Visual Studio 6.0 Professional EUR1465
Die Qt Professional kostet USD 1500
Mir ist schon klar, das bei VS mehr dabei ist, aber dafür bekommt man eine schrottige Classlibrary mit der man noch nicht mal die Option hat, auf eine andere Architektur oder Plattform zu gehen.

@jha:
Dann finde ich es aber die Distributoren sollten dass erledigen. Nur weil QT2 nicht mehr ganz so aktuell ist, heißt das noch lange nicht, dass ich bei QT2-Apps keine schönen, antialiased Fonts haben will...

Angeblich gibt es da eine Patentproblematik, die die Distributionen daran hindert, freetype anders zu kompilieren.
Aber Fontrendering ist sicher im Moment noch eine Schwachstelle von XFree.

Ciao,
_