Sicuramente chi utilizza un sistema operativo GNU/Linux, ma anche chi programma, avrà sicuramente sentito parlare dei GUI framework GTK e Qt, nati e sviluppati per permettere la creazione, in modo più o meno semplice, di interfacce grafiche per utilizzare programmi di qualsiasi natura. Chi non li ha mai utilizzati o non bazzica questo ambiente da tanto tempo potrebbe però non conoscere le reali differenze tra l’uno e l’altro framework, dopo essermi documentato un po’ ho deciso quindi di fare un piccolo articolo per fare un po’ di luce sulle differenze fra i due ambienti.

Un po’ di storia:

Volendo parlare brevemente della storia di questi framework, il primo a vedere la luce è stato Qt nel Maggio 1995, mentre GTK è nato nell’Aprile 1998. Per quanto riguarda lo sviluppo, quello di Qt è passato per le mani di ben 5 gruppi diversi (Trolltech è quello originale), addirittura negli ultimi 8 anni ci sono state ben 4 compagnie che hanno cercato di mettere le mani su Qt, e se nessuno può mettere in dubbio la maturità e stabilità del prodotto, non altrettanto si può dire della sua proprietà, comunque la compagnia che attualmente lo possiede, la Qt Company (che è community driven), pare aver portato un po’ d’ordine in questo caos. Per quanto riguarda GTK invece, esso è stato sviluppato sempre e soltanto dal progetto GNOME.

Qt Framework -1

Struttura, applicazioni e desktop environment:

Volendo parlare di struttura e realizzazione, Qt è un framework completo ed è scritto in C++ mentre GTK è solamente un GUI toolkit scritto in che si appoggia sul library stack di base GObject. Per quel che riguarda le performance non ci sono dati che palesano risultati migliori di uno rispetto all’altro: lanciare un’applicazione Qt in un’ambiente desktop GTK richiederà parecchio tempo (questo a causa del “caricamento a freddo” di tutte le librerie) e la stessa cosa vale al contrario.

Per quanto riguarda la loro diffusione nel campo dei desktop environment sicuramente GTK gode di una maggior presenza, sono infatti moltissimi i DE che si appoggiano su tale framework, mentre quelli Qt-based sono soltanto KDE Frameworks (ma non tutto quello che riguarda il mondo KDE è basato su Qt) ed LXQt.

Passando al numero di applicazioni che sfruttano i due ambienti, anche qui GTK vince nettamente sulla sua controparte, principalmente a causa del fatto che i DE Qt-based sono arrivati dopo. Le cose però stanno cambiando velocemente. Ogni giorno sono infatti sempre di più le applicazioni che passano a Qt (per esempio Dropbox, Wireshark ed OpenShot) mentre casi di migrazione nell’altro senso sono quasi inesistenti e ciò probabilmente è dovuto al fatto che GTK tende ad essere completamente “GNOME-centrico” e che il mercato desktop si trova in una fase di evidente stallo, mentre Qt sta spianando la strada per poterlo utilizzare anche con Android ed iOS.

gtk framework -1

Conclusioni:

Per quanto riguarda le piattaforme di utilizzo, Qt cerca sempre di più di conformarsi come un ambiente multi-piattaforma mentre ciò non accade per GTK (anche se in realtà entrambi possono girare su sistemi operativi diversi), cosa del tutto comprensibile dato che GTK è legato in un modo o nell’altro a GNOME. Volendo metterci in un’ottica volta a cercare di prevedere cosa ci riserverà il prossimo futuro possiamo sicuramente dire che Qt sta percorrendo una strada che lo porterà a sbarcare su dispositivi di qualsiasi forma mentre non è altrettanto facile capire come si muoverà GTK dato che molti DE lo supportano di default ma che è molto difficile portarlo al di fuori dei desktop senza delle pesanti modifiche.

Qui si conclude la mia breve panoramica sui GUI Toolkit framework. E voi che ne pensate di questi due ambienti? Quale preferite? Condividete con noi le vostre impressioni!

