[Discussione] Quale Futuro per le librerie grafiche in Linux

[Giepi]

Salve gente...

Da un pò di tempo rimugino su una cosa...
Mettiamo che una casa decide "Ok, figo sto linux: migriamoci la nostra applicazione di cad/masterizzazione/istantmessaging/mediaplayer/chipiùnehapiùnemetta"
Che fa?
Comincia a informarsi sulla struttura di linux (ovviamente) e su cosa si usa per fare quello che gli serve...
Arriverà al fatidico momento dell'aspetto Grafico dell' applicazione e si chiederà: "E ora che diamine c'è al posto dell WinForm?!"
Eccolo che si imbatterà in una mezza dozzina di librerie grafiche usate attivamente, tra cui le due grandi big: Qt & Gtk.

Ovviamente dovrà andare avanti, che farà? cercherà di capire "qual'è quella che realmente si usa in giro"
Così vedrà k3b, che usa le qt
Così vedrà il grande Firefox (figo! lo conosco! c'è pure su win!), che usa le gtk

Insomma, alla fine sarà come tirare a sorte, o magari possono riciclare qualche programmatore che già conosce uno dei due, o magari vedono un pò che altro hanno scelto i grandi vendor...

La questione non è riconducibile a un "tanto su gnome e kde si possono usare sia roba gtk che qt", eh.
E neanche con un "libertà prima di usare quello che piace prima di tutto!" perchè qua si parla di ricerca di uno standard, che diventerà sempre più necessaria alla diffusione di linux, dato dalla necessità di dare un'aspetto abbastanza professionale al nostro pinguino.
Soprattutto se considerate il fatto che un'applicazione qt come k3b eseguita nella mia gnome box 2.10 è un autentico pugno nell' occhio!

Sembra indicarci la via la tanto denigrata libreria Wx: su windows usa le WinForm, su linux le Gtk e su macos quello che si usa lì (ho visto lo schema tempo fa, e dovrebbe essere qualcosa del genere, se ho capito male, linciatemi pure, e potrei pure aver frainteso visto che sono talmente esperto da essermi arenato nello studio delle librerie grafiche in attesa di arrivare alla fine del capitolo sulle classi derivate * indispensabili per fare questo * del mio bravo manuale di C++). Questo però non è abbastanza per diventare uno standard.
E i fruitori delle altre librerie? bruciano tutti kilotoni di software o riconvertono a wx, perdendo le loro peculiarità?
E chi preferisce Kde a Gnome? si accontenta di usare roba che usa le gtk? ci dovrebbe essere un applicazione per trasformare i temi gtk uguali a quelli della loro kde box, ma non so bene se è applicabile in questo caso, se è apprezzabile in termini di velocità, e se esiste ( O_O )


Pensando e ripensando ecco cosa mi è venuto in mente (se dovete sfottere soltanto, potete pure non leggere, eh):
una sorta di meta - graphic library!
Mi spiego, chiamiamo questa "cosa" Mpl, in cosa consisterebbe?
Uno sviluppa l'applicazione X e arrivato alla gui usa come libreria Mpl anzichè qt, gtk e altro.
L'utente esegue X.
A secondo di come ha configurato la copia installata in locale di Mpl, Mpl usa le librerie che gli sono state dette di usare.
In pratica quella applicazione da me avrà un aspetto totalmente integrato tra le mie applicazioni Gtk preferite, mentre un utente kde, le vedrà in qt!
E non finisce qui! Sviluppando Mpl per supportare le altri librerie grafiche, uno potrà, chessò vederle con un aspetto da tcl/tk o altro, proprio perchè Mpl userebbe proprio quelle librerie per il rendering! (Non arrivo a dire che si potrà fare qualcosa del genere con le ncurses, ma chi lo sà!)

Sarebbe la vera libertà: non si condannerebbero tutte le altre librerie a una morte certa cercando di imporre una libreria come standard, e soprattutto sarebbe una soluzione che si potrebbe diffondere dolcemente, non dovendo rivoluzionare nulla, ma soltanto inizialmente affiancarsi alle normali applicazioni gtk/qt fino a rappresentare la quasi totalità delle applicazioni (infatti per esempio i tool di conf dei vari de non avrebbero motivo di migrare).

Vi sembra utopia? tra le varie librerie c'è troppa distanza per potere sviluppare un set di api comune?
Una volta che il progetto avrebbe una certa maturità potrebbe addirittura diventare parte delle specifiche comuni che per ora si stanno autocreando, vedi freedesktop.org (e soprattutto sarebbe più facile portare applicazioni su windows, o da windows)

Voglio vedere che ne pensate, ovviamente io non posso per motivi di conoscenza, cominciare nulla del genere, ma chissà tra un paio di anni o giù di lì
_________________
I SEE THE FLASH! THE FLAAASH!
AND YOU INFEDEL WILL DIE!!!
SLEEEPEEER AWAAAKEE!!!
* allucinato *

[!equilibrium]

a parte il fatto che la tua proposta oltre ad essere utopica non ha proprio senso, ma in secondo luogo arrivi tardi, basta implementare nel software che si sviluppa dei binding appositi per le varie librerie di Widgets esistenti; un esempio di questo genere è il software Eclipse che con un semplice "click" può switchare tra gtk, Qt, FOX, Motif senza dover "ricompilare" nulla... avviene tutto runtime; se tutti i developers opensource adottassero questa tecnica sarebbe indubbiamente il massimo, ma penso sia una richiesta troppo utopica anche questa. (my 2 cents)
_________________
Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe

all my contents are released under the Creative Commons Licence by-nc-nd 2.5

[Giepi]

[federico]

[federico]

[!equilibrium]

[lopio]

[!equilibrium]

[Dr.Dran]

Quoto in pieno quello appena detto da DarkAngel...
Tenete conto che esistono delle librerie che gestiscono bindings che già fanno un lavoro simile tipo le gtk-qt-engines etc. etc...
Sicuramente la proposta di Giepi di una libreria che gestisce le chiamate grafice è alettante, e allora nello spirito da pioniere perchè non iniziare a sviluppare una cosa simile...
Il problema è già stato sottoposto all'attenzione delle major: è nato per ovvie esigenze il progetto freedesktop (parliamo sempre di librerie grafiche)
Se seguiste bene la situazione globale dello sviluppo in x/xorg si stanno fornendo degli standard sia per quello che riguarda lo sviluppo di applicativi sia per quello che riguarda il lato client e l'usabilità degli ambienti grafici.
Librerie come qt e gtk, entrambe specializzate e utilizzate in contesti differenti vengono sviluppate seguendo uno scheletro fornito da freedesktop, poi ogni gruppo di sviluppo implemente delle caratteristiche avanzate a seconda delle decisioni commerciali e di marketing, però comunque questo non ne vieta la possibilità di utilizza in ogni ambiente sia che voi utilizziate Gnome, Kde, blackbox, xfce, fvwm... questo è già molto...
La cosa non si ferma qui... memore del fatto anche del progetto fallito miseramente di United Linux (cosa che anche se non direttamente ha che fare come teoria di gestione con quello che tu hai detto...) sembre che la gestione e lo sviluppo di freedesktop invece vada alla grande e ogni versione dei nuovi ambienti che si profila sembra sempre + versatile e "amichevole" cosa che può invogliare tanta gente a passare o almeno anche solo a guardare meravigliata il nostro carinissimo amico pinguino

[!equilibrium]

[Dr.Dran]

Riquoto quello che hai detto... e poi insomma ci lamentiamo di winzozz che ti vincola a programmare con le sua "bellissime" DirectX e compagnia bella, mentre noi con linux possiamo programmare in gtk, qt, sdl e far girare il tutto su tutti i sistemi... ma dai insomma dove finisce la libertà a volte mi sembra che ci lamentiamo della "roba dolce".

Comunque per non accender flames, credo che il discorso dei bindings sia interessante, ma credo che per ora prevalga il fatto degli standard

[GiRa]

Mmmh... I manutentori di Mpl dovrebbero continuare ad aggiornare i layer di compatibilità con le librerie (solo le wxWidgets che al momento sembrano essere tra le più portabili da una versione all'altra cambiano tantissimo persino i costruttori!).

Bisognerebbe cambiare completamente approccio ma la questione diventa molto complessa ed io non sono in grado di fare un'analisi decente.

[!equilibrium]

[Giepi]

mmmh... dunque secondo voi il principale problema è la creazione di tutto perchè lavoro troppo titanico.
Beh, innanzitutto il problema della "confusione mentale" non si creerebbe, se c'è abbastanza gente da fare un team per una data libreria e mantenerla, si crea quel gruppo, come le localizzazioni dei vari programmi, ma mooolto più complesso.
Secondo voi sarebbe una via più percorribile utilizzare il codice di qualcosa tipo le Wx che fa già astrazione, e rendere disponibili più "output" di rendering?
Una struttura tipo il gcc, un middle unico, e tanti risultati a seconda della piattaforma unica.
Ovviamente non si potrebbe fornire un supporto a TUTTO, ma a quello che è supportato universalmente, senza scendere nelle peculiarità di ogni GTK/QT/MOTIF di turno: è limitante ma garantisce una base standard e una uguaglianza di risultati, senza strane sorprese o "funzionalità supportata solo su qt" che manda in fumo il progetto iniziale.

Quanto all'inutilità... lo scopo non è una grafica a scelta, ma fornire una base standard, poter dire "consiglio di utilizzare x windget" senza sollevare guerre di religione, a cui il mondo open source è dolorosamente soggetto.

Altrimenti una soluzione sarebbe dire "Da oggi si usano solo gtk! convertite tutto belli miei!"

Considerate la situazione: non si può andare avanti senza una strumento "ufficiale" (se mai c'è qualcosa di ufficiale in Gnu/Linux, vabbè, nel senso che la comunità in generale lo riconosce come tale)

Se avete altre idee, vi invito a dirle pure, rileggete il titolo del post, la mia è solo una proposta, mi auguro che ce ne siano altre!


Edit: tralaltro direi che sarebbe per un progetto del genere praticamente obbligatorio la benedizione delle maggiori vendor, o almeno della maggior parte, e sicuramente una totale integrazione con freedesktop!

In pratica propongo di ESTENDERE la standard aperto, su cui poi tutti potranno sviluppare le loro vie!
_________________
I SEE THE FLASH! THE FLAAASH!
AND YOU INFEDEL WILL DIE!!!
SLEEEPEEER AWAAAKEE!!!
* allucinato *

[Dr.Dran]

[Ciccio]

Quello di cui MS si vanta maggiormente è proprio essere riuscita a uniformare l'aspetto delle applicazioni, barre degli strumenti e compagnia in un sistema omogeneo che permette alla maggior parte degli applicativi di usufruire di un aspetto simile e di una simile struttura.
Questo rende il sistema molto più usabile sia da un utente inesperto sia da uno più esperto che comunque girando fra finestre gtk, qt & co. sempre diverse, con posizioni dei pulsanti sempre diversi comunque perde del tempo e si "stressa" maggiormente.
Un esempio pratico una qualsiasi finestra di Apri file... la struttura cambia fra qt e gtk o altre librerie grafiche e anche le funzionalità sono diverse.
Un'unificazione a un livello più alto di astrazione darebbe una straordinaria forza propulsiva proprio alla diffusione del sistema, rendendolo più semplice da usare a chi non lo conosce a fondo, facendo breccia proprio in chi non riesce mai bene a orientarsi e si scoraggia di fronte a decine di finestre tutte diverse con le medesime funzionalità.
E' sicuramente vero che è un vincolo per i programmatori, ma se qualcuno ha un po' di memoria è esattamente quello che è successo con Windows, MS ha imposto la sua via, il suo "standard" e adattarsi è convenuto a tutti, nel medio periodo.
C'è molto lavoro da fare è vero ma ritengo sia una cosa che andrebbe affrontata con meno superficialità perché l'interfaccia in un sistema desktop è ciò che viene utilizzata per il 90/95% del tempo se non di più, e andrebbe curata sin nei minimi dettagli, se si vuole aumentare la diffusione di questo sistema operativo. La sola qualità e stabilità del codice non sempre basta a fare di un SW il migliore.
_________________
Francesco
http://www.ciccio.org

[Dr.Dran]

Concordo, ma se leggete bene, in giro, è proprio questa la tendenza attuale si propone di fare nel medio periodo, nel senso che Freedesktop (documentazione allegata) parla molto chiaro: lo "scheletro" deve essere questo e poi il resto è a discrezione degli sviluppatori, ricordatevi che fino a circa 4/5 anni fa era improponibile fare girare sullo stesso desktop applicazioni KDE e GNOME, bisognava installare tutte e due gli ambienti e poi bisognava adattare il codice... un lavorazzo...
Forse alcuni di voi non si ricordano degli albori sia di KDE che di Gnome... era un vero macello altro che gli ambienti eye-candy e usabili di ora... per una persona esterna è facile criticare lo sviluppo, ma provate a pensare perchè UnitedLinux non ha funzionato... insomma non si può e non si deve rivoluzionare tutto in pochi mesi... cavolo qui si fa per discutere, ma cerchiamo di stare con i piedi per terra... ricordate che una parte dello sviluppo è supportata da persone che dedicano il proprio tempo libero a questo... avete notato l'istituzione delle varie foundation? Secondo voi a cosa servono? Ci si sta organizzando per dare possibilità agli sviluppatori di essere supportati e di seguire delle linee guida ben definite, infatti Gnome dalla versiona 2.0 ha iniziato a programmare l'uscita delle release con il relativo schema di sviluppo e se vedete da circa 2 anni il sistema ha subito migliorie e fornisce innovazioni (HAL, DBUS, BEAGLE, MONO etc.. etc..) mentre prima era considerato un giocattolo... anche KDE che è più vecchio ha seguito uno sviluppo simile, ovviamente hanno avuto l'occhio di applicare prima questa politica e quindi ha sempre avuto la nomea di sistema integrato e professionale per Linux...

Quindi quello che cerco di dire in tutti questi post che ho fatto è questo: è vero che c'è la necessità di un ambiente omogeneo, ma credetemi che si sta evolvendo il tutto verso questo!!! Solo che bisogna adeguare lo sviluppo agli sviluppatori e viceversa...

[thewally]

Dato che la possibilità si "switchare" da una libreria all'altra non e' cosi' semplice come la si credeva (alias "export GRAPHLIB=QT" ): credo che sia il caso di pensare piu' che altro allo sviluppo di motori grafici che consentano una "conversione in realtime" dell'interfaccia grafica.

Per esempio:
ho sempre utilizzato KDE e Mozilla Firefox, ma mi ha sempre dato fastidio la differenza di interfaccia grafica durante l'utilizzo (Qt vs Gtk).
Ho risolto il tutto con:

[Dr.Dran]

[Giepi]

[assente]

Le killer app stanno arrivando (IMO) dal mondo gtk/C#:
Beagle, F-SPOT, http://diva.mdk.org.pl/, Monodevelop, poi Evolution su win (che non è c#)

ovviamente ci sono anche Opera e Skype fatte con le Qt
_________________
Blog
E8400, 4850, P5q

[Dr.Dran]

[randomaze]

[akiross]

Bhe l'idea non e' cosi' male in fondo, ma ci sono molte cose da dire a riguardo:

1. Lo sviluppatore non pensa spesso alla questione "integrazione nel desktop". Sarebbe impensabile stare a pensare ad ogni povero user linux che ha un desktop un po' disordinato a livello di interfacce grafiche. Senza contare che in linux questa varieta' esiste da molto tempo, e io - anche se in passato la pensavo diversamente - attualmente non lo vedo affatto come un problema.

2. Lo sviluppatore sceglie il toolkit che piu' si adatta alle sue esigenze: e' inutile usare tutta la potenza di QT o GTK quando quello di cui hai bisogno sono 3 pulsanti messi in croce. Molto meglio un toolkit leggero.
Se lo sviluppatore ha bisogno di performance nella GUI, aggiungere un nuovo layer come dici tu e' assolutamente sconsigliabile.
Sappiamo tutti che aggiungere layer e' una buona cosa dal punto della portabilita' e della flessibilita', ma non lo e' per la sicurezza (piu' codice = piu' bachi) ne' per la velocita'.

3. Lo sviluppatore sceglie il tookit che piu' si adatta al progetto: se e' tutto in C, inutile usare Qt che e' nativamente in C++. Se il tuo sistema e' ad oggetti, meglio usare Qt (anche se ovviamente con i binding non serve tutta sta premura... esistono bind per ogni linguaggio ed ogni libreria)

4. A mio modestissimo avviso, anche se io uso GTK ma per ragioni che non sto a spiegare, credo che QT sia comunque la scelta migliore. Non so se esiste un binding delle API Qt per C - probabilmente si - e questo e' l'unico motivo per cui io non ho ancora iniziato ad usare Qt:
Qt e' veloce (il fatto che il desktop KDE sia lento non e' assolutamente dovuto a Qt: e' dovuto al fatto che KDE e' complesso, aggiunge suoi widget e features, che e' scriptabile eccetera), se prendete delle applicazioni QT pure vedete tutta la sua velocita'.

Qt e' portabile sui maggiori sistemi: linux, windows, macosx. Anche GTK lo e', ma in un modo diverso: Qt e' nativo su ogni sistema: questo significa che se fai andare una applicazione Qt su windows, lo vedrai con la grafica di windows. Su linux: qt per linux. Su mac: grafica di mac.

Quindi le librerie Qt sono GIA' effettivamente un potente e portabile mezzo per disporre di una gui su ogni sistema, con il look del sistema.

Io sono un programmatore C principalmente, non ho mai studiato a fondo QT (ho iniziato da gtk perche' son partito con python e mi era piu' veloce creare appl usando glade), ma onestamente aspetto solo che mi arrivi la voglia di mettermi a studiarle, perche' sono davvero un gioiellino.

Piuttosto che scrivere nuovi layer astrattivi per le GUI, io ti consiglierei di impararti le librerie trolltech e - se ti gustano - di diffondere la voce.

Ciauz
_________________
Libera scienza in libero stato.
Horizon of Events

[Little Cash]

Quoto cio' che molti altri hanno detto, dicendo che il bello, grazie all'etica open source a cui *nix ci ha da sempre abituati, e' proprio la liberta' di scelta (in questo caso della libreria grafica che si vuole utilizzare).
_________________
D: Perche' usi linux?
R: Perche' mi piace dover riavviare solo per un kernel upgrade

- badguy@IRCNet -