1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Unix-Desktop: LXDE treibt Qt-Port…
  6. Thema

Qt vs GTK

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


  1. Re: Qt vs GTK

    Autor: nille02 05.07.13 - 20:22

    bstea schrieb:
    --------------------------------------------------------------------------------
    > Gibts denn mittlerweile GTK in einer aktuellen Version auf für Windows?

    Nein, 2.22 wird meist benutzt und das höchste der Gefühle ist 2.28

  2. Re: Qt vs GTK

    Autor: nille02 05.07.13 - 20:24

    Es deutet aber einen Trend an. Man hört auch öfters davon, dass Programme auf Qt Portiert werden, als auf GTK.

  3. Re: Qt vs GTK

    Autor: ubuntu_user 05.07.13 - 20:32

    nille02 schrieb:
    --------------------------------------------------------------------------------

    > Schon mal GTK unter Windows benutzt? Nur bestimmte Versionen lassen sich
    > überhaupt Kompilieren und anfühlen tun sie sie sich wie Fremdkörper.

    das liegt auch daran, dass gtk alles mögliche nutzt.
    cairo, gobject, usw. alles kann dann mit ner anderen version nicht mehr funktionieren oder es gibt keine ports. dazu ist dann keine ide dabei.
    bei qt habe ich alles in einem installer. IDE gleich dabei. in visual studio kann ich das auch einbinden, genauso wie mit makefiles + konsole. die meisten sachen sind auch logisch aufgebaut. (QHash, QHostAddress, usw)

    im gegensatz zu gtk:
    https://developer.gnome.org/gtk-tutorial/2.90/x1100.html


    gtk_calendar_get_date (GTK_CALENDAR (data->window),
    &year, &month, &day);
    g_date_set_dmy (&date, day, month + 1, year);

    also ich sehe da wenig sinn drin das nicht objektorientiert zu machen.

  4. Re: Qt vs GTK

    Autor: /mecki78 05.07.13 - 20:52

    nille02 schrieb:
    --------------------------------------------------------------------------------
    > Es deutet aber einen Trend an. Man hört auch öfters davon, dass Programme
    > auf Qt Portiert werden, als auf GTK.

    Das liegt glaube ich daran, das Qt eine C++, GTK jedoch eine C API ist. Es ist ja auch bei nicht UI Apps viel eher der Fall, das eine funktionelle C App zu einer Objekt-orientierten C++ App wird als umgekehrt. Wer bitte geht denn von OO Programmierung zurück auf Funktionelle Programmierung?

    Allerdings ist OO eben auch nicht der Weisheit letzter Schluss und die Lösung aller Probleme, weswegen viele Programmierer C++ vermeiden, wenn sie der Meinung sind, das C alles bietet, was sie zu ihrem Glück brauchen. Und Qt von C aus zu verwenden, ist zwar theoretisch möglich, aber nur über eine C-C++ Brücke. D.h. der UI Code ist dann in C++ geschrieben, der Rest der App in C und irgendwo gibt es eine Brücke, die zwischen diesen "beiden Welten" vermittelt. Das ganze Konzept ist aber so aufwendig, dass man sich natürlich die Frage stellen muss, warum machen wir nicht gleich alles in C++?

    C++ hat aber in der Linux Welt immer noch einen schlechten Ruf. Die meisten Linux Apps und Libraries sind nach wie vor in C geschrieben. Unter Windows ist es eher umgekehrt, hier ist C++ eigentlich mehr oder weniger normal, jede größere, besser Windows App ist in C++ geschrieben (und benutzt höchstens noch C, dort wo Objekte unnötig sind oder keinen Sinn machen, bzw. dort wo es auf Low Level System Funktionen zugreifen muss, die auch nur eine C API bieten). Am Mac sieht die Sache dann wieder ganz anders aus, denn hier ist Objective-C die Sprache der Wahl, die zwar auch C um Objekte erweitert, aber ganz anders aufgebaut ist als C++.

    Ich persönlich mag C++ auch nicht. C++ bietet Programmieren IMHO zu viele "Freiheiten". Das klingt paradox, aber C++ erlaubt viele Dinge, die die meisten anderen Sprachen (und das sind ja auch häufig OO Sprachen) aus guten Grund nicht erlauben, weil die Erfinder dieser Sprachen der Meinung sind, dass das zu schrecklichen Code Konstrukten führt - und die Praxis gibt ihnen leider häufig recht. Es ist aber sehr schwierig einen Programmierer zu verklickern, dass er zwar Prinzipiell etwas machen kann, aber eben nicht machen soll. Sicherlich kann man auch schrecklichen Java Code schreiben, aber da Java eben viele der "hässlichen Dinge" gar nicht anbietet, die es in C++ gibt, ist es eben deutlich schwieriger hier lange in die falsche Richtung zu laufen, ohne dass das irgendwann jemanden auffällt.

    Wobei ich hier nicht andeuten möchte, dass ich Qt schrecklich finde. Im Gegenteil, meine GTK Erfahrungen waren deutlich negativer. GTK versucht objekt-orientiertes UI Design zu ermöglichen, aber eben auf der Basis von reinem C. Da aber C eben nicht für so etwas geschaffen wurde, kommen hier Konstrukte und Syntaxe zum Einsatz, bei denen es sich letztlich natürlich um echten C Code handelt, die aber in ihrer "Hässlichkeit" oft kaum mehr zu überbieten sind. Wer aber mit aller Gewalt nichts von C++ Wissen will, der hat zu GTK kaum brauchbare Alternativen.

    /Mecki

  5. Re: Qt vs GTK

    Autor: Thaodan 05.07.13 - 22:18

    Eben nicht, was du meinst sind GNOME libs.

    Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
    -- Georg Schramm

  6. Re: Qt vs GTK

    Autor: Steffo 05.07.13 - 22:41

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Wer bitte geht denn von OO Programmierung zurück auf Funktionelle Programmierung?

    Es gibt keine funktionelle Programmierung, nur funktionale und das ist etwas ganz ganz anderes und btw. etwas sehr viel mächtigeres als es C oder gar OO-Sprachen bieten!

    L. G.
    Steffo

  7. Re: Qt vs GTK

    Autor: hb 06.07.13 - 14:12

    Thaodan schrieb:
    --------------------------------------------------------------------------------
    > Eben nicht, was du meinst sind GNOME libs.

    Nein, ich meine GTK+ und seine Basis (die du übrigends je nach Geschmack ihrerseits als GNOME-Libs betiteln kannst, oder auch nicht - da gibts keine klare Definition).

    Wenn du unter Qt alle Teil-Libs verstehst (QtCore, QtGui, QtXml, ...) - aber glib/GObject/GIO/... nicht als Teil von GTK+, dann argumentierst du nicht sachlich.

  8. die Brüche haste in Windows auch

    Autor: Kaiser Ming 06.07.13 - 14:22

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > umgekehrt. Ja, sie funktioniert, ja, man kann sie bedienen, aber es ist
    > einfach ein massiver Bruch, den du so in Windows oder OS X bei nativen Apps
    > nie derart erleben wirst (oder wenn, dann nur eher selten, meistens bei

    zum einen durch Microsoft selbst durch ständige Änderungen der GUI Richtlinien
    als auch Progamme die die GUI selbst zeichnen, das sind sowohl Fremd als auch Microsoftprogramme

    Apple ist in der Beziehung erheblich stringenter (bei aller sonstigen Kritik ;)



    1 mal bearbeitet, zuletzt am 06.07.13 14:23 durch Kaiser Ming.

  9. Re: die Brüche haste in Windows auch

    Autor: nille02 06.07.13 - 14:51

    Kaiser Ming schrieb:
    --------------------------------------------------------------------------------
    > Apple ist in der Beziehung erheblich stringenter (bei aller sonstigen
    > Kritik ;)

    Apple Interessiert sich aber auch nicht sonderlich für Abwärtskompatibilität und die Kunden machen hier auch mehr druck ein passendes System Look and Feel zu bekommen.

    Unter Windows versuchen sich ja die Hersteller durch eigene GUIs leider von der Masse abzuheben.

  10. Re: Qt vs GTK

    Autor: Seitan-Sushi-Fan 06.07.13 - 16:15

    /mecki78 schrieb:
    ------
    > 2) Alle Apps hören auf Qt und GTK direkt zu nutzen, sondern verwenden nur
    > noch abstrahierende Libraries, die dann wahlweise, je nachdem was der
    > Nutzer bevorzugt, die UI über Qt oder über GTK zeichnen (wovon der App
    > Entwickler selber aber wieder nichts mitbekommen oder wissen muss).

    Gibt's doch schon. Nennt sich Qt. Qt kann problemlos GTK-Theme-Engines laden und macht das unter GTK-Umgebungen auch standardmäßig.
    Das fremde Anfühlen kommt von unterschiedlichen HIGs. Es gibt keine technsichen Gründe, weshalb man nicht Qt-Anwendungen, die den GNOME-HIGs folgen, entwickeln sollte. Punktuell (Button-Reihenfolge, Öffnen/Speichern-Fenster) passen sich reine Qt-Anwendungen auch automatisch an.

  11. Re: Qt vs GTK

    Autor: Seitan-Sushi-Fan 06.07.13 - 16:18

    /mecki78 schrieb:
    ----------------------------------------
    > Bonita.M schrieb:
    > -------------------------------------
    > > Aber wart ab; GTK ist eh irgendwann tot.
    >
    > Wie kommst du da drauf? Nur weil jetzt Ubuntu auf Qt wechseln will und LXDE
    > ein paar Apps auf Qt umgezogen hat? Das hat nun wirklich nichts zu sagen,
    > IMHO.

    Das Gnome-Projekt nutzt für ihre Shell und diverse neue Anwendungen (Boxes fällt mir spontan ein) kein GTK mehr, sondern ein separates Toolkit auf Clutter-Basis.

  12. Re: Qt vs GTK

    Autor: hb 06.07.13 - 16:41

    Seitan-Sushi-Fan schrieb:
    --------------------------------------------------------------------------------
    > Das Gnome-Projekt nutzt für ihre Shell und diverse neue Anwendungen (Boxes
    > fällt mir spontan ein) kein GTK mehr, sondern ein separates Toolkit auf
    > Clutter-Basis.

    Wenngleich du Recht hast, dass viel über Clutter geht, ist die Aussage, dass kein GTK+ mehr genutzt wird, natürlich Unsinn.

  13. Re: Qt vs GTK

    Autor: Seitan-Sushi-Fan 06.07.13 - 16:57

    hb schrieb:
    -----------------------------------------------
    > Wenngleich du Recht hast, dass viel über Clutter geht, ist die Aussage,
    > dass kein GTK+ mehr genutzt wird, natürlich Unsinn.

    Diese Aussage habe ich auch nicht getätigt. Ich schrieb, dass für viele (aber nicht alle) Gnome-Neuentwicklungen kein GTK mehr genutzt wird.
    Beleg für den Rückgang an Bedeutung für GTK isse in jedem Fall.

  14. Re: Qt vs GTK

    Autor: Thaodan 06.07.13 - 18:56

    Glib und ist kein direkter Teil von GNOME. Viele nicht GNOME Programme wie Pulseaudio oder Telepathy nutzen dies.

    Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
    -- Georg Schramm

  15. Re: Qt vs GTK

    Autor: hb 06.07.13 - 21:40

    Und der Bezug zum Thema ist...?

  16. Re: Qt vs GTK

    Autor: Thaodan 06.07.13 - 21:47

    Und der Bezug zum Thema bei deinem Post darüber?
    Mir geht es darum das durch aus Glib und Qt verwendet wird. Aber nicht GNOME Libs und Qt.

    Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
    -- Georg Schramm

  17. Re: Qt vs GTK

    Autor: hb 06.07.13 - 22:42

    Seitan-Sushi-Fan schrieb:
    --------------------------------------------------------------------------------
    > > Wenngleich du Recht hast, dass viel über Clutter geht, ist die Aussage,
    > > dass kein GTK+ mehr genutzt wird, natürlich Unsinn.
    >
    > Diese Aussage habe ich auch nicht getätigt.

    Doch, und zwar praktisch wörtlich. Ich bezog mich auf die von dir zitierten Projekte (das war aus dem Teil, den ich von dir zitiert habe, auch eindeutig - schade, dass du den Kontext sinn-entstellend gesnippt hast).

    > Ich schrieb, dass für viele
    > (aber nicht alle) Gnome-Neuentwicklungen kein GTK mehr genutzt wird.

    Natürlich wird es auch in diesen Projekten genutzt. Schonmal versucht, die von die erwähnten Projekte ohne GTK+ zu übersetzen?

    > Beleg für den Rückgang an Bedeutung für GTK isse in jedem Fall.

    Das mag ja deine Meinung sein - ich finde sie eher exotisch. Zumal Kern-Entwickler der von dir genannten Projekte ihrerseits nach wie vor zu den größten Contributoren von GTK+ zählen... Interessante Logik.

  18. Re: Qt vs GTK

    Autor: hb 06.07.13 - 22:44

    Thaodan schrieb:
    --------------------------------------------------------------------------------
    > Und der Bezug zum Thema bei deinem Post darüber?
    > Mir geht es darum das durch aus Glib und Qt verwendet wird. Aber nicht
    > GNOME Libs und Qt.

    Es gibt keine allgemeingültige Definition, was GNOME Libs sind. Du kannst GTK+ und GLib gerne dazuzählen, oder auch nicht - je nachdem, was du unter "GNOME Lib" verstehen willst.

    Das ist aber dafür, was GTK+ bietet, und was nicht, bzw was Qt bietet und was nicht, völlig egal und off-topic. Deren Feature-Sets ändern sich nicht durch deine Namens-Definition. Deshalb die Frage nach dem Bezug.

  19. Re: Qt vs GTK

    Autor: tundracomp 07.07.13 - 21:05

    So ein platformunabhäniges Toolkit gibt es schon seit Jahren:
    http://www.wxwidgets.org
    Unstützt natives "Widget" Rendering mit diversen Platformen:
    Windows (MFC), Windows CE, Windows Mobile, Palm OS, Symbian, Mac OS, Unix/Linux (GTK oder X11)

    Blöderweise fehlt Android und Qt, aber sonst wird wohl so zeihmlich alles abgedeckt...

  20. Re: die Brüche haste in Windows auch

    Autor: Kaiser Ming 08.07.13 - 13:04

    nille02 schrieb:
    --------------------------------------------------------------------------------
    > Kaiser Ming schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Apple ist in der Beziehung erheblich stringenter (bei aller sonstigen
    > > Kritik ;)
    >
    > Apple Interessiert sich aber auch nicht sonderlich für
    > Abwärtskompatibilität

    da ist was dran, ist allerdings ein anderes Thema imo

    > und die Kunden machen hier auch mehr druck ein
    > passendes System Look and Feel zu bekommen.

    Apple hatte schon ein durchdachtes und hübsches Interface bevor die Kunden hatten
    (nein ich bin kein Applefreund ;)

    >
    > Unter Windows versuchen sich ja die Hersteller durch eigene GUIs leider von
    > der Masse abzuheben.

    weils Micki erstmal mehr oder weniger Wurst ist, solange die Leute ihr Zeug kaufen
    zum anderen waren die Oberflächen entweder sehr technisch oder im Gummibärendesign

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Dürr Systems AG, Goldkronach
  2. NOVO Interactive GmbH, Rellingen
  3. Hays AG, München
  4. Loy & Hutz Solutions GmbH, Freiburg im Breisgau

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de