# [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ì  :Smile: 

----------

## !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)

----------

## Giepi

 *DarkAngel76 wrote:*   

> 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)

 

Ciao

Mi potresti spiegare per quale motivo secondo te non ha senso?

Questa di Eclipse non la sapevo, mi sembra una grande trovata.

Il fatto è che spesso non si ci sbatte per implementare tutte le librerie, e lo dimostra che, stando a quanto dici, c'è solo eclipse che lo fa (e pochi altri eventuali).

Implementando invece questo Mps come ho appena detto, si ci fa lo sbattimento di fare tutti i binding una sola volta, e al programmatore finale non resta che usare una sola e unica libreria, facilitandogli il lavoro.

----------

## federico

 *DarkAngel76 wrote:*   

> 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)

 

Se lo puo' permettere eclipse forse, e sull'utilita' della cosa avrei anche da ridire, ma non e' una cosa che si puo' chiedere a tutti i programmi.

----------

## federico

 *Giepi wrote:*   

> Implementando invece questo Mps come ho appena detto, si ci fa lo sbattimento di fare tutti i binding una sola volta, e al programmatore finale non resta che usare una sola e unica libreria, facilitandogli il lavoro.

 

Si ma e' un lavoro colossale, non so se hai idea di quante chiamate, funzioni, hanno le gtk... E quante tutte le altre librerie, e quanto velocemente si sviluppano (e quindi devi stargli pure dietro); e poi a che serve, a far felice l'utente cosi' puo' scegliere la grafichina che gli piace di piu' ? Gia' neanche abbiamo tutti i programmi di cui vorremmo disporre, mi pare lavoro sprecato questo.

----------

## !equilibrium

 *Giepi wrote:*   

> Mi potresti spiegare per quale motivo secondo te non ha senso?

 

ti sei risposto da solo poche righe sotto:

 *Giepi wrote:*   

> Questa di Eclipse non la sapevo, mi sembra una grande trovata.
> 
> Il fatto è che spesso non si ci sbatte per implementare tutte le librerie, e lo dimostra che, stando a quanto dici, c'è solo eclipse che lo fa (e pochi altri eventuali).
> 
> Implementando invece questo Mps come ho appena detto, si ci fa lo sbattimento di fare tutti i binding una sola volta, e al programmatore finale non resta che usare una sola e unica libreria, facilitandogli il lavoro.

 

non puoi "predire" tutti i binding, ogni applicazione li implementerebbe in modo totalmente diverso, e non te lo nascondo, non è facile implementare un binding per + di 1 di un widget set; ma il gioco vale la candela sul lungo termine perchè il developer o i deverloper non devo + preoccuparsi di dedicare tempo alla programmazione dei widgets. ma già qui entriamo in un campo + filosofico che teorico: "fattore tempo contro risorse, fattore tempo contro deadlines, riusabilità del codice ecc ecc". Per tutto questo non c'è ragione di implementare una libreria come la intendi tu..

(IMHO: il fatto che solo Eclipse implementi un sistema del genere mentre gli altr no, per me è per una questione di pigrizia totale da parte degli altri developers  :Laughing:  )

----------

## lopio

 *DarkAngel76 wrote:*   

> 
> 
> (IMHO: il fatto che solo Eclipse implementi un sistema del genere mentre gli altr no, per me è per una questione di pigrizia totale da parte degli altri developers  )

 

A me (come q federico) sembra un lavoro titanico.

Impossibile estenderlo a tutte le applicazioni altro che pigrizia...e' come tirarsi la zappa sui piedi e aumentare i bachi esponenzialmenteLast edited by lopio on Fri Aug 05, 2005 6:36 pm; edited 1 time in total

----------

## !equilibrium

 *federico wrote:*   

> e poi a che serve, a far felice l'utente cosi' puo' scegliere la grafichina che gli piace di piu' ? Gia' neanche abbiamo tutti i programmi di cui vorremmo disporre, mi pare lavoro sprecato questo.

 

infatti, già ad essere pignoli ed estremisti non ha nemmeno senso che esistono diversi widget grafici che fanno tutti la stessa identica cosa, ci manca solo che ne viene sviluppato uno nuovo e totalmente "astratto" che si ingarbuglia con tutti gli altri... (mi ricorda molto il signore degli anelli: "Un Widget per domarli, un Widget per trovarli, un Widget per ghermirli e nell'oscurità incatenarli"  :Laughing:  )

