ubuntuusers.de

@mat69
Korrigiere mich wo ich falsch liege statt einfach nur rumzufrotzeln. Die GTK-Qt Theme Engine ist nicht von Trolltech und wurde schon 2004 ins leben gerufen.

area42 hat geschrieben:

@mat69
Korrigiere mich wo ich falsch liege statt einfach nur rumzufrotzeln. Die GTK-Qt Theme Engine ist nicht von Trolltech und wurde schon 2004 ins leben gerufen.

David Sansome ist kein GTK-Entwickler. 🙄
Und stimmt schon, Trolltech entwickelt Qt – genauso wie die GTK-Entwickler GTK – is aber nicht so, als würden die nicht auf Feedback etc. hören (bestes Beispiel ist Phonon).

area42 hat geschrieben:

@ppcuser
Ja ich finde solche Diskussionen auch nervig und kann Dir nur zustimmen.

@jtoegel
Das GTK-Apps das aussehen der QT-Umgebung annehmen können ist eine Errungenschaft der GTK-Entwickler.
Das Trolltech das nach Jahren Verspätung auch mal für QT macht ist schön, aber ist auch deren Aufgabe und nicht der GTK-Entwickler.
Niemand anders ausser Trolltech kann das QT-Toolkit entwickeln.

So ein Schwachsinn. Nix da Errungenschaft der GTK-Entwickler, xxxxxxxx. Das war eine Initiative von Leuten aus dem KDE-Umfeld, gerade auch weil das Default-GTK-Theme so ausnehmend häßlich ist. Also hör auf, hier FUD zu verbreiten.

Bitte mäßige deinen Tonfall jtoegel 👿

jtoegel hat geschrieben:

So ein Schwachsinn. Nix da Errungenschaft der GTK-Entwickler, xxxxxxxx. Das war eine Initiative von Leuten aus dem KDE-Umfeld, gerade auch weil das Default-GTK-Theme so ausnehmend häßlich ist. Also hör auf, hier FUD zu verbreiten.

Moderiert von elendil:

Beleidigung entfernt...

Hm, also wenn man fälschlicherweise schreibt, QGTK sei von GTK-Devs geschrieben, verbreitet man Fear, Uncertainty and Doubt? Aber sonst geht's dir noch gut?

Sollte man nicht eher dümmliches, falsches und uninformiertes Gepöbel, wie den ..., den du hier absonderst, als FUD bezeichnen. Was ist zum Beispiel mit deiner völlig an den Haaren herbeigezogenen Behauptung, D-Bus sei im Vergleich zu DCop ein Rückschritt?

http://www.kuliniewicz.org/blog/archives/2007/12/12/cop-versus-bus-d-edition/

Dbus ist im Vergleich zu Dcop irrsinnig umständlich, ohne dass dafür ein Grund besteht. Dcop kann teilweise sogar mehr als D-Bus, bei viel einfacherer Benutzung.

Ach komm, die Kritik zerfällt bis auf das d-bus calls länger sind. Die Ursachen dafür muss er aber selbst einräumen und auch wie irrelevant das ist, es geht um IPC und nicht Mensch-Maschine-Kommunikation. Wesentliche Aspekte, wie das dbus ohnehin bei jeder modernen Distribution faktisch laufen muss und wie sinnvoll es ist das aus der DE auszugliedern, (Was soll ich mit 5 IPC Modellen?) lässt er weg und kommt letztlich auch zu dem Schluß, dass dbus mehr Vorteile hat.

Metathemen wie das Initialisieren allübergreifender Standards mal völlig außen vor gelassen.

Der Entwickler der GTK-Qt Theme Engine (David Sansome) hat sich meines Wissens nach nie dazu geäussert, welche Desktopumgebung er verwendet. Aber halten wir uns mal folgende Umstände vor Augen:

1. David Sansome veröffentlicht Anfang 2004 seine Theme Engine. Auf KDE Seite sehen plötzlich GTK+ Programme akzeptabel aus.
2. Auf GNOME/GTK+ Seite sehen KDE Programme weiterhin grausig aus. Erst Qt Entwickler Trolltech setzt der traurigen Situation ein Ende.

Meine Frage nun: Wenn Herr Sansome GTK+/GNOME Entwickler (und Anwender) wäre, warum würde er 4+ Jahre grottenhässliche KDE Programme auf seinem Desktop dulden, ohne eine Lösung zu programmieren? Es liegt also meiner Meinung nach eher nahe, dass es sich bei Herr Sansome um einen KDE Benutzer handelt. Auch wenn sich einige GNOME Anwender auf den Schlips getreten fühlen, bleibt es doch ein Faktum, dass seitens GNOME keinerlei ernsthafte Anstrengungen unternommen wurden KDE Programme zumindest minimal in den Desktop zu integrieren.