[Fonte]

  • Ilgard

    Non conosco molto bene le applicazioni, ma di sicuro QT è un passo avanti a Gnome, che pian piano sta diventando sempre più un mondo a sé.

    • floriano

      esclusiva redhat (come sistemd)

      • Rehdon Lofgeornost

        Con la differenza che systemd è stato adottato da quasi tutte le maggiori distribuzioni.

        • floriano

          perché è stato scelto da Debian che è la mamma di quasi tutte le derivate

          • michele casari

            non me lo ricordare, sto ancora dubitando che abbiano fatto la scelta giusta.
            Per fortuna che c’è slackware

          • Teo

            C’è anche Devuan se vuoi.

          • michele casari

            Stanno ancora sistemando la versione 6, la old stable. Credo poco nel progetto nato di impulso e dopo la spinta emotiva se la base non è stabile finirà presto.
            Se non sbaglio in Arch puoi scegliere di non usare systemd

          • Samael

            Teoricamente no, perché Arch supporta solo systemd.
            Tuttavia, puoi usare OpenRC o sysvinit che sono mantenuti dalla comunità.

            Il punto è: ne vale la pena? Sbattersi per mettere OpenRC o sysvinit che non fanno niente di più o meglio di quanto già non faccia systemd?
            Voglio dire, io da utente Slackware faccio uso di INIT System V e la cosa mi sta bene. Funziona e fa il suo dovere.
            Ma lo stesso dicasi quando do un’occhiata ad Arch, che fa uso di systemd.

          • michele casari

            systemd non fa solo l’init, si è fagogitato enne servizi che prima giravano come demoni a parte (demoni e non). sytemd usa il pid 0 che prima era usato dal kernel.
            Intendiamoci io sono un incompetente e mi baso sul sentito dire da chi ne sa più di me, ma non ho trovato smentita in rete dei ‘danni’ (altri li condiderano un bene) di systemd, se aggiungi che è un software RedHat (ottima azienda che fa ottimo software che contribuisce molto al kernel, ma rimane una azienda privata), c’è poco da stare allegri.

          • Samael

            No, michele. Stai facendo confusione.
            systemd usa il PID1 che è il PID storico di /sbin/init. Ma lo usa perché il compito di systemd è proprio quello di sostituire INIT System V e non di fare supervisione esterna (sebbene sia comunque possibile), come fanno supervisord e God.

            systemd ha incorporato parecchie parti dello userland di Linux, è vero. Ma nessuna di queste gira in PID1. Sono tutti demoni separati che hanno gli stessi compiti dei precedenti, ma con differenze sostanziali.
            In PID1 ci gira solo il gestore dei servizi e ad esso fanno riferimento diretto solo systemd-journald e systemd-logind.
            systemd-journald comunica con systemd perché ha il compito di registrare *qualsiasi* avvenimento accada nel sistema, non soltanto l’output che stampavano i singoli demoni in syslog. Journald infatti registra persino il contesto SELinux in cui ogni singolo servizio gira.
            systemd-logind comunica con systemd perché ha bisogno di capire lo stato del sistema per poter gestire una sessione di login.
            A questi ci si aggiunge systemd-networkd che ha il compito di inizializzare lo stack di rete, dalle interfacce ai server ad esse collegati.

            Tutti i restanti componenti che fanno parte di systemd: systemd-machined, systemd-timedated, systemd-hostnamed ecc. sono tutti componenti opzionali, che sono stati implementati perché su Linux non è mai esistito uno userland proprio.
            GNU/Linux è un ammasso di componenti prese da altri progetti, GNU in primis, ma non è un sistema operativo integrato, come invece avviene da sempre su UNIX.
            Il che vuol dire che se il kernel o un componente nello userland espone una tecnologia è difficile che le altre parti la adottino per integrarsi, perché ogni componente è sviluppato in maniera indipendente, con obbiettivi propri.
            Questo è quanto più lontano accade rispetto alle altre piattaforme UNIX, dove il kernel e lo userland sono sviluppati insieme e quindi quando viene sviluppata una tecnologia viene subito estesa a tutti.
            systemd sta facendo la stessa cosa, creando uno userland su misura per Linux che permetta di esporre le numerose funzionalità del kernel nello userspace. In particolar modo namespace e cgroup.

            Riguardo alla mancanza di smentite sui danni di systemd la risposta è presto detta: non ci sono smentite perché i “danni” stanno solo nella testa di chi li pensa. Ad oggi di tutte le accuse e le preoccupazioni mosse sul futuro di systemd non c’è niente di concreto, ma solo chiacchiere.
            Ed intanto *tutti* i sistemi operativi enterprise Linux lo hanno adottato: RHEL, SLES, Oracle Linux, Ubuntu.
            Tra l’altro ciò che fa systemd non è nemmeno niente di nuovo, dato che le idee sulla quale è stato progettato si rifanno a SMF di Solaris e launchd di OSX. Entrambi strumenti che esistono da più di un decennio e che funzionano a tutti i livelli, dal singolo PC domestico ai datacenter.

          • michele casari

            Grazie.

          • alex

            Ecco, i commenti per cui vale la pena fare un salto su LFFL… grazie!

          • How The West Was Won

            Informarsi prima di scrivere please. Non hanno mai avuto a che fare con la oldstable ed è nato tutt’altro che d’impulso. Gran parte degli sforzi iniziali sono serviti a mettere su un’infrastruttua in grado di garantire una solida base. Comunque la beta di devuan jessie è disponibile già da un pezzo, quindi non c’è da “credere” o “non credere” ma soltanto testare.

          • michele casari

            Scusa ero convinto che fossero alla 6.

            Sugli sforzi fatti non c’è dubbio.
            Sarà una mia impressione, ma la devuan è nata dopo cuocenti polemiche dell’adozione di systemd, per questo la gidico nata d’impulso, e sarà solo il tempo a decretarne il successo o un triste declino.

  • rohmable

    Qualche mese fa ho dovuto creare un programma in C con le GTK e le ho trovate molto scomode: devo ancora conoscere qualcuno che si trova bene con Glade e non ha mai incontrato bug o crash che fanno perdere tempo, sinceramente non credo che scrivere l’intera interfaccia grafica all’interno del programma sia qualcosa di lungimirante.

  • Marco

    GTK sono nate come toolkit grafico del software Gimp (GTK sta per Gimp ToolKit) e poi successivamente sono state adottate dal DE Gnome per sostituire le vecchie librerie Motif.

    Da sviluppatore, se io dovessi oggi iniziare a sviluppare un software multipiattaforma utilizzerei le Qt per diversi motivi, uno tra tutti il che esiste un IDE (Qt Creator) che permette di lavorare agevolmente.

    Purtroppo sulle Qt c’è sempre stato lo spettro della licenza essendoci dietro aziende commerciali (se non mi sbaglio la Qt Company è stata creata dalla Digia, che ha acquisito le licenze dalla Nokia), e per questo motivo non sono mai state favorite per lo sviluppo applicazioni open (da ricordare che comunque ad oggi la licenza è LGPL se non erro, quindi una licenza FLOSS).

  • Kib

    I programmo pirncipalmente per il mondo Web e le poche volte che ho dovuto fare client desktop mi sono appoggiato a Qt.
    Poi sono un patito di KDE quindi ho sempre odiato il fatto di dovermi installare anche librerie GTK solo perchè molti software in Linux sono sviluppati con quelle librerie.

  • floriano

    in qt dovrebbe esserci anche il nuovo unity e deepin desktop

    • Valerio Pizzi

      anche lumina desktop

      • Rehdon Lofgeornost

        Quanti desktop che non ho mai sentito nominare prima! Ma immagino che siano fork di altri esistenti? Qualche link? grazie.

        • ange98

          Il Lumina desktop mi pare che sia scritto da 0 e fornito da PC-BSD.
          Andando a curiosare di chi sia il progetto, risulta infatti nel github dei dev di PC-BSD. È inoltre fatto notare dai dev stessi che è pensato maggiormente per FreeBSD, ma è comunque avviabile anche su molte distro Linux (sul sito ufficiale ci sono tutte le istruzioni per compilarlo).
          Deepin è il DE di Deepin Linux, distro ubuntu-based della quale è stato fatto un articolo su questo blog pochi giorni fa (assomiglia molto a OS X).
          Unity è invece il DE di default di Ubuntu e con la sua versione 8, sarà scritto in Qt.

  • Danilo

    Io l’ho detto anni e anni fa che le Qt erano molto più avanzate delle GTK, e ho sempre sostenuto che Canonical avrebbe fatto bene a creare il proprio DE basando su KDE4, visto che permette di creare un ambiente totalmente custom. Ma a quanto pare le mie erano solo eresie (da programmatore che ha utilizzato entrambi)… E oggi sviluppano in Qt anche loro hahahahah poche volte su queste cose ho avuto torto sarà che forse ci vedo lungo 😛

    • loki

      le qt sono un conto, kde è una cosa ben diversa… per fortuna che almeno loro se ne sono resi conto

      • Danilo

        Dove ho scritto che hanno usato KDE? ma sapete leggere?

        • MoMy

          Però hai scritto ”basando su kde4”, è ovvio che chi legge pensa a kde4 nella sua interezza. :

          • Maudit

            Ha scritto così perché Ubuntu prima di Unity era basato su Gnome 2, mentre l’alternativa di quel periodo era KDE 4.

            KDE 4 era anche il DE preferito di Mark Shuttleworth.

            Ubuntu utilizza tutt’ora il parco software di Gnome, quindi per quanto presenti una shell diversa (Unity) è basato su Gnome, e non semplicemente sulle librerie GTK.

            Quello che lui sta dicendo è che se fossero partiti da KDE come desktop ufficiale, oggi Unity, con le librerie QT, godrebbe di una maggiore continuità con il resto del sistema.
            Ed io sono ben lieto del fatto che siano rimasti lontani dal parco applicazioni di KDE, Canonical non porta nulla di buono ai progetti da cui attinge.

          • Danilo

            Esattamente, se avessero preso kde4 a quei tempi, tolto plasma e preso tutti i vari software ora ubuntu sarebbe un SO molto più completo. Nel 2016 le notifiche ancora non sono clickabili, nautilus rispetto a dolphin è veramente minimale, e così dicendo per tutti i software gnome. E non parlo a vanvera visto che uso a lavoro ogni giorno gnome shell. Senza parlare del fatto che con KDE avrebbero avuto tutto un sistema di render ampiamente supportato e in sviluppo a differenza di compiz che era già morente a quei tempi. Però a quanto pare sono io che non ci vedo lungo secondo questi sigonri XD

          • MoMy

            Sì! La mia osservazione era sul modo di porsi e non sul concetto. 😛

        • loki

          infatti ho detto per fortuna che tu non sei nostradamus e kde non l’hanno manco preso in considerazione

    • gabriele tesio

      Unity 8 non è basato su kde4… ne su un qualsiasi kde, è scritto da 0.

      • floriano

        unity 8 è basato sulle qt, senza passare per kde hanno fatto tutto da zero….

        • Ilgard

          QT è un framework esterno a KDE.

      • Danilo

        Infatti hanno fatto una gran cacchiata, ora così ti porti dietro tutta la roba in gtk più tutta quella in Qt. Se avessero usato un IDE già basato sulle Qt, come KDE, si eviterebbero queste porcherie. Secondo me non sapete leggere non ho mai detto che Canonical utilizza le librerie di KDE ma le Qt.

        • gabriele tesio

          Kde non è una IDE, ma il nome di una comunità, KDevelop è un’IDE, e prendere come base Kde non implica il non portarsi dietro le gtk, perchè basta che ci metti un software che le usa e ce le hai.

          • Danilo

            Leva la I da IDE e capirai di cosa stavo parlando, è stato un lapsus XD

            Il tuo discorso regge poco, ho usato per anni KDE e ho fatto a meno di tutti i software GTK visto che ci sono le alternative e che spesso e volentieri sono anche migliori, a partire da Konsol che rispetto al Terminale di gnome è un secolo avanti. Di software gtk veramente utili ce ne sono veramente un paio.

            Il mio concetto, lo ripeto, è semplice se avessero usato un DE basato già sulle Qt anni fa oggi la situazione sarebbe molto diversa e sono anni che lo dico. Come anche la gran cacchiata di continuare ad usare compiz o come diavolo si chiama ora per le animazioni, strada sbagliata e lo dissi già 8/9 anni fa quando il progetto era ancora vivo e vegeto. E ora vi dico anche questo altra cacchiata fatta da canonical è stata non supportare wayland e farse un server grafico per fatti loro, con il risultato che dopo anni stiamo ancora usando Xorg.

          • michele casari

            Wayland era praticamente morto finché Canonical ha detto MIR.

          • Maudit

            francamente, credo che sia stata una vera fortuna il fatto che Canonical abbia basato in passato (ma anche ora per le applicazioni) il suo lavoro su Gnome.
            Una fortuna per KDE, ovviamente.
            Più sta lontana dal mio DE preferito e meglio è.

          • Danilo

            hahahahahah, questo commento è il top 😀

          • michele casari

            in effetti, ci ha messo il becco con Kubuntu, e uno degli sviluppatori di punta (scusa non ricordo il nome) ha lasciato il team.

    • Nome

      Qt è un framework, GTK è un toolkit grafico: è come confrontare mele con pere. Se vuoi confrontare GTK con Qt devi considerare GTK+GLib+GStreamer+GSettings+GIO e molti altri componenti.

      • floriano

        di solito si confronta qt con gtk per la grafica , dalla tua lista mi sa che le qt sono ben più potenti di quanto già pensassi….

        • Nome

          Semplicemente con Qt hanno scelto di sviluppare tutti i componenti sotto lo stesso nome, mentre GTK hanno scelto di sviluppare tanti componenti con nomi diversi. Per esempio GLib era “parte” di GTK, ma poi è stato separato per diventare un progetto tutto suo. Non centra molto il “essere più potenti”, è una questione di nomenclatura.

  • theShort

    Ma con le applicazioni che sfruttano le nuove QT5.x succede ancora che, installandole in ambienti GTK, si portino dietro mezzo KDE?

    • Maddo

      Non succede più già da anni grazie a dio(era di kde 4.12 o giù di lì, quando divenne modulare).

      • theShort

        Questo è un gran vantaggio. Avevo abbandonato KDE parecchi anni fa per svariati motivi, quindi non sono più molto informato sugli sviluppi. Prima o poi ci ritornerò.

  • Luky

    Il grosso problema è anche che i temi QT non sono compatibili per GTK ma viceversa sì

    • floriano

      Gtk è compatibile solo con se stesso

  • Darkat

    Non c’è molto da dire, le QT sono migliori, sotto praticamente ogni punto di vista, non solo le librerie grafiche sono più complete (presenza di grafica 2D e 3D avanzata) ma tutte le componenti extra sono ben integrate, tutto multipiattaforma, presenza di un IDE ufficiale molto completo (QT Creator) e di un linguaggio simil-scripting per agevolare la scrittura di interfacce grafiche. Poi, è vero che le QT sono usate in meno ambienti grafici, ma i pochi DE che sono scritti in QT sono molto importanti: KDE, LXQT, Unity 8 il futuro ambiente di Ubuntu e tutto Sailfish OS. Senza contare il fatto che non ci sono grandi applicazioni scritte in GTK a parte GIMP e poco altro, mentre le QT sono utilizzate da realtà molto affermate, Adobe, VLC, Autodesk, Spotify, Scribus, Google, VirtualBox, Telegram ecc…il motivo della diatriba era unicamente la licenza, inizialmente non completamente open per le QT, motivo per cui sono nate le gtk, ma ad oggi non c’è davvero nessun motivo valido per preferirle se non avere un app esclusivamente integrata in Gnome. Gli stessi sviluppatori di Gimp hanno lamentato le problematiche di usare le GTK con C: dopo un tot di tempo ti ritrovi un mostro di codice ingestibile.

No more articles