----------

## 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  :Wink: 

----------

## !equilibrium

 *lopio wrote:*   

> A me (come q federico) sembra un lavoro titanico.

 

e infatti ho detto che non è facile come lavoro, ma dire "titanico" è un po troppo... non è facile, ma nemmeno difficile

 *lopio wrote:*   

> Impossibile estenderlo a tutte le applicazioni altro che pigrizia...e' come tirarsi la zappa sui piedi e aumentare i bachi esponenzialmente

 

la questione bachi e il fattore esponenziale dei bachi non ha nulla a che vedere con il binding dei widgets, per esempio Eclipse l'ha adottato per un motivo semplice, per non creare una versione diversa del software per ogni piattaforma, ce n'è una per tutte, e usa i widget che trova sulla macchina su cui gira, stop. I developers di Eclipse si sono sbattuti e hanno fatto un Abastraction Layer per tutti i widget, fine della storia, nulla di trascendentale... solo che richiede molto tempo per l'affinamento e non è un qualcosa che puo' essere copia/incollato in un'altra applicazione per via dei motivi che ho esposto sopra.

----------

## 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".  :Wink: 

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

----------

## 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

 *DranXXX wrote:*   

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

 

infatti spero anche io che la freedesktop riesca ad imporre il suo standard per i widget e le librerie grafiche, se ciò andasse in porto allora un Abstraction Layer per tutti i widgets non sarebbe + cosi tanto utopico; io sinceramente rimango comunque molto scettico sulla cosa, non tanto sulla "fattibilità" dell'idea (perchè è fattibilissima), + che altro per le reazioni dei developers che sicuramente trarranno spunto per una nuova e avvincente guerra di religione... lo standard esploderà in un flop come una bolla di sapone... e per ripicca il mondo opensource partorirà un nuovo toolkit di widget dal fork di uno già esistente  :Laughing:  eheheheh (ok, era solo per sdrammatizzare un po, non prendete sul serio la mia ultima frase!!)

----------

## 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!

----------

## Dr.Dran

 *DarkAngel76 wrote:*   

>  *DranXXX wrote:*   Comunque per non accender flames, credo che il discorso dei bindings sia interessante, ma credo che per ora prevalga il fatto degli standard  
> 
> infatti spero anche io che la freedesktop riesca ad imporre il suo standard per i widget e le librerie grafiche, se ciò andasse in porto allora un Abstraction Layer per tutti i widgets non sarebbe + cosi tanto utopico; io sinceramente rimango comunque molto scettico sulla cosa, non tanto sulla "fattibilità" dell'idea (perchè è fattibilissima), + che altro per le reazioni dei developers che sicuramente trarranno spunto per una nuova e avvincente guerra di religione... lo standard esploderà in un flop come una bolla di sapone... e per ripicca il mondo opensource partorirà un nuovo toolkit di widget dal fork di uno già esistente  eheheheh (ok, era solo per sdrammatizzare un po, non prendete sul serio la mia ultima frase!!)

 

In effetti è quello che è poi accaduto con United Linux  :Razz: 

Comunque per ora sembra che il progetto freedesktop stia raccogliendo buoni frutti da tutto il mondo di sviluppatori... HAL è uno standard partorito da F.D.  :Wink: 

EDIT: Inoltre HAL è sia supportato da GTK che da QT eh eh eh  :Wink:  (meglio per non destare flames sia da Gnome che da KDE e con ivman può essere gestito da tutti gli altri DM e WM)  :Very Happy: 

----------

## 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.

----------

## 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"  :Laughing:  ): 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:

```
 # emerge gtk-engines-qt
```

  :Very Happy: 

Adesso, io non sono un esperto in materia, ma credo che si possa realizzare un programma in grado di "convertire" anche da e verso altre librerie...

Cosa ne pensate?

P.S. : Purtroppo rimarrebe sempre il problema della diversità di interfaccia nella navigazione dei file. Ma saremmo comunque a metà dell'opera.  :Very Happy: 

----------

## Dr.Dran

 *DranXXX wrote:*   