@adun: Nein, es geht auch um Mensch-Maschine Kommunikation. Wenn man zum Beispiel mal schnell eine bestimmte Aktion in einem Programm ausführen will, dann geht das unter KDE3 ganz einfach, man setzt einfach einen DCop-Call ab. Oder wenn man mit einer bestimmten Tastenkombination eine spezielle Aktion auslösen will - DCop. Und nebenbei: Die Programme werden immer noch von Menschen entwickelt, und solche unnötig komplizierten Sachen schrecken schon extrem ab, zumal sie viel zusätzlichen Aufwand bedeuten.

@Erunno: Das habe ich schon vorhin geposted (zumindest die Aussage am Ende 😉 ), aber die Gnomies wissen es ja besser.

Hmm, komische Sache. Skype will noch nicht so richtig. Wenn ich Skype starte hat es das normale graue KDE-Theme. Wähle ich bei den QT-Einstellungen GTK, wird es im Skypefenster übernommen. Schließe ich aber Skype und starte es wieder, kommt wieder das hässliche KDE-Grau, bis ich bei QT wieder auf GTK stelle (also erst auf etwas anderes wechsle und dann nochmal zu GTK zurückstelle). 😕

jtoegel hat geschrieben:

http://www.kuliniewicz.org/blog/archives/2007/12/12/cop-versus-bus-d-edition/

Vielleicht solltest du die Sachen auch mal lesen. Oder würde dich das überfordern.
Ich zitiere mal aus dem von dir verlinkten Artikel:

I’m not going to go into the technical merits of each, or any of their implementation details. I’m only looking from the perspective of someone trying to write some Python code that interacts with other programs via D-Bus or DCOP.

However, there’s a more obnoxious problem with DCOP when compared to D-Bus. Although D-Bus is used by GNOME, it’s not actually part of GNOME; it’s a freedesktop.org project with minimal dependencies. So, if D-Bus isn’t already running (which in GNOME is pretty unlikely anyway), there isn’t that much the library has to do to start it up.

DCOP, on the other hand, is a part of KDE itself, and to assure that it’s running, it’s necessary to initialize at least the base set of KDE services. Remember that code in the Python DCOP example I didn’t show you before? Here’s what it is:

So, while DCOP does have simplicity going for it, D-Bus ends up providing a more robust Python interface and lower initialization overhead, which are both big plusses when you want your program to be small and responsive.

Sehr überzeugend...

Und wer meint, es sei eine gute Idee, Programme von Hand dadurch zu steuern, indem man mal kurz einen IPC-Call absetzt, hat nicht mehr alle Tassen im Schrank.

Wenn du dein kleines Köpfchen mal dazu einsetzen würdest, dich kurz damit zu beschäftigen, warum dbus komplexer ist als dcop und in welchem Verhältnis die beiden zueinander stehen, würde es dir vielleicht auch zumindest einmal in deinem Leben gelingen, ein Posting zu schreiben, in dem du dich nicht komplett lächerlich machst.

DCop kann ich als User ohne mehr als 20 Stunden Einarbeitungszeit bedienen, D-Bus nicht.

Und wer meint, es sei eine gute Idee, Programme von Hand dadurch zu steuern, indem man mal kurz einen IPC-Call absetzt, hat nicht mehr alle Tassen im Schrank.

Nur weil du es nicht schaffst, heisst das nicht dass es scheiße ist. Es ist sogar eine sehr gute Idee, und zusammen mit dem mächtigen Keybindingwerkzeugen von KDE 3.5.9 extrem praktisch. So kann ich zum Beispiel Tastenkombinationen dazu benutzen, um Amarok komplett ohne Maus zu steuern.

Ich bin kein Entwickler, aber sollte ich mal einer werden würde ich mit Sicherheit DCop D-Bus vorziehen. Manchmal ist weniger Komplexität eben doch mehr, auch wenn D-Bus etwas mehr kann.

Na ja, in diesem Falle bin ich aber auch für jeden Schritt dankbar, den GNOME und KDE aufeinander zugehen. Mein persönlicher Wunsch wäre eine gemeinsame Passwortverwaltung. Schade, dass sich in die Richtung bis jetzt nur wenig getan hat.

Was cool wäre ist ein DCop-D-Bus-Wrapper, nachdem D-Bus "umfangreicher" ist als DCop müssten sich DCop-Calls recht gut auf D-Bus-Calls übertragen lassen...

Edit: Ja, eine gemeinsame Passwortverwaltung wäre super, darüber wurde ja auch schon ein bisschen auf PlanetKDE geredet...

jtoegel hat geschrieben:

Was cool wäre ist ein DCop-D-Bus-Wrapper, nachdem D-Bus "umfangreicher" ist als DCop müssten sich DCop-Calls recht gut auf D-Bus-Calls übertragen lassen...

Edit: Ja, eine gemeinsame Passwortverwaltung wäre super, darüber wurde ja auch schon ein bisschen auf PlanetKDE geredet...

dcop gibts doch bald nicht mehr also überflüssig oder