> Tenete conto che esistono delle librerie che gestiscono bindings che già fanno un lavoro simile tipo le gtk-qt-engines etc. etc...
> 
> 

 

eh eh eh mi autocito, ma comunque credo che Thewally abbia appena centrato il motivo della discussione, cioè per il momento è preferibile utilizzare queste librerie intermedie che si stanno sviluppando e promettono bene  :Wink: 

----------

## Giepi

 *thewally wrote:*   

> 
> 
> Adesso, io non sono un esperto in materia, ma credo che si possa realizzare un programma in grado di "convertire" anche da e verso altre librerie...
> 
> Cosa ne pensate?
> ...

 

Che quello che ho esposto sopra è una implementazione di quanto hai detto tu  :Wink: 

Voi dite che le cose si stanno evolvendo in questo senso: siamo d'accordo. Voi dite che se ne parla e si ci organizza per farlo: e noi che stiamo facendo?

Io sinceramente la mia idea la vedo come una idea "centralizzata" dei vari convertitori come quello da te creato: una killer app!

Insomma, voi vedete altri punti di arrivo? Mi sembra UTOPICO nel mondo linux dire "we, si usa QUESTA SOLA LIBRERIA E BASTA!". Bisogna sviluppare qualcosa che non tema le altre librerie, anzi le inciti a svilupparsi!

La community siamo noi, eh, chissà che a parlarne in brainstorming non esca qualche bella proposta!

----------

## 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

----------

## Dr.Dran

 *assente wrote:*   

> 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

 

Ottima osservazione, mono (sviluppato da Icaza), C# e compagnia bella sevono per riuscire a fare degli ottimi port di applicazioni su vari ambienti, credo sia questo un possibile ottimo futuro...

----------

## randomaze

 *Giepi wrote:*   

> 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.

 

La via del supportare solo quello che supportato universalmente é quella delle AWT/Swing di java "secondo SUN".

Dato che in IBM trovavano la cosa limitante hanno creato SWT, il Toolkit con cui é costruito eclipse, il quale sftutta i widget nativi del sistema e non si ferma al massimo comune denominatore ma a patire da un sistema cerca di implementare tutto il possibile. Differenti punti di vista anche se non mi ricordo di aver mai incontrato qualcuno particolarmente felice delle AWT/Swing il che mi fa pensare che sia stata una scelta non graditissima.

In ogni caso leggendo il thread non ho ben capito i vantaggi che avrebbe questa "standardizzazione del toolkit, oltre al fatto che tutto quello di cui avete parlato esiste da anni e si chiama Java. Ma ne utenti ne programmatori hanno sposato in maggioranza tale scelta di uniformitá.

Dal mio punto di vista lo standard lo detta il linguaggio che si vuole usare:

Se implemento un programma C la via "quasi obbligata" sono le GTK. Il resto é in C++ e il condice si imbastardirebbe alquanto.

Se implemento in C++ la via "migliore" dovrebbe essere data dalle QT o dalle wx, entrambe ad oggetti.

Se implemento in Java come ho detto prima AWT/Swing privilegiando la politica sun oppure SWT privilegiando la via IBM

Se implemento in python la maggioranza punta sulle wxGTK, ma mi sembra ci siano anche le pyQT o qualcosa di simile.

Se devo usare C# allora saranno le GTK# (che dal punto di vista delle chiamate mi sa che sono un pó diverse dalle GTK normali)

...

e guai se non potessi cercare lo strumento migliore per fare il lavoro migliore.  :Wink: 

----------

## 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

----------

## 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).

----------

## lopio

 *randomaze wrote:*   

> 
> 
> La via del supportare solo quello che supportato universalmente é quella delle AWT/Swing di java "secondo SUN".
> 
> Dato che in IBM trovavano la cosa limitante hanno creato SWT, il Toolkit con cui é costruito eclipse, il quale sftutta i widget nativi del sistema e non si ferma al massimo comune denominatore ma a patire da un sistema cerca di implementare tutto il possibile. Differenti punti di vista anche se non mi ricordo di aver mai incontrato qualcuno particolarmente felice delle AWT/Swing il che mi fa pensare che sia stata una scelta non graditissima.
> ...

 

Quoto mi sembra quasi che si stia per reinventare la ruota per  certi versi.

Chi si lamenta di swing e java spesso e' prevenuto per la solita guerra di religione per esempio con c++ e affini dimenticando che piu' si va avanti e, soprattutto per programmazione non strettamente legata a interfacce di basso livello dove i requisiti di memoria e l'uso dei puntatori e' obbligatorio  il gap tra linguaggio compilato e jvm con jni e' proprio molto basso a livello di tempi di esecuzione e velocita'

Le swing non sono + il mostro di lentezza che erano prima (anni fa ormai) e memoria  processori veloci rendono gui swing e applicazioni java in genere gradevoli veloci e funzionali per performance e tempi di implementazione.

Per esperienza personale direi che swing mi/ci ha tirato fuori le castagne dal fuoco quando il codice doveva girare su  NT/XP/HP/solaris/linux insieme in scenario multithread client/server. 

E' non e' poco avere tutto questo gratis....

----------

## Dr.Dran

OK! Quoto sempre tutto quello che hanno detto sia Randomaze che Akiross, e credo che siano state esaurite delle eventuali alternative  :Wink: 

P.S. So perfettamente che sono stati ribaditi concetti vecchi... solo che probabilmente qualche d'uno di noi è nuovo del mondo opensource e non ne ha seguito l'evoluzione dagli albori... e quindi ogni tanto è bello tirare fuori vicende passate per poter capire quello che effettivamente avviene odiernamente e perchè  :Wink: 

----------

## Giepi

io più che altro mi preoccupo per il fatto della classica azienda che vuole migrare una applicazione e si vede tutto sto ammasso di librerie e non sa che usare: secondo me qua si dovrebbero fare sforzi comuni.

In pratica il consiglio che date voi è: "falli ammazzare tra di loro e per legge d'evoluzione alla lunga un widget prevarrà"?  :Smile: 

Quanto al consiglio di imparare qt... saranno belle ma sono uno Gnomo appassionato ^^

----------

## akiross

 *Giepi wrote:*   

> Quanto al consiglio di imparare qt... saranno belle ma sono uno Gnomo appassionato ^^

 

Bhe non pensare, anche io ho un desktop quasi interamente GTK, ma la questione - almeno per me - non sono le librerie.

Dal mio punto di vista, e' normale preferire KDE, GNOME o altro per la sua usabilita', per i plugin, per quello che ce ne si fa, per l'estetica eccetera, ok va benissimo, ma io stesso, che come ho ribadito uso GTK, ritengo che a livello qualitativo le Qt siano superiori a GTK (anche se rimane un buon toolkit).

Adottare Qt come libreria "standard" non e' una pessima cosa... a te piacerebbe meno gnome se fosse uguale ad ora ma sviluppato con Qt? L'unica ragione per cui un "Si" sarebbe logico e' che chi lo dice e' perche' odia per qualche motivo le librerie Qt in quanto tali, ma non c'e' una ragione particolare...

La gente preferisce gnome o kde per quello che ti danno, non tanto per le librerie in cui sono scritte.

Ciauz

----------

## randomaze

 *Giepi wrote:*   

> io più che altro mi preoccupo per il fatto della classica azienda che vuole migrare una applicazione e si vede tutto sto ammasso di librerie e non sa che usare: secondo me qua si dovrebbero fare sforzi comuni.

 

La "classica azienda" spende qualche giorno di tempo e sudia quale tk si adatta meglio ai suoi scopi.

Mi sembra assolutamente normale peraltro fare uno studio di fattibilitá piuttosto che buttarsi in un porting che potrebbe rivelarsi impossibile.

----------

## akiross

 *Giepi wrote:*   

> io più che altro mi preoccupo per il fatto della classica azienda che vuole migrare una applicazione e si vede tutto sto ammasso di librerie e non sa che usare: secondo me qua si dovrebbero fare sforzi comuni.

 

Aggiungo una cosa a cio' che ha detto randomaze:

Se l'azienda vuole migrare, non le costa certo di meno usare un toolkit unico. Il punto e' che se esistesse un toolkit unico (qt  :Very Happy: ) usatissimo sia su linux che su windows, il costo di migrazione sarebbe poco, e quindi con ovvi vantaggi. Se un'appz e' fatta per windows (che usa le API di win) e si vuole migrare a linux, a questo punto e' inutile smenarsi su quale toolkit usare: si sceglie il piu' adatto alle necessita' dell'azienda e via. Il costo a questo punto e' pressoche' uguale, quindi cio' che dici avrebbe un vantaggio reale se diminuisse i costi di porting. Ma questo e' fattibile solo se tutti lo usassero su tutti i sistemi, ma a questo punto siamo da capo.

Qt sono native, sono portabili e sono veloci. Anzi sapete che vi dico? che ADESSO - appena finito questo post - che non ho sonno, mi cerco la documentazione e faccio le mie prime app in Qt!  :Smile: 

Ciauz

----------

## Dr.Dran

 *Giepi wrote:*   

> io più che altro mi preoccupo per il fatto della classica azienda che vuole migrare una applicazione e si vede tutto sto ammasso di librerie e non sa che usare: secondo me qua si dovrebbero fare sforzi comuni.
> 
> In pratica il consiglio che date voi è: "falli ammazzare tra di loro e per legge d'evoluzione alla lunga un widget prevarrà"? 
> 
> Quanto al consiglio di imparare qt... saranno belle ma sono uno Gnomo appassionato ^^

 

Dunque, per la mia "breve" esperienza (circa 10 anni di sistemi e prog.) con "classiche aziende" ti posso confermare che gli stessi problemi ce li hai anche se lavori con il "bellissimo mondo" winzoz, hai mai sentito dibattiti su utilizzare Visual Basic o Visual C++ oppure utilizzare il C++ BUilder della Borland? Beh  io si, purtroppo, ed è veramente sconcertante, vedere che applicativi che utilizzano le stesse wiget siano così differenti (parlo dei due comp. c++)...

Per me entrare nel mondo opensource è stata una vera conquista, grazie alle diversità sia prestazionali e di implementazione sono riuscito a proporre progetti di varia entità (gtk/gtkmm, qt) senza mai alla fine avere grossi problemi... anche se in effetti all'inizio bisogna essere molto diplomatici per sconfiggere il velo di diffidenza che avvolge le aziende nostrane verso linux...

Quindi perchè limitare tutto a un unico sistema che può creare "dipendenza" e invece non mantenere questa diversità e seguire tutti degli standard implementativi, in modo tale da fornire di base tutti le stesse cose e in + a seconda dello sviluppo ogni libreria offre prestazioni migliori in ambiti differenti (embedded etc. etc.)

Ciauz  :Wink: 

----------

## !equilibrium

 *DranXXX wrote:*   

> Quindi perchè limitare tutto a un unico sistema che può creare "dipendenza" e invece non mantenere questa diversità e seguire tutti degli standard implementativi, in modo tale da fornire di base tutti le stesse cose e in + a seconda dello sviluppo ogni libreria offre prestazioni migliori in ambiti differenti (embedded etc. etc.)

 

hai espresso perfettamente il concetto che ho tentato di esporre qualche post addietro: avere uno standard solido che permetta ad un developer di creare un software e all'accorrenza switchare da un toolkit all'altro senza dover stravolgere il proprio software (non parlo di runtime); questa per me sarebbe la  vera evoluzione, e il fatto che ci siano 10 o 100 o 1 milione di widgets toolkit non avrebbe + nessuna importanza rilevante.

----------

## lopio

 *DranXXX wrote:*   

> Quindi perchè limitare tutto a un unico sistema che può creare "dipendenza" e invece non mantenere questa diversità e seguire tutti degli standard implementativi, in modo tale da fornire di base tutti le stesse cose e in + a seconda dello sviluppo ogni libreria offre prestazioni migliori in ambiti differenti (embedded etc. etc.)

 

a me sembra la stessa cosa che fa swing

----------

## Dr.Dran

 *lopio wrote:*   

>  *DranXXX wrote:*   Quindi perchè limitare tutto a un unico sistema che può creare "dipendenza" e invece non mantenere questa diversità e seguire tutti degli standard implementativi, in modo tale da fornire di base tutti le stesse cose e in + a seconda dello sviluppo ogni libreria offre prestazioni migliori in ambiti differenti (embedded etc. etc.) 
> 
> a me sembra la stessa cosa che fa swing

 

Vero, infati swing per chi sviluppa java è una manna  :Wink: 

----------

## akiross

 *DarkAngel76 wrote:*   

> hai espresso perfettamente il concetto che ho tentato di esporre qualche post addietro: avere uno standard solido che permetta ad un developer di creare un software e all'accorrenza switchare da un toolkit all'altro senza dover stravolgere il proprio software (non parlo di runtime); questa per me sarebbe la  vera evoluzione, e il fatto che ci siano 10 o 100 o 1 milione di widgets toolkit non avrebbe + nessuna importanza rilevante.

 

Eh uno standard... il problema e' che anche di standard ce ne sono a valanghe  :Very Happy:  e secondo me c'e' anche chi si occupa di standard a livello di GUI.

Il problema non e' il fatto che mancano gli standard, il problema e' che nessuno li adotta, o che se li adotta, li interpreta a modo proprio o effettua modifiche per ragioni piu' o meno stupide.

Onestamente non so se a livello di GUI ci siano cose simili (ecco giusto per dimostrare che se esistono nessuno le caga  :Razz:   :Smile: ) pero' parlando piu' in generale, occhio a creare standard... ce ne sono gia tanti, vediamo di diffonderli ed usarli.

Ciauz

EDIT: Al mio discorso manca questo: anche se fate uno standard per le gui, chi lo adotta? Dovrebbe essere messa una interfaccia unica per usare ogni libreria (come ho gia detto aggiungere un layer in piu' diventa lentooo) quindi sarebbe l'unica soluzione veloce, che pero' ovviamente non e' affatto comoda e pratica, perche' - ok che basta una riscrittura del software - ma ogni libreria dovrebbe cambiare le sue API

----------

## Dr.Dran

 *akiross wrote:*   

> ...Eh uno standard... il problema e' che anche di standard ce ne sono a valanghe  e secondo me c'e' anche chi si occupa di standard a livello di GUI. Il problema non e' il fatto che mancano gli standard, il problema e' che nessuno li adotta, o che se li adotta, li interpreta a modo proprio o effettua modifiche per ragioni piu' o meno stupide....
> 
> Onestamente non so se a livello di GUI ci siano cose simili (ecco giusto per dimostrare che se esistono nessuno le caga  ) pero' parlando piu' in EDIT: Al mio discorso manca questo: anche se fate uno standard per le gui, chi lo adotta? Dovrebbe essere messa una interfaccia unica per usare ogni libreria (come ho gia detto aggiungere un layer in piu' diventa lentooo) quindi sarebbe l'unica soluzione veloce, che pero' ovviamente non e' affatto comoda e pratica, perche' - ok che basta una riscrittura del software - ma ogni libreria dovrebbe cambiare le sue API

 

Riassumo dicendo che questo è l'impegno del consorzio Freedesktop www.freedesktop.org , quello che supporta xorg, cairo, gtk, glitz, glx, qt e tutte le api che servono ad X... inoltre è proprio quel consorzio che definisce le linee guida generali per l'ambienti desktop e di sviluppo è l'ente che è stato istituito per unificare i vari standard in giro! Se poi uno vuole fare come gli pare, beh esiste anche la libertà di farlo e non vedo nulla di male, se però so che esiste una linea guida generale io la seguo anche perchè è molto + facile trovare supporto...

----------

## akiross

Ehhh si conoscevo freesdesktop, ma io parlavo a livello piu' basso (non so se fd si occupa di cio', ma non credo perche' mi sembra una cosa abbastanza utopica).

Una buona soluzione, secondo me quella con il compromesso migliore, e' definire una singola interfaccia software alle librerie. Mi spiego: voi sapete che esiste l'ANSI C. E' il C standard, ha determinate features, ed una sola interfaccia al programmatore:

quando dici printf() sai che la sintassi della printf e' sempre quella: (char *, ...).

L'implementazione della printf, pero', varia da sistema a sistema: glibc la implementa in modo diverso della libc, che e' implementata in modo diverso dalla libreria standard di windows (o almeno credo... non mi sembra che l'ANSI C definisca anche COME vanno implementate le funzioni).

Sta di fatto che cosa buona sarebbe avere la stessa interfaccia al programmatore per le librerie grafiche: vuoi creare una finestra? Usi il tipo "Window", vuoi fare un bottone? Usi il tipo "Button", eccetera.

Ovviamente poi l'implementazione sta al costruttore di librerie: Qt fara' le sue librerie, aggiungera' sue features (anche nell'ANSI C si possono aggiungere features... non so se nativamente C99 supporta l'identificatore %lli nella printf... secondo me no). GTK stesso: usa l'interfaccia standard per alcune funzioni, ed estende le librerie come vuole.

In questo modo chi fa librerie implementa delle API standard - cosi' un programmatore impara quelle ed e' sicuro di usarle come meglio crede - e inoltre aggiunge estensioni, e implementa le API come meglio crede: se GTK ha una filosofia tipo: "carico quando ho bisogno cosi' occupo meno ram", Qt mantiene la filosofia: "Carico tutto cosi' sono piu' veloce dopo", questo viene fatto in modo indipendente e autonomo, senza pero' rinunciare ad una sola interfaccia grafica.

Io la butto li, mi piacerebbe - credo - uno standard per le GUI a questo livello, ma le complicazioni non sono poche...

primo: se due gui hanno dati diversi (eg se GTK gestisce la finestra come: w, h, colore, e Qt la gestisce come: w, h, colore e spessore) si dovrebbe trovare l'intersezione, e non e' sicuramente una cosa facile...

Mi sa che non si risolvera' molto facilmente questo problema  :Very Happy: 

Ciauz

----------

## Dr.Dran

QUOTO in pieno... Ecco ora ho capito bene il concetto che volevi esprimere e credo di essere daccordo con te, definiamo degli standard sulle classi e sulle funzioni, beh questo è molto interessante ma alquanto utopico  :Razz:   :Very Happy: 

----------

## akiross

Secondo me sarebbe fattibile se si definissero dei layer (come fa W3C con XHTML ad esempio, o per X3D):

Un layer "base" che include i widget base: finestra, bottoni, text eccetera. In questo modo i toolkit basilari e semplici userebbero questo layer di API.

Un layer "esteso" che include widget per OpenGL, widget per i plot x,y, e cose avanzate di questo tipo. Cosi' i toolkit avanzati tipo Qt o GTK implementano queste interfacce anche ad un livello piu' elevato (nel senso di complessita').

Poi ovviamente non puoi standardizzare tutto: se Qt ha un widget per fare il caffe' che GTK non ha, e' ovvio che non puoi standardizzarlo, quindi questo widget diventa una estensione del layer esteso.

Sarebbe fattibile: garantire un livello minimo di compatibilita': se fai una aplicazione di layer esteso, sei sicuro che hai a tua disposizione alcuni widget, e non altri.

Umm mi garba questa idea  :Very Happy: 

----------

## Dr.Dran

Ecco questa è una vera e buona soluzione! E credo che si quella + fattibile a cui si sta tentando di arrivare  :Wink: 

----------

## akiross

Ora dovremmo preoccuparci di capire se

1. Qualcuno ci ha gia pensato e sta sviluppando qualcosa

2. Se qualcosa esiste, vedere se e' davvero valida come soluzione

3. Se non esiste niente, muoviamoci noi e/o interpelliamo/contattiamo qualcuno che e' in posizione per farlo

Magari scrivendo a freesdekstop.org valutano se e' fattobile... o magari a livelli ancora piu' alti tipo ISO/ANSI... chissa' se questa idea puo' interessarli.

Al massimo lo metto tra i progetti dei bluecodelabs.org  :Very Happy:  [OT]Eh un pelo di pubblicita', comunque non serve che andiate a visitare il sito che non c'e' su ancora niente, a parte i loghi e qualche prova  :Very Happy: [/OT]

Ciauz

----------

## Dr.Dran

beh io ho il www.TekNoLab.net anche questo è in fase beta e per ora ci sono solo prove e cavolatine, magari se viene fuori qualche cosa di bello si può tentare di fare un Ring-Network  :Wink: 

----------

## mouser

Mi sembra si sia giunti ad una soluzione fattibile e moooolto carina....

Se avete bisogno di 10 dita in piu', sapete dove trovarmi  :Laughing: 

Ciriciao

mouser  :Wink: 

----------

