Dcromato
05-02-2010, 21:28
A volte ci penso e credo che possa davvero essere una cosa buona per come si stanno evolvendo le Qt...sono il solo a sognare?
View Full Version : Riscrivere Gnome su Qt?
kernelex
05-02-2010, 21:42
o gnome in qt o kde in gtk.
mi sono fracassato di avere millemila librerie in ram, magaro per solo un programma, e avere una GUI non omogenea.
Sto sognando per tante cose da 8 anni e mi sono fracassato i maroni, al prossimo giro win 7 e OSX.
mi sono fracassato di avere millemila librerie in ram, magaro per solo un programma, e avere una GUI non omogenea.
Sto sognando per tante cose da 8 anni e mi sono fracassato i maroni, al prossimo giro win 7 e OSX.
bicchiere
05-02-2010, 22:03
io mi accontenterei di sognare un futuro QUALSIASI per gnome e kde,
non sono convinto che ci sarà.
non sono convinto che ci sarà.
Chiancheri
05-02-2010, 22:17
io mi accontenterei di sognare un futuro QUALSIASI per gnome e kde,
non sono convinto che ci sarà.
mah io non la vedo così tragica.. poi gnome-shell prossimamente porterà un bel pò di novità..
non sono convinto che ci sarà.
mah io non la vedo così tragica.. poi gnome-shell prossimamente porterà un bel pò di novità..
killercode
05-02-2010, 23:46
Si, non sarebbe male, ma mantenedo la filosofia k.i.s.s. perchè ad usare kde mi vengono gli attacchi di panico dal casino che c'è
Dcromato
05-02-2010, 23:50
Si, non sarebbe male, ma mantenedo la filosofia k.i.s.s. perchè ad usare kde mi vengono gli attacchi di panico dal casino che c'è
beh non c'entra un cavo qui kde, ma le qt4 sono quanto di piu avanzato ci sia in ambiente opensource e oltretutto in lgpl come chiedeva la comunità....usarle ora sarebbe una cosa davvero valida.
beh non c'entra un cavo qui kde, ma le qt4 sono quanto di piu avanzato ci sia in ambiente opensource e oltretutto in lgpl come chiedeva la comunità....usarle ora sarebbe una cosa davvero valida.
jeremy.83
06-02-2010, 00:55
Assolutamente favorevole.
Le qt4 sono le librerie grafiche migliori al mondo, non c'è storia.
Peccato che l'unico DE che le implementi era rivoluzionario 2 anni fa, soppiantato oggi da gnome di ubuntu e win 7, tutto imho.
Le qt4 sono le librerie grafiche migliori al mondo, non c'è storia.
Peccato che l'unico DE che le implementi era rivoluzionario 2 anni fa, soppiantato oggi da gnome di ubuntu e win 7, tutto imho.
red.hell
06-02-2010, 09:20
riscrivessero firefox e thunderbird in QT :sbav: :sbav:
bicchiere
06-02-2010, 10:36
Ricordiamo inoltre che Opera sta abbandonando le QT.
IMHO, perché sono di Nokia.
IMHO, perché sono di Nokia.
>|HaRRyFocKer|
06-02-2010, 14:14
Ricordiamo che gnome sta avendo qualche problemino con GNU. Potrebbe addirittura uscirne...
McB
06-02-2010, 15:14
A me è completamente indifferente. Gnome mi funziona bene anche così. Qualche programma in qt lo uso e se mi sta in ram non me ne può fregare di meno.
Damage92
06-02-2010, 17:07
Una delle cose belle dell'opensource è che esistono tante alternative diverse, la conseguenza è che poi sono "incompatibili" tra loro.
Le cose sono due: o trovano un modo per renderle completamente compatibili (una base comune per esempio), oppure riscrivono i programmi per entrambi i casi!
Ma abbandonare non è possibile... potrebbe nascere un altro ambiente in qt simile, ma sicuramente gnome non verrebbe abbandonato!
E poi io uso solo programmi gtk, quali sono quelli che usate voi in qt su gnome?
Le cose sono due: o trovano un modo per renderle completamente compatibili (una base comune per esempio), oppure riscrivono i programmi per entrambi i casi!
Ma abbandonare non è possibile... potrebbe nascere un altro ambiente in qt simile, ma sicuramente gnome non verrebbe abbandonato!
E poi io uso solo programmi gtk, quali sono quelli che usate voi in qt su gnome?
McB
06-02-2010, 18:43
Ormai in qt ne uso solo 1 ed è smplayer. Prima ne usavo un paio.
Dcromato
06-02-2010, 20:26
Ricordiamo che gnome sta avendo qualche problemino con GNU. Potrebbe addirittura uscirne...
:eek: :eek: :eek:
come mai?Cavoli Gnome è la faccia della FSF...
:eek: :eek: :eek:
come mai?Cavoli Gnome è la faccia della FSF...
ozeta
06-02-2010, 20:48
ma chi ha votato no potrebbe argomentare? ormai sono 7 vs 6 :stordita:
kernelex
06-02-2010, 21:20
riscrivessero firefox e thunderbird in QT :sbav: :sbav:
http://aur.archlinux.org/packages.php?ID=22050 :O
aggiornatevi con un bel pacman -Syu :O
provato win 7 e tutti i suoi programmi impallati e in loop, al prossimo giro arch e kde4 :O
http://aur.archlinux.org/packages.php?ID=22050 :O
aggiornatevi con un bel pacman -Syu :O
provato win 7 e tutti i suoi programmi impallati e in loop, al prossimo giro arch e kde4 :O
yggdrasil
06-02-2010, 21:21
ma chi ha votato no potrebbe argomentare? ormai sono 7 vs 6 :stordita:
io ho appena votato.
è una sensazione di pelle...sia come utente di programmi qt, che di un desktop environment che come programmatore.
sarà che fin dall'inizio non mi sono mai piaciute tutte quelle k dentro kde ma kde proprio non mi va giù, troppo pieno di fronzoli. e le qt hanno seguito questo mia profonda avversità con le stesse librerie alla base di kde.
poi ci si aggiunge un fattore prettamente di logistica: le qt sono in mano a nokia(lo so, lgpl e blablabla ma alla fine senza i dindi di nokia... :rolleyes: ) invece le gtk sono più in mano alla comunità (fsf). da un lato è un difetto ma dall'altro è un grosso pregio. ;)
se poi ci si aggiunge che non mi ci trovo a programmare in qt(parlo di python)...:D
io ho appena votato.
è una sensazione di pelle...sia come utente di programmi qt, che di un desktop environment che come programmatore.
sarà che fin dall'inizio non mi sono mai piaciute tutte quelle k dentro kde ma kde proprio non mi va giù, troppo pieno di fronzoli. e le qt hanno seguito questo mia profonda avversità con le stesse librerie alla base di kde.
poi ci si aggiunge un fattore prettamente di logistica: le qt sono in mano a nokia(lo so, lgpl e blablabla ma alla fine senza i dindi di nokia... :rolleyes: ) invece le gtk sono più in mano alla comunità (fsf). da un lato è un difetto ma dall'altro è un grosso pregio. ;)
se poi ci si aggiunge che non mi ci trovo a programmare in qt(parlo di python)...:D
Dcromato
06-02-2010, 21:33
Io ho votato si perchè le applicazioni in qt4 mi sembrano molto piu leggere e reattive.Sto provando kde proprio in questi giorni e mi sembra diventato una piuma.Se le Qt4 hanno portato questo alleggerimento l'attesa allora ne è valsa.
McB
07-02-2010, 09:42
:eek: :eek: :eek:
come mai?Cavoli Gnome è la faccia della FSF...
Se non sbaglio è perchè gnome per certe cose vorrebbe usare mono come base. O così mi era parso di capire.
Aspettiamo >|HaRRyFocKer| per vedere se è questo o c'è un altro motivo.
come mai?Cavoli Gnome è la faccia della FSF...
Se non sbaglio è perchè gnome per certe cose vorrebbe usare mono come base. O così mi era parso di capire.
Aspettiamo >|HaRRyFocKer| per vedere se è questo o c'è un altro motivo.
Barra
07-02-2010, 11:54
Se non sbaglio è perchè gnome per certe cose vorrebbe usare mono come base. O così mi era parso di capire.
Aspettiamo >|HaRRyFocKer| per vedere se è questo o c'è un altro motivo.
Mono non ha nulla a che vedere con questo.
Tutto è nato dal fatto che planet gnome pubblica post presi dai posti degli sviuppatori. In questi post personaggi come De icaza (ma anche molti dei dipendenti di collabora che hanno lavorato con nokia x il n900) parlano del loro lavoro e di cavolate di progetti non strettamente legatia gnome e a FSF. Da qui la risposta (un pò infastidita dal solito tono di RMS: io sono dio, seguite i miei insegnamenti) di uno dei leader del progetto gnome (non ricordo chi) ha ipotizzato l'uscita da FSF per accontentare RMS.
Tornando IT: ho votato contro per vari motivi:
-Lo sforzo richiesto farebbe tornare all'età della pietra questo DE (mentre si reinventa la ruota i concorrenti andrebbero avanti).
-ottimizzare le gtk è un lavoro possibile e già avviato. Molta della lentezza è data dall'abbondanza di "vecchio codice" mantenuto per questioni di compatibilità. Gnome3 romperà questa compatibilità e quindi tutto dovrebbe diventare più veloce.
-tutti i migliori applicativi nati nell'ultimo periodo sono gtk, Evidentemente non sono poi così scarse. Oggi un Ubuntu user x cosa usa QT? Personalmente uso solo SMPplayer e se trovassi un'alternativa di mio gradimento in GTK un pò più evoluta di totem mi libererei anche di questo
-Gtk come già detto da altri sono indipendenti. Questo offre un notevole vantaggio tecnico: vanno nella direzione stabilita dalla gnome foundation e da nessun altro. Mi sbaglierò ma temo che QT possano diventare un tools un pò troppo legato a nokia e ai progetti di suo interesse. Se questo è un bene (sviluppare su dispositivi mobile sarà una passeggiata) potrebbero esserci problemi in futuro per il mancato supporto a tecnologie magari necessarie per un DE o in generale per applicativi desktop. Tutto a livello teorico ma i rischi ci sono.
-Grazie all'introduzione dei temi css in gtk (già attivo in gnome-shell) sarà possibile editare un tema anche per chi non capisce una mazza di programmazione!
Aspettiamo >|HaRRyFocKer| per vedere se è questo o c'è un altro motivo.
Mono non ha nulla a che vedere con questo.
Tutto è nato dal fatto che planet gnome pubblica post presi dai posti degli sviuppatori. In questi post personaggi come De icaza (ma anche molti dei dipendenti di collabora che hanno lavorato con nokia x il n900) parlano del loro lavoro e di cavolate di progetti non strettamente legatia gnome e a FSF. Da qui la risposta (un pò infastidita dal solito tono di RMS: io sono dio, seguite i miei insegnamenti) di uno dei leader del progetto gnome (non ricordo chi) ha ipotizzato l'uscita da FSF per accontentare RMS.
Tornando IT: ho votato contro per vari motivi:
-Lo sforzo richiesto farebbe tornare all'età della pietra questo DE (mentre si reinventa la ruota i concorrenti andrebbero avanti).
-ottimizzare le gtk è un lavoro possibile e già avviato. Molta della lentezza è data dall'abbondanza di "vecchio codice" mantenuto per questioni di compatibilità. Gnome3 romperà questa compatibilità e quindi tutto dovrebbe diventare più veloce.
-tutti i migliori applicativi nati nell'ultimo periodo sono gtk, Evidentemente non sono poi così scarse. Oggi un Ubuntu user x cosa usa QT? Personalmente uso solo SMPplayer e se trovassi un'alternativa di mio gradimento in GTK un pò più evoluta di totem mi libererei anche di questo
-Gtk come già detto da altri sono indipendenti. Questo offre un notevole vantaggio tecnico: vanno nella direzione stabilita dalla gnome foundation e da nessun altro. Mi sbaglierò ma temo che QT possano diventare un tools un pò troppo legato a nokia e ai progetti di suo interesse. Se questo è un bene (sviluppare su dispositivi mobile sarà una passeggiata) potrebbero esserci problemi in futuro per il mancato supporto a tecnologie magari necessarie per un DE o in generale per applicativi desktop. Tutto a livello teorico ma i rischi ci sono.
-Grazie all'introduzione dei temi css in gtk (già attivo in gnome-shell) sarà possibile editare un tema anche per chi non capisce una mazza di programmazione!
McB
07-02-2010, 12:11
Grazie per la spiegazione Barra.
Bisogna proprio dire che RMS ogni tanto tanto rompe un pò troppo.:)
Bisogna proprio dire che RMS ogni tanto tanto rompe un pò troppo.:)
Barra
07-02-2010, 13:39
sinceramente non ho trovato l'appunto fatto da RMS completamente fuoriluogo. L'atteggiamento è IMHO ASSURDO ma non lo è l'argomento.
Un planet che tratta di opensource e in particolare di linux, applicativi GTK e gnome dovrebbe concentrarsi su di esso. Visto che è stato costruito ad-hoc sarebbe stato intelligente fare in modo di implementare nel codice un qualcosa che andasse ad escludere i post taggati in certo modo.
Anche io non sopporto che si parli di altro in aggregatori a tema. Se RMS avesse argomentato con PIÙ INTELLIGENZA tutto si sarebbe risolto con una tranquilla discussione che avrebbe portato IMHO a qualcosa di buono (fermo restando cmq che ritengo l'allontamamento da FSF di gnome una cosa positiva, ma non è questo l'argomento della discussione).
Dcromato scusami per l'OT (o quasi OT) :ave: , non continuerò la discussione qui, al massimo apriamo un thread dedicato!
Un planet che tratta di opensource e in particolare di linux, applicativi GTK e gnome dovrebbe concentrarsi su di esso. Visto che è stato costruito ad-hoc sarebbe stato intelligente fare in modo di implementare nel codice un qualcosa che andasse ad escludere i post taggati in certo modo.
Anche io non sopporto che si parli di altro in aggregatori a tema. Se RMS avesse argomentato con PIÙ INTELLIGENZA tutto si sarebbe risolto con una tranquilla discussione che avrebbe portato IMHO a qualcosa di buono (fermo restando cmq che ritengo l'allontamamento da FSF di gnome una cosa positiva, ma non è questo l'argomento della discussione).
Dcromato scusami per l'OT (o quasi OT) :ave: , non continuerò la discussione qui, al massimo apriamo un thread dedicato!
jeremy.83
07-02-2010, 14:38
poi ci si aggiunge un fattore prettamente di logistica: le qt sono in mano a nokia(lo so, lgpl e blablabla ma alla fine senza i dindi di nokia... :rolleyes: ) invece le gtk sono più in mano alla comunità (fsf). da un lato è un difetto ma dall'altro è un grosso pregio. ;)
Mi dispiace, ma non approvo. MENO MALE che le qt sono dietro a una grossa azienda, un'azienda a scopo di lucro.... molti casini vengono meno, perchè perdere i soldi è peggio che perdere la faccia.
Ma poi non capisco, nokia le ha migliorate notevolmente queste qt, in più le han fatte lgpl....
Per quanto riguarda quello che diceva Barra di reinventare la ruota da gtk a qt... beh nel frattempo potrebbero mantenere il vecchio supporto, MS ci viaggia da 20 anni con la retrocompatibilità. Per i soldi, Stallman potrebbe pagare i programmatori con tutti i soldi che si fa dalle conferenze, visto che non mi risulta che li spenda in vestiti
Mi dispiace, ma non approvo. MENO MALE che le qt sono dietro a una grossa azienda, un'azienda a scopo di lucro.... molti casini vengono meno, perchè perdere i soldi è peggio che perdere la faccia.
Ma poi non capisco, nokia le ha migliorate notevolmente queste qt, in più le han fatte lgpl....
Per quanto riguarda quello che diceva Barra di reinventare la ruota da gtk a qt... beh nel frattempo potrebbero mantenere il vecchio supporto, MS ci viaggia da 20 anni con la retrocompatibilità. Per i soldi, Stallman potrebbe pagare i programmatori con tutti i soldi che si fa dalle conferenze, visto che non mi risulta che li spenda in vestiti
eclissi83
07-02-2010, 16:10
in più le han fatte lgpl....
peccato che le librerie lgpl possano essere incluse in software closed, alimentando cosi' l'utilizzo di software libero (le librerie lgpl) senza ritorno alcuno verso la comunita' (il software finale e' closed). tutto cio', ovviamente, e' un danno per tutto il software libero.
Per quanto riguarda quello che diceva Barra di reinventare la ruota da gtk a qt... beh nel frattempo potrebbero mantenere il vecchio supporto, MS ci viaggia da 20 anni con la retrocompatibilità. Per i soldi, Stallman potrebbe pagare i programmatori con tutti i soldi che si fa dalle conferenze, visto che non mi risulta che li spenda in vestiti
microsoft ha risorse diverse di quelle della gnome foundation e puo' permettersi di avere un team che segue la retrocompatibilita' delle applicazioni.
non so quanto sia fattibile tutto cio': un'unica piattaforma comporta un'accentramento degli sforzi, il che sarebbe un bene (siano esse qt, gtk o delle fantomatiche qtk4 :p ) per l'uniformita' dell'interfaccia. d'altro canto c'e' anche da riflettere sull'ideologia che c'e' alla base di tutto il software libero, che una scelta del genere un po' castrerebbe.
i fondi che stallman raccoglie alle conferenze (a cui viene gratis, e' bene ricordarlo) vanno nelle casse della Free Software Foundation, che deve mantenere in piedi una struttura ben piu' complessa di un paio di siti web... basta pensare solo al team che segue le problematiche legali che ci sono attorno alle licenze e al patent violation per avere un'idea...
ciao
peccato che le librerie lgpl possano essere incluse in software closed, alimentando cosi' l'utilizzo di software libero (le librerie lgpl) senza ritorno alcuno verso la comunita' (il software finale e' closed). tutto cio', ovviamente, e' un danno per tutto il software libero.
Per quanto riguarda quello che diceva Barra di reinventare la ruota da gtk a qt... beh nel frattempo potrebbero mantenere il vecchio supporto, MS ci viaggia da 20 anni con la retrocompatibilità. Per i soldi, Stallman potrebbe pagare i programmatori con tutti i soldi che si fa dalle conferenze, visto che non mi risulta che li spenda in vestiti
microsoft ha risorse diverse di quelle della gnome foundation e puo' permettersi di avere un team che segue la retrocompatibilita' delle applicazioni.
non so quanto sia fattibile tutto cio': un'unica piattaforma comporta un'accentramento degli sforzi, il che sarebbe un bene (siano esse qt, gtk o delle fantomatiche qtk4 :p ) per l'uniformita' dell'interfaccia. d'altro canto c'e' anche da riflettere sull'ideologia che c'e' alla base di tutto il software libero, che una scelta del genere un po' castrerebbe.
i fondi che stallman raccoglie alle conferenze (a cui viene gratis, e' bene ricordarlo) vanno nelle casse della Free Software Foundation, che deve mantenere in piedi una struttura ben piu' complessa di un paio di siti web... basta pensare solo al team che segue le problematiche legali che ci sono attorno alle licenze e al patent violation per avere un'idea...
ciao
jeremy.83
07-02-2010, 16:37
peccato che le librerie lgpl possano essere incluse in software closed, alimentando cosi' l'utilizzo di software libero (le librerie lgpl) senza ritorno alcuno verso la comunita' (il software finale e' closed). tutto cio', ovviamente, e' un danno per tutto il software libero.
Mah, guarda, dato che si sta parlando delle qt, che sono mantenute da nokia, il "ritorno verso la comunità" te lo dà nokia che ha tutto l'interesse per mantenerlo. Inoltre se il prodotto è buono e diventa utile alle grandi aziende, io penso che i fondi possano provenire da quelle grosse aziende che fanno anche del closed i loro maggiori guadagni (come fanno col kernel linux, ad esempio). Detto questo non vedo danni per il software libero, tutt'altro.
Anzi quei programmatori che creano sw libero "per diletto" e che quindi vivono del software closed potrebbero utilizzare le qt senza diventare pazzi per i loro prodotti closed, offrendo qualcosa di meglio ai loro clienti.
microsoft ha risorse diverse di quelle della gnome foundation e puo' permettersi di avere un team che segue la retrocompatibilita' delle applicazioni.
non so quanto sia fattibile tutto cio': un'unica piattaforma comporta un'accentramento degli sforzi, il che sarebbe un bene (siano esse qt, gtk o delle fantomatiche qtk4 :p ) per l'uniformita' dell'interfaccia. d'altro canto c'e' anche da riflettere sull'ideologia che c'e' alla base di tutto il software libero, che una scelta del genere un po' castrerebbe.
i fondi che stallman raccoglie alle conferenze (a cui viene gratis, e' bene ricordarlo) vanno nelle casse della Free Software Foundation, che deve mantenere in piedi una struttura ben piu' complessa di un paio di siti web... basta pensare solo al team che segue le problematiche legali che ci sono attorno alle licenze e al patent violation per avere un'idea...
ciao
Io penso che con un po' di sforzo anche lavorativo si possa fare, oltre al fatto di chiedere money alle grosse aziende...
Quella di Stallman voleva essere una battuta, anche se sinceramente lo reputo troppo integralista.
Mah, guarda, dato che si sta parlando delle qt, che sono mantenute da nokia, il "ritorno verso la comunità" te lo dà nokia che ha tutto l'interesse per mantenerlo. Inoltre se il prodotto è buono e diventa utile alle grandi aziende, io penso che i fondi possano provenire da quelle grosse aziende che fanno anche del closed i loro maggiori guadagni (come fanno col kernel linux, ad esempio). Detto questo non vedo danni per il software libero, tutt'altro.
Anzi quei programmatori che creano sw libero "per diletto" e che quindi vivono del software closed potrebbero utilizzare le qt senza diventare pazzi per i loro prodotti closed, offrendo qualcosa di meglio ai loro clienti.
microsoft ha risorse diverse di quelle della gnome foundation e puo' permettersi di avere un team che segue la retrocompatibilita' delle applicazioni.
non so quanto sia fattibile tutto cio': un'unica piattaforma comporta un'accentramento degli sforzi, il che sarebbe un bene (siano esse qt, gtk o delle fantomatiche qtk4 :p ) per l'uniformita' dell'interfaccia. d'altro canto c'e' anche da riflettere sull'ideologia che c'e' alla base di tutto il software libero, che una scelta del genere un po' castrerebbe.
i fondi che stallman raccoglie alle conferenze (a cui viene gratis, e' bene ricordarlo) vanno nelle casse della Free Software Foundation, che deve mantenere in piedi una struttura ben piu' complessa di un paio di siti web... basta pensare solo al team che segue le problematiche legali che ci sono attorno alle licenze e al patent violation per avere un'idea...
ciao
Io penso che con un po' di sforzo anche lavorativo si possa fare, oltre al fatto di chiedere money alle grosse aziende...
Quella di Stallman voleva essere una battuta, anche se sinceramente lo reputo troppo integralista.
eclissi83
07-02-2010, 17:11
Mah, guarda, dato che si sta parlando delle qt, che sono mantenute da nokia, il "ritorno verso la comunità" te lo dà nokia che ha tutto l'interesse per mantenerlo. Inoltre se il prodotto è buono e diventa utile alle grandi aziende, io penso che i fondi possano provenire da quelle grosse aziende che fanno anche del closed i loro maggiori guadagni (come fanno col kernel linux, ad esempio). Detto questo non vedo danni per il software libero, tutt'altro.
Nokia ha acquistato Trolltech e quindi le Qt per un motivo commerciale, visto che aveva necessita' di librerie grafiche per i suoi dispositivi mobili.
appena acquistate le ha fatte rilasciare in lgpl in modo da poterle inserire nei suoi software closed.
tra l'altro quando parlo di "ritorno alla comunita'", non lo intendo facendo riferimento alle librerie stesse (che restano comunque libere), ma parlo dei software closed sviluppati su quelle librerie, che non mi sembra diano qualcosa al resto del mondo del software libero.
inoltre grandi aziende (come RedHat o Intel, per esempio) contribuiscono attivamente allo sviluppo del kernel linux e del software libero. di quali fondi parli? altre aziende che daranno soldi per lo sviluppo delle qt che gia' sono pagate da nokia?
quali vantaggi vedi per il software libero nello sviluppo di software closed? scusa ma non c'arrivo (il tono non e' polemico anche se magari non si capisce).
Anzi quei programmatori che creano sw libero "per diletto" e che quindi vivono del software closed potrebbero utilizzare le qt senza diventare pazzi per i loro prodotti closed, offrendo qualcosa di meglio ai loro clienti.
oppure potrebbero pensare di cambiare tipologia di "business" e non vendere software closed ma personalizzazioni e servizi di software liberi, ma questa cosa meriterebbe un thread apposito, quindi non vado oltre.
Io penso che con un po' di sforzo anche lavorativo si possa fare, oltre al fatto di chiedere money alle grosse aziende...
sinceramente non lo so, secondo me la mole di lavoro e' davvero grossa e difficilmente affrontabile.
Quella di Stallman voleva essere una battuta, anche se sinceramente lo reputo troppo integralista.
e' anche grazie all'integralismo di stallman che si ha gnu/linux come e' oggi, ed hai tante applicazioni libere che utilizzi tutti i giorni. forse, se stallman fosse stato meno integralista, avremmo un sistema operativo molto piu' chiuso di quanto lo e' ora.
ciao
Nokia ha acquistato Trolltech e quindi le Qt per un motivo commerciale, visto che aveva necessita' di librerie grafiche per i suoi dispositivi mobili.
appena acquistate le ha fatte rilasciare in lgpl in modo da poterle inserire nei suoi software closed.
tra l'altro quando parlo di "ritorno alla comunita'", non lo intendo facendo riferimento alle librerie stesse (che restano comunque libere), ma parlo dei software closed sviluppati su quelle librerie, che non mi sembra diano qualcosa al resto del mondo del software libero.
inoltre grandi aziende (come RedHat o Intel, per esempio) contribuiscono attivamente allo sviluppo del kernel linux e del software libero. di quali fondi parli? altre aziende che daranno soldi per lo sviluppo delle qt che gia' sono pagate da nokia?
quali vantaggi vedi per il software libero nello sviluppo di software closed? scusa ma non c'arrivo (il tono non e' polemico anche se magari non si capisce).
Anzi quei programmatori che creano sw libero "per diletto" e che quindi vivono del software closed potrebbero utilizzare le qt senza diventare pazzi per i loro prodotti closed, offrendo qualcosa di meglio ai loro clienti.
oppure potrebbero pensare di cambiare tipologia di "business" e non vendere software closed ma personalizzazioni e servizi di software liberi, ma questa cosa meriterebbe un thread apposito, quindi non vado oltre.
Io penso che con un po' di sforzo anche lavorativo si possa fare, oltre al fatto di chiedere money alle grosse aziende...
sinceramente non lo so, secondo me la mole di lavoro e' davvero grossa e difficilmente affrontabile.
Quella di Stallman voleva essere una battuta, anche se sinceramente lo reputo troppo integralista.
e' anche grazie all'integralismo di stallman che si ha gnu/linux come e' oggi, ed hai tante applicazioni libere che utilizzi tutti i giorni. forse, se stallman fosse stato meno integralista, avremmo un sistema operativo molto piu' chiuso di quanto lo e' ora.
ciao
jeremy.83
07-02-2010, 17:58
di quali fondi parli? altre aziende che daranno soldi per lo sviluppo delle qt che gia' sono pagate da nokia?
Poco realizzabile, però sì.
quali vantaggi vedi per il software libero nello sviluppo di software closed? scusa ma non c'arrivo (il tono non e' polemico anche se magari non si capisce).
Beh, se per realizzare un sw closed migliorano le qt, di fatto le qt sono migliorate per tutti.
oppure potrebbero pensare di cambiare tipologia di "business" e non vendere software closed ma personalizzazioni e servizi di software liberi, ma questa cosa meriterebbe un thread apposito, quindi non vado oltre.
In un mondo diverso da quello reale sarei d'accordo con te, ma hai ragione, non parliamone oltre.
e' anche grazie all'integralismo di stallman che si ha gnu/linux come e' oggi, ed hai tante applicazioni libere che utilizzi tutti i giorni. forse, se stallman fosse stato meno integralista, avremmo un sistema operativo molto piu' chiuso di quanto lo e' ora.
ciao
Era giusto che Stallman fosse integralista all'inizio, ma ora che ha creato una buona comunità (sicuramente agguerrita) e un nome potrebbe snche scendere a patti con i vari diavoli, ma anche questo è OT, ripeto la mia citazione a Stallman voleva solo essere una battuta.
Ciao.
Poco realizzabile, però sì.
quali vantaggi vedi per il software libero nello sviluppo di software closed? scusa ma non c'arrivo (il tono non e' polemico anche se magari non si capisce).
Beh, se per realizzare un sw closed migliorano le qt, di fatto le qt sono migliorate per tutti.
oppure potrebbero pensare di cambiare tipologia di "business" e non vendere software closed ma personalizzazioni e servizi di software liberi, ma questa cosa meriterebbe un thread apposito, quindi non vado oltre.
In un mondo diverso da quello reale sarei d'accordo con te, ma hai ragione, non parliamone oltre.
e' anche grazie all'integralismo di stallman che si ha gnu/linux come e' oggi, ed hai tante applicazioni libere che utilizzi tutti i giorni. forse, se stallman fosse stato meno integralista, avremmo un sistema operativo molto piu' chiuso di quanto lo e' ora.
ciao
Era giusto che Stallman fosse integralista all'inizio, ma ora che ha creato una buona comunità (sicuramente agguerrita) e un nome potrebbe snche scendere a patti con i vari diavoli, ma anche questo è OT, ripeto la mia citazione a Stallman voleva solo essere una battuta.
Ciao.
CaFFeiNe
07-02-2010, 19:12
le qt sono in mano a nokia praticamente...
le altre sono in mano "invisibilmente" ma cmq in mano ad altre grosse aziende, nel senso che se queste aziende togliessero il loro supporto, lo sviluppo gtk, kernel, linux in generale perderebbe il 90% delle potenzialita' di crescita...
direttamente o indirettamente, i capitali e le aziende, sono fondamentali anche nell'ambiente opensource...
pensate che avremmo un sistema cosi' di qualita' se non ci fossero capitali (soldi o risorse umane) dietro con i propri interessi?
ci sono progetto completamente liberi...
ci sono sistemi a base unix che con un enorme apporto sarebbero facilmente superiori a linux....
eppure... 100 utenti.... 50 ?
linux fa invece qualche punto percentuale.... decine di migliaia....
novell ci vive di opensource....redhat, ibm, investono tutte con il loro ritorno...
nokia invece è legata alle qt... ma attenzione, questo diventa un arma a doppiotaglio, il "pericolo" è ben visibile, e quindi ci si puo' fare molta piu' attenzione....
io trovo che le qt, la loro altissima portabilita' e il fatto che almeno il 30 40%(ricordiamo che nokia mettera' le qt anche su symbian non solo maemo) dei telefoni al mondo, siano fattori positivi per la comunita'...
nuovi driver, nuovi capitali investiti, nuovi sviluppatori pagati, quindi tante ore di lavoro... etc...
inoltre le qt sono gia compatibili con:
linux
windows
linux maemo
symbian
windows mobile (in beta)
in modo da poter avere gli stessi software, compatibilita', multipiattaforma...
(ti piace come lettore audio amarok? potresti facilmente averlo sul tuo pc, sul tuo palmare maemo o windows mobile, e sul telefonino "muletto" symbian.... per fare un esempio)
nokia puo' decidere un giorno di cambiare la licenza..
bene il prodotto è ottimo, a quel punto, con una vastissima community di sviluppatori che hanno imparato, sara' facile per la community appropiarsi della versione lgpl delle librerie, e fare un fork delel librerie....
quindi se anche gnome fosse in qt, secondo me sarebbe ottimo, e la presenza di nokia sarebbe un problema secondario, perchè una volta unite le community kde/gnome/maemo/symbian...
e magari novell si interessa allo sviluppo che gia' è un ottima sostenitrice delle qt..
potremmo anche fare a meno di nokia e mandarla a quel paese :asd:
perchè vi ricordo che la symbian foundation al momento è completamente slegata da nokia, è una fondazione a parte, completamente libera, e finanziata da molte aziende...
non so, io vedo solo vantaggi ;)
jeremy, il software closed porta vantaggi indiretti.
ammettiamolo, una piattaforma appetibile commercialmente, attira tutti, attira intere, sviluppatori, etc.
se ci fosse un photoshop originale by adobe su linux, ci sono decine di grafici che magari lo userebbero.
e posso farti tanti altri esempi al merito....
ma cmq in linux la community c'è, aumenterebbe di volume e di COESIONE, gli sviluppatori lavorerebbero molto piu' "in parallelo", e sappiamo che in questo genere di cose, la parallelizzazione del dato è la migliore soluzione ;)
interessi comuni, sforzi maggiori ;)
le altre sono in mano "invisibilmente" ma cmq in mano ad altre grosse aziende, nel senso che se queste aziende togliessero il loro supporto, lo sviluppo gtk, kernel, linux in generale perderebbe il 90% delle potenzialita' di crescita...
direttamente o indirettamente, i capitali e le aziende, sono fondamentali anche nell'ambiente opensource...
pensate che avremmo un sistema cosi' di qualita' se non ci fossero capitali (soldi o risorse umane) dietro con i propri interessi?
ci sono progetto completamente liberi...
ci sono sistemi a base unix che con un enorme apporto sarebbero facilmente superiori a linux....
eppure... 100 utenti.... 50 ?
linux fa invece qualche punto percentuale.... decine di migliaia....
novell ci vive di opensource....redhat, ibm, investono tutte con il loro ritorno...
nokia invece è legata alle qt... ma attenzione, questo diventa un arma a doppiotaglio, il "pericolo" è ben visibile, e quindi ci si puo' fare molta piu' attenzione....
io trovo che le qt, la loro altissima portabilita' e il fatto che almeno il 30 40%(ricordiamo che nokia mettera' le qt anche su symbian non solo maemo) dei telefoni al mondo, siano fattori positivi per la comunita'...
nuovi driver, nuovi capitali investiti, nuovi sviluppatori pagati, quindi tante ore di lavoro... etc...
inoltre le qt sono gia compatibili con:
linux
windows
linux maemo
symbian
windows mobile (in beta)
in modo da poter avere gli stessi software, compatibilita', multipiattaforma...
(ti piace come lettore audio amarok? potresti facilmente averlo sul tuo pc, sul tuo palmare maemo o windows mobile, e sul telefonino "muletto" symbian.... per fare un esempio)
nokia puo' decidere un giorno di cambiare la licenza..
bene il prodotto è ottimo, a quel punto, con una vastissima community di sviluppatori che hanno imparato, sara' facile per la community appropiarsi della versione lgpl delle librerie, e fare un fork delel librerie....
quindi se anche gnome fosse in qt, secondo me sarebbe ottimo, e la presenza di nokia sarebbe un problema secondario, perchè una volta unite le community kde/gnome/maemo/symbian...
e magari novell si interessa allo sviluppo che gia' è un ottima sostenitrice delle qt..
potremmo anche fare a meno di nokia e mandarla a quel paese :asd:
perchè vi ricordo che la symbian foundation al momento è completamente slegata da nokia, è una fondazione a parte, completamente libera, e finanziata da molte aziende...
non so, io vedo solo vantaggi ;)
jeremy, il software closed porta vantaggi indiretti.
ammettiamolo, una piattaforma appetibile commercialmente, attira tutti, attira intere, sviluppatori, etc.
se ci fosse un photoshop originale by adobe su linux, ci sono decine di grafici che magari lo userebbero.
e posso farti tanti altri esempi al merito....
ma cmq in linux la community c'è, aumenterebbe di volume e di COESIONE, gli sviluppatori lavorerebbero molto piu' "in parallelo", e sappiamo che in questo genere di cose, la parallelizzazione del dato è la migliore soluzione ;)
interessi comuni, sforzi maggiori ;)
jeremy.83
07-02-2010, 20:48
Ma, guarda, figliolo, sono sostanzialmente d'accordo con te. Non capisco un paio di cose di quelle che dici:
nokia invece è legata alle qt... ma attenzione, questo diventa un arma a doppiotaglio, il "pericolo" è ben visibile, e quindi ci si puo' fare molta piu' attenzione....
Non capisco dove sta il "pericolo", considerando anche quello che scrivi dopo, che non riporto per brevità.
nokia puo' decidere un giorno di cambiare la licenza..
bene il prodotto è ottimo, a quel punto, con una vastissima community di sviluppatori che hanno imparato, sara' facile per la community appropiarsi della versione lgpl delle librerie, e fare un fork delel librerie....
Qui in realtà capisco, ma ribatto che nokia difficilmente cambierà licenze, per come la vedo io a nokia interessa hw e sw inteso come applicazioni, e avere le qt al massimo della libertà le toglie un sacco di fastidi.
non so, io vedo solo vantaggi ;)
jeremy, il software closed porta vantaggi indiretti.
ammettiamolo, una piattaforma appetibile commercialmente, attira tutti, attira intere, sviluppatori, etc.
se ci fosse un photoshop originale by adobe su linux, ci sono decine di grafici che magari lo userebbero.
e posso farti tanti altri esempi al merito....
ma cmq in linux la community c'è, aumenterebbe di volume e di COESIONE, gli sviluppatori lavorerebbero molto piu' "in parallelo", e sappiamo che in questo genere di cose, la parallelizzazione del dato è la migliore soluzione ;)
interessi comuni, sforzi maggiori ;)
Qui, io sostengo la tua stessa tesi... non si capiva?
nokia invece è legata alle qt... ma attenzione, questo diventa un arma a doppiotaglio, il "pericolo" è ben visibile, e quindi ci si puo' fare molta piu' attenzione....
Non capisco dove sta il "pericolo", considerando anche quello che scrivi dopo, che non riporto per brevità.
nokia puo' decidere un giorno di cambiare la licenza..
bene il prodotto è ottimo, a quel punto, con una vastissima community di sviluppatori che hanno imparato, sara' facile per la community appropiarsi della versione lgpl delle librerie, e fare un fork delel librerie....
Qui in realtà capisco, ma ribatto che nokia difficilmente cambierà licenze, per come la vedo io a nokia interessa hw e sw inteso come applicazioni, e avere le qt al massimo della libertà le toglie un sacco di fastidi.
non so, io vedo solo vantaggi ;)
jeremy, il software closed porta vantaggi indiretti.
ammettiamolo, una piattaforma appetibile commercialmente, attira tutti, attira intere, sviluppatori, etc.
se ci fosse un photoshop originale by adobe su linux, ci sono decine di grafici che magari lo userebbero.
e posso farti tanti altri esempi al merito....
ma cmq in linux la community c'è, aumenterebbe di volume e di COESIONE, gli sviluppatori lavorerebbero molto piu' "in parallelo", e sappiamo che in questo genere di cose, la parallelizzazione del dato è la migliore soluzione ;)
interessi comuni, sforzi maggiori ;)
Qui, io sostengo la tua stessa tesi... non si capiva?
Barra
07-02-2010, 22:04
@jeremy.83
nokia ha rilasciato le qt in lgpl ma a parte questo cosa ha fatto realmente per migliorarle?
@eclissi83
non sicuro che avere un'unica piattaforma di sviluppo significhi migliorare questa. Non avere concorrenza è una cosa spesso negativa.
Il mio timore, come ho già avuto modo di dire è che Nokia possa integrare in QT strumenti NON OPENSOURCE (possibile grazie alla licenza lgpl), oppure potrebbero introdurre in qt solo strumenti utili in dispositivi mobili, non dare supporto alle richieste della comunità ecc.
Lo sviluppo di GTK è in gran parte finanziato da aziende come RH, Intel, SUN/Oracle, IBM, Novell, Canonical, Collabora, oltre che da contribiti di FSF, Debian ecc.
Queste aziende fanno business con linux, ognuna sfruttando il lavoro degli altri. Questo non funziona con Nokia, azienda che sviluppa soluzioni closed e che anche con Maemo (che ricordo essere opensource e sviluppato su GTK) vive in un ambiente praticamente chiuso. Il passaggio all'opensource symbian poi IMHO significa solo che sta riducendo gli investimenti su quella che è una soluzione destinata a morire. La prossima Maemo (basata su QT) vedreche che finirà nella maggior parte dei dispositivi Nokia
(P.s.inizio ad essere vecchio tra voi pischelli classe 83 :D)
nokia ha rilasciato le qt in lgpl ma a parte questo cosa ha fatto realmente per migliorarle?
@eclissi83
non sicuro che avere un'unica piattaforma di sviluppo significhi migliorare questa. Non avere concorrenza è una cosa spesso negativa.
Il mio timore, come ho già avuto modo di dire è che Nokia possa integrare in QT strumenti NON OPENSOURCE (possibile grazie alla licenza lgpl), oppure potrebbero introdurre in qt solo strumenti utili in dispositivi mobili, non dare supporto alle richieste della comunità ecc.
Lo sviluppo di GTK è in gran parte finanziato da aziende come RH, Intel, SUN/Oracle, IBM, Novell, Canonical, Collabora, oltre che da contribiti di FSF, Debian ecc.
Queste aziende fanno business con linux, ognuna sfruttando il lavoro degli altri. Questo non funziona con Nokia, azienda che sviluppa soluzioni closed e che anche con Maemo (che ricordo essere opensource e sviluppato su GTK) vive in un ambiente praticamente chiuso. Il passaggio all'opensource symbian poi IMHO significa solo che sta riducendo gli investimenti su quella che è una soluzione destinata a morire. La prossima Maemo (basata su QT) vedreche che finirà nella maggior parte dei dispositivi Nokia
(P.s.inizio ad essere vecchio tra voi pischelli classe 83 :D)
eclissi83
08-02-2010, 00:41
@eclissi83
non sicuro che avere un'unica piattaforma di sviluppo significhi migliorare questa. Non avere concorrenza è una cosa spesso negativa.
si, il non aver concorrenza non l'avevo valutato, ed in effetti e' una cosa negativa, si farebbe il bello e cattivo tempo; cosi' com'e' ora, invece, un po' ci si rincorre a vicenda, cercando di dare comunque un prodotto migliore.
d'altro canto, una piattaforma comune permetterebbe, unendo (anche se non del tutto) i due team di sviluppo, una "forza lavoro" maggiore.
Il mio timore, come ho già avuto modo di dire è che Nokia possa integrare in QT strumenti NON OPENSOURCE (possibile grazie alla licenza lgpl), oppure potrebbero introdurre in qt solo strumenti utili in dispositivi mobili, non dare supporto alle richieste della comunità ecc.
questo pericolo e' dato esclusivamente dal fatto che dietro le Qt ci sia solo Nokia...
Lo sviluppo di GTK è in gran parte finanziato da aziende come RH, Intel, SUN/Oracle, IBM, Novell, Canonical, Collabora, oltre che da contribiti di FSF, Debian ecc.
anche le gtk sono rilasciate in LGPL, con {,gl}i {,s}vantaggi del caso, il loro punto di forza e' che le aziende che investono nelle gtk sono varie e che solitamente investono in software libero..
(P.s.inizio ad essere vecchio tra voi pischelli classe 83 :D)
non ti preoccupare, noi tutti (te compreso) siamo bambini, e' il mondo che ci invecchia a tradimento...
ciao
non sicuro che avere un'unica piattaforma di sviluppo significhi migliorare questa. Non avere concorrenza è una cosa spesso negativa.
si, il non aver concorrenza non l'avevo valutato, ed in effetti e' una cosa negativa, si farebbe il bello e cattivo tempo; cosi' com'e' ora, invece, un po' ci si rincorre a vicenda, cercando di dare comunque un prodotto migliore.
d'altro canto, una piattaforma comune permetterebbe, unendo (anche se non del tutto) i due team di sviluppo, una "forza lavoro" maggiore.
Il mio timore, come ho già avuto modo di dire è che Nokia possa integrare in QT strumenti NON OPENSOURCE (possibile grazie alla licenza lgpl), oppure potrebbero introdurre in qt solo strumenti utili in dispositivi mobili, non dare supporto alle richieste della comunità ecc.
questo pericolo e' dato esclusivamente dal fatto che dietro le Qt ci sia solo Nokia...
Lo sviluppo di GTK è in gran parte finanziato da aziende come RH, Intel, SUN/Oracle, IBM, Novell, Canonical, Collabora, oltre che da contribiti di FSF, Debian ecc.
anche le gtk sono rilasciate in LGPL, con {,gl}i {,s}vantaggi del caso, il loro punto di forza e' che le aziende che investono nelle gtk sono varie e che solitamente investono in software libero..
(P.s.inizio ad essere vecchio tra voi pischelli classe 83 :D)
non ti preoccupare, noi tutti (te compreso) siamo bambini, e' il mondo che ci invecchia a tradimento...
ciao
jeremy.83
08-02-2010, 22:15
@jeremy.83
nokia ha rilasciato le qt in lgpl ma a parte questo cosa ha fatto realmente per migliorarle?
No d'accordo, ancora nulla, però già passarle a lgpl è un vantaggio per tutti. Chi fa software closed per vivere (e lasciamo stare il discorso cambiare business perchè non funziona per tutti in questo mondo) poter usare le qt senza dover diventare pazzi con questioni di licenza solleva veramente il morale! Io quando uso qualche libreria che trovo su internet mi capita che non posso usarle o modificarle anche leggermente perchè la licenza non me lo permette col risultato che quella libreria di fatto non serve nel 90% dei casi
Il mio timore, come ho già avuto modo di dire è che Nokia possa integrare in QT strumenti NON OPENSOURCE (possibile grazie alla licenza lgpl), oppure potrebbero introdurre in qt solo strumenti utili in dispositivi mobili, non dare supporto alle richieste della comunità ecc.
Io non vedo dove sia il pericolo. In quasi 2 anni che lavoro stabilmente come PICCOLO programmatore il fatto di introdurre strumenti non open non me ne può fregà de meno: mi serve? funziona? perfetto, lo uso. Ho smesso di tirarmi le menate per i miei ristretti usi, e di gente come me ce n'è tanta.
(P.s.inizio ad essere vecchio tra voi pischelli classe 83 )
Pischello è il più grande complimento che potevi farmi :D :cool:
nokia ha rilasciato le qt in lgpl ma a parte questo cosa ha fatto realmente per migliorarle?
No d'accordo, ancora nulla, però già passarle a lgpl è un vantaggio per tutti. Chi fa software closed per vivere (e lasciamo stare il discorso cambiare business perchè non funziona per tutti in questo mondo) poter usare le qt senza dover diventare pazzi con questioni di licenza solleva veramente il morale! Io quando uso qualche libreria che trovo su internet mi capita che non posso usarle o modificarle anche leggermente perchè la licenza non me lo permette col risultato che quella libreria di fatto non serve nel 90% dei casi
Il mio timore, come ho già avuto modo di dire è che Nokia possa integrare in QT strumenti NON OPENSOURCE (possibile grazie alla licenza lgpl), oppure potrebbero introdurre in qt solo strumenti utili in dispositivi mobili, non dare supporto alle richieste della comunità ecc.
Io non vedo dove sia il pericolo. In quasi 2 anni che lavoro stabilmente come PICCOLO programmatore il fatto di introdurre strumenti non open non me ne può fregà de meno: mi serve? funziona? perfetto, lo uso. Ho smesso di tirarmi le menate per i miei ristretti usi, e di gente come me ce n'è tanta.
(P.s.inizio ad essere vecchio tra voi pischelli classe 83 )
Pischello è il più grande complimento che potevi farmi :D :cool:
zephyr83
09-02-2010, 16:18
peccato che le librerie lgpl possano essere incluse in software closed, alimentando cosi' l'utilizzo di software libero (le librerie lgpl) senza ritorno alcuno verso la comunita' (il software finale e' closed). tutto cio', ovviamente, e' un danno per tutto il software libero.
ma pure le gtk sn LGPL, anzi finora la scusa della preferenza delle gtk sulle qt era proprio QUESTA!! Prima dipendeva dal fatto che le qt NON erano GPL e nn ci si poteva fidare di trolltech anche se aveva dato tutte le rassicurazioni del caso cn una licenza alternativa! Poi quando sn diventate GPL nn andava ancora bene perché diverse grosse aziende hanno BISOGNO almeno della LGPL. Ora che pure le qt sn LGPL nn va bene lo stesso :sofico:
Io cmq sarei FAVOREVOLISSIMO! sn superiori ed è un dato di fatto (nn capisco perché qualcuno lo voglia negare) inoltre risolvono il dannato problema della compatibilità fra vari sistemi operativi. Cn la stessa SDK puoi programmare su: windows, linux, osx (e altri OS "minori"...per diffusione ovviamente), symbian, maemo e addirittura windows mobile (cn alcune limitazioni). Marble, diciamo un programma open source analogo a google earth presente in kde4 (ovviamente è fatto cn le qt4) è stato portato su windows mobile 5 senza alcun problema.....l'unica limitazione era la memoria virtuale di 32 MB su WM. Lo stesso sviluppatore ha detto che è stato un porting facilissimo!
Questo sarebbe un enorme vantaggio per tutti "noi"!!!
E poi cosa cambia se gnome è in gtk o in qt o in vattelapesca??? Come ha scritto qualcuno, l'importante è che rimanga la "filosofia" kiss, il resto nn conta! uno gnome in qt sarebbe come lo gnome attuale ma molto probabilmente più prestante. Si incrementerebbero i software in qt e ci sarebbero molti meno problemi di "integrazione".
Io penso che sia colpa dell'effetto "palio" (presente i palio di siena?), ormai kde e le qt, dopo tanti anni di "guerre" si odiano e si preferisce continuare a prescindere cn le gtk, anche se le QT hanno risolto tutti i problemi che lamentavano gli esponenti del software libero!!
Inoltre adesso si ha addirittura paura di nokia!! Se google e anche opera hanno deciso di nn sfruttare più le qt per me è solo perché sn di nokia, nn riesco a trovare altre giustificazioni!! A me pare che nokia si stia comportando benissimo, ha preso le QT e la rese anche LGPL! Sta collaborando cn quelli di koffice (da portare su maemo) e ha personalmente migliorato il supporto ai documenti di office. Ha "donato" (che in fondo cn software open source nn è che si possano vietare certe cose :sofico: ) l'interfaccia Hildon di maemo alla community che è stata subito integrata in gnome e verrà usata su ubuntu mobile edition (nokia su maemo userà una nuova interfaccia basata ovviamente sulle qt). Che paura c'è scusate? e poi le QT sn open source, se nokia decide di fare "caxxate" si possono sempre riprendere e sviluppare in altra maniera! Magari quelli di KDE potrebbero curarne lo sviluppo creando una qualche "fondazione", in maniera analoga a quello che succede per gnome o per firefox! dov'è tutta sta paura? E allora di gnome e delle gtk che si stanno legando sempre più a mono e a c#? :sofico: ma come, la si menava tanto alle QT e a trolltech inizialmente e ora ci si butta a pesce su microsoft? :sofico:
Mi spiace ma a me pare proprio l'effetto palio!!!! Anziché buttarsi sulle gtk# e su mono nn si poteva iniziare a passare alle QT? bastava inizialmente migliorare l'integrazione in gnome e cambiare di volta in volta qualcosa come già sta avvenendo per il passaggio a gnome 3. Tanto hanno già deciso di passare piano piano a gnome 3, avrebbero avuto tutto il tempo di farlo anche nel caso di utilizzo delle QT. Per me sarebbe stata un'ottima occasione per linux e tutto il mondo open source, maggior integrazioni, più programmi cross-platform!!
Io ci vedo solo VANTAGGI! gli svantaggi quali sarebbero? :stordita:
ma pure le gtk sn LGPL, anzi finora la scusa della preferenza delle gtk sulle qt era proprio QUESTA!! Prima dipendeva dal fatto che le qt NON erano GPL e nn ci si poteva fidare di trolltech anche se aveva dato tutte le rassicurazioni del caso cn una licenza alternativa! Poi quando sn diventate GPL nn andava ancora bene perché diverse grosse aziende hanno BISOGNO almeno della LGPL. Ora che pure le qt sn LGPL nn va bene lo stesso :sofico:
Io cmq sarei FAVOREVOLISSIMO! sn superiori ed è un dato di fatto (nn capisco perché qualcuno lo voglia negare) inoltre risolvono il dannato problema della compatibilità fra vari sistemi operativi. Cn la stessa SDK puoi programmare su: windows, linux, osx (e altri OS "minori"...per diffusione ovviamente), symbian, maemo e addirittura windows mobile (cn alcune limitazioni). Marble, diciamo un programma open source analogo a google earth presente in kde4 (ovviamente è fatto cn le qt4) è stato portato su windows mobile 5 senza alcun problema.....l'unica limitazione era la memoria virtuale di 32 MB su WM. Lo stesso sviluppatore ha detto che è stato un porting facilissimo!
Questo sarebbe un enorme vantaggio per tutti "noi"!!!
E poi cosa cambia se gnome è in gtk o in qt o in vattelapesca??? Come ha scritto qualcuno, l'importante è che rimanga la "filosofia" kiss, il resto nn conta! uno gnome in qt sarebbe come lo gnome attuale ma molto probabilmente più prestante. Si incrementerebbero i software in qt e ci sarebbero molti meno problemi di "integrazione".
Io penso che sia colpa dell'effetto "palio" (presente i palio di siena?), ormai kde e le qt, dopo tanti anni di "guerre" si odiano e si preferisce continuare a prescindere cn le gtk, anche se le QT hanno risolto tutti i problemi che lamentavano gli esponenti del software libero!!
Inoltre adesso si ha addirittura paura di nokia!! Se google e anche opera hanno deciso di nn sfruttare più le qt per me è solo perché sn di nokia, nn riesco a trovare altre giustificazioni!! A me pare che nokia si stia comportando benissimo, ha preso le QT e la rese anche LGPL! Sta collaborando cn quelli di koffice (da portare su maemo) e ha personalmente migliorato il supporto ai documenti di office. Ha "donato" (che in fondo cn software open source nn è che si possano vietare certe cose :sofico: ) l'interfaccia Hildon di maemo alla community che è stata subito integrata in gnome e verrà usata su ubuntu mobile edition (nokia su maemo userà una nuova interfaccia basata ovviamente sulle qt). Che paura c'è scusate? e poi le QT sn open source, se nokia decide di fare "caxxate" si possono sempre riprendere e sviluppare in altra maniera! Magari quelli di KDE potrebbero curarne lo sviluppo creando una qualche "fondazione", in maniera analoga a quello che succede per gnome o per firefox! dov'è tutta sta paura? E allora di gnome e delle gtk che si stanno legando sempre più a mono e a c#? :sofico: ma come, la si menava tanto alle QT e a trolltech inizialmente e ora ci si butta a pesce su microsoft? :sofico:
Mi spiace ma a me pare proprio l'effetto palio!!!! Anziché buttarsi sulle gtk# e su mono nn si poteva iniziare a passare alle QT? bastava inizialmente migliorare l'integrazione in gnome e cambiare di volta in volta qualcosa come già sta avvenendo per il passaggio a gnome 3. Tanto hanno già deciso di passare piano piano a gnome 3, avrebbero avuto tutto il tempo di farlo anche nel caso di utilizzo delle QT. Per me sarebbe stata un'ottima occasione per linux e tutto il mondo open source, maggior integrazioni, più programmi cross-platform!!
Io ci vedo solo VANTAGGI! gli svantaggi quali sarebbero? :stordita:
zephyr83
09-02-2010, 16:33
@jeremy.83
nokia ha rilasciato le qt in lgpl ma a parte questo cosa ha fatto realmente per migliorarle?
L'ho scritto anche prima, ha realizzato un'unica SDK che migliora lo sviluppo e ha eliminato le qtopia "integrandole" nelle QT normale! cmq nn è che nokia ha comprato trolltech e ha mandato tutti i dipendenti della ex azienda a casa :sofico: penso che buona parte degli sviluppatori che lavoravano alle qt prima, lavorino alle qt anche adesso :sofico:
Inoltre nokia sta collaborando ATTIVAMENTE cn altri progetti open source, soprattutto legati alle qt (vedi koffice) e la vechcia interfaccia di maemo (hildon) è stata integrata in gnome e verrà usata su ubuntu mobile edition! mi pare abbia fatto più nokia di tante altre grosse aziende che sfruttano l'open source e danno poco in cambio :sofico:
Nokia ha solo interesse che le qt migliorino e si diffondano!! inoltre è un'azienda che punta sulla vendita di "hardware", si può permettere benissimo di nn voler guadagnare direttamente sul software ma di usarlo invece come risorsa per i propri prodotti/servizi
nokia ha rilasciato le qt in lgpl ma a parte questo cosa ha fatto realmente per migliorarle?
L'ho scritto anche prima, ha realizzato un'unica SDK che migliora lo sviluppo e ha eliminato le qtopia "integrandole" nelle QT normale! cmq nn è che nokia ha comprato trolltech e ha mandato tutti i dipendenti della ex azienda a casa :sofico: penso che buona parte degli sviluppatori che lavoravano alle qt prima, lavorino alle qt anche adesso :sofico:
Inoltre nokia sta collaborando ATTIVAMENTE cn altri progetti open source, soprattutto legati alle qt (vedi koffice) e la vechcia interfaccia di maemo (hildon) è stata integrata in gnome e verrà usata su ubuntu mobile edition! mi pare abbia fatto più nokia di tante altre grosse aziende che sfruttano l'open source e danno poco in cambio :sofico:
Nokia ha solo interesse che le qt migliorino e si diffondano!! inoltre è un'azienda che punta sulla vendita di "hardware", si può permettere benissimo di nn voler guadagnare direttamente sul software ma di usarlo invece come risorsa per i propri prodotti/servizi
zephyr83
09-02-2010, 16:36
@jeremy.83
Il mio timore, come ho già avuto modo di dire è che Nokia possa integrare in QT strumenti NON OPENSOURCE (possibile grazie alla licenza lgpl), oppure potrebbero introdurre in qt solo strumenti utili in dispositivi mobili, non dare supporto alle richieste della comunità ecc.
pure le gtk sn lgpl, inoltre questi pericoli nn ci sn anche cn mono e c#? ci sn di mezzo anche "brevetti"!!!
Il mio timore, come ho già avuto modo di dire è che Nokia possa integrare in QT strumenti NON OPENSOURCE (possibile grazie alla licenza lgpl), oppure potrebbero introdurre in qt solo strumenti utili in dispositivi mobili, non dare supporto alle richieste della comunità ecc.
pure le gtk sn lgpl, inoltre questi pericoli nn ci sn anche cn mono e c#? ci sn di mezzo anche "brevetti"!!!
zephyr83
09-02-2010, 16:41
si, il non aver concorrenza non l'avevo valutato, ed in effetti e' una cosa negativa, si farebbe il bello e cattivo tempo; cosi' com'e' ora, invece, un po' ci si rincorre a vicenda, cercando di dare comunque un prodotto migliore.
d'altro canto, una piattaforma comune permetterebbe, unendo (anche se non del tutto) i due team di sviluppo, una "forza lavoro" maggiore.
mha nn saprei! a me pare finora che gtk e qt nn è che si siano fatta tutta sta grandissima concorrenza e quest'ultime hanno sempre avuto uno sviluppo "maggiore" e "migliore" (da notare le virgolette). Inoltre mi pare che gli sviluppatori abbiano sempre continuato per la propria strada senza badarsi troppo (se nn proprio all'inizio)!! C'è stata tantissima concorrenza fra gnome e kde, quello si e per me nn potrebbe far altro che AUMENTARE se adottassero le stesse librerie di base!
d'altro canto, una piattaforma comune permetterebbe, unendo (anche se non del tutto) i due team di sviluppo, una "forza lavoro" maggiore.
mha nn saprei! a me pare finora che gtk e qt nn è che si siano fatta tutta sta grandissima concorrenza e quest'ultime hanno sempre avuto uno sviluppo "maggiore" e "migliore" (da notare le virgolette). Inoltre mi pare che gli sviluppatori abbiano sempre continuato per la propria strada senza badarsi troppo (se nn proprio all'inizio)!! C'è stata tantissima concorrenza fra gnome e kde, quello si e per me nn potrebbe far altro che AUMENTARE se adottassero le stesse librerie di base!
eclissi83
09-02-2010, 16:56
pure le gtk sn lgpl, inoltre questi pericoli nn ci sn anche cn mono e c#? ci sn di mezzo anche "brevetti"!!!
ma infatti non si difendono le gtk necessariamente. non mi pare che ci sia scritto da nessuna parte, anzi. secondo me la reazione che ha avuto stallman sulla questione gnome e' stata piu' che lecita.
L'ho scritto anche prima, ha realizzato un'unica SDK che migliora lo sviluppo e ha eliminato le qtopia "integrandole" nelle QT normale! cmq nn è che nokia ha comprato trolltech e ha mandato tutti i dipendenti della ex azienda a casa :sofico: penso che buona parte degli sviluppatori che lavoravano alle qt prima, lavorino alle qt anche adesso :sofico:
io non sono un programmatore, ma anche prima programmare in qt era "facile e divertente" (passami il termine, virgolettato appositamente) e cio' che e' stato fatto per la portabilita' e' un grosso passo in avanti.
Inoltre nokia sta collaborando ATTIVAMENTE cn altri progetti open source, soprattutto legati alle qt (vedi koffice) e la vechcia interfaccia di maemo (hildon) è stata integrata in gnome e verrà usata su ubuntu mobile edition! mi pare abbia fatto più nokia di tante altre grosse aziende che sfruttano l'open source e danno poco in cambio :sofico:
non credo che altre aziende (tipo Intel o RedHat o IBM) diano poco allo sviluppo del software libero (che distinguo da quello open source), basti pensare solo a cio' che inseriscono nei rami del kernel per capirlo.
Nokia ha solo interesse che le qt migliorino e si diffondano!! inoltre è un'azienda che punta sulla vendita di "hardware", si può permettere benissimo di nn voler guadagnare direttamente sul software ma di usarlo invece come risorsa per i propri prodotti/servizi
e' chiaro che a nokia interessa che le qt si diffondano: c'ha investito soldi. le aziende non fanno nulla per caso, soprattutto colossi come nokia. il mio unico dubbio rimane non tanto sul fatto che le librerie restino o meno libere (perche' di fatto lo sono), ma sul fatto che nessuna azienda sviluppa un prodotto finito totalmente libero.
ma pure le gtk sn LGPL, anzi finora la scusa della preferenza delle gtk sulle qt era proprio QUESTA!! Prima dipendeva dal fatto che le qt NON erano GPL e nn ci si poteva fidare di trolltech anche se aveva dato tutte le rassicurazioni del caso cn una licenza alternativa! Poi quando sn diventate GPL nn andava ancora bene perché diverse grosse aziende hanno BISOGNO almeno della LGPL. Ora che pure le qt sn LGPL nn va bene lo stesso :sofico:
se avessi letto il successivo post ti saresti accorto che l'ho anche detto. ed ho anche spiegato la motivazione per cui secondo me la licenza LGPL non e' adatta per il mondo del software libero.
l'unico vantaggio, imho, per le gtk e' che alle spalle ci stanno varie aziende e non una sola.
Inoltre adesso si ha addirittura paura di nokia!! Se google e anche opera hanno deciso di nn sfruttare più le qt per me è solo perché sn di nokia, nn riesco a trovare altre giustificazioni!!
mah, io avrei piu' paura di google che di nokia, ma questo e' un altro paio di maniche.
A me pare che nokia si stia comportando benissimo, ha preso le QT e la rese anche LGPL! Sta collaborando cn quelli di koffice (da portare su maemo) e ha personalmente migliorato il supporto ai documenti di office. Ha "donato" (che in fondo cn software open source nn è che si possano vietare certe cose :sofico: ) l'interfaccia Hildon di maemo alla community che è stata subito integrata in gnome e verrà usata su ubuntu mobile edition (nokia su maemo userà una nuova interfaccia basata ovviamente sulle qt). Che paura c'è scusate? e poi le QT sn open source, se nokia decide di fare "caxxate" si possono sempre riprendere e sviluppare in altra maniera! Magari quelli di KDE potrebbero curarne lo sviluppo creando una qualche "fondazione", in maniera analoga a quello che succede per gnome o per firefox! dov'è tutta sta paura? E allora di gnome e delle gtk che si stanno legando sempre più a mono e a c#? :sofico: ma come, la si menava tanto alle QT e a trolltech inizialmente e ora ci si butta a pesce su microsoft? :sofico:
il problema, imho, non e' che nokia faccia cazzate e chiuda le qt, ma che nokia investa in software closed scritto usando le qt. ovviamente avrei detto la stessa cosa se nokia avesse acquistato le gtk piuttosto che le qt.
ciao
ma infatti non si difendono le gtk necessariamente. non mi pare che ci sia scritto da nessuna parte, anzi. secondo me la reazione che ha avuto stallman sulla questione gnome e' stata piu' che lecita.
L'ho scritto anche prima, ha realizzato un'unica SDK che migliora lo sviluppo e ha eliminato le qtopia "integrandole" nelle QT normale! cmq nn è che nokia ha comprato trolltech e ha mandato tutti i dipendenti della ex azienda a casa :sofico: penso che buona parte degli sviluppatori che lavoravano alle qt prima, lavorino alle qt anche adesso :sofico:
io non sono un programmatore, ma anche prima programmare in qt era "facile e divertente" (passami il termine, virgolettato appositamente) e cio' che e' stato fatto per la portabilita' e' un grosso passo in avanti.
Inoltre nokia sta collaborando ATTIVAMENTE cn altri progetti open source, soprattutto legati alle qt (vedi koffice) e la vechcia interfaccia di maemo (hildon) è stata integrata in gnome e verrà usata su ubuntu mobile edition! mi pare abbia fatto più nokia di tante altre grosse aziende che sfruttano l'open source e danno poco in cambio :sofico:
non credo che altre aziende (tipo Intel o RedHat o IBM) diano poco allo sviluppo del software libero (che distinguo da quello open source), basti pensare solo a cio' che inseriscono nei rami del kernel per capirlo.
Nokia ha solo interesse che le qt migliorino e si diffondano!! inoltre è un'azienda che punta sulla vendita di "hardware", si può permettere benissimo di nn voler guadagnare direttamente sul software ma di usarlo invece come risorsa per i propri prodotti/servizi
e' chiaro che a nokia interessa che le qt si diffondano: c'ha investito soldi. le aziende non fanno nulla per caso, soprattutto colossi come nokia. il mio unico dubbio rimane non tanto sul fatto che le librerie restino o meno libere (perche' di fatto lo sono), ma sul fatto che nessuna azienda sviluppa un prodotto finito totalmente libero.
ma pure le gtk sn LGPL, anzi finora la scusa della preferenza delle gtk sulle qt era proprio QUESTA!! Prima dipendeva dal fatto che le qt NON erano GPL e nn ci si poteva fidare di trolltech anche se aveva dato tutte le rassicurazioni del caso cn una licenza alternativa! Poi quando sn diventate GPL nn andava ancora bene perché diverse grosse aziende hanno BISOGNO almeno della LGPL. Ora che pure le qt sn LGPL nn va bene lo stesso :sofico:
se avessi letto il successivo post ti saresti accorto che l'ho anche detto. ed ho anche spiegato la motivazione per cui secondo me la licenza LGPL non e' adatta per il mondo del software libero.
l'unico vantaggio, imho, per le gtk e' che alle spalle ci stanno varie aziende e non una sola.
Inoltre adesso si ha addirittura paura di nokia!! Se google e anche opera hanno deciso di nn sfruttare più le qt per me è solo perché sn di nokia, nn riesco a trovare altre giustificazioni!!
mah, io avrei piu' paura di google che di nokia, ma questo e' un altro paio di maniche.
A me pare che nokia si stia comportando benissimo, ha preso le QT e la rese anche LGPL! Sta collaborando cn quelli di koffice (da portare su maemo) e ha personalmente migliorato il supporto ai documenti di office. Ha "donato" (che in fondo cn software open source nn è che si possano vietare certe cose :sofico: ) l'interfaccia Hildon di maemo alla community che è stata subito integrata in gnome e verrà usata su ubuntu mobile edition (nokia su maemo userà una nuova interfaccia basata ovviamente sulle qt). Che paura c'è scusate? e poi le QT sn open source, se nokia decide di fare "caxxate" si possono sempre riprendere e sviluppare in altra maniera! Magari quelli di KDE potrebbero curarne lo sviluppo creando una qualche "fondazione", in maniera analoga a quello che succede per gnome o per firefox! dov'è tutta sta paura? E allora di gnome e delle gtk che si stanno legando sempre più a mono e a c#? :sofico: ma come, la si menava tanto alle QT e a trolltech inizialmente e ora ci si butta a pesce su microsoft? :sofico:
il problema, imho, non e' che nokia faccia cazzate e chiuda le qt, ma che nokia investa in software closed scritto usando le qt. ovviamente avrei detto la stessa cosa se nokia avesse acquistato le gtk piuttosto che le qt.
ciao
zephyr83
09-02-2010, 17:11
io non sono un programmatore, ma anche prima programmare in qt era "facile e divertente" (passami il termine, virgolettato appositamente) e cio' che e' stato fatto per la portabilita' e' un grosso passo in avanti.
si lo erano anche prima ma ora di più :) inoltre lo sviluppo delle QT è continuato, ora siamo alle 4.6! che doveva fare di più? :) a me pare che in così poco tempo abbia fatto abbastanza :)
non credo che altre aziende (tipo Intel o RedHat o IBM) diano poco allo sviluppo del software libero (che distinguo da quello open source), basti pensare solo a cio' che inseriscono nei rami del kernel per capirlo.
E infatti nn mi riferivo a queste aziende :sofico: mi riferivo più che altro a google (anche se però i suoi soldi finanziano molte aziende e progetti :D ) o apple!
e' chiaro che a nokia interessa che le qt si diffondano: c'ha investito soldi. le aziende non fanno nulla per caso, soprattutto colossi come nokia. il mio unico dubbio rimane non tanto sul fatto che le librerie restino o meno libere (perche' di fatto lo sono), ma sul fatto che nessuna azienda sviluppa un prodotto finito totalmente libero.
ma guarda che sn cmq anche GPL! dipende da chi realizza il software! ed essere lgpl fa comodo soprattutto a grosse aziende come redhat e intel!
mah, io avrei piu' paura di google che di nokia, ma questo e' un altro paio di maniche.
idem :sofico:
il problema, imho, non e' che nokia faccia cazzate e chiuda le qt, ma che nokia investa in software closed scritto usando le qt. ovviamente avrei detto la stessa cosa se nokia avesse acquistato le gtk piuttosto che le qt.
ciao
bhe ma nokia potrebbe anche farlo (e in parte lo farà) ma che cambia se software proprietario viene realizzato cn le qt o altre librerie? sicuramente migliorerebbe il problema della compatibilità, in ogni caso il problema sarebbe lo stesso di qualsiasi altro software proprietario! anche opera usa le qt ma è proprietario, a me nn pare sia un problema.
Cioè, nn è una cosa che riguarda le librerie in se! è una scelta di chi sviluppa! Io cmq sn un po' "contro" all'imposizione del software open source e/o libero (che nn è la stessa cosa). Se all'inizio è stato fondamentali essere "integralisti" e battersi cn tutte le forze per imporre e affermare il software libero, ora direi che si può lasciare un pochino la catena e lasciar decidere al "mercato"/"utenti". è meglio scegliere un software open source perché ritenuto superiore (migliore o più conveniente per i propri scopi) all'alternativa closed senza voler costringere nessuno! idem per il metodo di sviluppo! per alcune cose è sicuramente più indicato, ma se un'azienda vive di vendita di programmi nn può passare al software libero. però usando le qt magari migliora la compatibilità (quel software può girare anche su linux) e visto che già conosce lo strumento può magari realizzare facilmente ANCHE qualche progetto progetto open source. ecco perché nn ci vedo niente di male nella licenza LGPL :)
si lo erano anche prima ma ora di più :) inoltre lo sviluppo delle QT è continuato, ora siamo alle 4.6! che doveva fare di più? :) a me pare che in così poco tempo abbia fatto abbastanza :)
non credo che altre aziende (tipo Intel o RedHat o IBM) diano poco allo sviluppo del software libero (che distinguo da quello open source), basti pensare solo a cio' che inseriscono nei rami del kernel per capirlo.
E infatti nn mi riferivo a queste aziende :sofico: mi riferivo più che altro a google (anche se però i suoi soldi finanziano molte aziende e progetti :D ) o apple!
e' chiaro che a nokia interessa che le qt si diffondano: c'ha investito soldi. le aziende non fanno nulla per caso, soprattutto colossi come nokia. il mio unico dubbio rimane non tanto sul fatto che le librerie restino o meno libere (perche' di fatto lo sono), ma sul fatto che nessuna azienda sviluppa un prodotto finito totalmente libero.
ma guarda che sn cmq anche GPL! dipende da chi realizza il software! ed essere lgpl fa comodo soprattutto a grosse aziende come redhat e intel!
mah, io avrei piu' paura di google che di nokia, ma questo e' un altro paio di maniche.
idem :sofico:
il problema, imho, non e' che nokia faccia cazzate e chiuda le qt, ma che nokia investa in software closed scritto usando le qt. ovviamente avrei detto la stessa cosa se nokia avesse acquistato le gtk piuttosto che le qt.
ciao
bhe ma nokia potrebbe anche farlo (e in parte lo farà) ma che cambia se software proprietario viene realizzato cn le qt o altre librerie? sicuramente migliorerebbe il problema della compatibilità, in ogni caso il problema sarebbe lo stesso di qualsiasi altro software proprietario! anche opera usa le qt ma è proprietario, a me nn pare sia un problema.
Cioè, nn è una cosa che riguarda le librerie in se! è una scelta di chi sviluppa! Io cmq sn un po' "contro" all'imposizione del software open source e/o libero (che nn è la stessa cosa). Se all'inizio è stato fondamentali essere "integralisti" e battersi cn tutte le forze per imporre e affermare il software libero, ora direi che si può lasciare un pochino la catena e lasciar decidere al "mercato"/"utenti". è meglio scegliere un software open source perché ritenuto superiore (migliore o più conveniente per i propri scopi) all'alternativa closed senza voler costringere nessuno! idem per il metodo di sviluppo! per alcune cose è sicuramente più indicato, ma se un'azienda vive di vendita di programmi nn può passare al software libero. però usando le qt magari migliora la compatibilità (quel software può girare anche su linux) e visto che già conosce lo strumento può magari realizzare facilmente ANCHE qualche progetto progetto open source. ecco perché nn ci vedo niente di male nella licenza LGPL :)
Barra
09-02-2010, 18:30
Hildon è un progetto open, sviluppato da nokia, abbandonato da nokia, praticamente morto (moblin non lo usa più dalla versione 2, ubuntu mobile non esiste + e non credo che ci siano altri progetti in giro a farne uso).
Non vorrei scrivere tra un paio di anni la stessa cosa riferendomi a QT. Ed è probabilmente per questo che grandi aziende come Google ed Opera abbandonano QT (cosa che tra le altre cose non sapevo!). Maemo è un sistema open ma che non gira da nessuna parte se non su 1 paio di dispositivi proprio per lo scarso interese che ha nokia verso il mondo open.
Sulla mancanza di concorrenza sbagli di grosso. D-bus è nato come alternativa a DCOP, sviluppato da KDE (anche se poi ne ha preso il posto). Molte delle novità introdotte dai 2 DE sono poi state replicate anche dall'altro. Hanno spesso sperimentato strade diverse per poi adottare la soluzione rivale quando questa si è rivelata migliore (vedi zeitgeist, tracker e nepomuk che faranno a breve il salto della barricata).
L'avere 2 alternative forti (occhio ho detto 2 forti, non 400 di merda come succede spesso su linux) è positivo, sempre e comunque.
Non credo molto nella portabilità dei vari applicativi. Firefox x windows e linux sono due applicativi ben diversi nel codice. Le ottimizzazioni necessarie per ottenere il meglio da un sistema rendono la portabilità un'utopia e lo ha dimostato anche KDE. Dovevano portare il DE su windows ma il lavoro è stato decisamente ostico e (e tutt'ora è incompleto) Certo molti programmi ci girano ma come ci girano?
Altro esempio Openoffice, è un colosso che si muove come una lumaca se paragonato alle alternative.
Google con il google summer of code finanzia sviluppatori e novelli programmatori. è IMHO uno dei maggiori contributi al free software.
http://socghop.appspot.com/gsoc/program/list_projects/google/gsoc2009?limit_0=100
Non sono un esperto ma stando a quello che ho potuto leggere tanti sviluppatori preferiscono GTK, un motivo ci sarà! QT poi significa quasi esclusivamente C++, GTK è C, C++, Javascript (gnome-shell è javascript), python, java, C#, Vala ecc. Penso anche qui che avere più alternative sia una cosa buona.
Detto questo: tutte queste sono chiaccihere abbastanza inutili visto che NESSUNO tra gli sviluppatori di gnome si è mai sognato di riscrivere gnome in QT perchè stanno benone così. Hanno introdotto così tanti cambiamenti in GTK che probabilmente con l'uscita di GTK3 tanti inizieranno a parlare di un porting verso GTK di KDE :sofico:
Non vorrei scrivere tra un paio di anni la stessa cosa riferendomi a QT. Ed è probabilmente per questo che grandi aziende come Google ed Opera abbandonano QT (cosa che tra le altre cose non sapevo!). Maemo è un sistema open ma che non gira da nessuna parte se non su 1 paio di dispositivi proprio per lo scarso interese che ha nokia verso il mondo open.
Sulla mancanza di concorrenza sbagli di grosso. D-bus è nato come alternativa a DCOP, sviluppato da KDE (anche se poi ne ha preso il posto). Molte delle novità introdotte dai 2 DE sono poi state replicate anche dall'altro. Hanno spesso sperimentato strade diverse per poi adottare la soluzione rivale quando questa si è rivelata migliore (vedi zeitgeist, tracker e nepomuk che faranno a breve il salto della barricata).
L'avere 2 alternative forti (occhio ho detto 2 forti, non 400 di merda come succede spesso su linux) è positivo, sempre e comunque.
Non credo molto nella portabilità dei vari applicativi. Firefox x windows e linux sono due applicativi ben diversi nel codice. Le ottimizzazioni necessarie per ottenere il meglio da un sistema rendono la portabilità un'utopia e lo ha dimostato anche KDE. Dovevano portare il DE su windows ma il lavoro è stato decisamente ostico e (e tutt'ora è incompleto) Certo molti programmi ci girano ma come ci girano?
Altro esempio Openoffice, è un colosso che si muove come una lumaca se paragonato alle alternative.
Google con il google summer of code finanzia sviluppatori e novelli programmatori. è IMHO uno dei maggiori contributi al free software.
http://socghop.appspot.com/gsoc/program/list_projects/google/gsoc2009?limit_0=100
Non sono un esperto ma stando a quello che ho potuto leggere tanti sviluppatori preferiscono GTK, un motivo ci sarà! QT poi significa quasi esclusivamente C++, GTK è C, C++, Javascript (gnome-shell è javascript), python, java, C#, Vala ecc. Penso anche qui che avere più alternative sia una cosa buona.
Detto questo: tutte queste sono chiaccihere abbastanza inutili visto che NESSUNO tra gli sviluppatori di gnome si è mai sognato di riscrivere gnome in QT perchè stanno benone così. Hanno introdotto così tanti cambiamenti in GTK che probabilmente con l'uscita di GTK3 tanti inizieranno a parlare di un porting verso GTK di KDE :sofico:
Dcromato
09-02-2010, 20:14
Mah...a dire il vero ho qualche dubbio sulla reale esistenza delle gtk3...fin'ora ho sentito parlare di gnome 3 sulle solite gtk2 e conoscendo l'ambiente che le circonda mi sa che poco cambierà...poi non so fino a che punto gli sviluppatori siano ancora felici di utilizzare ancora queste gtk2,da quel che vedo sono più propensi a un uso di mono...detto questo vedo che molti vedono il probabile uso delle qt come l'unificazione con kde cosa totalmente errata...
zephyr83
09-02-2010, 20:28
Hildon è un progetto open, sviluppato da nokia, abbandonato da nokia, praticamente morto (moblin non lo usa più dalla versione 2, ubuntu mobile non esiste + e non credo che ci siano altri progetti in giro a farne uso).
Non vorrei scrivere tra un paio di anni la stessa cosa riferendomi a QT. Ed è probabilmente per questo che grandi aziende come Google ed Opera abbandonano QT (cosa che tra le altre cose non sapevo!). Maemo è un sistema open ma che non gira da nessuna parte se non su 1 paio di dispositivi proprio per lo scarso interese che ha nokia verso il mondo open.
detta così pare quasi che nokia abbia abbandonato hildon e che qualcuno l'abbia raccattato, invece nn mi pare sia andata così
http://arstechnica.com/open-source/news/2007/06/nokia-pushes-hildon-upstream.ars
era il 2007 quando ancora nn esisteva alcun nokia N900 e maemo ora basato tutto sulle gtk!
Inoltre hildon è servito per la versione MID di ubuntu rilasciata a giugno del 2008! se poi il progetto è stato abbandonato è un altro discorso! E poi ubuntu remix deriva proprio da ubuntu mobile edition
Sulla mancanza di concorrenza sbagli di grosso. D-bus è nato come alternativa a DCOP, sviluppato da KDE (anche se poi ne ha preso il posto). Molte delle novità introdotte dai 2 DE sono poi state replicate anche dall'altro. Hanno spesso sperimentato strade diverse per poi adottare la soluzione rivale quando questa si è rivelata migliore (vedi zeitgeist, tracker e nepomuk che faranno a breve il salto della barricata).
L'avere 2 alternative forti (occhio ho detto 2 forti, non 400 di merda come succede spesso su linux) è positivo, sempre e comunque.
E dove ho sbagliato di grosso :) ho detto che la concorrenza c'è stata e anche tanta fra i due DE! ho detto che nn è ho vista così tanta fra gtk e qt che è ben diverso! anzi, per me usare le stesse librerie può solo far aumentare la concorrenza fra i due DE.
Non credo molto nella portabilità dei vari applicativi. Firefox x windows e linux sono due applicativi ben diversi nel codice. Le ottimizzazioni necessarie per ottenere il meglio da un sistema rendono la portabilità un'utopia e lo ha dimostato anche KDE. Dovevano portare il DE su windows ma il lavoro è stato decisamente ostico e (e tutt'ora è incompleto) Certo molti programmi ci girano ma come ci girano?
Altro esempio Openoffice, è un colosso che si muove come una lumaca se paragonato alle alternative.
[quote]
Per me pensi male!! nn mi pare che firefox per windows usi le stesse librerie di firefox per linux! Inoltre l'esempio di kde nn ci azzecca molto perché si parla di un INTERO DE! Perché nn prendi altri esempi di software realizzati in qt che girano senza problemi, nella stessa maniera sia su windows che su linux e addirittura osx?
Ecco alcuni esempi: scribus, inkscape, vlc, smplayer, google earth, avidemux, virtualbox!!
poi ho fatto prima l'esempio di Marble, portato senza problemi da kde4 a windows mobile :read:
http://labs.trolltech.com/blogs/2008/04/04/marble-running-on-windows-ce/
Che altro aggiungere? :)
Sarebbe ottimo anche per programmi professionali! Da questa pagina
http://qt.nokia.com/qt-in-use
ho scoperto che esistono software realizzati in QT come FEKO che funzionano addirittura su linux!! Altro che programmi realizzati in .net cn la speranza che girino anche su mono :sofico: meglio se realizzati direttamente cn le qt :sofico: Se magari si diffondessero maggiormente diverse aziende potrebbero interessarsi maggiormente e realizzare i propri programmi proprio cn queste librerie!!
[quote]
Google con il google summer of code finanzia sviluppatori e novelli programmatori. è IMHO uno dei maggiori contributi al free software.
http://socghop.appspot.com/gsoc/program/list_projects/google/gsoc2009?limit_0=100
Forse nn sn stato chiaro! certo che contribuisce, avevo detto anche io che ci mette molti soldi! intendo dire che nn lo fa "attivamente" mettendo mano al codice o rilasciando i propri programmi cn una licenza open source. Al kernel linux mi pare nn contribuisca minimamente! Android è libero solo per il 30% circa. Anche cn altri progetti è un po' "ambigua" (vedi chrome, chromium).
Non sono un esperto ma stando a quello che ho potuto leggere tanti sviluppatori preferiscono GTK, un motivo ci sarà! QT poi significa quasi esclusivamente C++, GTK è C, C++, Javascript (gnome-shell è javascript), python, java, C#, Vala ecc. Penso anche qui che avere più alternative sia una cosa buona.
[quote]
nn mi pare proprio sia così! se nn sbaglio per c++ si parla di gtkmm e nn mi pare che abbia avuto un gran successo! se il problema è solo il linguaggio quello si poteva risolvere anche cn le qt e ci avevano anche provato, qtjampi dove si programmava in java. inoltre le qt possono benissimo essere usati in altri linguaggi di programmazione via language binding! esistono interfacce per Java, Python, C, Perl e PHP.
[quote]
Detto questo: tutte queste sono chiacchiere abbastanza inutili visto che NESSUNO tra gli sviluppatori di gnome si è mai sognato di riscrivere gnome in QT perchè stanno benone così. Hanno introdotto così tanti cambiamenti in GTK che probabilmente con l'uscita di GTK3 tanti inizieranno a parlare di un porting verso GTK di KDE :sofico:
ovvio che sn chiacchiere inutili ma siamo su un forum! possiamo anche discutere e fantasticare un po' :) Cmq in questa discussioni ho letto tanti vantaggi delle QT ma nn ho letto nessuna contro indicazione nel loro utilizzo oppure in cosa le gtk sono meglio (o portano vantaggi).
Cmq nn dovrebbe essere obbligatorio un intervento degli sviluppatori gnome, potrebbero farlo anche persone "esterne"....ovviamente sarebbe tutto più difficile e complicato e penso che nessuno si imbarcherà mai in una impresa del genere visto che nn porterebbe ad alcun risultato davvero utile (nn credo che qualche distro userebbe questa versione di gnome :sofico: ).......però.......mai dire mai! magari qualcuno preoccupato da mono e c# potrebbe addirittura farlo :sofico: magari la FSF stessa :sofico: ovviamente le mie sn chiacchiere inutili :D
Ah, se a qualcuno può interessare questa è la roadmap relative alle qt
http://qt.nokia.com/developer/qt-roadmap
questo è un elenco di applicazioni open source realizzate in qt
http://www.qt-apps.org/
qui invece programmi proprietari realizzati in qt (ovviamente nn tutti quelli esistenti, mancano quelli delle software house "note")
http://qt-prop.org/
Non vorrei scrivere tra un paio di anni la stessa cosa riferendomi a QT. Ed è probabilmente per questo che grandi aziende come Google ed Opera abbandonano QT (cosa che tra le altre cose non sapevo!). Maemo è un sistema open ma che non gira da nessuna parte se non su 1 paio di dispositivi proprio per lo scarso interese che ha nokia verso il mondo open.
detta così pare quasi che nokia abbia abbandonato hildon e che qualcuno l'abbia raccattato, invece nn mi pare sia andata così
http://arstechnica.com/open-source/news/2007/06/nokia-pushes-hildon-upstream.ars
era il 2007 quando ancora nn esisteva alcun nokia N900 e maemo ora basato tutto sulle gtk!
Inoltre hildon è servito per la versione MID di ubuntu rilasciata a giugno del 2008! se poi il progetto è stato abbandonato è un altro discorso! E poi ubuntu remix deriva proprio da ubuntu mobile edition
Sulla mancanza di concorrenza sbagli di grosso. D-bus è nato come alternativa a DCOP, sviluppato da KDE (anche se poi ne ha preso il posto). Molte delle novità introdotte dai 2 DE sono poi state replicate anche dall'altro. Hanno spesso sperimentato strade diverse per poi adottare la soluzione rivale quando questa si è rivelata migliore (vedi zeitgeist, tracker e nepomuk che faranno a breve il salto della barricata).
L'avere 2 alternative forti (occhio ho detto 2 forti, non 400 di merda come succede spesso su linux) è positivo, sempre e comunque.
E dove ho sbagliato di grosso :) ho detto che la concorrenza c'è stata e anche tanta fra i due DE! ho detto che nn è ho vista così tanta fra gtk e qt che è ben diverso! anzi, per me usare le stesse librerie può solo far aumentare la concorrenza fra i due DE.
Non credo molto nella portabilità dei vari applicativi. Firefox x windows e linux sono due applicativi ben diversi nel codice. Le ottimizzazioni necessarie per ottenere il meglio da un sistema rendono la portabilità un'utopia e lo ha dimostato anche KDE. Dovevano portare il DE su windows ma il lavoro è stato decisamente ostico e (e tutt'ora è incompleto) Certo molti programmi ci girano ma come ci girano?
Altro esempio Openoffice, è un colosso che si muove come una lumaca se paragonato alle alternative.
[quote]
Per me pensi male!! nn mi pare che firefox per windows usi le stesse librerie di firefox per linux! Inoltre l'esempio di kde nn ci azzecca molto perché si parla di un INTERO DE! Perché nn prendi altri esempi di software realizzati in qt che girano senza problemi, nella stessa maniera sia su windows che su linux e addirittura osx?
Ecco alcuni esempi: scribus, inkscape, vlc, smplayer, google earth, avidemux, virtualbox!!
poi ho fatto prima l'esempio di Marble, portato senza problemi da kde4 a windows mobile :read:
http://labs.trolltech.com/blogs/2008/04/04/marble-running-on-windows-ce/
Che altro aggiungere? :)
Sarebbe ottimo anche per programmi professionali! Da questa pagina
http://qt.nokia.com/qt-in-use
ho scoperto che esistono software realizzati in QT come FEKO che funzionano addirittura su linux!! Altro che programmi realizzati in .net cn la speranza che girino anche su mono :sofico: meglio se realizzati direttamente cn le qt :sofico: Se magari si diffondessero maggiormente diverse aziende potrebbero interessarsi maggiormente e realizzare i propri programmi proprio cn queste librerie!!
[quote]
Google con il google summer of code finanzia sviluppatori e novelli programmatori. è IMHO uno dei maggiori contributi al free software.
http://socghop.appspot.com/gsoc/program/list_projects/google/gsoc2009?limit_0=100
Forse nn sn stato chiaro! certo che contribuisce, avevo detto anche io che ci mette molti soldi! intendo dire che nn lo fa "attivamente" mettendo mano al codice o rilasciando i propri programmi cn una licenza open source. Al kernel linux mi pare nn contribuisca minimamente! Android è libero solo per il 30% circa. Anche cn altri progetti è un po' "ambigua" (vedi chrome, chromium).
Non sono un esperto ma stando a quello che ho potuto leggere tanti sviluppatori preferiscono GTK, un motivo ci sarà! QT poi significa quasi esclusivamente C++, GTK è C, C++, Javascript (gnome-shell è javascript), python, java, C#, Vala ecc. Penso anche qui che avere più alternative sia una cosa buona.
[quote]
nn mi pare proprio sia così! se nn sbaglio per c++ si parla di gtkmm e nn mi pare che abbia avuto un gran successo! se il problema è solo il linguaggio quello si poteva risolvere anche cn le qt e ci avevano anche provato, qtjampi dove si programmava in java. inoltre le qt possono benissimo essere usati in altri linguaggi di programmazione via language binding! esistono interfacce per Java, Python, C, Perl e PHP.
[quote]
Detto questo: tutte queste sono chiacchiere abbastanza inutili visto che NESSUNO tra gli sviluppatori di gnome si è mai sognato di riscrivere gnome in QT perchè stanno benone così. Hanno introdotto così tanti cambiamenti in GTK che probabilmente con l'uscita di GTK3 tanti inizieranno a parlare di un porting verso GTK di KDE :sofico:
ovvio che sn chiacchiere inutili ma siamo su un forum! possiamo anche discutere e fantasticare un po' :) Cmq in questa discussioni ho letto tanti vantaggi delle QT ma nn ho letto nessuna contro indicazione nel loro utilizzo oppure in cosa le gtk sono meglio (o portano vantaggi).
Cmq nn dovrebbe essere obbligatorio un intervento degli sviluppatori gnome, potrebbero farlo anche persone "esterne"....ovviamente sarebbe tutto più difficile e complicato e penso che nessuno si imbarcherà mai in una impresa del genere visto che nn porterebbe ad alcun risultato davvero utile (nn credo che qualche distro userebbe questa versione di gnome :sofico: ).......però.......mai dire mai! magari qualcuno preoccupato da mono e c# potrebbe addirittura farlo :sofico: magari la FSF stessa :sofico: ovviamente le mie sn chiacchiere inutili :D
Ah, se a qualcuno può interessare questa è la roadmap relative alle qt
http://qt.nokia.com/developer/qt-roadmap
questo è un elenco di applicazioni open source realizzate in qt
http://www.qt-apps.org/
qui invece programmi proprietari realizzati in qt (ovviamente nn tutti quelli esistenti, mancano quelli delle software house "note")
http://qt-prop.org/
AnonimoVeneziano
09-02-2010, 20:46
Fare il porting di gnome alle QT4 è un progetto assurdo, bisognerebbe riscrivere tutte le applicazione oltre a tutto il DE.
Tanto fare un "rm -rf /gnome" in tal caso se si decidesse di seguire questa strada.
Guardate cos'è successo a KDE nel tentare di fare un complete rewrite. Ora si è ripreso , ma ne è passato di tempo da quando era stato annunciato alla 4.2 (release in cui si è ripreso).
Se si vuole riscrivere tutto Gnome allora tanto vale rimanere con solo KDE.
Ciao
Tanto fare un "rm -rf /gnome" in tal caso se si decidesse di seguire questa strada.
Guardate cos'è successo a KDE nel tentare di fare un complete rewrite. Ora si è ripreso , ma ne è passato di tempo da quando era stato annunciato alla 4.2 (release in cui si è ripreso).
Se si vuole riscrivere tutto Gnome allora tanto vale rimanere con solo KDE.
Ciao
zephyr83
09-02-2010, 20:55
Fare il porting di gnome alle QT4 è un progetto assurdo, bisognerebbe riscrivere tutte le applicazione oltre a tutto il DE.
Tanto fare un "rm -rf /gnome" in tal caso se si decidesse di seguire questa strada.
Guardate cos'è successo a KDE nel tentare di fare un complete rewrite. Ora si è ripreso , ma ne è passato di tempo da quando era stato annunciato alla 4.2 (release in cui si è ripreso).
Se si vuole riscrivere tutto Gnome allora tanto vale rimanere con solo KDE.
Ciao
basterebbe iniziare piano piano! in fondo stanno già andando lentamente nello sviluppo no? Anziché migrare piano piano alle gtk# e a mono si migrava alle qt! prima si migliorava l'integrazione e tutte le parti nuove si realizzavano in qt senza dare un taglio netto cn il passato (proprio come già stanno facendo adesso per gnome 3). Ovvio sarebbe stato un lavoro lungo ma in futuro si sarebbero raccolti i frutti IMHO :)
Tanto fare un "rm -rf /gnome" in tal caso se si decidesse di seguire questa strada.
Guardate cos'è successo a KDE nel tentare di fare un complete rewrite. Ora si è ripreso , ma ne è passato di tempo da quando era stato annunciato alla 4.2 (release in cui si è ripreso).
Se si vuole riscrivere tutto Gnome allora tanto vale rimanere con solo KDE.
Ciao
basterebbe iniziare piano piano! in fondo stanno già andando lentamente nello sviluppo no? Anziché migrare piano piano alle gtk# e a mono si migrava alle qt! prima si migliorava l'integrazione e tutte le parti nuove si realizzavano in qt senza dare un taglio netto cn il passato (proprio come già stanno facendo adesso per gnome 3). Ovvio sarebbe stato un lavoro lungo ma in futuro si sarebbero raccolti i frutti IMHO :)
Barra
09-02-2010, 21:16
Fai un pò di confusione...
GTK e mono non sono alternative. Mono per le applicicazioni su linux usa gtk#, una serie di bindings a GTK.
GTK3 esistono e godono di ottima salute.
gnome-shell utilizza un nuovo gestore di temi basato su CSS. Clutter diventerà parte di GTK (dalla versione 1.1 di clutter quindi non con GTK3.0), mossa estremamente intelligente (non si reinventa la ruota, si ricicla la migliore in circolazione). oltre a questo puoi vedere qui http://live.gnome.org/ChristianHergert/Gtk3Wishlist una serie di nuovi strumenti introdotti.
Tenete comunque presente che è da gnome 2.24 che si è iniziato a lavorare per introdurre gtk3. Sono state introdotte nuove librerie, affiancandole però alle vecchie (gnome-vfs e gvfs ad esempio) e deprecando queste ultime pian piano, dando quindi il tempo ai programmatori di mettere mano un pò per volta al codice.
Inoltre in gnome foundation ci tengono a precisare che GTK3.0 non è un punto di arrivo ma un punto di partenza, una base solida, pulita e stabile sulla quale costruire un futuro.
GTK e mono non sono alternative. Mono per le applicicazioni su linux usa gtk#, una serie di bindings a GTK.
GTK3 esistono e godono di ottima salute.
gnome-shell utilizza un nuovo gestore di temi basato su CSS. Clutter diventerà parte di GTK (dalla versione 1.1 di clutter quindi non con GTK3.0), mossa estremamente intelligente (non si reinventa la ruota, si ricicla la migliore in circolazione). oltre a questo puoi vedere qui http://live.gnome.org/ChristianHergert/Gtk3Wishlist una serie di nuovi strumenti introdotti.
Tenete comunque presente che è da gnome 2.24 che si è iniziato a lavorare per introdurre gtk3. Sono state introdotte nuove librerie, affiancandole però alle vecchie (gnome-vfs e gvfs ad esempio) e deprecando queste ultime pian piano, dando quindi il tempo ai programmatori di mettere mano un pò per volta al codice.
Inoltre in gnome foundation ci tengono a precisare che GTK3.0 non è un punto di arrivo ma un punto di partenza, una base solida, pulita e stabile sulla quale costruire un futuro.
AnonimoVeneziano
09-02-2010, 21:28
Ma riscrivere per cosa? Per buttare via tutto il codice che è stato scritto in tutti questi anni e la retrocompatibilità con tutto il software che già esiste per avere un qualcosa con le stesse funzionalità, scritto solo con un toolkit diverso?
Si è già visto con KDE cosa una rivoluzione può portare, ossia blocco totale dello sviluppo per tutto il periodo in cui si fa la riscrittura. E' un illusione pensare di poter portare avanti tutto insieme.
Vi chiedete perchè i programmatori di KDE hanno deciso di buttare fuori KDE 4.0 incompiuto? Il motivo è che non avevano le risorse per sviluppare il 4.0 come si doveva mentre dovevano continuare lo sviluppo della 3.x . Dovevano fare una scelta: portiamo avanti seriamente la versione 4 o continuiamo con la 3? E hanno deciso di passare alla 4.
Inoltre facendo questo passaggio i programmatori di KDE hanno perso tutto quello che avevano fatto fino alla versione 3 , dal codice del DE stesso alle applicazioni che su questo giravano. Si è dovuto riscrivere tutto.
Per questa ragione Gnome 3 non sarà una complete rewrite come KDE4 , ma sarà un insieme di cambiamenti notevoli si, ma solo incrementali e non rivoluzionari rispetto alla versione 2 .
E' la stessa ragione per cui Windows è simile e usa le stesse librerie di base dal 1986. Le rivoluzioni non hanno mai fatto bene a nessuno e loro lo avevano già capito all'epoca.
Ciao
Si è già visto con KDE cosa una rivoluzione può portare, ossia blocco totale dello sviluppo per tutto il periodo in cui si fa la riscrittura. E' un illusione pensare di poter portare avanti tutto insieme.
Vi chiedete perchè i programmatori di KDE hanno deciso di buttare fuori KDE 4.0 incompiuto? Il motivo è che non avevano le risorse per sviluppare il 4.0 come si doveva mentre dovevano continuare lo sviluppo della 3.x . Dovevano fare una scelta: portiamo avanti seriamente la versione 4 o continuiamo con la 3? E hanno deciso di passare alla 4.
Inoltre facendo questo passaggio i programmatori di KDE hanno perso tutto quello che avevano fatto fino alla versione 3 , dal codice del DE stesso alle applicazioni che su questo giravano. Si è dovuto riscrivere tutto.
Per questa ragione Gnome 3 non sarà una complete rewrite come KDE4 , ma sarà un insieme di cambiamenti notevoli si, ma solo incrementali e non rivoluzionari rispetto alla versione 2 .
E' la stessa ragione per cui Windows è simile e usa le stesse librerie di base dal 1986. Le rivoluzioni non hanno mai fatto bene a nessuno e loro lo avevano già capito all'epoca.
Ciao
zephyr83
09-02-2010, 21:40
Fai un pò di confusione...
GTK e mono non sono alternative. Mono per le applicicazioni su linux usa gtk#, una serie di bindings a GTK.
io parlavo di mono e gtk# relativo a gnome! sempre più programmi per gnome vengono realizzati in mono e le gtk# hanno sempre più consensi!! Se gli sviluppatori di gnome un giorno decidessero di integrare ad esempio gnome-do in gnome-base? Poteva già esser accaduto!! nn è così remota come possibilità!! a sto punto io preferirei vedere uno gnome che migra, anche se a fatica, alle qt.
Inoltre cn le gtk3 si perderà ugualmente la compatibilità cn il vecchio software quindi dove sta il problema?
GTK e mono non sono alternative. Mono per le applicicazioni su linux usa gtk#, una serie di bindings a GTK.
io parlavo di mono e gtk# relativo a gnome! sempre più programmi per gnome vengono realizzati in mono e le gtk# hanno sempre più consensi!! Se gli sviluppatori di gnome un giorno decidessero di integrare ad esempio gnome-do in gnome-base? Poteva già esser accaduto!! nn è così remota come possibilità!! a sto punto io preferirei vedere uno gnome che migra, anche se a fatica, alle qt.
Inoltre cn le gtk3 si perderà ugualmente la compatibilità cn il vecchio software quindi dove sta il problema?
zephyr83
09-02-2010, 21:42
Ma riscrivere per cosa? Per buttare via tutto il codice che è stato scritto in tutti questi anni e la retrocompatibilità con tutto il software che già esiste per avere un qualcosa con le stesse funzionalità, scritto solo con un toolkit diverso?
Si è già visto con KDE cosa una rivoluzione può portare, ossia blocco totale dello sviluppo per tutto il periodo in cui si fa la riscrittura. E' un illusione pensare di poter portare avanti tutto insieme.
Vi chiedete perchè i programmatori di KDE hanno deciso di buttare fuori KDE 4.0 incompiuto? Il motivo è che non avevano le risorse per sviluppare il 4.0 come si doveva mentre dovevano continuare lo sviluppo della 3.x . Dovevano fare una scelta: portiamo avanti seriamente la versione 4 o continuiamo con la 3? E hanno deciso di passare alla 4.
Inoltre facendo questo passaggio i programmatori di KDE hanno perso tutto quello che avevano fatto fino alla versione 3 , dal codice del DE stesso alle applicazioni che su questo giravano. Si è dovuto riscrivere tutto.
Per questa ragione Gnome 3 non sarà una complete rewrite come KDE4 , ma sarà un insieme di cambiamenti notevoli si, ma solo incrementali e non rivoluzionari rispetto alla versione 2 .
E' la stessa ragione per cui Windows è simile e usa le stesse librerie di base dal 1986. Le rivoluzioni non hanno mai fatto bene a nessuno e loro lo avevano già capito all'epoca.
Ciao
ma la compatibilità nn si perderà lo stesso? :) l'errore di quelli di kde è stato voler dare un taglio troppo netto e cercare di fare tutto in fretta!! potevano benissimo prendersela cn più calma e fare passaggi più graduali e aspettare che ANCHE il software passasse alle qt4!
Si è già visto con KDE cosa una rivoluzione può portare, ossia blocco totale dello sviluppo per tutto il periodo in cui si fa la riscrittura. E' un illusione pensare di poter portare avanti tutto insieme.
Vi chiedete perchè i programmatori di KDE hanno deciso di buttare fuori KDE 4.0 incompiuto? Il motivo è che non avevano le risorse per sviluppare il 4.0 come si doveva mentre dovevano continuare lo sviluppo della 3.x . Dovevano fare una scelta: portiamo avanti seriamente la versione 4 o continuiamo con la 3? E hanno deciso di passare alla 4.
Inoltre facendo questo passaggio i programmatori di KDE hanno perso tutto quello che avevano fatto fino alla versione 3 , dal codice del DE stesso alle applicazioni che su questo giravano. Si è dovuto riscrivere tutto.
Per questa ragione Gnome 3 non sarà una complete rewrite come KDE4 , ma sarà un insieme di cambiamenti notevoli si, ma solo incrementali e non rivoluzionari rispetto alla versione 2 .
E' la stessa ragione per cui Windows è simile e usa le stesse librerie di base dal 1986. Le rivoluzioni non hanno mai fatto bene a nessuno e loro lo avevano già capito all'epoca.
Ciao
ma la compatibilità nn si perderà lo stesso? :) l'errore di quelli di kde è stato voler dare un taglio troppo netto e cercare di fare tutto in fretta!! potevano benissimo prendersela cn più calma e fare passaggi più graduali e aspettare che ANCHE il software passasse alle qt4!
AnonimoVeneziano
09-02-2010, 22:38
Tutto infretta? Lo sviluppo di KDE4 è partito nel 2005 con l'uscita di QT4. KDE 4 è uscito 3 anni dopo, non mi sembra uno sviluppo fatto "di fretta" Tant'è che in quanti si sono lamentati che ci hanno messo troppo ... etc.
La verità è che se nel fare la rivoluzione ci sono voluti 3 anni (in realtà 4 anni perchè KDE4.0 non era completo) , immaginiamoci incrementalmente quanto tempo ci sarebbe voluto ... sarebbero già uscite le QT6
E' troppo problematico per guadagnarci troppo poco. Richiede di cambiare tutta l'infrastruttura sottostante (innanzitutto bisogna riscrivere tutto perchè le QT sono C++ e Gnome è scritto in C) .
Ciao
La verità è che se nel fare la rivoluzione ci sono voluti 3 anni (in realtà 4 anni perchè KDE4.0 non era completo) , immaginiamoci incrementalmente quanto tempo ci sarebbe voluto ... sarebbero già uscite le QT6
E' troppo problematico per guadagnarci troppo poco. Richiede di cambiare tutta l'infrastruttura sottostante (innanzitutto bisogna riscrivere tutto perchè le QT sono C++ e Gnome è scritto in C) .
Ciao
zephyr83
09-02-2010, 22:47
Tutto infretta? Lo sviluppo di KDE4 è partito nel 2005 con l'uscita di QT4. KDE 4 è uscito 3 anni dopo, non mi sembra uno sviluppo fatto "di fretta" Tant'è che in quanti si sono lamentati che ci hanno messo troppo ... etc.
La verità è che se nel fare la rivoluzione ci sono voluti 3 anni (in realtà 4 anni perchè KDE4.0 non era completo) , immaginiamoci incrementalmente quanto tempo ci sarebbe voluto ... sarebbero già uscite le QT6
E' troppo problematico per guadagnarci troppo poco. Richiede di cambiare tutta l'infrastruttura sottostante (innanzitutto bisogna riscrivere tutto perchè le QT sono C++ e Gnome è scritto in C) .
Ciao
hanno dato un taglio NETTO senza neanche aspettare che altre applicazioni passassero alle qt4! si poteva anche fare un passaggio più graduale cambiando di volta in volta in volta qualche componente fondamentale e facendo convivere più a lungo qt3 e qt4! certo, ci sarebbe voluto più tempo ma ci sarebbero stati meno problemi!
in fondo nn è quello che stanno facendo quelli di gnome? E anche cn le gtk 3 si perderà la compatibilità cn i programmi scritti cn le gtk2.
Oppure potrebbero continuare cn gnome come è adesso e pensare ANCHE allo sviluppo, parallelo, di gnome in QT....un po' come ha fatto apple che ha preparato il passaggio a osx su piattaforma x86 in "segreto" per anni! Certo, anche qui ci vorrebbe più tempo e più risorse ma per me alla fine il gioco varrebbe sempre la candela! Avessero iniziato al tempo delle qt4 ora sarebbero sicuramente a buon punto :sofico:
EDIT cmq il mio "troppo infretta" si riferiva al fato che la prima versione definita stabile, cioè kde 4.0 è uscita solo dopo un ano e mezzo di sviluppo!! Nn dovevano semplicemente definire stabile quella questione (o nn chiamarla kde 4.0)
La verità è che se nel fare la rivoluzione ci sono voluti 3 anni (in realtà 4 anni perchè KDE4.0 non era completo) , immaginiamoci incrementalmente quanto tempo ci sarebbe voluto ... sarebbero già uscite le QT6
E' troppo problematico per guadagnarci troppo poco. Richiede di cambiare tutta l'infrastruttura sottostante (innanzitutto bisogna riscrivere tutto perchè le QT sono C++ e Gnome è scritto in C) .
Ciao
hanno dato un taglio NETTO senza neanche aspettare che altre applicazioni passassero alle qt4! si poteva anche fare un passaggio più graduale cambiando di volta in volta in volta qualche componente fondamentale e facendo convivere più a lungo qt3 e qt4! certo, ci sarebbe voluto più tempo ma ci sarebbero stati meno problemi!
in fondo nn è quello che stanno facendo quelli di gnome? E anche cn le gtk 3 si perderà la compatibilità cn i programmi scritti cn le gtk2.
Oppure potrebbero continuare cn gnome come è adesso e pensare ANCHE allo sviluppo, parallelo, di gnome in QT....un po' come ha fatto apple che ha preparato il passaggio a osx su piattaforma x86 in "segreto" per anni! Certo, anche qui ci vorrebbe più tempo e più risorse ma per me alla fine il gioco varrebbe sempre la candela! Avessero iniziato al tempo delle qt4 ora sarebbero sicuramente a buon punto :sofico:
EDIT cmq il mio "troppo infretta" si riferiva al fato che la prima versione definita stabile, cioè kde 4.0 è uscita solo dopo un ano e mezzo di sviluppo!! Nn dovevano semplicemente definire stabile quella questione (o nn chiamarla kde 4.0)
Torav
09-02-2010, 22:56
Trovo che sarebbe una follia portare gnome su Qt4, troppo lavoro. La cosa da fare semmai sarebbe scrivere le gtk in un linguaggio a oggetti, tipo c++, nativamente.
Non sono un esperto ma stando a quello che ho potuto leggere tanti sviluppatori preferiscono GTK, un motivo ci sarà! QT poi significa quasi esclusivamente C++, GTK è C, C++, Javascript (gnome-shell è javascript), python, java, C#, Vala ecc. Penso anche qui che avere più alternative sia una cosa buona.
Non per dire, ma le Qt4 hanno bindings per una quantità impressionante di linguaggi (io ad esempio uso pyqt), basta vedere qui (http://en.wikipedia.org/wiki/Qt_%28framework%29#Bindings)
Non sono un esperto ma stando a quello che ho potuto leggere tanti sviluppatori preferiscono GTK, un motivo ci sarà! QT poi significa quasi esclusivamente C++, GTK è C, C++, Javascript (gnome-shell è javascript), python, java, C#, Vala ecc. Penso anche qui che avere più alternative sia una cosa buona.
Non per dire, ma le Qt4 hanno bindings per una quantità impressionante di linguaggi (io ad esempio uso pyqt), basta vedere qui (http://en.wikipedia.org/wiki/Qt_%28framework%29#Bindings)
Barra
10-02-2010, 08:41
@Torav
ci sarà un motivo se su QT QUASI TUTTI gli sviluppatori usato C++ mentre su con GTK python è così diffuso. Il fatto che chi sviluppa in python di solito sceglie gnome penso sia innegabile.
@Tutti
Perchè vi ostinate a dire che GTK3 romperanno la compatibilità con GTK2? perchè non sono più supportate libbonobo e simili? Librerie che hanno un'alternativa tecnicamente superiore da almeno 2 anni?
Aggiornare a GTK3 qualunque applicativo significa RISCRIVERNE UNA MINIMA PARTE. Avete presente il lavoro fatto con KDE4? stiamo parlando di 2 operazioni ben diverse.
Intregrare le funzionalità di clutter in un'applicativo è possibile farlo con 4/5 righe di codice (date un'occhio al blog di Mirko Muller), per le altre funzionalità nessuno obbliga ad usarla da subito, quando gli sviluppatori avranno tempo (e se lo riterranno opportuno) me faranno uso, altrimenti tanti saluti.
Mutter (fork di metacity che utilizza Clutter per effetti, trasparenze ecc) è stato portato avanti da UNA SOLA PERSONA per un paio di anni (mantenendo contemporaneamente Metacity che sarà cmq presente in gnome3) e ora è pronto per gnome3. Riscriverlo in QT quanto tempo avrebbe richiesto?
Affiancare il ramo GTK a uno in sviluppo QT avrebbe portato al disperdere forze (gli sviluppatori non sono poi tantissimi e cmq lavorano aggratis nel tempo libero, hanno mogli, fidanzate, forse figli da mantenere e con cui magari passare un pò di tempo libero).
Cosa avete contro GTK#, mono ecc ormai non lo capisco e sinceramente rinuncio a capirlo. Le 'menate politiche' non mi interessano. Se MS è il diavolo allora togliete il supporto a fat e ntfs, togliete samba, togliete amsn ed emesene dai vostri pc prima di pensare a una libreria contro cui MS ha messo nero su bianco che non si rivarra legalemente.
P.s. zephyr83 non mi sembra di avere letto in questo thread grandi i vantaggi tecnici di QT. E non mi sembra di averli mai nemmeno visti all'opera visto che alla fine KDE4 è una versione graficamente più carina di KDE3 ma nulla +. A livello di usabilità e funzioni cosa è stato introdotto con QT? (questo dovrebbe interessare a noi utenti finali. Una differenza di prestazioni nell'ordine dell 5% è poca roba).
ci sarà un motivo se su QT QUASI TUTTI gli sviluppatori usato C++ mentre su con GTK python è così diffuso. Il fatto che chi sviluppa in python di solito sceglie gnome penso sia innegabile.
@Tutti
Perchè vi ostinate a dire che GTK3 romperanno la compatibilità con GTK2? perchè non sono più supportate libbonobo e simili? Librerie che hanno un'alternativa tecnicamente superiore da almeno 2 anni?
Aggiornare a GTK3 qualunque applicativo significa RISCRIVERNE UNA MINIMA PARTE. Avete presente il lavoro fatto con KDE4? stiamo parlando di 2 operazioni ben diverse.
Intregrare le funzionalità di clutter in un'applicativo è possibile farlo con 4/5 righe di codice (date un'occhio al blog di Mirko Muller), per le altre funzionalità nessuno obbliga ad usarla da subito, quando gli sviluppatori avranno tempo (e se lo riterranno opportuno) me faranno uso, altrimenti tanti saluti.
Mutter (fork di metacity che utilizza Clutter per effetti, trasparenze ecc) è stato portato avanti da UNA SOLA PERSONA per un paio di anni (mantenendo contemporaneamente Metacity che sarà cmq presente in gnome3) e ora è pronto per gnome3. Riscriverlo in QT quanto tempo avrebbe richiesto?
Affiancare il ramo GTK a uno in sviluppo QT avrebbe portato al disperdere forze (gli sviluppatori non sono poi tantissimi e cmq lavorano aggratis nel tempo libero, hanno mogli, fidanzate, forse figli da mantenere e con cui magari passare un pò di tempo libero).
Cosa avete contro GTK#, mono ecc ormai non lo capisco e sinceramente rinuncio a capirlo. Le 'menate politiche' non mi interessano. Se MS è il diavolo allora togliete il supporto a fat e ntfs, togliete samba, togliete amsn ed emesene dai vostri pc prima di pensare a una libreria contro cui MS ha messo nero su bianco che non si rivarra legalemente.
P.s. zephyr83 non mi sembra di avere letto in questo thread grandi i vantaggi tecnici di QT. E non mi sembra di averli mai nemmeno visti all'opera visto che alla fine KDE4 è una versione graficamente più carina di KDE3 ma nulla +. A livello di usabilità e funzioni cosa è stato introdotto con QT? (questo dovrebbe interessare a noi utenti finali. Una differenza di prestazioni nell'ordine dell 5% è poca roba).
cionci
10-02-2010, 09:50
@Torav
ci sarà un motivo se su QT QUASI TUTTI gli sviluppatori usato C++ mentre su con GTK python è così diffuso. Il fatto che chi sviluppa in python di solito sceglie gnome penso sia innegabile.
Python ha un ottimo wrap anche per le Qt ;)
ci sarà un motivo se su QT QUASI TUTTI gli sviluppatori usato C++ mentre su con GTK python è così diffuso. Il fatto che chi sviluppa in python di solito sceglie gnome penso sia innegabile.
Python ha un ottimo wrap anche per le Qt ;)
zephyr83
10-02-2010, 13:59
@Torav
ci sarà un motivo se su QT QUASI TUTTI gli sviluppatori usato C++ mentre su con GTK python è così diffuso. Il fatto che chi sviluppa in python di solito sceglie gnome penso sia innegabile.
Forse il problema è l'opposto.....chi usa le gtk sente maggiormente la necessità di usare qualcosa che nn sia il C :) cmq le qt si possono usare anche cn python!
Perchè vi ostinate a dire che GTK3 romperanno la compatibilità con GTK2? perchè non sono più supportate libbonobo e simili? Librerie che hanno un'alternativa tecnicamente superiore da almeno 2 anni?
Aggiornare a GTK3 qualunque applicativo significa RISCRIVERNE UNA MINIMA PARTE. Avete presente il lavoro fatto con KDE4? stiamo parlando di 2 operazioni ben diverse.
Intregrare le funzionalità di clutter in un'applicativo è possibile farlo con 4/5 righe di codice (date un'occhio al blog di Mirko Muller), per le altre funzionalità nessuno obbliga ad usarla da subito, quando gli sviluppatori avranno tempo (e se lo riterranno opportuno) me faranno uso, altrimenti tanti saluti.
perché è così e l'hai scritto pure tu :)
Molta della lentezza è data dall'abbondanza di "vecchio codice" mantenuto per questioni di compatibilità. Gnome3 romperà questa compatibilità e quindi tutto dovrebbe diventare più veloce.
se il passaggio sarà più indolore rispetto a KDE4 è perché quelli di gnome hanno deciso di fare un passaggio graduale e nn netto!
Mutter (fork di metacity che utilizza Clutter per effetti, trasparenze ecc) è stato portato avanti da UNA SOLA PERSONA per un paio di anni (mantenendo contemporaneamente Metacity che sarà cmq presente in gnome3) e ora è pronto per gnome3. Riscriverlo in QT quanto tempo avrebbe richiesto?
ci sarebbe voluto molto così come ci stanno mettendo a passare alle gtk3 e a gnome 3........ma a quest'ora sarebbero a buon punto e in futuro i vantaggi si sarebbero visti :)
Affiancare il ramo GTK a uno in sviluppo QT avrebbe portato al disperdere forze (gli sviluppatori non sono poi tantissimi e cmq lavorano aggratis nel tempo libero, hanno mogli, fidanzate, forse figli da mantenere e con cui magari passare un pò di tempo libero).
Si è vero, ma, sempre secondo il MIO parere, alla fine avrebbe giovato a molti!
Cosa avete contro GTK#, mono ecc ormai non lo capisco e sinceramente rinuncio a capirlo. Le 'menate politiche' non mi interessano. Se MS è il diavolo allora togliete il supporto a fat e ntfs, togliete samba, togliete amsn ed emesene dai vostri pc prima di pensare a una libreria contro cui MS ha messo nero su bianco che non si rivarra legalemente.
ma che diavolo! la questione è ben diversa! un conto è usare un "programmino" come amsn! un conto è basare la maggior parte dei programmi e addirittura un intero DE (il rischio c'è) su un'implementazione di .net e C# che hanno alcune parti coperte da BREVETTI. nn si parla SOLO di implementare le parti "aperte" e libere da brevetti ma di TUTTO (è questo che fa mono). E a quale scopo? tanto la compatibilità cn .net nn si avrà mai e si dovrà stare sempre dietro allo sviluppo di microsoft! per me è una cosa assurda visto che c'era già una valida alternativa (QT).
Si corre il rischio che si ripeta una questione simile a quella del file system fat!!
E poi, anche trolltech a suo tempo aveva messo nero su bianco tutte le garanzie del caso per le QT cn una licenza "adeguata".......allora nn bastò mentre oggi basta?
P.s. zephyr83 non mi sembra di avere letto in questo thread grandi i vantaggi tecnici di QT. E non mi sembra di averli mai nemmeno visti all'opera visto che alla fine KDE4 è una versione graficamente più carina di KDE3 ma nulla +. A livello di usabilità e funzioni cosa è stato introdotto con QT? (questo dovrebbe interessare a noi utenti finali. Una differenza di prestazioni nell'ordine dell 5% è poca roba).
L'usabilità dipende principalmente dal DE e da chi lo sviluppa! i vantaggi nell'uso delle QT sn principalmente quelli di interoperabilità cn altre piattaforme! anche come sviluppo e prestazioni sn "migliori" ma qui ci vorrebbe qualcuno che spieghi più nel tecnico il perché! Inoltre a livello "grafico" le qt hanno sempre avuto una marcia in più........cosa che cn le gtk si sta avendo solo ora grazie a clutter se no chissà a che punto erano ancora :D
Ecco un "confronto" fra le funzioni di qt 4.5 e gtk 2.14
http://techfreaks4u.com/blog/?p=1021
si vedo come lo sviluppo di qt sia stato decisamente più intenso e "completo" rispetto a quello delle gtk. Però diciamo anche che riflette molto bene i due differenti sistemi di sviluppo: da una parte una società che ci investe e si occupa di tutto (trolltech cn le qt) e dall'altra dove nn arrivano gli sviluppatori (di gtk) arriva il contributo della community (cn cairo, clutter, ecc). Nn dico che sia meglio il primo dal secondo metodo, anzi! però se ci fosse stato un po' meno "campanilismo" magari si poteva sfruttare fin dall'inizio una solo libreria che negli anni si è dimostrata sempre eccellente e cn un ottimo sviluppo! poi per assurdo, attualmente meglio le QT come licenza (che sn anche gpl) delle gtk+ (che sono solo lgpl) :sofico:
Cmq, da alcuni test, il sistema base di kde4 consuma il 30% in memoria rispetto al sistema base kde3! è da prendere un po' cn le pinze come sempre in confronti del genere ma sicuramente le qt4 hanno avuto migliorie anche sotto questo aspetto rispetto le qt3, cosa che ormai è rara da vedere! cmq si nota anche ad occhio, kde4 è bello veloce e reattivo nonostante gli effettini grafici :sofico:
ci sarà un motivo se su QT QUASI TUTTI gli sviluppatori usato C++ mentre su con GTK python è così diffuso. Il fatto che chi sviluppa in python di solito sceglie gnome penso sia innegabile.
Forse il problema è l'opposto.....chi usa le gtk sente maggiormente la necessità di usare qualcosa che nn sia il C :) cmq le qt si possono usare anche cn python!
Perchè vi ostinate a dire che GTK3 romperanno la compatibilità con GTK2? perchè non sono più supportate libbonobo e simili? Librerie che hanno un'alternativa tecnicamente superiore da almeno 2 anni?
Aggiornare a GTK3 qualunque applicativo significa RISCRIVERNE UNA MINIMA PARTE. Avete presente il lavoro fatto con KDE4? stiamo parlando di 2 operazioni ben diverse.
Intregrare le funzionalità di clutter in un'applicativo è possibile farlo con 4/5 righe di codice (date un'occhio al blog di Mirko Muller), per le altre funzionalità nessuno obbliga ad usarla da subito, quando gli sviluppatori avranno tempo (e se lo riterranno opportuno) me faranno uso, altrimenti tanti saluti.
perché è così e l'hai scritto pure tu :)
Molta della lentezza è data dall'abbondanza di "vecchio codice" mantenuto per questioni di compatibilità. Gnome3 romperà questa compatibilità e quindi tutto dovrebbe diventare più veloce.
se il passaggio sarà più indolore rispetto a KDE4 è perché quelli di gnome hanno deciso di fare un passaggio graduale e nn netto!
Mutter (fork di metacity che utilizza Clutter per effetti, trasparenze ecc) è stato portato avanti da UNA SOLA PERSONA per un paio di anni (mantenendo contemporaneamente Metacity che sarà cmq presente in gnome3) e ora è pronto per gnome3. Riscriverlo in QT quanto tempo avrebbe richiesto?
ci sarebbe voluto molto così come ci stanno mettendo a passare alle gtk3 e a gnome 3........ma a quest'ora sarebbero a buon punto e in futuro i vantaggi si sarebbero visti :)
Affiancare il ramo GTK a uno in sviluppo QT avrebbe portato al disperdere forze (gli sviluppatori non sono poi tantissimi e cmq lavorano aggratis nel tempo libero, hanno mogli, fidanzate, forse figli da mantenere e con cui magari passare un pò di tempo libero).
Si è vero, ma, sempre secondo il MIO parere, alla fine avrebbe giovato a molti!
Cosa avete contro GTK#, mono ecc ormai non lo capisco e sinceramente rinuncio a capirlo. Le 'menate politiche' non mi interessano. Se MS è il diavolo allora togliete il supporto a fat e ntfs, togliete samba, togliete amsn ed emesene dai vostri pc prima di pensare a una libreria contro cui MS ha messo nero su bianco che non si rivarra legalemente.
ma che diavolo! la questione è ben diversa! un conto è usare un "programmino" come amsn! un conto è basare la maggior parte dei programmi e addirittura un intero DE (il rischio c'è) su un'implementazione di .net e C# che hanno alcune parti coperte da BREVETTI. nn si parla SOLO di implementare le parti "aperte" e libere da brevetti ma di TUTTO (è questo che fa mono). E a quale scopo? tanto la compatibilità cn .net nn si avrà mai e si dovrà stare sempre dietro allo sviluppo di microsoft! per me è una cosa assurda visto che c'era già una valida alternativa (QT).
Si corre il rischio che si ripeta una questione simile a quella del file system fat!!
E poi, anche trolltech a suo tempo aveva messo nero su bianco tutte le garanzie del caso per le QT cn una licenza "adeguata".......allora nn bastò mentre oggi basta?
P.s. zephyr83 non mi sembra di avere letto in questo thread grandi i vantaggi tecnici di QT. E non mi sembra di averli mai nemmeno visti all'opera visto che alla fine KDE4 è una versione graficamente più carina di KDE3 ma nulla +. A livello di usabilità e funzioni cosa è stato introdotto con QT? (questo dovrebbe interessare a noi utenti finali. Una differenza di prestazioni nell'ordine dell 5% è poca roba).
L'usabilità dipende principalmente dal DE e da chi lo sviluppa! i vantaggi nell'uso delle QT sn principalmente quelli di interoperabilità cn altre piattaforme! anche come sviluppo e prestazioni sn "migliori" ma qui ci vorrebbe qualcuno che spieghi più nel tecnico il perché! Inoltre a livello "grafico" le qt hanno sempre avuto una marcia in più........cosa che cn le gtk si sta avendo solo ora grazie a clutter se no chissà a che punto erano ancora :D
Ecco un "confronto" fra le funzioni di qt 4.5 e gtk 2.14
http://techfreaks4u.com/blog/?p=1021
si vedo come lo sviluppo di qt sia stato decisamente più intenso e "completo" rispetto a quello delle gtk. Però diciamo anche che riflette molto bene i due differenti sistemi di sviluppo: da una parte una società che ci investe e si occupa di tutto (trolltech cn le qt) e dall'altra dove nn arrivano gli sviluppatori (di gtk) arriva il contributo della community (cn cairo, clutter, ecc). Nn dico che sia meglio il primo dal secondo metodo, anzi! però se ci fosse stato un po' meno "campanilismo" magari si poteva sfruttare fin dall'inizio una solo libreria che negli anni si è dimostrata sempre eccellente e cn un ottimo sviluppo! poi per assurdo, attualmente meglio le QT come licenza (che sn anche gpl) delle gtk+ (che sono solo lgpl) :sofico:
Cmq, da alcuni test, il sistema base di kde4 consuma il 30% in memoria rispetto al sistema base kde3! è da prendere un po' cn le pinze come sempre in confronti del genere ma sicuramente le qt4 hanno avuto migliorie anche sotto questo aspetto rispetto le qt3, cosa che ormai è rara da vedere! cmq si nota anche ad occhio, kde4 è bello veloce e reattivo nonostante gli effettini grafici :sofico:
cionci
10-02-2010, 15:42
Programmare con le GTK+ è davvero un macello, sono di una verbosità assoluta. Le Qt sono da questo punto di vista sicuramente più "programmer friendly". Senza contare gli strumenti messi a disposizione da Nokia (vedi l'ottimo QtCreator).
C'è più o meno la stessa differenza che su Windows c'è fra programmare con le API Win32 e con la piattaforma .Net (gestione della memoria a parte).
Senza contare che le GTK+ da sole non coprono assolutamente tutto lo spazio di funzionalità offerte dalle Qt. Per fare quello che fanno le Qt per KDE, su Gnome c'è bisogno di libpango, gettext, libcairo, libpthread, expat/libxml, decine di system call per i socket, una decina di librerie diverse per la connessione ai DB e altro ancora. Tutto questo con documentazione eterogenea (a volte incompleta), con minor revision delle librerie che variano mediamente ogni 30 giorni, problemi di portabilità su sistemi non Linux o a volte anche fra sistemi Linux stessi.
Mi sembra evidente che i vantaggi di Qt siano notevoli per l'intera comunità, per i vecchi e per i nuovi sviluppatori.
I problemi nel passaggio di Gnome a Qt sono comunque immensi, quasi invalicabili:
- fossilizzazione degli sviluppatori su GTK+ e sul C (le Qt con il C non si possono usare)
- riscrittura completa do Gnome e di tutte le applicazioni (hanno avuto la bella idea di appoggiarsi direttamente a tutte le varie librerie senza fare una libreria wrapper che le raggruppasse tutte)
L'ideale sarebbe riscrivere le GTK+ tramite le Qt, sinceramente non ho mai esplorato le problematiche relative alla scrittura di una libreria C che fa da wrapper per una librerie C++, ma credo che non sia comunque semplice (anche la gestione degli eventi è completamente diversa).
C'è più o meno la stessa differenza che su Windows c'è fra programmare con le API Win32 e con la piattaforma .Net (gestione della memoria a parte).
Senza contare che le GTK+ da sole non coprono assolutamente tutto lo spazio di funzionalità offerte dalle Qt. Per fare quello che fanno le Qt per KDE, su Gnome c'è bisogno di libpango, gettext, libcairo, libpthread, expat/libxml, decine di system call per i socket, una decina di librerie diverse per la connessione ai DB e altro ancora. Tutto questo con documentazione eterogenea (a volte incompleta), con minor revision delle librerie che variano mediamente ogni 30 giorni, problemi di portabilità su sistemi non Linux o a volte anche fra sistemi Linux stessi.
Mi sembra evidente che i vantaggi di Qt siano notevoli per l'intera comunità, per i vecchi e per i nuovi sviluppatori.
I problemi nel passaggio di Gnome a Qt sono comunque immensi, quasi invalicabili:
- fossilizzazione degli sviluppatori su GTK+ e sul C (le Qt con il C non si possono usare)
- riscrittura completa do Gnome e di tutte le applicazioni (hanno avuto la bella idea di appoggiarsi direttamente a tutte le varie librerie senza fare una libreria wrapper che le raggruppasse tutte)
L'ideale sarebbe riscrivere le GTK+ tramite le Qt, sinceramente non ho mai esplorato le problematiche relative alla scrittura di una libreria C che fa da wrapper per una librerie C++, ma credo che non sia comunque semplice (anche la gestione degli eventi è completamente diversa).
Torav
10-02-2010, 17:00
@Torav
ci sarà un motivo se su QT QUASI TUTTI gli sviluppatori usato C++ mentre su con GTK python è così diffuso. Il fatto che chi sviluppa in python di solito sceglie gnome penso sia innegabile.
io uso le PyQt4 e francamente aveva dato un'occhiata (molto superficiale senza dubbio) alle pygtk e onestamente non mi sembra ci sia alcuna possibilità di paragone... le Qt integrano il 95% delle funzionalità che servono normalmente. Per le gtk ti devi scaricare classi aggiuntive per un sacco di roba
ci sarà un motivo se su QT QUASI TUTTI gli sviluppatori usato C++ mentre su con GTK python è così diffuso. Il fatto che chi sviluppa in python di solito sceglie gnome penso sia innegabile.
io uso le PyQt4 e francamente aveva dato un'occhiata (molto superficiale senza dubbio) alle pygtk e onestamente non mi sembra ci sia alcuna possibilità di paragone... le Qt integrano il 95% delle funzionalità che servono normalmente. Per le gtk ti devi scaricare classi aggiuntive per un sacco di roba
Barra
10-02-2010, 17:10
Molti programmatori dicono esattamente il contrario (Andrea Cimitan ad esempio ha messo mano al codice di KDE ed è scappato perchè la parte di gestione dei temi era un CASINO TREMENDO http://www.cimitan.com/blog/2008/02/01/aggiornamenti-sul-mio-oxygen/). In ogni post che si trova cercando "GTK vs QT" ci sono sempre 2 fazioni, ognuna che elogia le qualità della propria soluzione.
Non capisco poi dove sia il problema nel dover usare dipendenze esterne a GTK. Uno è un Framework completo, l'altro un toolkit grafico, trovo abbastanza normale che ci siano delle differenze...
Con Monodevelop e Vala (se proprio non si vuole usare Mono) sviluppare in GTK mi sembra decisamente semplice!
Su mono mi sono già espresso, per me ci possono fare tutto il DE che (carte alla mano) non ci sono problemi, salvo un'eventuale porting su windows (dove invece restano problemi di licenze e brevetti per alcune parti del codice).
Non capisco poi dove sia il problema nel dover usare dipendenze esterne a GTK. Uno è un Framework completo, l'altro un toolkit grafico, trovo abbastanza normale che ci siano delle differenze...
Con Monodevelop e Vala (se proprio non si vuole usare Mono) sviluppare in GTK mi sembra decisamente semplice!
Su mono mi sono già espresso, per me ci possono fare tutto il DE che (carte alla mano) non ci sono problemi, salvo un'eventuale porting su windows (dove invece restano problemi di licenze e brevetti per alcune parti del codice).
cionci
10-02-2010, 18:39
Non capisco poi dove sia il problema nel dover usare dipendenze esterne a GTK. Uno è un Framework completo, l'altro un toolkit grafico, trovo abbastanza normale che ci siano delle differenze...
Certo non è un punto a favore delle GTK+ ;)
Il problema c'è perché appunto:
- hai documentazione eterogenea e non sempre ben fatta
- devi stare dietro ai cambiamenti di tutte le librerie
- le modalità di utilizzo delle librerie non sono uniformi
- eterogeneità nei rilasci dei bugfix, nella politica di gestione dei bug e nei test
Sono tutti problemi a cui un programmatore che scrive un programma per un DE non si dovrebbe dover trovare a trattare.
Molti programmatori dicono esattamente il contrario (Andrea Cimitan ad esempio ha messo mano al codice di KDE ed è scappato perchè la parte di gestione dei temi era un CASINO TREMENDO http://www.cimitan.com/blog/2008/02/01/aggiornamenti-sul-mio-oxygen/). In ogni post che si trova cercando "GTK vs QT" ci sono sempre 2 fazioni, ognuna che elogia le qualità della propria soluzione.
Nessuno ha detto che KDE sia migliore o sia più facilmente programmabile. Dipende anche dalle scelte dei progettisti.
Certo non è un punto a favore delle GTK+ ;)
Il problema c'è perché appunto:
- hai documentazione eterogenea e non sempre ben fatta
- devi stare dietro ai cambiamenti di tutte le librerie
- le modalità di utilizzo delle librerie non sono uniformi
- eterogeneità nei rilasci dei bugfix, nella politica di gestione dei bug e nei test
Sono tutti problemi a cui un programmatore che scrive un programma per un DE non si dovrebbe dover trovare a trattare.
Molti programmatori dicono esattamente il contrario (Andrea Cimitan ad esempio ha messo mano al codice di KDE ed è scappato perchè la parte di gestione dei temi era un CASINO TREMENDO http://www.cimitan.com/blog/2008/02/01/aggiornamenti-sul-mio-oxygen/). In ogni post che si trova cercando "GTK vs QT" ci sono sempre 2 fazioni, ognuna che elogia le qualità della propria soluzione.
Nessuno ha detto che KDE sia migliore o sia più facilmente programmabile. Dipende anche dalle scelte dei progettisti.
cionci
10-02-2010, 18:57
Tra l'altro quello sopra è il motivo principale per cui Python si è diffuso su Gnome. Proprio perché a questi problemi poi ci deve stare dietro chi programma il wrapper per Python e non il programmatore. Insomma...è un modo dire: "A lavorare con le librerie di basso livello ci pensino gli altri".
Il problema in Gnome sta nel progetto iniziale. Studiato intorno alle GTK+ e con altre decine di librerie. Per KDE invece, oltre alle QT, le funzionalità aggiuntive sono state messe tutte in librerie mantenute dal progetto. E quindi abbastanza facile cambiare una dipendenza di queste librerie, mentre il programmatore che le usa di fatto non deve fare assolutamente niente.
E tutto questo lo dico da utente di Gnome, ormai da molti anni.
Il problema in Gnome sta nel progetto iniziale. Studiato intorno alle GTK+ e con altre decine di librerie. Per KDE invece, oltre alle QT, le funzionalità aggiuntive sono state messe tutte in librerie mantenute dal progetto. E quindi abbastanza facile cambiare una dipendenza di queste librerie, mentre il programmatore che le usa di fatto non deve fare assolutamente niente.
E tutto questo lo dico da utente di Gnome, ormai da molti anni.
ArtX
10-02-2010, 20:49
Io trovo che le qt siano fantastiche, e poi ora sono. come già detto da altri, anche gpl e lgpl. Dunque l'unico vero vantaggio che ha favorito le GTK alle QT è stato superato.
Magari linux diventasse una piattaforma un pò più chiusa, con solo le qt come gui grafica (per kde però ci vorrebbe una rasatina :D ). ( ah ma ci sono solo loro nell'LSB :D?).
E poi quà vi chiedete perchè non riscrivere gnome in qt?
cavolo ma dovete inventare la ruota 4 volte per fare un'auto???
non basterebbe usare le librerie di kde4, visto che ormai sono belle pronte e più stabili delle applicazioni che le usano, per fare il desktop secondo la loro filosofia, perchè le gtk dovrebbero servire a creare un desktop secondo la filosifia gnome... ah nò scusate un programmatore gnome è troppo razzista per poter usare le qt o le kdelibs.
Sulle GTK ognuno pensi quello che vuole, ma ormai sono a dir poco obsolete e a quanto pare hanno anche pochi sviluppatori. Le qt invece sono in ottima forma e sono anche molto più facili e potenti. Inoltre provate a usare un software QT4 e uno GTK su windows o macosx. Non esiste paragone!!!
E poi ora mono..... lol:mc:
Magari linux diventasse una piattaforma un pò più chiusa, con solo le qt come gui grafica (per kde però ci vorrebbe una rasatina :D ). ( ah ma ci sono solo loro nell'LSB :D?).
E poi quà vi chiedete perchè non riscrivere gnome in qt?
cavolo ma dovete inventare la ruota 4 volte per fare un'auto???
non basterebbe usare le librerie di kde4, visto che ormai sono belle pronte e più stabili delle applicazioni che le usano, per fare il desktop secondo la loro filosofia, perchè le gtk dovrebbero servire a creare un desktop secondo la filosifia gnome... ah nò scusate un programmatore gnome è troppo razzista per poter usare le qt o le kdelibs.
Sulle GTK ognuno pensi quello che vuole, ma ormai sono a dir poco obsolete e a quanto pare hanno anche pochi sviluppatori. Le qt invece sono in ottima forma e sono anche molto più facili e potenti. Inoltre provate a usare un software QT4 e uno GTK su windows o macosx. Non esiste paragone!!!
E poi ora mono..... lol:mc:
zephyr83
10-02-2010, 21:24
Molti programmatori dicono esattamente il contrario (Andrea Cimitan ad esempio ha messo mano al codice di KDE ed è scappato perchè la parte di gestione dei temi era un CASINO TREMENDO http://www.cimitan.com/blog/2008/02/01/aggiornamenti-sul-mio-oxygen/). In ogni post che si trova cercando "GTK vs QT" ci sono sempre 2 fazioni, ognuna che elogia le qualità della propria soluzione.
la gestione dei temi? e pensare che una volta era proprio il contrario :sofico: ma questo cn le qt CHE C'ENTRA? nn si sta discutendo di gnome o kde ma di librerie!
Non capisco poi dove sia il problema nel dover usare dipendenze esterne a GTK. Uno è un Framework completo, l'altro un toolkit grafico, trovo abbastanza normale che ci siano delle differenze...
Con Monodevelop e Vala (se proprio non si vuole usare Mono) sviluppare in GTK mi sembra decisamente semplice!
Ma anche io ho detto che nn è un grosso problema ma se parliamo delle librerie in se non si può negare che le QT siano molto più evolute e complete mentre le gtk+ devono compensare cn "parti" esterne! Cmq Cionci alcuni inconvenienti li ha elencati.
Su mono mi sono già espresso, per me ci possono fare tutto il DE che (carte alla mano) non ci sono problemi, salvo un'eventuale porting su windows (dove invece restano problemi di licenze e brevetti per alcune parti del codice).
il futuro ci dirà se la strada intrapresa è stata "corretta" :)
la gestione dei temi? e pensare che una volta era proprio il contrario :sofico: ma questo cn le qt CHE C'ENTRA? nn si sta discutendo di gnome o kde ma di librerie!
Non capisco poi dove sia il problema nel dover usare dipendenze esterne a GTK. Uno è un Framework completo, l'altro un toolkit grafico, trovo abbastanza normale che ci siano delle differenze...
Con Monodevelop e Vala (se proprio non si vuole usare Mono) sviluppare in GTK mi sembra decisamente semplice!
Ma anche io ho detto che nn è un grosso problema ma se parliamo delle librerie in se non si può negare che le QT siano molto più evolute e complete mentre le gtk+ devono compensare cn "parti" esterne! Cmq Cionci alcuni inconvenienti li ha elencati.
Su mono mi sono già espresso, per me ci possono fare tutto il DE che (carte alla mano) non ci sono problemi, salvo un'eventuale porting su windows (dove invece restano problemi di licenze e brevetti per alcune parti del codice).
il futuro ci dirà se la strada intrapresa è stata "corretta" :)
_Reve_
11-02-2010, 17:17
Tra l'altro quello sopra è il motivo principale per cui Python si è diffuso su Gnome. Proprio perché a questi problemi poi ci deve stare dietro chi programma il wrapper per Python e non il programmatore. Insomma...è un modo dire: "A lavorare con le librerie di basso livello ci pensino gli altri".
Ma anche no...attualmente programmare in GTK+ più C è una scelta più che giusta e sicuramente non complesso...mai avuto problemi....non capisco dove puoi aver trovato problemi...
Il problema in Gnome sta nel progetto iniziale. Studiato intorno alle GTK+ e con altre decine di librerie.
si chiama modularità...e di certo questo non presenta un problema...anzi...
hai documentazione eterogenea e non sempre ben fatta
:eek: io trovo che sia esattamente il contrario...spesso non trovo documentazione su certe classi di qt4 e comunque la documentazione c'è ed è ben fatta: http://library.gnome.org/devel/gtk/
In ogni modo, sono d'accordo che le qt4 sono più complete, ma bisogna considerare il fatto che le gtk non "pretendono" di essere un framework come la controparte ma solo un toolkit grafico come esempio le wxwidget...
Le GTK+ sono delle ottime librerie GRAFICHE...è ovvio che se poi uno cerca anche classi per la gestione del network deve affidarsi ad altro...
Tornando in Topic: Comunque riscrivere gnome con qt4 sarebbe un inutile spreco di tempo e risorse e soprattutto andrebbe contro a tutto quello che gnome ha cercato di creare in questi anni e cioè essere un de leggero e veloce....purtoppo qt4 non è (per adesso) in grado di competere in termini di performance e consumi di risorse, con le gtk....provare per credere...
PS: le qt4 non sono poi così portabili come si vuol far credere: http://flavio.tordini.org/windows-adventures
ciao! :D
Ma anche no...attualmente programmare in GTK+ più C è una scelta più che giusta e sicuramente non complesso...mai avuto problemi....non capisco dove puoi aver trovato problemi...
Il problema in Gnome sta nel progetto iniziale. Studiato intorno alle GTK+ e con altre decine di librerie.
si chiama modularità...e di certo questo non presenta un problema...anzi...
hai documentazione eterogenea e non sempre ben fatta
:eek: io trovo che sia esattamente il contrario...spesso non trovo documentazione su certe classi di qt4 e comunque la documentazione c'è ed è ben fatta: http://library.gnome.org/devel/gtk/
In ogni modo, sono d'accordo che le qt4 sono più complete, ma bisogna considerare il fatto che le gtk non "pretendono" di essere un framework come la controparte ma solo un toolkit grafico come esempio le wxwidget...
Le GTK+ sono delle ottime librerie GRAFICHE...è ovvio che se poi uno cerca anche classi per la gestione del network deve affidarsi ad altro...
Tornando in Topic: Comunque riscrivere gnome con qt4 sarebbe un inutile spreco di tempo e risorse e soprattutto andrebbe contro a tutto quello che gnome ha cercato di creare in questi anni e cioè essere un de leggero e veloce....purtoppo qt4 non è (per adesso) in grado di competere in termini di performance e consumi di risorse, con le gtk....provare per credere...
PS: le qt4 non sono poi così portabili come si vuol far credere: http://flavio.tordini.org/windows-adventures
ciao! :D
cionci
11-02-2010, 17:39
Ma anche no...attualmente programmare in GTK+ più C è una scelta più che giusta e sicuramente non complesso...mai avuto problemi....non capisco dove puoi aver trovato problemi...
Il problema non sono le GTK, ma tutte le librerie che gli stanno d'intorno. Mi sembrava di essermi spiegato bene. Il passo che hai quotato parlava di scrivere applicazioni per Gnome, che è ben diverso dall'usare le GTK.
si chiama modularità...e di certo questo non presenta un problema...anzi...
Forse non mi sono spiegato, la modularità è un bene, ma per un DE per me deve essere obbligatorio avere un framework che astragga dalle librerie base il cui sviluppo è indipendente da Gnome, in modo da rendere tutto l'ambiente ed i programmi più tolleranti ai cambiamenti. Ora se si volesse sostituire una delle tante librerie con un'altra andrebbero riscritti centinaia di programmi, con un framework che fa da wrapper per queste librerie basterebbe riscrivere parte del framework e ricompilare. Ecco, questa per me è modularità.
:eek: io trovo che sia esattamente il contrario...spesso non trovo documentazione su certe classi di qt4 e comunque la documentazione c'è ed è ben fatta: http://library.gnome.org/devel/gtk/
Per documentazione eterogenea non intendo solo quella delle GTK, ma anche quella delle altre decine di librerie che sono necessarie per sviluppare un programma per gnome.
Fammi un esempio di cosa non trovi sulla documentazione delle Qt perché che io sappia è praticamente impossibile.
In ogni modo, sono d'accordo che le qt4 sono più complete, ma bisogna considerare il fatto che le gtk non "pretendono" di essere un framework come la controparte ma solo un toolkit grafico come esempio le wxwidget...
Le GTK+ sono delle ottime librerie GRAFICHE...è ovvio che se poi uno cerca anche classi per la gestione del network deve affidarsi ad altro...
Appunto per questo sto dicendo che sarebbe stato più furbo per gnome crearsi un framework, magari da aggiungere alle GTK, che facesse da wrapper per le altre librerie ;) Così le dipendenze dirette si sarebbero ridotto alle GTK e al framework. Il framework sarebbe stato mantenuto, aggiornato, documentato e testato insieme a Gnome.
Ribadisco che io non ce l'ho con le GTK, le GTK fanno il loro lavoro. E' tutto l'insieme di librerie che sono necessarie per scrivere una qualsiasi applicazione per Gnome che è veramente troppo dispersivo (devo ripetere perché ?).
PS: le qt4 non sono poi così portabili come si vuol far credere: http://flavio.tordini.org/windows-adventures
Avrà provato con le Qt 4.5.x ? No perché una libreria può essere anche buggata, visto che ha usato le 4.6 che erano alla prima release, potrebbe anche essere molto probabile. Mi sembra più un bug che problemi di portabilità.
Il problema non sono le GTK, ma tutte le librerie che gli stanno d'intorno. Mi sembrava di essermi spiegato bene. Il passo che hai quotato parlava di scrivere applicazioni per Gnome, che è ben diverso dall'usare le GTK.
si chiama modularità...e di certo questo non presenta un problema...anzi...
Forse non mi sono spiegato, la modularità è un bene, ma per un DE per me deve essere obbligatorio avere un framework che astragga dalle librerie base il cui sviluppo è indipendente da Gnome, in modo da rendere tutto l'ambiente ed i programmi più tolleranti ai cambiamenti. Ora se si volesse sostituire una delle tante librerie con un'altra andrebbero riscritti centinaia di programmi, con un framework che fa da wrapper per queste librerie basterebbe riscrivere parte del framework e ricompilare. Ecco, questa per me è modularità.
:eek: io trovo che sia esattamente il contrario...spesso non trovo documentazione su certe classi di qt4 e comunque la documentazione c'è ed è ben fatta: http://library.gnome.org/devel/gtk/
Per documentazione eterogenea non intendo solo quella delle GTK, ma anche quella delle altre decine di librerie che sono necessarie per sviluppare un programma per gnome.
Fammi un esempio di cosa non trovi sulla documentazione delle Qt perché che io sappia è praticamente impossibile.
In ogni modo, sono d'accordo che le qt4 sono più complete, ma bisogna considerare il fatto che le gtk non "pretendono" di essere un framework come la controparte ma solo un toolkit grafico come esempio le wxwidget...
Le GTK+ sono delle ottime librerie GRAFICHE...è ovvio che se poi uno cerca anche classi per la gestione del network deve affidarsi ad altro...
Appunto per questo sto dicendo che sarebbe stato più furbo per gnome crearsi un framework, magari da aggiungere alle GTK, che facesse da wrapper per le altre librerie ;) Così le dipendenze dirette si sarebbero ridotto alle GTK e al framework. Il framework sarebbe stato mantenuto, aggiornato, documentato e testato insieme a Gnome.
Ribadisco che io non ce l'ho con le GTK, le GTK fanno il loro lavoro. E' tutto l'insieme di librerie che sono necessarie per scrivere una qualsiasi applicazione per Gnome che è veramente troppo dispersivo (devo ripetere perché ?).
PS: le qt4 non sono poi così portabili come si vuol far credere: http://flavio.tordini.org/windows-adventures
Avrà provato con le Qt 4.5.x ? No perché una libreria può essere anche buggata, visto che ha usato le 4.6 che erano alla prima release, potrebbe anche essere molto probabile. Mi sembra più un bug che problemi di portabilità.
Dcromato
11-02-2010, 17:49
.purtoppo qt4 non è (per adesso) in grado di competere in termini di performance e consumi di risorse, con le gtk....provare per credere...
provato e la superiorità prestazionale di apps nate su qt è netta...se poi si fa un confronto fra Gnome (che ho usato fino a 2 giorni fa) e Kde....la superiorità nell'esecuzione di quest'ultimo è lampante...se poi invece si vuol andare avanti a fare discorsi meramente politici...
provato e la superiorità prestazionale di apps nate su qt è netta...se poi si fa un confronto fra Gnome (che ho usato fino a 2 giorni fa) e Kde....la superiorità nell'esecuzione di quest'ultimo è lampante...se poi invece si vuol andare avanti a fare discorsi meramente politici...
Barra
11-02-2010, 18:03
Sinceramente dopo aver provato ad installare + volte (l'ultima volta 3/4 mesi fa) KDE sul mio eee 701 sono dell'idea che hw datato o cmq non molto performante sia estremamente in difficoltà con KDE. Sul desktop si ci arrivava benone ma poi lavorarci diventava complicato (e a parte questo avevo problemi nel 'fare entrare tutto nello schermo').
Magari però è in grado di sfruttare meglio le caratteritiche di hw più performante perchè effettivamente in questo gnome sul mio pc (phenom 975 + 4gb con geforce 8400 come scheda video) certe volte mi sembra un pò 'pachidermico' (ma qui la colpa è forse mia, sperimento, installo software non stabili ecc).
@cionci
Non capisco quali e quante librerie 'esterne' a gtk siano necessarie per sviluppare su gnome. E quali di queste siano male documentate o abbiano dato problemi nell'evoluzione di programmi gnome.
Io non sono uno sviluppatore ma guardando un pò in giro mi sembra che di software gnome ce ne siano a volontà, molti più di KDE e non riesco a spiegarmi come sia possibile se, come dici tu, ci sono problemi di documentazione, librerie ecc.
Certamente il doversi rivolgere a 'più fornitori' richiede un pò più di impegno iniziale per scegliere e capire le documentazioni ma penso che non sia un grande scoglio per i programmatori (addirittura _Reve_ lo ritiene un vantaggio).
Diversi approcci, diverse mentalità. Dire però che una è superiore all'altra perchè "ha già tutto" mi sembra eccessivo.
Magari però è in grado di sfruttare meglio le caratteritiche di hw più performante perchè effettivamente in questo gnome sul mio pc (phenom 975 + 4gb con geforce 8400 come scheda video) certe volte mi sembra un pò 'pachidermico' (ma qui la colpa è forse mia, sperimento, installo software non stabili ecc).
@cionci
Non capisco quali e quante librerie 'esterne' a gtk siano necessarie per sviluppare su gnome. E quali di queste siano male documentate o abbiano dato problemi nell'evoluzione di programmi gnome.
Io non sono uno sviluppatore ma guardando un pò in giro mi sembra che di software gnome ce ne siano a volontà, molti più di KDE e non riesco a spiegarmi come sia possibile se, come dici tu, ci sono problemi di documentazione, librerie ecc.
Certamente il doversi rivolgere a 'più fornitori' richiede un pò più di impegno iniziale per scegliere e capire le documentazioni ma penso che non sia un grande scoglio per i programmatori (addirittura _Reve_ lo ritiene un vantaggio).
Diversi approcci, diverse mentalità. Dire però che una è superiore all'altra perchè "ha già tutto" mi sembra eccessivo.
cionci
11-02-2010, 18:23
@cionci
Non capisco quali e quante librerie 'esterne' a gtk siano necessarie per sviluppare su gnome. E quali di queste siano male documentate o abbiano dato problemi nell'evoluzione di programmi gnome.
Guarda nei miei post precedenti. Ho scritto un po' di librerie necessarie a coprire quello che le già Qt fanno ;)
Io non sono uno sviluppatore ma guardando un pò in giro mi sembra che di software gnome ce ne siano a volontà, molti più di KDE e non riesco a spiegarmi come sia possibile se, come dici tu, ci sono problemi di documentazione, librerie ecc.
Gnome è nato per ovviare ad un problema etico relativo alle Qt. Il mondo open source è particolarmente sensibile a queste problematiche, eccone spiegate le motivazioni.
Poi sinceramente mi sono sempre trovato meglio con l'approccio di Gnome dal punto di vista dell'usabilità.
Certamente il doversi rivolgere a 'più fornitori' richiede un pò più di impegno iniziale per scegliere e capire le documentazioni ma penso che non sia un grande scoglio per i programmatori (addirittura _Reve_ lo ritiene un vantaggio).
Non solo all'inizio. La documentazione non la si consulta solo all'inizio.
E dietro alle variazioni delle librerie chi ci sta ? Se il mio programma non funziona più con una nuova release di una libreria chi lo testa ? Se io ho una o due dipendenze si fa presto, se ne ho 20 ? Ogni 30 giorni mi devo mettere nuovamente a testare il programma, eventualmente a modificarlo.
Riprendendo il tuo esempio: io ho una ditta che deve vendere certi prodotti, questi prodotti sono disponibili da 20 fornitori diversi oppure da 2 fornitori diversi. I prezzi sono gli stessi, quale strada scegli ? Ovviamente devi considerare anche 20 cataloghi diversi contro 2 (l'help), 20 modalità di comunicazione diverse degli ordini contro 2 (le modalità d'uso della libreria), 20 modi diversi per le RMA contro 2 (la segnalazione dei bug), etc etc.
Diversi approcci, diverse mentalità. Dire però che una è superiore all'altra perchè "ha già tutto" mi sembra eccessivo.
A me invece sembra evidentemente fondato.
Non capisco quali e quante librerie 'esterne' a gtk siano necessarie per sviluppare su gnome. E quali di queste siano male documentate o abbiano dato problemi nell'evoluzione di programmi gnome.
Guarda nei miei post precedenti. Ho scritto un po' di librerie necessarie a coprire quello che le già Qt fanno ;)
Io non sono uno sviluppatore ma guardando un pò in giro mi sembra che di software gnome ce ne siano a volontà, molti più di KDE e non riesco a spiegarmi come sia possibile se, come dici tu, ci sono problemi di documentazione, librerie ecc.
Gnome è nato per ovviare ad un problema etico relativo alle Qt. Il mondo open source è particolarmente sensibile a queste problematiche, eccone spiegate le motivazioni.
Poi sinceramente mi sono sempre trovato meglio con l'approccio di Gnome dal punto di vista dell'usabilità.
Certamente il doversi rivolgere a 'più fornitori' richiede un pò più di impegno iniziale per scegliere e capire le documentazioni ma penso che non sia un grande scoglio per i programmatori (addirittura _Reve_ lo ritiene un vantaggio).
Non solo all'inizio. La documentazione non la si consulta solo all'inizio.
E dietro alle variazioni delle librerie chi ci sta ? Se il mio programma non funziona più con una nuova release di una libreria chi lo testa ? Se io ho una o due dipendenze si fa presto, se ne ho 20 ? Ogni 30 giorni mi devo mettere nuovamente a testare il programma, eventualmente a modificarlo.
Riprendendo il tuo esempio: io ho una ditta che deve vendere certi prodotti, questi prodotti sono disponibili da 20 fornitori diversi oppure da 2 fornitori diversi. I prezzi sono gli stessi, quale strada scegli ? Ovviamente devi considerare anche 20 cataloghi diversi contro 2 (l'help), 20 modalità di comunicazione diverse degli ordini contro 2 (le modalità d'uso della libreria), 20 modi diversi per le RMA contro 2 (la segnalazione dei bug), etc etc.
Diversi approcci, diverse mentalità. Dire però che una è superiore all'altra perchè "ha già tutto" mi sembra eccessivo.
A me invece sembra evidentemente fondato.
zephyr83
11-02-2010, 19:37
In ogni modo, sono d'accordo che le qt4 sono più complete, ma bisogna considerare il fatto che le gtk non "pretendono" di essere un framework come la controparte ma solo un toolkit grafico come esempio le wxwidget...
Le GTK+ sono delle ottime librerie GRAFICHE...è ovvio che se poi uno cerca anche classi per la gestione del network deve affidarsi ad altro...
ma era appunto questo che si voleva dire! però se uno dice che nn è vero che le gtk nn sn da meno alle qt bisognerà pur ribadire :)
Tornando in Topic: Comunque riscrivere gnome con qt4 sarebbe un inutile spreco di tempo e risorse e soprattutto andrebbe contro a tutto quello che gnome ha cercato di creare in questi anni e cioè essere un de leggero e veloce....purtoppo qt4 non è (per adesso) in grado di competere in termini di performance e consumi di risorse, con le gtk....provare per credere...
PS: le qt4 non sono poi così portabili come si vuol far credere: http://flavio.tordini.org/windows-adventures
ciao! :D
mha, nn mi pare che gnome sia più leggero di kde! :stordita: inoltre quello che hai linkato nn è certo un problema di porting delle qt!!! mi pare ben diversa la questione :)
Le GTK+ sono delle ottime librerie GRAFICHE...è ovvio che se poi uno cerca anche classi per la gestione del network deve affidarsi ad altro...
ma era appunto questo che si voleva dire! però se uno dice che nn è vero che le gtk nn sn da meno alle qt bisognerà pur ribadire :)
Tornando in Topic: Comunque riscrivere gnome con qt4 sarebbe un inutile spreco di tempo e risorse e soprattutto andrebbe contro a tutto quello che gnome ha cercato di creare in questi anni e cioè essere un de leggero e veloce....purtoppo qt4 non è (per adesso) in grado di competere in termini di performance e consumi di risorse, con le gtk....provare per credere...
PS: le qt4 non sono poi così portabili come si vuol far credere: http://flavio.tordini.org/windows-adventures
ciao! :D
mha, nn mi pare che gnome sia più leggero di kde! :stordita: inoltre quello che hai linkato nn è certo un problema di porting delle qt!!! mi pare ben diversa la questione :)
zephyr83
11-02-2010, 19:43
Sinceramente dopo aver provato ad installare + volte (l'ultima volta 3/4 mesi fa) KDE sul mio eee 701 sono dell'idea che hw datato o cmq non molto performante sia estremamente in difficoltà con KDE. Sul desktop si ci arrivava benone ma poi lavorarci diventava complicato (e a parte questo avevo problemi nel 'fare entrare tutto nello schermo').
Magari però è in grado di sfruttare meglio le caratteritiche di hw più performante perchè effettivamente in questo gnome sul mio pc (phenom 975 + 4gb con geforce 8400 come scheda video) certe volte mi sembra un pò 'pachidermico' (ma qui la colpa è forse mia, sperimento, installo software non stabili ecc).
:confused: sul mio acer one 110L kde gira senza problemi, meglio di windows! nessun problema! tra l'altro cn kde hanno pensato anche a interfaccia di plasma proprio per i netbook che sembra andar bene (vedrò di testarla al pià presto sul mio acer one)
@cionci
Non capisco quali e quante librerie 'esterne' a gtk siano necessarie per sviluppare su gnome. E quali di queste siano male documentate o abbiano dato problemi nell'evoluzione di programmi gnome.
Io non sono uno sviluppatore ma guardando un pò in giro mi sembra che di software gnome ce ne siano a volontà, molti più di KDE e non riesco a spiegarmi come sia possibile se, come dici tu, ci sono problemi di documentazione, librerie ecc.
Certamente il doversi rivolgere a 'più fornitori' richiede un pò più di impegno iniziale per scegliere e capire le documentazioni ma penso che non sia un grande scoglio per i programmatori (addirittura _Reve_ lo ritiene un vantaggio).
Diversi approcci, diverse mentalità. Dire però che una è superiore all'altra perchè "ha già tutto" mi sembra eccessivo.
a me Cionci pare esser stato chiaro! il problema è che devi reperire da più fonti! cn le qt è tutto più semplice hai un'unica libreria più completa! è questo che si sta cercando di dire! le qt hanno da sempre avuto uno sviluppo maggiore che le ha portate ad essere oltre a delle sole librerie grafiche. Penso che nessuno abbia detto che le gtk facciano schifo o nn si riesce a programmare ma che semplicemente nn sn a livello delle qt nella loro "interezza". Cn le qt puoi avere un unico ambiente di sviluppo, cn le gtk no. inoltre se nn sbaglio a livello grafico le qt hanno sempre avuto qualcosa in più, cosa che invece cn le gtk si sta avendo solo adesso grazie a cairo e clutter.
Epoi, la butto sempre li, ma nn è un caso se su gnome si sente così tanto l'esigenza di mono e delle gtk#.
Magari però è in grado di sfruttare meglio le caratteritiche di hw più performante perchè effettivamente in questo gnome sul mio pc (phenom 975 + 4gb con geforce 8400 come scheda video) certe volte mi sembra un pò 'pachidermico' (ma qui la colpa è forse mia, sperimento, installo software non stabili ecc).
:confused: sul mio acer one 110L kde gira senza problemi, meglio di windows! nessun problema! tra l'altro cn kde hanno pensato anche a interfaccia di plasma proprio per i netbook che sembra andar bene (vedrò di testarla al pià presto sul mio acer one)
@cionci
Non capisco quali e quante librerie 'esterne' a gtk siano necessarie per sviluppare su gnome. E quali di queste siano male documentate o abbiano dato problemi nell'evoluzione di programmi gnome.
Io non sono uno sviluppatore ma guardando un pò in giro mi sembra che di software gnome ce ne siano a volontà, molti più di KDE e non riesco a spiegarmi come sia possibile se, come dici tu, ci sono problemi di documentazione, librerie ecc.
Certamente il doversi rivolgere a 'più fornitori' richiede un pò più di impegno iniziale per scegliere e capire le documentazioni ma penso che non sia un grande scoglio per i programmatori (addirittura _Reve_ lo ritiene un vantaggio).
Diversi approcci, diverse mentalità. Dire però che una è superiore all'altra perchè "ha già tutto" mi sembra eccessivo.
a me Cionci pare esser stato chiaro! il problema è che devi reperire da più fonti! cn le qt è tutto più semplice hai un'unica libreria più completa! è questo che si sta cercando di dire! le qt hanno da sempre avuto uno sviluppo maggiore che le ha portate ad essere oltre a delle sole librerie grafiche. Penso che nessuno abbia detto che le gtk facciano schifo o nn si riesce a programmare ma che semplicemente nn sn a livello delle qt nella loro "interezza". Cn le qt puoi avere un unico ambiente di sviluppo, cn le gtk no. inoltre se nn sbaglio a livello grafico le qt hanno sempre avuto qualcosa in più, cosa che invece cn le gtk si sta avendo solo adesso grazie a cairo e clutter.
Epoi, la butto sempre li, ma nn è un caso se su gnome si sente così tanto l'esigenza di mono e delle gtk#.
_Reve_
11-02-2010, 19:49
provato e la superiorità prestazionale di apps nate su qt è netta...se poi si fa un confronto fra Gnome (che ho usato fino a 2 giorni fa) e Kde....la superiorità nell'esecuzione di quest'ultimo è lampante...se poi invece si vuol andare avanti a fare discorsi meramente politici...
sarà...ma a me anche adesso con un widget custom su qt4 consuma più ram di gtk...non si tratta di discorsi politici ma di cose provate sul campo (o computer XD) ....con le qt4 ci lavoro ma preferisco le gtk...sarà che all'inizio usavo solo gtk e ora sono più gtk-centrico ( :D )
PS: kde gli fa un baffo a gnome in termini di prestazioni :D :Prrr: :D
Per documentazione eterogenea non intendo solo quella delle GTK, ma anche quella delle altre decine di librerie che sono necessarie per sviluppare un programma per gnome.
si, su quello hai ragione
Avrà provato con le Qt 4.5.x ? No perché una libreria può essere anche buggata, visto che ha usato le 4.6 che erano alla prima release, potrebbe anche essere molto probabile. Mi sembra più un bug che problemi di portabilità.
anche le 4.6 hanno dei problemi con phonon
comunque si...le qt4 sono più complete nonostante questo continuo a vedere sempre più software scritti con le gtk :Prrr: (sotto linux ovviamente)
sarà...ma a me anche adesso con un widget custom su qt4 consuma più ram di gtk...non si tratta di discorsi politici ma di cose provate sul campo (o computer XD) ....con le qt4 ci lavoro ma preferisco le gtk...sarà che all'inizio usavo solo gtk e ora sono più gtk-centrico ( :D )
PS: kde gli fa un baffo a gnome in termini di prestazioni :D :Prrr: :D
Per documentazione eterogenea non intendo solo quella delle GTK, ma anche quella delle altre decine di librerie che sono necessarie per sviluppare un programma per gnome.
si, su quello hai ragione
Avrà provato con le Qt 4.5.x ? No perché una libreria può essere anche buggata, visto che ha usato le 4.6 che erano alla prima release, potrebbe anche essere molto probabile. Mi sembra più un bug che problemi di portabilità.
anche le 4.6 hanno dei problemi con phonon
comunque si...le qt4 sono più complete nonostante questo continuo a vedere sempre più software scritti con le gtk :Prrr: (sotto linux ovviamente)
zephyr83
11-02-2010, 20:31
sarà...ma a me anche adesso con un widget custom su qt4 consuma più ram di gtk...non si tratta di discorsi politici ma di cose provate sul campo (o computer XD) ....con le qt4 ci lavoro ma preferisco le gtk...sarà che all'inizio usavo solo gtk e ora sono più gtk-centrico ( :D )
PS: kde gli fa un baffo a gnome in termini di prestazioni :D :Prrr: :D
si ma che prova è? :sofico: sarebbe come dire che sul mio pc il sistema base di kde consuma meno ram del sistema base di gnome :D
anche le 4.6 hanno dei problemi con phonon
comunque si...le qt4 sono più complete nonostante questo continuo a vedere sempre più software scritti con le gtk :Prrr: (sotto linux ovviamente)
ecco appunto Phonon che è una libreria di kde, nn una cosa che fa parte delle qt :)
inoltre vedi più software in gtk perché le maggiori distro usano gnome (vedi ubuntu).....però io sento lodare più spesso (per prestazioni e funzioni) programmi in qt che in gtk, amarok e k3b su tutti (o vlc, inkscape e tanti altri) ;)
PS: kde gli fa un baffo a gnome in termini di prestazioni :D :Prrr: :D
si ma che prova è? :sofico: sarebbe come dire che sul mio pc il sistema base di kde consuma meno ram del sistema base di gnome :D
anche le 4.6 hanno dei problemi con phonon
comunque si...le qt4 sono più complete nonostante questo continuo a vedere sempre più software scritti con le gtk :Prrr: (sotto linux ovviamente)
ecco appunto Phonon che è una libreria di kde, nn una cosa che fa parte delle qt :)
inoltre vedi più software in gtk perché le maggiori distro usano gnome (vedi ubuntu).....però io sento lodare più spesso (per prestazioni e funzioni) programmi in qt che in gtk, amarok e k3b su tutti (o vlc, inkscape e tanti altri) ;)
Barra
11-02-2010, 21:43
@Cionci
scusami ma forse non mi sono spiegato bene:
Ok, servono librerie esterne (e fun qui è già stato chiarito GTK non è un framework) ma non parliamo di 800 diverse librerie. Inoltre in quale caso l'evoluzione di una di queste librerie ha portato casini seri (parlo di quelli che richiedono + di 10 minuti di impegno da parte di uno sviluppatore) in applicativi GTK? non ho mai letto nulla di così grave.
Poi permettimi di dire che NON MI INTERESSA perchè è nato gnome e perchè MONO è odiato da tanti e RMS ha la barba alla gesù cristo :D . Quando parlo di opensource mi interessa avere programmi usabili, completi e potenti. Tutto il resto sono "pugnette politiche" che non mi interessano!
Riguardo la documentazione: dicevo all'inizio perchè nei primi approcci a una libreria il difficile può essere trovare e capire la documentazione (sto studiando tcpdf e nei primi istanti NON CI CAPIVO UN C@$$0) ma dopo si procede spediti (sempre se la documentazione è completa). Nel mio precedente post ti chiedevo un esempio di libreria non ben documentata proprio per questo. Spesso si confonde la mancanza di informaziono con la difficoltà nel reperirle e lavorando sul WEB so bene cosa significa!
Sulla tua ultima affermazione potrei dire (e penso di avere ragione tanto quanto te) che la LIBERTÀ di poter usare più librerie e di scegliere quale soluzione usare è una cosa positiva nel panorama del free software!
@Zephir: il mio netbook monta un celeron (900 downcloccato a 600mhz). Con ubuntu netbook remix vado BENONE (a parte firefox ma oggi che è uscito firebugs x Chrome posso abbandonarlo senza problemi). Con KDE (sia kubuntu che fedora) l'avvio era rapidissimo am tenere aperti 2 programmi era un dramma....
A parte questo non ritendo il 'dover reperire da tante fonti' un limite, anzi. Ognuno sviluppa il suo e avere molte menti pensati è sempre un vantaggio IMHO!.
Su gnome si sente l'esigenza di GTK# e mono perchè TANTE AZIENDE HANNO SVILUPPATO APPLICATIVI .NET. Queste aziende per molti motivi potrebbero essere interessate a un porting su linux.
De Icaza ha fatto un mare di soldi grazie a queste aziende e negare l'importanza di un'opportunità di business come questa è assurdo. Se poi l'applicativo .NET nel passaggio a Mono guadagna in prestazioni vuole dire che tanto schifo non deve fare mono (dati alla mano di Ximiam), quindi perchè non dovrei svilupparci un'applicativo (portabile praticamente ovunque, su iphone compreso)?
Probabilmente poi se mai troverò il tempo di sviluppare partirò o con python (per la sua vicinanza al WEB) o Vala ma trovo inutile discutere dell'importanza di Mono....
scusami ma forse non mi sono spiegato bene:
Ok, servono librerie esterne (e fun qui è già stato chiarito GTK non è un framework) ma non parliamo di 800 diverse librerie. Inoltre in quale caso l'evoluzione di una di queste librerie ha portato casini seri (parlo di quelli che richiedono + di 10 minuti di impegno da parte di uno sviluppatore) in applicativi GTK? non ho mai letto nulla di così grave.
Poi permettimi di dire che NON MI INTERESSA perchè è nato gnome e perchè MONO è odiato da tanti e RMS ha la barba alla gesù cristo :D . Quando parlo di opensource mi interessa avere programmi usabili, completi e potenti. Tutto il resto sono "pugnette politiche" che non mi interessano!
Riguardo la documentazione: dicevo all'inizio perchè nei primi approcci a una libreria il difficile può essere trovare e capire la documentazione (sto studiando tcpdf e nei primi istanti NON CI CAPIVO UN C@$$0) ma dopo si procede spediti (sempre se la documentazione è completa). Nel mio precedente post ti chiedevo un esempio di libreria non ben documentata proprio per questo. Spesso si confonde la mancanza di informaziono con la difficoltà nel reperirle e lavorando sul WEB so bene cosa significa!
Sulla tua ultima affermazione potrei dire (e penso di avere ragione tanto quanto te) che la LIBERTÀ di poter usare più librerie e di scegliere quale soluzione usare è una cosa positiva nel panorama del free software!
@Zephir: il mio netbook monta un celeron (900 downcloccato a 600mhz). Con ubuntu netbook remix vado BENONE (a parte firefox ma oggi che è uscito firebugs x Chrome posso abbandonarlo senza problemi). Con KDE (sia kubuntu che fedora) l'avvio era rapidissimo am tenere aperti 2 programmi era un dramma....
A parte questo non ritendo il 'dover reperire da tante fonti' un limite, anzi. Ognuno sviluppa il suo e avere molte menti pensati è sempre un vantaggio IMHO!.
Su gnome si sente l'esigenza di GTK# e mono perchè TANTE AZIENDE HANNO SVILUPPATO APPLICATIVI .NET. Queste aziende per molti motivi potrebbero essere interessate a un porting su linux.
De Icaza ha fatto un mare di soldi grazie a queste aziende e negare l'importanza di un'opportunità di business come questa è assurdo. Se poi l'applicativo .NET nel passaggio a Mono guadagna in prestazioni vuole dire che tanto schifo non deve fare mono (dati alla mano di Ximiam), quindi perchè non dovrei svilupparci un'applicativo (portabile praticamente ovunque, su iphone compreso)?
Probabilmente poi se mai troverò il tempo di sviluppare partirò o con python (per la sua vicinanza al WEB) o Vala ma trovo inutile discutere dell'importanza di Mono....
zephyr83
11-02-2010, 21:58
@Zephir: il mio netbook monta un celeron (900 downcloccato a 600mhz). Con ubuntu netbook remix vado BENONE (a parte firefox ma oggi che è uscito firebugs x Chrome posso abbandonarlo senza problemi). Con KDE (sia kubuntu che fedora) l'avvio era rapidissimo am tenere aperti 2 programmi era un dramma....
A parte questo non ritendo il 'dover reperire da tante fonti' un limite, anzi. Ognuno sviluppa il suo e avere molte menti pensati è sempre un vantaggio IMHO!.
Su gnome si sente l'esigenza di GTK# e mono perchè TANTE AZIENDE HANNO SVILUPPATO APPLICATIVI .NET. Queste aziende per molti motivi potrebbero essere interessate a un porting su linux.
De Icaza ha fatto un mare di soldi grazie a queste aziende e negare l'importanza di un'opportunità di business come questa è assurdo. Se poi l'applicativo .NET nel passaggio a Mono guadagna in prestazioni vuole dire che tanto schifo non deve fare mono (dati alla mano di Ximiam), quindi perchè non dovrei svilupparci un'applicativo (portabile praticamente ovunque, su iphone compreso)?
Probabilmente poi se mai troverò il tempo di sviluppare partirò o con python (per la sua vicinanza al WEB) o Vala ma trovo inutile discutere dell'importanza di Mono....
il mio acer one ha un atom n270 che come prestazioni nn è tanto meglio del tuo celeron!! lo uso senza problemi!! cmq sui desktop manager possiamo discutere quanto vogliamo, a me kde ha sempre dato di essere più veloce e reattivo rispetto a gnome (sulla stessa distro).......però qui si parla di librerie e di programmi scritti in gtk o in qt e la cosa è un po' differente!
Su mono e gtk# io di porting finora NON ne ho visti, tutte le applicazioni nate finora per gnome sn rimaste su gnome e da windows nn ho visto arrivare nulla (giusto paint.net che per girare ha avuto bisogno di un'aggiustatina :sofico: ).
Inoltre nn mi pare che le applicazioni realizzate cn mono siano più leggere e reattive di quelle realizzate in qt oppure cn le gtk stesse! sarà più facile da programmare, ma a parte questo nn ci ho visto nessun altro vantaggio!! Se davvero si voleva contribuire la porting si doveva puntare su QT! io sostengo questo, perché per me questo è l'unico strumento abbastanza diffuso che garantisce una vera interoperabilità, nn solo cn windows ma cn tanti altri sistemi operativi! se anche l'ambiente gnome avesse deciso di supportarlo le cose sarebbero potute migliora molto! inoltre già diverse aziende, anche importanti, usano le qt!!! io purtroppo dietro a mono ci vedo solo scelte campanilistiche e di convenienza per alcuni individui!! a sto punto avrei preferito gnustep :sofico:
A parte questo non ritendo il 'dover reperire da tante fonti' un limite, anzi. Ognuno sviluppa il suo e avere molte menti pensati è sempre un vantaggio IMHO!.
Su gnome si sente l'esigenza di GTK# e mono perchè TANTE AZIENDE HANNO SVILUPPATO APPLICATIVI .NET. Queste aziende per molti motivi potrebbero essere interessate a un porting su linux.
De Icaza ha fatto un mare di soldi grazie a queste aziende e negare l'importanza di un'opportunità di business come questa è assurdo. Se poi l'applicativo .NET nel passaggio a Mono guadagna in prestazioni vuole dire che tanto schifo non deve fare mono (dati alla mano di Ximiam), quindi perchè non dovrei svilupparci un'applicativo (portabile praticamente ovunque, su iphone compreso)?
Probabilmente poi se mai troverò il tempo di sviluppare partirò o con python (per la sua vicinanza al WEB) o Vala ma trovo inutile discutere dell'importanza di Mono....
il mio acer one ha un atom n270 che come prestazioni nn è tanto meglio del tuo celeron!! lo uso senza problemi!! cmq sui desktop manager possiamo discutere quanto vogliamo, a me kde ha sempre dato di essere più veloce e reattivo rispetto a gnome (sulla stessa distro).......però qui si parla di librerie e di programmi scritti in gtk o in qt e la cosa è un po' differente!
Su mono e gtk# io di porting finora NON ne ho visti, tutte le applicazioni nate finora per gnome sn rimaste su gnome e da windows nn ho visto arrivare nulla (giusto paint.net che per girare ha avuto bisogno di un'aggiustatina :sofico: ).
Inoltre nn mi pare che le applicazioni realizzate cn mono siano più leggere e reattive di quelle realizzate in qt oppure cn le gtk stesse! sarà più facile da programmare, ma a parte questo nn ci ho visto nessun altro vantaggio!! Se davvero si voleva contribuire la porting si doveva puntare su QT! io sostengo questo, perché per me questo è l'unico strumento abbastanza diffuso che garantisce una vera interoperabilità, nn solo cn windows ma cn tanti altri sistemi operativi! se anche l'ambiente gnome avesse deciso di supportarlo le cose sarebbero potute migliora molto! inoltre già diverse aziende, anche importanti, usano le qt!!! io purtroppo dietro a mono ci vedo solo scelte campanilistiche e di convenienza per alcuni individui!! a sto punto avrei preferito gnustep :sofico:
cionci
12-02-2010, 08:27
@Cionci
scusami ma forse non mi sono spiegato bene:
Ok, servono librerie esterne (e fun qui è già stato chiarito GTK non è un framework) ma non parliamo di 800 diverse librerie. Inoltre in quale caso l'evoluzione di una di queste librerie ha portato casini seri (parlo di quelli che richiedono + di 10 minuti di impegno da parte di uno sviluppatore) in applicativi GTK? non ho mai letto nulla di così grave.
Ti posso fare l'esempio di una libreria a oggetti per l'accesso a MySQL che usavo qualche anno fa. La forma di licensing è stata cambiata a partire da una major revision che inseriva anche al compatibilità con MySQL 5.
Ho dovuto riscrivere tutta la parte relativa alla gestione del database cambiando libreria.
Poi permettimi di dire che NON MI INTERESSA perchè è nato gnome e perchè MONO è odiato da tanti e RMS ha la barba alla gesù cristo :D . Quando parlo di opensource mi interessa avere programmi usabili, completi e potenti. Tutto il resto sono "pugnette politiche" che non mi interessano!
Nemmeno a me, io semplicemente cercavo di spiegarti perché ci sono molte applicazioni GTK su Linux (domanda insita nella tua affermazione precedente). Poi se non ti interessa che ti devo dire :D
Riguardo all'interesse di avere programmi usabili, completi e potenti: sono tutti fattori proporzionali al tempo speso nello sviluppo. Questo dipende molto dalle capacità dei programmatori, ma se la capacità dei programmatori è un fattore non valutabile e lo prendiamo come costante, il tempo di sviluppo dipende fortemente da:
- dagli strumenti usati (IDE, ambienti RAD)
- dalla produttività del linguaggio
- dalla produttività delle librerie usate
- dai tempi di progettazione (non necessariamente solo iniziali)
- dai tempi necessari al reperire le informazioni (documentazione)
- dai tempi di debug e testing
A me pare chiaro come in TUTTO GTK+decina di librerie sia inferiore a Qt sotto tutti i punti di vista. Senza stare poi a contare il linguaggio di programmazione (C vs C++, ma meglio non aprire il vaso di pandora).
Riguardo la documentazione: dicevo all'inizio perchè nei primi approcci a una libreria il difficile può essere trovare e capire la documentazione (sto studiando tcpdf e nei primi istanti NON CI CAPIVO UN C@$$0) ma dopo si procede spediti (sempre se la documentazione è completa). Nel mio precedente post ti chiedevo un esempio di libreria non ben documentata proprio per questo. Spesso si confonde la mancanza di informaziono con la difficoltà nel reperirle e lavorando sul WEB so bene cosa significa!
Si procede spediti, ma per consultare la documentazione ti servono 10 volte il tempo che ci metteresti con Qt, magari lavorando proprio con QtCreator (F1 sul nome di una classe o su un metodo, oppure semplicemente non appena apri la tonda ti fa vedere i parametri per la funzione).
Oh cavolo dove ho messo la documentazione di questa libreria ? Mi sembra che fosse con man...mmmmhhh no, con man non c'è. Allora proviamo a cercarla in HTML...cavolo anche qui no. Sarà un pdf ? Boh...me la scarico così vedo meglio. 5 minuti per cercare una cavolo di funzione :D
scusami ma forse non mi sono spiegato bene:
Ok, servono librerie esterne (e fun qui è già stato chiarito GTK non è un framework) ma non parliamo di 800 diverse librerie. Inoltre in quale caso l'evoluzione di una di queste librerie ha portato casini seri (parlo di quelli che richiedono + di 10 minuti di impegno da parte di uno sviluppatore) in applicativi GTK? non ho mai letto nulla di così grave.
Ti posso fare l'esempio di una libreria a oggetti per l'accesso a MySQL che usavo qualche anno fa. La forma di licensing è stata cambiata a partire da una major revision che inseriva anche al compatibilità con MySQL 5.
Ho dovuto riscrivere tutta la parte relativa alla gestione del database cambiando libreria.
Poi permettimi di dire che NON MI INTERESSA perchè è nato gnome e perchè MONO è odiato da tanti e RMS ha la barba alla gesù cristo :D . Quando parlo di opensource mi interessa avere programmi usabili, completi e potenti. Tutto il resto sono "pugnette politiche" che non mi interessano!
Nemmeno a me, io semplicemente cercavo di spiegarti perché ci sono molte applicazioni GTK su Linux (domanda insita nella tua affermazione precedente). Poi se non ti interessa che ti devo dire :D
Riguardo all'interesse di avere programmi usabili, completi e potenti: sono tutti fattori proporzionali al tempo speso nello sviluppo. Questo dipende molto dalle capacità dei programmatori, ma se la capacità dei programmatori è un fattore non valutabile e lo prendiamo come costante, il tempo di sviluppo dipende fortemente da:
- dagli strumenti usati (IDE, ambienti RAD)
- dalla produttività del linguaggio
- dalla produttività delle librerie usate
- dai tempi di progettazione (non necessariamente solo iniziali)
- dai tempi necessari al reperire le informazioni (documentazione)
- dai tempi di debug e testing
A me pare chiaro come in TUTTO GTK+decina di librerie sia inferiore a Qt sotto tutti i punti di vista. Senza stare poi a contare il linguaggio di programmazione (C vs C++, ma meglio non aprire il vaso di pandora).
Riguardo la documentazione: dicevo all'inizio perchè nei primi approcci a una libreria il difficile può essere trovare e capire la documentazione (sto studiando tcpdf e nei primi istanti NON CI CAPIVO UN C@$$0) ma dopo si procede spediti (sempre se la documentazione è completa). Nel mio precedente post ti chiedevo un esempio di libreria non ben documentata proprio per questo. Spesso si confonde la mancanza di informaziono con la difficoltà nel reperirle e lavorando sul WEB so bene cosa significa!
Si procede spediti, ma per consultare la documentazione ti servono 10 volte il tempo che ci metteresti con Qt, magari lavorando proprio con QtCreator (F1 sul nome di una classe o su un metodo, oppure semplicemente non appena apri la tonda ti fa vedere i parametri per la funzione).
Oh cavolo dove ho messo la documentazione di questa libreria ? Mi sembra che fosse con man...mmmmhhh no, con man non c'è. Allora proviamo a cercarla in HTML...cavolo anche qui no. Sarà un pdf ? Boh...me la scarico così vedo meglio. 5 minuti per cercare una cavolo di funzione :D
cionci
12-02-2010, 08:39
Su gnome si sente l'esigenza di GTK# e mono perchè TANTE AZIENDE HANNO SVILUPPATO APPLICATIVI .NET. Queste aziende per molti motivi potrebbero essere interessate a un porting su linux.
A chi programma con Mono, usare un wrapper chiamato QT# al posto di GTK# farebbe veramente poca differenza ;) Quello è un problema assolutamente minimo rispetto alle applicazioni già scritte in C o Python per Gnome.
Inoltre GTK# non sono le vere GTK, le GTK# sono orientate agli oggetti, sono molto più simili a Qt che alle GTK+. Lo sforzo è assolutamente minore rispetto ad usare le GTK+ con C ;)
A chi programma con Mono, usare un wrapper chiamato QT# al posto di GTK# farebbe veramente poca differenza ;) Quello è un problema assolutamente minimo rispetto alle applicazioni già scritte in C o Python per Gnome.
Inoltre GTK# non sono le vere GTK, le GTK# sono orientate agli oggetti, sono molto più simili a Qt che alle GTK+. Lo sforzo è assolutamente minore rispetto ad usare le GTK+ con C ;)
gash
12-02-2010, 09:45
inkscape
inkscape è gtk, facciamo finta di niente shhhh shhhh :D
Comunque sono d'accordo con chi dice che applicativi in gtk sono più conosciuti data la diffusione di distro gnome-based o che spingono in quella direzione, ma se andiamo a vedere kde-apps e qt-apps si trova una marea di software scritto in qt che copre tutti gli aspetti di cui un normale utente necessita.
Nel mio kde4 ho solo 2 applicativi in wxgtk, amule ma perchè non ho voglia di sbattermi con mldonkey e la sua gui kmldonkey in qt4 e boinc che possiede una gui in qt ma quella che viene installata insieme a boinc è in wxgtk, usavo anche gimp ma poi mi sono accorto che per togliere gli occhi rossi e aumentare o diminuire l'intensità del colore (la cosa che il 90% della gente fa sulle foto) di una foto krita e digikam(killer application per le fotocamere digitali) sono ottimi.
inkscape è gtk, facciamo finta di niente shhhh shhhh :D
Comunque sono d'accordo con chi dice che applicativi in gtk sono più conosciuti data la diffusione di distro gnome-based o che spingono in quella direzione, ma se andiamo a vedere kde-apps e qt-apps si trova una marea di software scritto in qt che copre tutti gli aspetti di cui un normale utente necessita.
Nel mio kde4 ho solo 2 applicativi in wxgtk, amule ma perchè non ho voglia di sbattermi con mldonkey e la sua gui kmldonkey in qt4 e boinc che possiede una gui in qt ma quella che viene installata insieme a boinc è in wxgtk, usavo anche gimp ma poi mi sono accorto che per togliere gli occhi rossi e aumentare o diminuire l'intensità del colore (la cosa che il 90% della gente fa sulle foto) di una foto krita e digikam(killer application per le fotocamere digitali) sono ottimi.
cionci
12-02-2010, 09:51
Nel mio kde4 ho solo 2 applicativi in wxgtk, amule ma perchè non ho voglia di sbattermi con mldonkey e la sua gui kmldonkey in qt4 e boinc che possiede una gui in qt ma quella che viene installata insieme a boinc è in wxgtk, usavo anche gimp ma poi mi sono accorto che per togliere gli occhi rossi e aumentare o diminuire l'intensità del colore (la cosa che il 90% della gente fa sulle foto) di una foto krita e digikam(killer application per le fotocamere digitali) sono ottimi.
Poi non è mica un delitto usare applicativi gtk o qt al di fuori del proprio ambiente ideale.
Poi non è mica un delitto usare applicativi gtk o qt al di fuori del proprio ambiente ideale.
gash
12-02-2010, 11:42
No no assolutamente, era solo per rispondere a chi diceva che è impossibile avere un kde senza roba gtk/gnome per la carenza di roba in qt.
Me ne ritorno zitto zitto a leggervi perchè sulla parte tecnica non so niente, a me piace kde e quindi l'aspetto di qt, se poi sono superiori o no non lo so.
Me ne ritorno zitto zitto a leggervi perchè sulla parte tecnica non so niente, a me piace kde e quindi l'aspetto di qt, se poi sono superiori o no non lo so.
Slayer86
12-02-2010, 12:24
Che un framework sia superiore ad un'altro ok... ma riscrivere un intero DE è proprio da fusi... capisco anche io che potrebbe essere comodo... ma tanto avremmo cmq le apps che sono strettamente legate al DE e la portabiltà andrebbe afarsi benedire...
Cmq mi pare che questo thread si sia trasformato nel solito duello gtk vs qt e si tralasci il punto fondamentale... la riscrittura di gnome...
ripeto che qt sia superiore a gtk può starci... ma questo non significa che si debba riscrivere tutto gnome... penso sia più semplice migliorare il framework...
per chi critica mono dicendo che invece di introdurlo dovevano migliorare il supporto a qt... bhe mono è solo un framework in più... mica si sta riscrivendo gnome usandolo...
Cmq mi pare che questo thread si sia trasformato nel solito duello gtk vs qt e si tralasci il punto fondamentale... la riscrittura di gnome...
ripeto che qt sia superiore a gtk può starci... ma questo non significa che si debba riscrivere tutto gnome... penso sia più semplice migliorare il framework...
per chi critica mono dicendo che invece di introdurlo dovevano migliorare il supporto a qt... bhe mono è solo un framework in più... mica si sta riscrivendo gnome usandolo...
cionci
12-02-2010, 12:33
Che un framework sia superiore ad un'altro ok... ma riscrivere un intero DE è proprio da fusi... capisco anche io che potrebbe essere comodo... ma tanto avremmo cmq le apps che sono strettamente legate al DE e la portabiltà andrebbe afarsi benedire...
Infatti, è quello che avevo scritto io qualche post fa. L'errore è stato scrivere Gnome senza creare un framework alla base (anche basato sulle Gtk+ e sulle altre librerie) che rendesse più semplice lo sviluppo ed eventualmente che permettesse in modo quasi indolore di cambiare le dipendenze sottostanti.
In sostanza: sarebbe sicuramente bello, ma sarebbe anche un'incredibile spreco di tempo.
Infatti, è quello che avevo scritto io qualche post fa. L'errore è stato scrivere Gnome senza creare un framework alla base (anche basato sulle Gtk+ e sulle altre librerie) che rendesse più semplice lo sviluppo ed eventualmente che permettesse in modo quasi indolore di cambiare le dipendenze sottostanti.
In sostanza: sarebbe sicuramente bello, ma sarebbe anche un'incredibile spreco di tempo.
zephyr83
12-02-2010, 13:32
inkscape è gtk, facciamo finta di niente shhhh shhhh :D
cavoli hai ragione!! cmq stanno facendo il porting in c++ cioè in gtkmm :)
cavoli hai ragione!! cmq stanno facendo il porting in c++ cioè in gtkmm :)
zephyr83
12-02-2010, 13:36
per chi critica mono dicendo che invece di introdurlo dovevano migliorare il supporto a qt... bhe mono è solo un framework in più... mica si sta riscrivendo gnome usandolo...
nn si sta riscrivendo ma sempre più programmi per gnome vengono realizzati cn gnome e gtk#. Ad esempio gnome-do poteva benissimo esser integrato in gnome base....cosa lo vietava? nulla!! se i programmi iniziano a diffondersi il rischio che gnome in futuro comprenda diversi programmi realizzati cn mono c'è! a quel punto potrebbe anche diventare il framework di riferimento!!
nn si sta riscrivendo ma sempre più programmi per gnome vengono realizzati cn gnome e gtk#. Ad esempio gnome-do poteva benissimo esser integrato in gnome base....cosa lo vietava? nulla!! se i programmi iniziano a diffondersi il rischio che gnome in futuro comprenda diversi programmi realizzati cn mono c'è! a quel punto potrebbe anche diventare il framework di riferimento!!
Dcromato
12-02-2010, 19:10
Cmq mi pare che questo thread si sia trasformato nel solito duello gtk vs qt e si tralasci il punto fondamentale... la riscrittura di gnome...
io ho aperto un sondaggio perchè tempo fa anche in Canonical si era favorevoli a sta cosa (per quanto Canonical possa influenzare o no i programmi di Gnome, e direi che un po lo fa visto che gnome 3 è stato rimandato e cosi, guarda caso, non arriva in coincidenza di una LTS).
E a dire il vero almeno si è evitato di fare un Gnome VS KDE...che poi sia un Gtk vs Qt non ci vedo nulla di male visto che si cerca di esaminare pro e contro dellla riscrittura.
io ho aperto un sondaggio perchè tempo fa anche in Canonical si era favorevoli a sta cosa (per quanto Canonical possa influenzare o no i programmi di Gnome, e direi che un po lo fa visto che gnome 3 è stato rimandato e cosi, guarda caso, non arriva in coincidenza di una LTS).
E a dire il vero almeno si è evitato di fare un Gnome VS KDE...che poi sia un Gtk vs Qt non ci vedo nulla di male visto che si cerca di esaminare pro e contro dellla riscrittura.
X360X
13-02-2010, 00:34
Non ne vedo la necessità, non stiamo parlando di 500 alternative, un ambiente in gtk (su cui sono fatti tantissimi software) bene che ci sia
Vorrei un ambiente grafico alla gnome in qt questo si, ma non gnome stesso
Vorrei un ambiente grafico alla gnome in qt questo si, ma non gnome stesso
cionci
13-02-2010, 00:37
Vorrei un ambiente grafico alla gnome in qt questo si, ma non gnome stesso
Ecco, su questo sono assolutamente d'accordo.
Ecco, su questo sono assolutamente d'accordo.
zephyr83
13-02-2010, 00:53
Non ne vedo la necessità, non stiamo parlando di 500 alternative, un ambiente in gtk (su cui sono fatti tantissimi software) bene che ci sia
Vorrei un ambiente grafico alla gnome in qt questo si, ma non gnome stesso
alla fine si fa per discutere, siamo su un forum :) io per essere avrei anche tanti altri desideri inapplicabili per linux........"immaginare" e "sperare" nn fa mai male!
Io per essere sn MOLTO curioso di vedere gnome 3 e le gtk 3 (?), di carne al fuoco ce n'è molta (come ce n'era molta al tempo di kde 4) e mi sembra anche un bel progetto interessante! Detto questo, io vedrei, in ottica futuro, una "unificazione" delle librerie almeno per i due DE principali e ovviamente in QT visto che questo toolkit permetterebbe di realizzare programmi crossplatform senza grossi problemi. L'interoperabilità ne guadagnerebbe molto! anziché buttarsi su mono e gtk# avrei preferito si fossero buttati sulle QT! magari una strada più difficile da percorrere ma per me molto più "proficuo" per linux.
Vorrei un ambiente grafico alla gnome in qt questo si, ma non gnome stesso
alla fine si fa per discutere, siamo su un forum :) io per essere avrei anche tanti altri desideri inapplicabili per linux........"immaginare" e "sperare" nn fa mai male!
Io per essere sn MOLTO curioso di vedere gnome 3 e le gtk 3 (?), di carne al fuoco ce n'è molta (come ce n'era molta al tempo di kde 4) e mi sembra anche un bel progetto interessante! Detto questo, io vedrei, in ottica futuro, una "unificazione" delle librerie almeno per i due DE principali e ovviamente in QT visto che questo toolkit permetterebbe di realizzare programmi crossplatform senza grossi problemi. L'interoperabilità ne guadagnerebbe molto! anziché buttarsi su mono e gtk# avrei preferito si fossero buttati sulle QT! magari una strada più difficile da percorrere ma per me molto più "proficuo" per linux.
xyz3D
13-02-2010, 08:21
Chi ha proposto questo tema ignora la storia e cosa c'è dietro alle GTK+ e alle QT.
Sono librerie con basi molto diverse, basta solo dire che le GTK+ sono in C e le QT in C++, non ha senso un passaggio di Gnone alle QT.
La programmazione delle QT è in C++, ricorda molto le vecchie MFC della MS, anche la gestione dei nomi dei file delle librerie e delle convenzioni sulla programmazione si rifanno all'ambiente MS-Windows.
Le GTK+ sono librerie in C con un sistema a oggetti senza utilizzare il C++ (esiste l'interfaccia GTKmm per C++), utilizzano convenzioni tipiche del mondo POSIX in molti aspetti della programmazione.
Lasciate Gnome con le GTK+ e KDE con le QT, saranno poi gli utenti a decidere quali ambienti usare, comunque esistono altre scelte non solo questi due.
Sono librerie con basi molto diverse, basta solo dire che le GTK+ sono in C e le QT in C++, non ha senso un passaggio di Gnone alle QT.
La programmazione delle QT è in C++, ricorda molto le vecchie MFC della MS, anche la gestione dei nomi dei file delle librerie e delle convenzioni sulla programmazione si rifanno all'ambiente MS-Windows.
Le GTK+ sono librerie in C con un sistema a oggetti senza utilizzare il C++ (esiste l'interfaccia GTKmm per C++), utilizzano convenzioni tipiche del mondo POSIX in molti aspetti della programmazione.
Lasciate Gnome con le GTK+ e KDE con le QT, saranno poi gli utenti a decidere quali ambienti usare, comunque esistono altre scelte non solo questi due.
cionci
13-02-2010, 09:36
La programmazione delle QT è in C++, ricorda molto le vecchie MFC della MS, anche la gestione dei nomi dei file delle librerie e delle convenzioni sulla programmazione si rifanno all'ambiente MS-Windows.
Conosco in modo approfondito sia MFC che Qt. Non hanno assolutamente niente in comune. Le MFC eseguono il mapping dei messaggi di Windows sui metodi delle classi tramite delle macro. Le Qt invece lo fanno tramite il sistema signal-slot (e già qui il vantaggio delle Qt è abissale).
Le MFC oltre a coprire sicuramente meno funzioni delle Qt, sono assolutamente più verbose delle Qt. Ad esempio se vuoi personalizzare un minimo qualsiasi cosa ti devi mettere a catturare messaggi, a lavorare con i DC e con i brush (20 linee per cambiare il colore di sfondo di un pulsante). Con le Qt con una linea di codice hai concluso.
Lasciate Gnome con le GTK+ e KDE con le QT, saranno poi gli utenti a decidere quali ambienti usare, comunque esistono altre scelte non solo questi due.
Gli utenti non si devono assolutamente preoccupare di certi aspetti. Il problema sono i programmatori C con GTK+ che stanno sparendo in favore di Mono e Python (giustamente aggiungo, vista la produttività decisamente inferiore e le maggiori difficoltà di debugging rispetto alle altre alternative). Chissà perché questo non avviene su KDE.
Conosco in modo approfondito sia MFC che Qt. Non hanno assolutamente niente in comune. Le MFC eseguono il mapping dei messaggi di Windows sui metodi delle classi tramite delle macro. Le Qt invece lo fanno tramite il sistema signal-slot (e già qui il vantaggio delle Qt è abissale).
Le MFC oltre a coprire sicuramente meno funzioni delle Qt, sono assolutamente più verbose delle Qt. Ad esempio se vuoi personalizzare un minimo qualsiasi cosa ti devi mettere a catturare messaggi, a lavorare con i DC e con i brush (20 linee per cambiare il colore di sfondo di un pulsante). Con le Qt con una linea di codice hai concluso.
Lasciate Gnome con le GTK+ e KDE con le QT, saranno poi gli utenti a decidere quali ambienti usare, comunque esistono altre scelte non solo questi due.
Gli utenti non si devono assolutamente preoccupare di certi aspetti. Il problema sono i programmatori C con GTK+ che stanno sparendo in favore di Mono e Python (giustamente aggiungo, vista la produttività decisamente inferiore e le maggiori difficoltà di debugging rispetto alle altre alternative). Chissà perché questo non avviene su KDE.
Barra
13-02-2010, 10:12
I problemi che hai segnalato sono IMHO facilmente risolvibili e in buona parte sono già stati risolti.
Se invece di parlare di software GTK parliamo di SOFTWARE GNOME le cose già cambiano molto. OK GTK sono librerie grafiche, ma le altre tecnologie necessarie per creare un applicativo gnome sono tutte abbastanza "tutelate" da gnome foundation.
Non penso che quanto hai segnalato (libreria che cambia licenza) oggi sia possibile senza che gnome foundation si muova per evitare "scomode conseguenze" (forkare e mantenere una libreria non deve essere complesso)
CMQ Canonical NON HA MAI PARLATO DI PORTARE GNOME IN QT. Mark Shuttleworth ha semplicemente risposto a una domanda in un'intervista e la risposta è stata: se ne può parlare, certamente i problemi sono molti e bisogna vedere quali possono essere i vantaggi.
Se invece di parlare di software GTK parliamo di SOFTWARE GNOME le cose già cambiano molto. OK GTK sono librerie grafiche, ma le altre tecnologie necessarie per creare un applicativo gnome sono tutte abbastanza "tutelate" da gnome foundation.
Non penso che quanto hai segnalato (libreria che cambia licenza) oggi sia possibile senza che gnome foundation si muova per evitare "scomode conseguenze" (forkare e mantenere una libreria non deve essere complesso)
CMQ Canonical NON HA MAI PARLATO DI PORTARE GNOME IN QT. Mark Shuttleworth ha semplicemente risposto a una domanda in un'intervista e la risposta è stata: se ne può parlare, certamente i problemi sono molti e bisogna vedere quali possono essere i vantaggi.
cionci
13-02-2010, 10:29
Se invece di parlare di software GTK parliamo di SOFTWARE GNOME le cose già cambiano molto. OK GTK sono librerie grafiche, ma le altre tecnologie necessarie per creare un applicativo gnome sono tutte abbastanza "tutelate" da gnome foundation.
Non penso che quanto hai segnalato (libreria che cambia licenza) oggi sia possibile senza che gnome foundation si muova per evitare "scomode conseguenze" (forkare e mantenere una libreria non deve essere complesso)
Sicuramente e lo spero, ma l'eterogeneità di documentazione e struttura delle librerie resta. Questo perché non sono progettate con l'idea di un'unica entità.
Giusto per fare capire (non a te) quante sono le librerie diverse e mantenute da gente diversa che entrano in gioco con la programmazione su Gnome: http://library.gnome.org/devel/references
Gnome alla fine entra fortemente in gioco nella stesura e nello sviluppo solamente fino al paragrafo "Librerie dello GNOME Desktop" escluse.
Non penso che quanto hai segnalato (libreria che cambia licenza) oggi sia possibile senza che gnome foundation si muova per evitare "scomode conseguenze" (forkare e mantenere una libreria non deve essere complesso)
Sicuramente e lo spero, ma l'eterogeneità di documentazione e struttura delle librerie resta. Questo perché non sono progettate con l'idea di un'unica entità.
Giusto per fare capire (non a te) quante sono le librerie diverse e mantenute da gente diversa che entrano in gioco con la programmazione su Gnome: http://library.gnome.org/devel/references
Gnome alla fine entra fortemente in gioco nella stesura e nello sviluppo solamente fino al paragrafo "Librerie dello GNOME Desktop" escluse.
Barra
13-02-2010, 10:56
Beh trovare la documentazione per tutta questa robbbba qui non è difficile (tutta linkata in quella pagina), vero però che sono spesso in formati molto diversi tra di loro.
Non penso però che librerie come quelle di evolution, telephaty e gstreamer siano così indipendendi da gnome foundation. Evolution è sviluppato da novell, apposta per fornire un'alternativa ad outlook ai propri clienti (su SUSE che usa gnome), Telephathy è ormai quasi completamente sviluppato da Collabora e gstreamer pure.
Collabora è una delle più forti realtà nel mondo Gnome oggi (ha collaborato con nokia x maemo e nokia 900, con intel x Moblin, ha ridato vita a Pitivi prendendone in mano lo sviluppo (che ha influenzato positivament anche gstreamer) ecc).
Non penso però che librerie come quelle di evolution, telephaty e gstreamer siano così indipendendi da gnome foundation. Evolution è sviluppato da novell, apposta per fornire un'alternativa ad outlook ai propri clienti (su SUSE che usa gnome), Telephathy è ormai quasi completamente sviluppato da Collabora e gstreamer pure.
Collabora è una delle più forti realtà nel mondo Gnome oggi (ha collaborato con nokia x maemo e nokia 900, con intel x Moblin, ha ridato vita a Pitivi prendendone in mano lo sviluppo (che ha influenzato positivament anche gstreamer) ecc).
cionci
13-02-2010, 11:04
Non penso però che librerie come quelle di evolution, telephaty e gstreamer siano così indipendendi da gnome foundation.
Non sono indipendenti da Gnome Foundation, ma hai detto tu stesso che sono sviluppate da realtà diverse ;)
Non sono indipendenti da Gnome Foundation, ma hai detto tu stesso che sono sviluppate da realtà diverse ;)
_Reve_
13-02-2010, 15:23
piccole precisazioni:
si ma che prova è? :sofico: sarebbe come dire che sul mio pc il sistema base di kde consuma meno ram del sistema base di gnome :D
bè, non per contraddirti (anzi si :D ), ma sono 2 cose completamente diverse...
ecco appunto Phonon che è una libreria di kde, nn una cosa che fa parte delle qt :)
phonon è parte integrante delle qt http://doc.trolltech.com/4.4/phonon-overview.html
ciao!
si ma che prova è? :sofico: sarebbe come dire che sul mio pc il sistema base di kde consuma meno ram del sistema base di gnome :D
bè, non per contraddirti (anzi si :D ), ma sono 2 cose completamente diverse...
ecco appunto Phonon che è una libreria di kde, nn una cosa che fa parte delle qt :)
phonon è parte integrante delle qt http://doc.trolltech.com/4.4/phonon-overview.html
ciao!
Barra
13-02-2010, 18:05
Prendiamo solo le librerie grafiche di QT.
Sono superiori a GTK? non penso, probabilmente si equivalgono in quanto a funzionalità, prestazioni ecc. In alcuni campi sono meglio le QT, in altri megli GTK.
Aggiungere a GTK quello che manca per farle diventare un framework serio sarebbe così impegnativo? Monodevelop ho letto più volte che è estremamente potente e flessibile. E' già ora compatibile con Vala e python (correggetemi se sbaglio).
Si potrebbe partire da questo applicativo e costruirci intorno una piattaforma completa in grado di creare applicativo mono così come altri. In alternativa netbeans e eclipse (meglio quest'ultimo forse, la vedo grigia per netbeans a meno che non venga 'completamente liberato da oracle e diventi un progetto autonomo nel qual caso potrebbe trovare una giusta casa in Gnome foundation!). Aggiungete un pò di altre cosette ed ecco un progetto in grado di 'fare tutto quello che fa QT'.
Il lavoro sarebbe certamente meno impegnativo delle completa riscrittura di Gnome!
Sono superiori a GTK? non penso, probabilmente si equivalgono in quanto a funzionalità, prestazioni ecc. In alcuni campi sono meglio le QT, in altri megli GTK.
Aggiungere a GTK quello che manca per farle diventare un framework serio sarebbe così impegnativo? Monodevelop ho letto più volte che è estremamente potente e flessibile. E' già ora compatibile con Vala e python (correggetemi se sbaglio).
Si potrebbe partire da questo applicativo e costruirci intorno una piattaforma completa in grado di creare applicativo mono così come altri. In alternativa netbeans e eclipse (meglio quest'ultimo forse, la vedo grigia per netbeans a meno che non venga 'completamente liberato da oracle e diventi un progetto autonomo nel qual caso potrebbe trovare una giusta casa in Gnome foundation!). Aggiungete un pò di altre cosette ed ecco un progetto in grado di 'fare tutto quello che fa QT'.
Il lavoro sarebbe certamente meno impegnativo delle completa riscrittura di Gnome!
cionci
13-02-2010, 19:00
Prendiamo solo le librerie grafiche di QT.
Sono superiori a GTK? non penso, probabilmente si equivalgono in quanto a funzionalità, prestazioni ecc. In alcuni campi sono meglio le QT, in altri megli GTK.
Se guardi alla produttività non c'è confronto.
Riguardo al resto del discorso sono d'accordo con te.
Sono superiori a GTK? non penso, probabilmente si equivalgono in quanto a funzionalità, prestazioni ecc. In alcuni campi sono meglio le QT, in altri megli GTK.
Se guardi alla produttività non c'è confronto.
Riguardo al resto del discorso sono d'accordo con te.
zephyr83
13-02-2010, 22:11
Beh trovare la documentazione per tutta questa robbbba qui non è difficile (tutta linkata in quella pagina), vero però che sono spesso in formati molto diversi tra di loro.
bhe, però quando si tratta di fare il porting su altre piattaforme, tipo su windows, i problemi sicuramente aumentano :)
bhe, però quando si tratta di fare il porting su altre piattaforme, tipo su windows, i problemi sicuramente aumentano :)
zephyr83
13-02-2010, 22:17
Prendiamo solo le librerie grafiche di QT.
Sono superiori a GTK? non penso, probabilmente si equivalgono in quanto a funzionalità, prestazioni ecc. In alcuni campi sono meglio le QT, in altri megli GTK.
Bhe ma se parliamo di librerie grafiche allora dobbiamo considerare appunto l'aspetto grafico! se nn sbaglio le gtk finora nn sn mai andate tanto d'accordo cn la "trasparenza". inoltre c'è voluto cario e ora clutter per raggiungere le stesse funzionalità delle QT. a sto punto mi pare normale le qt siano definite superiori a funzionalità rispetto alle gtk+!
Aggiungere a GTK quello che manca per farle diventare un framework serio sarebbe così impegnativo? Monodevelop ho letto più volte che è estremamente potente e flessibile. E' già ora compatibile con Vala e python (correggetemi se sbaglio).
Si potrebbe partire da questo applicativo e costruirci intorno una piattaforma completa in grado di creare applicativo mono così come altri. In alternativa netbeans e eclipse (meglio quest'ultimo forse, la vedo grigia per netbeans a meno che non venga 'completamente liberato da oracle e diventi un progetto autonomo nel qual caso potrebbe trovare una giusta casa in Gnome foundation!). Aggiungete un pò di altre cosette ed ecco un progetto in grado di 'fare tutto quello che fa QT'.
Il lavoro sarebbe certamente meno impegnativo delle completa riscrittura di Gnome!
a quanto pare si visto che si sta preferendo mono e le gtk# :sofico: mono e gtk# sn qualcosa di alternativo alle qt dove però c'è sempre l'indubbio vantaggio, secondo me, di essere un tutt'uno più pratico e comodo (in chiave cross-platform).
Sono superiori a GTK? non penso, probabilmente si equivalgono in quanto a funzionalità, prestazioni ecc. In alcuni campi sono meglio le QT, in altri megli GTK.
Bhe ma se parliamo di librerie grafiche allora dobbiamo considerare appunto l'aspetto grafico! se nn sbaglio le gtk finora nn sn mai andate tanto d'accordo cn la "trasparenza". inoltre c'è voluto cario e ora clutter per raggiungere le stesse funzionalità delle QT. a sto punto mi pare normale le qt siano definite superiori a funzionalità rispetto alle gtk+!
Aggiungere a GTK quello che manca per farle diventare un framework serio sarebbe così impegnativo? Monodevelop ho letto più volte che è estremamente potente e flessibile. E' già ora compatibile con Vala e python (correggetemi se sbaglio).
Si potrebbe partire da questo applicativo e costruirci intorno una piattaforma completa in grado di creare applicativo mono così come altri. In alternativa netbeans e eclipse (meglio quest'ultimo forse, la vedo grigia per netbeans a meno che non venga 'completamente liberato da oracle e diventi un progetto autonomo nel qual caso potrebbe trovare una giusta casa in Gnome foundation!). Aggiungete un pò di altre cosette ed ecco un progetto in grado di 'fare tutto quello che fa QT'.
Il lavoro sarebbe certamente meno impegnativo delle completa riscrittura di Gnome!
a quanto pare si visto che si sta preferendo mono e le gtk# :sofico: mono e gtk# sn qualcosa di alternativo alle qt dove però c'è sempre l'indubbio vantaggio, secondo me, di essere un tutt'uno più pratico e comodo (in chiave cross-platform).
zephyr83
13-02-2010, 22:23
phonon è parte integrante delle qt http://doc.trolltech.com/4.4/phonon-overview.html
ciao!
nn sn informatissimo ma a quanto so phonom è nato come API in kde e poi è stato adottato anche dalle qt a partire dalla versione 4.4
http://en.wikipedia.org/wiki/Phonon_(KDE)
se nn ho capito male, nn fa parte delle QT intese come librerie grafiche ma fa parte delle QT inteso come toolkit! Dico giusto? :stordita:
ciao!
nn sn informatissimo ma a quanto so phonom è nato come API in kde e poi è stato adottato anche dalle qt a partire dalla versione 4.4
http://en.wikipedia.org/wiki/Phonon_(KDE)
se nn ho capito male, nn fa parte delle QT intese come librerie grafiche ma fa parte delle QT inteso come toolkit! Dico giusto? :stordita:
Barra
14-02-2010, 01:32
Veramente per aggiungere il supporto alla trasparenza al Cimi è bastato aggiungere 10 righe di codice in metacity.... Già in hardy è possibile abilitare le trasparenze (ai tempi era opzionale, non so ora).
Cairo fanno parte di GTK e dalle 3.1 ci entrerà anche Clutter. Non poi il senso nella tua affermazione: gli sviluppatori QT hanno scritto da 0 funzionalità che invece in GTK sono state grazie ad altri progetti opensource (e che progetti, clutter è un GRAN BEL PEZZO DI SOFTWARE). IMHO è decisamente + intelligente la strada intrapresa da GTK (come ho scitto 1000 volte: perchè reinventare la ruota?)
Sul Cross platform mi sono già espresso: non me ne frega nulla e il mercato ha dimostrato come salvo in rari casi lo sviluppo di applicativi cross plarform è un fallimento.
Cairo fanno parte di GTK e dalle 3.1 ci entrerà anche Clutter. Non poi il senso nella tua affermazione: gli sviluppatori QT hanno scritto da 0 funzionalità che invece in GTK sono state grazie ad altri progetti opensource (e che progetti, clutter è un GRAN BEL PEZZO DI SOFTWARE). IMHO è decisamente + intelligente la strada intrapresa da GTK (come ho scitto 1000 volte: perchè reinventare la ruota?)
Sul Cross platform mi sono già espresso: non me ne frega nulla e il mercato ha dimostrato come salvo in rari casi lo sviluppo di applicativi cross plarform è un fallimento.
cionci
14-02-2010, 01:46
(come ho scitto 1000 volte: perchè reinventare la ruota?)
Assolutamente non ha senso per un progetto come Gnome, ha senso per un prodotto anche commerciale come le Qt.
Basta scriversi il suo bel wrapper in modo consistente rispetto alla libreria in modo da integrare le nuove funzionalità e renderle interscambiabili o utilizzabili insieme ad altre, integrare la nuova libreria come dipendenza, scrivere la documentazione in maniera conforme al resto della documentazione.
Per dare al programmatore uno strumento valido sicuramente la strada è questa, non certo buttare dentro nuove funzionalità senza integrarle con il resto.
Assolutamente non ha senso per un progetto come Gnome, ha senso per un prodotto anche commerciale come le Qt.
Basta scriversi il suo bel wrapper in modo consistente rispetto alla libreria in modo da integrare le nuove funzionalità e renderle interscambiabili o utilizzabili insieme ad altre, integrare la nuova libreria come dipendenza, scrivere la documentazione in maniera conforme al resto della documentazione.
Per dare al programmatore uno strumento valido sicuramente la strada è questa, non certo buttare dentro nuove funzionalità senza integrarle con il resto.
zephyr83
14-02-2010, 13:45
Veramente per aggiungere il supporto alla trasparenza al Cimi è bastato aggiungere 10 righe di codice in metacity.... Già in hardy è possibile abilitare le trasparenze (ai tempi era opzionale, non so ora).
Cairo fanno parte di GTK e dalle 3.1 ci entrerà anche Clutter. Non poi il senso nella tua affermazione: gli sviluppatori QT hanno scritto da 0 funzionalità che invece in GTK sono state grazie ad altri progetti opensource (e che progetti, clutter è un GRAN BEL PEZZO DI SOFTWARE). IMHO è decisamente + intelligente la strada intrapresa da GTK (come ho scitto 1000 volte: perchè reinventare la ruota?)
Sul Cross platform mi sono già espresso: non me ne frega nulla e il mercato ha dimostrato come salvo in rari casi lo sviluppo di applicativi cross plarform è un fallimento.
vedi? per le trasparenze in GTK+ c'era stato prima bisogno di compiz e poi è stato adeguato anche metacity. Come vedi cn le QT ci si è arrivato prima e cn meno "passaggi"! per questo si dice, a ragione, che lo sviluppo delle QT è sempre stato più intenso e sn librerie "superiori" (e più complete) delle GTK! che poi nel mondo gtk si riesca a ottenere, alla fine, gli stessi risultati è un altro discorso! Si clutter è una gran bel pezzo di software, fortuna che gli sviluppatori di gtk se ne siano accorti e abbiano deciso di "inglobarlo".....ma lo si deve a quelli che hanno sviluppato clutter e nn a quelli di gtk!!
Sul crossplatfom invece mi sa che sbagli! è che diverse software house NON sn interessate ad altri sistemi al di fuori di windows e nn ci provano neanche....nn lo fanno neanche per osx. Però vedo che diverso software nato sotto linux viene però portato verso windows e la cosa nn potrà che migliorare (anche in senso contrario).....nn è anche questa la "scusa" che c'è dietro a mono? Io sn anche fiducioso per symbian e maemo, potrebbe portare un gran bel numero di sviluppatori sotto QT!
Cairo fanno parte di GTK e dalle 3.1 ci entrerà anche Clutter. Non poi il senso nella tua affermazione: gli sviluppatori QT hanno scritto da 0 funzionalità che invece in GTK sono state grazie ad altri progetti opensource (e che progetti, clutter è un GRAN BEL PEZZO DI SOFTWARE). IMHO è decisamente + intelligente la strada intrapresa da GTK (come ho scitto 1000 volte: perchè reinventare la ruota?)
Sul Cross platform mi sono già espresso: non me ne frega nulla e il mercato ha dimostrato come salvo in rari casi lo sviluppo di applicativi cross plarform è un fallimento.
vedi? per le trasparenze in GTK+ c'era stato prima bisogno di compiz e poi è stato adeguato anche metacity. Come vedi cn le QT ci si è arrivato prima e cn meno "passaggi"! per questo si dice, a ragione, che lo sviluppo delle QT è sempre stato più intenso e sn librerie "superiori" (e più complete) delle GTK! che poi nel mondo gtk si riesca a ottenere, alla fine, gli stessi risultati è un altro discorso! Si clutter è una gran bel pezzo di software, fortuna che gli sviluppatori di gtk se ne siano accorti e abbiano deciso di "inglobarlo".....ma lo si deve a quelli che hanno sviluppato clutter e nn a quelli di gtk!!
Sul crossplatfom invece mi sa che sbagli! è che diverse software house NON sn interessate ad altri sistemi al di fuori di windows e nn ci provano neanche....nn lo fanno neanche per osx. Però vedo che diverso software nato sotto linux viene però portato verso windows e la cosa nn potrà che migliorare (anche in senso contrario).....nn è anche questa la "scusa" che c'è dietro a mono? Io sn anche fiducioso per symbian e maemo, potrebbe portare un gran bel numero di sviluppatori sotto QT!
Barra
14-02-2010, 20:49
???
stai scherzando spero...
Il primo dei pirla (sorry Cimi, si fa per dire :ciapet: ) che ha avuto bisogno delle trasparenze in GTK le ha introdotte con poche righe di codice. Su QT è vero erano già presenti da tempo ma venivano usate con questo risultato:
http://pollycoke.net/wp-content/uploads/2009/02/gnome-panel-run.jpg
Il fatto che gli sviluppatori gnome prima di scrivere codice si guardino intorno per capire se è il caso di perdere tempo o se invece conviene appoggiarsi a creature già mature lo trovi un difetto? questione di punti di vista ma il DRAMMA KDE4 dimostra che forse non sbagliano (Kwin è arrivato ad essere DECENTE dopo 1 anno almeno di lavori, su gnome Mutter, in stato di alpha era già più stabile!).
Per il crossplatform: dammi un nome di 1 applicativo NATO SU LINUX e portato con successo su windows. vero, tanti software nascono su linux poi vengono portati su windows, non ne ricordo uno solo di successo (oOo e FF sono app nati prima su winzozz e cmq usano tecnologie 'indipendenti'. Inoltre FF su linux e windows è 2 programmi differenti!). Spesso è necessario il contrario, soprattutto nel mondo professionale dove esistono aziende che vorrebbero smettere di pagare l'obolo a MS. In quel caso però QT non serve a molto (gli applicativi sono quasi sempre .net).
stai scherzando spero...
Il primo dei pirla (sorry Cimi, si fa per dire :ciapet: ) che ha avuto bisogno delle trasparenze in GTK le ha introdotte con poche righe di codice. Su QT è vero erano già presenti da tempo ma venivano usate con questo risultato:
http://pollycoke.net/wp-content/uploads/2009/02/gnome-panel-run.jpg
Il fatto che gli sviluppatori gnome prima di scrivere codice si guardino intorno per capire se è il caso di perdere tempo o se invece conviene appoggiarsi a creature già mature lo trovi un difetto? questione di punti di vista ma il DRAMMA KDE4 dimostra che forse non sbagliano (Kwin è arrivato ad essere DECENTE dopo 1 anno almeno di lavori, su gnome Mutter, in stato di alpha era già più stabile!).
Per il crossplatform: dammi un nome di 1 applicativo NATO SU LINUX e portato con successo su windows. vero, tanti software nascono su linux poi vengono portati su windows, non ne ricordo uno solo di successo (oOo e FF sono app nati prima su winzozz e cmq usano tecnologie 'indipendenti'. Inoltre FF su linux e windows è 2 programmi differenti!). Spesso è necessario il contrario, soprattutto nel mondo professionale dove esistono aziende che vorrebbero smettere di pagare l'obolo a MS. In quel caso però QT non serve a molto (gli applicativi sono quasi sempre .net).
eclissi83
14-02-2010, 20:50
scusate, parlo da perfetto ignorante in materia, ma gimp funziona su windows semplicemente installando le gtk (se non erro sono incluse nel pacchetto di gimp per windows)...
non so quanto sforzo ci sia stato e gimp non mi sembra un software semplice, ma l'hanno fatto... avete idee di cio' che e' stato dovuto fare?
per il resto mi pare che la discussione sia in stallo...
ciao
non so quanto sforzo ci sia stato e gimp non mi sembra un software semplice, ma l'hanno fatto... avete idee di cio' che e' stato dovuto fare?
per il resto mi pare che la discussione sia in stallo...
ciao
bicchiere
14-02-2010, 21:12
Per forza è in stallo.
Non si è MINIMAMENTE centrato il problema.
Non è gtk vs qt, bensì c vs c++.
C'è chi ritiene una cosa RAGIONEVOLE sviluppare widget in C.
Naturalmente ti parleranno di gobject e di gtkmm.
Le gtk 3 saranno ancora pensate per il C, quindi sono morte ancora prima di nascere, e si trascineranno dietro gnome in breve tempo.
Contenti loro.
Non si è MINIMAMENTE centrato il problema.
Non è gtk vs qt, bensì c vs c++.
C'è chi ritiene una cosa RAGIONEVOLE sviluppare widget in C.
Naturalmente ti parleranno di gobject e di gtkmm.
Le gtk 3 saranno ancora pensate per il C, quindi sono morte ancora prima di nascere, e si trascineranno dietro gnome in breve tempo.
Contenti loro.
Barra
14-02-2010, 22:55
Premesso che hai buttato li 2 cose senza argomentare e io potrei rispondere che gobject e gtkmm la cosa più meravigliosa di questo monto, mi sembra invece che la questione non sia quella.
Si può sviluppare con GTK senza conoscere C usando solo python, javascript (gnome-shell) o uno dei mille linguaggi supportati.
Si può sviluppare con GTK senza conoscere C usando solo python, javascript (gnome-shell) o uno dei mille linguaggi supportati.
cionci
15-02-2010, 00:34
In quel caso però QT non serve a molto (gli applicativi sono quasi sempre .net).
E cosa gli dovrebbe impedire di usare C++ e QT ?
E cosa gli dovrebbe impedire di usare C++ e QT ?
cionci
15-02-2010, 00:38
Si può sviluppare con GTK senza conoscere C usando solo python, javascript (gnome-shell) o uno dei mille linguaggi supportati.
Certo, i toolkit object oriented basati su GTK risolvono in grandissima parte i problemi delle GTK (e del C grazie ai linguaggi di alto livello).
Come ho già scritto in uno dei miei primi interventi, Python e Mono stanno prendendo piede su Gnome perché scrivere applicazioni per Gnome in C è altamente improduttivo.
Certo, i toolkit object oriented basati su GTK risolvono in grandissima parte i problemi delle GTK (e del C grazie ai linguaggi di alto livello).
Come ho già scritto in uno dei miei primi interventi, Python e Mono stanno prendendo piede su Gnome perché scrivere applicazioni per Gnome in C è altamente improduttivo.
bicchiere
15-02-2010, 10:13
Python e Mono stanno prendendo piede su Gnome perché scrivere applicazioni per Gnome in C è altamente improduttivo.
Esattamente.
Purtroppo i binding raramente supportano tutte le potenzialità del linguaggio naturale del toolkit, e raramente vengono mantenuti di pari passo.
Se il linguaggio naturale è buono si usa quello,
anche per QT esistono un casino di binding, ma non li usa nessuno,
perché il c++ va bene!
Esattamente.
Purtroppo i binding raramente supportano tutte le potenzialità del linguaggio naturale del toolkit, e raramente vengono mantenuti di pari passo.
Se il linguaggio naturale è buono si usa quello,
anche per QT esistono un casino di binding, ma non li usa nessuno,
perché il c++ va bene!
cionci
15-02-2010, 10:20
Se il linguaggio naturale è buono si usa quello,
anche per QT esistono un casino di binding, ma non li usa nessuno,
perché il c++ va bene!
Concordo, almeno per quanto riguarda KDE. Su Windows ad esempio sono in molti ad usare PyQt, anche perché di fatto Python non include nel proprio framework ufficiale una libreria grafica all'altezza.
anche per QT esistono un casino di binding, ma non li usa nessuno,
perché il c++ va bene!
Concordo, almeno per quanto riguarda KDE. Su Windows ad esempio sono in molti ad usare PyQt, anche perché di fatto Python non include nel proprio framework ufficiale una libreria grafica all'altezza.
zephyr83
15-02-2010, 15:04
???
stai scherzando spero...
Il primo dei pirla (sorry Cimi, si fa per dire :ciapet: ) che ha avuto bisogno delle trasparenze in GTK le ha introdotte con poche righe di codice. Su QT è vero erano già presenti da tempo ma venivano usate con questo risultato:
http://pollycoke.net/wp-content/uploads/2009/02/gnome-panel-run.jpg
Scusa ma in cosa starei scherzando?
http://www.ossblog.it/post/3576/gtk-e-trasparenze-si-puo-fare
Cosa c'è di diverso da quello che ho detto io? :confused:
Il fatto che gli sviluppatori gnome prima di scrivere codice si guardino intorno per capire se è il caso di perdere tempo o se invece conviene appoggiarsi a creature già mature lo trovi un difetto? questione di punti di vista ma il DRAMMA KDE4 dimostra che forse non sbagliano (Kwin è arrivato ad essere DECENTE dopo 1 anno almeno di lavori, su gnome Mutter, in stato di alpha era già più stabile!).
In kDE hanno voluto riscrivere TUTTO da zero, in pratica hanno realizzato un NUOVO DE! normale che le cose siano andate così!! nn hanno solo adottato le QT4, hanno proprio riscritto da zero ogni cosa! Sn due modi diversi di procedere! Sarà stato un dramma ma intanto KDE4 ora è pronto e stabile, gnome 3 invece a che punto è? cmq nn la vorrei buttare sempre su kde vs gnome, ma a quanto pare quando si parla di gtk nn si può fare a meno di nominare anche gnome, forse perché se no un confronto diretto cn le qt nn reggerebbe :stordita:
[quoe]
Per il crossplatform: dammi un nome di 1 applicativo NATO SU LINUX e portato con successo su windows. vero, tanti software nascono su linux poi vengono portati su windows, non ne ricordo uno solo di successo (oOo e FF sono app nati prima su winzozz e cmq usano tecnologie 'indipendenti'. Inoltre FF su linux e windows è 2 programmi differenti!). Spesso è necessario il contrario, soprattutto nel mondo professionale dove esistono aziende che vorrebbero smettere di pagare l'obolo a MS. In quel caso però QT non serve a molto (gli applicativi sono quasi sempre .net).[/QUOTE]
ma deve per forza nascere su linux e poi essere portato su windows? sarebbe più interessante il contrario visto che il problema è per le applicazioni windows che nn ci sn su linux!!! anziché incitare le aziende a sviluppare in .Net meglio spingerle verso le QT! invece cn mono per me è come dire di continuare a sviluppare in .net perché è l'alternativa migliore anche su linux!!
stai scherzando spero...
Il primo dei pirla (sorry Cimi, si fa per dire :ciapet: ) che ha avuto bisogno delle trasparenze in GTK le ha introdotte con poche righe di codice. Su QT è vero erano già presenti da tempo ma venivano usate con questo risultato:
http://pollycoke.net/wp-content/uploads/2009/02/gnome-panel-run.jpg
Scusa ma in cosa starei scherzando?
http://www.ossblog.it/post/3576/gtk-e-trasparenze-si-puo-fare
Cosa c'è di diverso da quello che ho detto io? :confused:
Il fatto che gli sviluppatori gnome prima di scrivere codice si guardino intorno per capire se è il caso di perdere tempo o se invece conviene appoggiarsi a creature già mature lo trovi un difetto? questione di punti di vista ma il DRAMMA KDE4 dimostra che forse non sbagliano (Kwin è arrivato ad essere DECENTE dopo 1 anno almeno di lavori, su gnome Mutter, in stato di alpha era già più stabile!).
In kDE hanno voluto riscrivere TUTTO da zero, in pratica hanno realizzato un NUOVO DE! normale che le cose siano andate così!! nn hanno solo adottato le QT4, hanno proprio riscritto da zero ogni cosa! Sn due modi diversi di procedere! Sarà stato un dramma ma intanto KDE4 ora è pronto e stabile, gnome 3 invece a che punto è? cmq nn la vorrei buttare sempre su kde vs gnome, ma a quanto pare quando si parla di gtk nn si può fare a meno di nominare anche gnome, forse perché se no un confronto diretto cn le qt nn reggerebbe :stordita:
[quoe]
Per il crossplatform: dammi un nome di 1 applicativo NATO SU LINUX e portato con successo su windows. vero, tanti software nascono su linux poi vengono portati su windows, non ne ricordo uno solo di successo (oOo e FF sono app nati prima su winzozz e cmq usano tecnologie 'indipendenti'. Inoltre FF su linux e windows è 2 programmi differenti!). Spesso è necessario il contrario, soprattutto nel mondo professionale dove esistono aziende che vorrebbero smettere di pagare l'obolo a MS. In quel caso però QT non serve a molto (gli applicativi sono quasi sempre .net).[/QUOTE]
ma deve per forza nascere su linux e poi essere portato su windows? sarebbe più interessante il contrario visto che il problema è per le applicazioni windows che nn ci sn su linux!!! anziché incitare le aziende a sviluppare in .Net meglio spingerle verso le QT! invece cn mono per me è come dire di continuare a sviluppare in .net perché è l'alternativa migliore anche su linux!!
bicchiere
15-02-2010, 20:21
NEWS! Fusione di Moblin e Maemo -> MEEGO
Anche Intel abbandona le GTK.
Anche Intel abbandona le GTK.
cionci
15-02-2010, 20:30
NEWS! Fusione di Moblin e Maemo -> MEEGO
Anche Intel abbandona le GTK.
In realtà le Gtk sono ancora supportate su Meego, ma le Qt sono il toolkit ufficiale della piattaforma.
Inoltre viene promosso QtCreator come strumenti principale di sviluppo.
Anche Intel abbandona le GTK.
In realtà le Gtk sono ancora supportate su Meego, ma le Qt sono il toolkit ufficiale della piattaforma.
Inoltre viene promosso QtCreator come strumenti principale di sviluppo.
ArtX
15-02-2010, 21:41
A mio parere le gtk sono una palla al piede. Le qt offrono di più, e perchè allora non fare gnome usando però le kdelibs? Sinceramente kde4 non mi piace, ma tutto il suo ecosistema di librerie penso sia il più avanzato per un DE al momento no? Sembra che gnome possa usare tutto ma non le qt. E se propio vogliono mono che lo sviluppino con le qt.
zephyr83
16-02-2010, 10:56
A mio parere le gtk sono una palla al piede. Le qt offrono di più, e perchè allora non fare gnome usando però le kdelibs? Sinceramente kde4 non mi piace, ma tutto il suo ecosistema di librerie penso sia il più avanzato per un DE al momento no? Sembra che gnome possa usare tutto ma non le qt. E se propio vogliono mono che lo sviluppino con le qt.
usare le kdelibs se prima nn passi alle qt nn ha senso :sofico: cmq io eliminerei anchel le kdelibs, voglio programmi "indipendenti", anche se mi rendo conto che è molto utopistico....un DE delle librerie base deve averle! Ecco magari gnome e kde potrebbero iniziare a realizzare qualcosa di compatibile però ci sarebbero enormi problemi di sviluppo per i due DE! Cioè sn due progetti molto differenti e usano componenti diverse fra loro.
Invece mono nn ha senso di esistere cn le qt visto che fanno la stessa cosa!! se usi già le qt nn hai bisogno di mono..........al massimo aggiungi C# alle qt visto che piacciono tanto (per essere di C# ne ho solo sentito parlare bene finora)
usare le kdelibs se prima nn passi alle qt nn ha senso :sofico: cmq io eliminerei anchel le kdelibs, voglio programmi "indipendenti", anche se mi rendo conto che è molto utopistico....un DE delle librerie base deve averle! Ecco magari gnome e kde potrebbero iniziare a realizzare qualcosa di compatibile però ci sarebbero enormi problemi di sviluppo per i due DE! Cioè sn due progetti molto differenti e usano componenti diverse fra loro.
Invece mono nn ha senso di esistere cn le qt visto che fanno la stessa cosa!! se usi già le qt nn hai bisogno di mono..........al massimo aggiungi C# alle qt visto che piacciono tanto (per essere di C# ne ho solo sentito parlare bene finora)
zephyr83
16-02-2010, 11:03
In realtà le Gtk sono ancora supportate su Meego, ma le Qt sono il toolkit ufficiale della piattaforma.
Inoltre viene promosso QtCreator come strumenti principale di sviluppo.
penso che saranno sempre "supportate", cioè ci sarà la possibilità di usare queste librerie così come tante altre, però il sistema sicuramente in futuro sarà basato sulle QT. Cmq bisogna dire che il progetto maemo di nokia, del "lontano" 2005 ha dato i suoi frutti partendo in sordina, senza pubblicità, senza investimenti mostruosi!! Tra l'altro, Hildon (guarda un po' chi si rivede), è diventato parte integrante di gnome, è stato adottato da Moblin e pure da ubuntu per la versione mobile (mi pare che nn se ne sia fatto più niente, o meglio, si è trasformato in ubuntu remix). Ora si migra piano piano alle QT sena problemi!! Per me si stanno muovendo bene anche se avrei preferito che maemo rimanesse sugli smartphone e magari anche tablet pc e smartbook cn arm!!!
Inoltre viene promosso QtCreator come strumenti principale di sviluppo.
penso che saranno sempre "supportate", cioè ci sarà la possibilità di usare queste librerie così come tante altre, però il sistema sicuramente in futuro sarà basato sulle QT. Cmq bisogna dire che il progetto maemo di nokia, del "lontano" 2005 ha dato i suoi frutti partendo in sordina, senza pubblicità, senza investimenti mostruosi!! Tra l'altro, Hildon (guarda un po' chi si rivede), è diventato parte integrante di gnome, è stato adottato da Moblin e pure da ubuntu per la versione mobile (mi pare che nn se ne sia fatto più niente, o meglio, si è trasformato in ubuntu remix). Ora si migra piano piano alle QT sena problemi!! Per me si stanno muovendo bene anche se avrei preferito che maemo rimanesse sugli smartphone e magari anche tablet pc e smartbook cn arm!!!
Barra
16-02-2010, 11:27
@zephyr: il mio "stai scherzando" era riferito al fatto che a sentir te è stato necessario sviluppare Compiz per introdurre le trasparenze su GTK, quando in realtà sono bastate poche righe di codice (quando qualcuno ne ha sentito la necessità).
Gnome3 uscirà e sarà STABILE DA SUBITO. Proprio perchè si è deciso di EVOLVERE, non rivoluzionare. Il rilascio è stato posticipato di 6 mesi e ci sta, cmq è un progetto nato anni dopo KDE4 (anche se a GTK3 si ci sta lavorando ormai dai tempi di gnome 2.22 o .24).
Non capisci poi il mio discorso su Mono. GLI APPLICATIVI WINDOWS .NET ESISTONO GIÀ. Sono milioni e generano un volume di affari IMPRESSIONANTE (se paragonato al mercato degli applicativi linux). Tanti applicativi estremamente verticali, dedicati a nicchie di mercato (nicchie che però spesso PAGANO BENE). Ecco perchè è nato mono.
Certo se un'azienda sviluppa da 0 un'applicativo multipiattaforma sceglie altre strade ma forse Java è una soluzione migliore ancora oggi (anche se bisogna ammettere che QT è diventata un'alternativa importante).
Un esempio? Paint.Net, citato da te è nato su .net e trasportato su linux grazie a mono. Una riscrittura in QT sarebbe stata decisamente improbabile....
hildon non era + usato in moblin e me che meno in ubuntu mobile (UNR non lo usa), come ti avevo annunciato pochi post fa morirà o cmq sarà fortemente limitato dalla nuova piattaforma che baserà su QT l'intera UI.
@cionci:
Gobject e gtkmm quali limiti hanno per chi vuole sviluppare su gnome?
Clutter: è C o C++?
Non è possibile iniziare a scrivere librerie GTK in C++?
(domande da ignorante in materia, per chiarirmi alcuni dubbi).
CMQ Gnome3 sta venendo su bene, zeitgeist è notevole, gnome-shell è ormai stabilissimo, il nuovo engine per i template (basato su CSS) permette di modificare un tema in pochi minuti). Infarcite tutto con tracker e nepomuk (da gnome 3.2 probabilmente) ed ecco servito un bel DE. Peccato solo per l'area di notifica, la trovo un pò indigesta :D
Gnome3 uscirà e sarà STABILE DA SUBITO. Proprio perchè si è deciso di EVOLVERE, non rivoluzionare. Il rilascio è stato posticipato di 6 mesi e ci sta, cmq è un progetto nato anni dopo KDE4 (anche se a GTK3 si ci sta lavorando ormai dai tempi di gnome 2.22 o .24).
Non capisci poi il mio discorso su Mono. GLI APPLICATIVI WINDOWS .NET ESISTONO GIÀ. Sono milioni e generano un volume di affari IMPRESSIONANTE (se paragonato al mercato degli applicativi linux). Tanti applicativi estremamente verticali, dedicati a nicchie di mercato (nicchie che però spesso PAGANO BENE). Ecco perchè è nato mono.
Certo se un'azienda sviluppa da 0 un'applicativo multipiattaforma sceglie altre strade ma forse Java è una soluzione migliore ancora oggi (anche se bisogna ammettere che QT è diventata un'alternativa importante).
Un esempio? Paint.Net, citato da te è nato su .net e trasportato su linux grazie a mono. Una riscrittura in QT sarebbe stata decisamente improbabile....
hildon non era + usato in moblin e me che meno in ubuntu mobile (UNR non lo usa), come ti avevo annunciato pochi post fa morirà o cmq sarà fortemente limitato dalla nuova piattaforma che baserà su QT l'intera UI.
@cionci:
Gobject e gtkmm quali limiti hanno per chi vuole sviluppare su gnome?
Clutter: è C o C++?
Non è possibile iniziare a scrivere librerie GTK in C++?
(domande da ignorante in materia, per chiarirmi alcuni dubbi).
CMQ Gnome3 sta venendo su bene, zeitgeist è notevole, gnome-shell è ormai stabilissimo, il nuovo engine per i template (basato su CSS) permette di modificare un tema in pochi minuti). Infarcite tutto con tracker e nepomuk (da gnome 3.2 probabilmente) ed ecco servito un bel DE. Peccato solo per l'area di notifica, la trovo un pò indigesta :D
cionci
16-02-2010, 11:43
@cionci:
Gobject
Clutter: è C o C++?
Sono tutte librerie per il C, certo l'approccio è simil-oggetti.
@cionci:e gtkmm quali limiti hanno per chi vuole sviluppare su gnome?
Le gtkmm sono un tentativo di portare le gtk+ in C++, di per sé possono anche essere più semplici per chi programma in C++. Sinceramente non le conosco tanto bene da poterne dare un valutazione assoluta, ma dal poco che ho visto sono un porting 1 a 1 delle gtk+, quindi ad ogni funzione gtk+ corrisponde un metodo di una classe gtkmm. Da quanto ne so sono veramente poco usate.
Non è possibile iniziare a scrivere librerie GTK in C++?
(domande da ignorante in materia, per chiarirmi alcuni dubbi).
Certo è possibile, sono le gtkmm. Il problema però non sono le gtk+, ma tutto il resto che c'è intorno. Sarebbe auspicabile creare un framework intermedio più consistente ed inglobare lì tutte le funzionalità del DE.
Gobject
Clutter: è C o C++?
Sono tutte librerie per il C, certo l'approccio è simil-oggetti.
@cionci:e gtkmm quali limiti hanno per chi vuole sviluppare su gnome?
Le gtkmm sono un tentativo di portare le gtk+ in C++, di per sé possono anche essere più semplici per chi programma in C++. Sinceramente non le conosco tanto bene da poterne dare un valutazione assoluta, ma dal poco che ho visto sono un porting 1 a 1 delle gtk+, quindi ad ogni funzione gtk+ corrisponde un metodo di una classe gtkmm. Da quanto ne so sono veramente poco usate.
Non è possibile iniziare a scrivere librerie GTK in C++?
(domande da ignorante in materia, per chiarirmi alcuni dubbi).
Certo è possibile, sono le gtkmm. Il problema però non sono le gtk+, ma tutto il resto che c'è intorno. Sarebbe auspicabile creare un framework intermedio più consistente ed inglobare lì tutte le funzionalità del DE.
zephyr83
16-02-2010, 13:30
Gnome3 uscirà e sarà STABILE DA SUBITO. Proprio perchè si è deciso di EVOLVERE, non rivoluzionare. Il rilascio è stato posticipato di 6 mesi e ci sta, cmq è un progetto nato anni dopo KDE4 (anche se a GTK3 si ci sta lavorando ormai dai tempi di gnome 2.22 o .24).
bhe è da vedere quanto sarà stabile :) ed è da vedere ancora quando uscirà e quante cose comprenderà...scommetto che inizialmente nn avrà tutte le novità annunciate!
Non capisci poi il mio discorso su Mono. GLI APPLICATIVI WINDOWS .NET ESISTONO GIÀ. Sono milioni e generano un volume di affari IMPRESSIONANTE (se paragonato al mercato degli applicativi linux). Tanti applicativi estremamente verticali, dedicati a nicchie di mercato (nicchie che però spesso PAGANO BENE). Ecco perchè è nato mono.
A me nn è che vengano in mente tutti sti gran applicativi realizzazi in .NET di cui si sentiva la mancanza! E paint.net, che era sicuramente una cosa semplice, ha avuto inizialmente bisogno di una correttina!!! Se c'è bisogno di "correggere" ogni cosa ciao ciao compatibilità! inoltre bisognerà sempre inseguire lo sviluppo di .net arrivando per forza di cose sempre dopo! è una falsa "compatibilità". è solo più facile da programmare ma secondo me nn porta vantaggi al mondo linux!
Certo se un'azienda sviluppa da 0 un'applicativo multipiattaforma sceglie altre strade ma forse Java è una soluzione migliore ancora oggi (anche se bisogna ammettere che QT è diventata un'alternativa importante).
Quello che dico io è che il mondo open source doveva proporre in maniera "compatta" un'alternativa a .net senza dover tirare fuori mono! qual era quello strumento che poteva proporsi come alternativa a .net anche su windows e risolvere il problema della'interoperabilità? QT! allora perché nn proporlo e cercare di spingere nuovi sviluppatori, ANCHE SU WINDOWS, a usare questo toolkit? sarebbe stato da giovamento anche per linux........peccato che così ci avrebbe forse "rimesso" gnome.
Un esempio? Paint.Net, citato da te è nato su .net e trasportato su linux grazie a mono. Una riscrittura in QT sarebbe stata decisamente improbabile....
ovvio, ma sarebbe stato meglio se paint.net fosse stato paint.qt, si sarebbe portato su linux senza alcuna aggiustatina!
hildon non era + usato in moblin e me che meno in ubuntu mobile (UNR non lo usa), come ti avevo annunciato pochi post fa morirà o cmq sarà fortemente limitato dalla nuova piattaforma che baserà su QT l'intera UI.
Certo che nn è più usato da moblin, nn credo che l'accordo cn nokia sia nato da ieri :sofico: però è servito e sicuramente i "principi" su cui si basa questa interfaccia utente nn sn stati buttati via, li ritrovi anche in ubuntu remix e li ritroverai anche su maemo e meego.........diciamo che l'hanno "riscritto" in qt :sofico:
bhe è da vedere quanto sarà stabile :) ed è da vedere ancora quando uscirà e quante cose comprenderà...scommetto che inizialmente nn avrà tutte le novità annunciate!
Non capisci poi il mio discorso su Mono. GLI APPLICATIVI WINDOWS .NET ESISTONO GIÀ. Sono milioni e generano un volume di affari IMPRESSIONANTE (se paragonato al mercato degli applicativi linux). Tanti applicativi estremamente verticali, dedicati a nicchie di mercato (nicchie che però spesso PAGANO BENE). Ecco perchè è nato mono.
A me nn è che vengano in mente tutti sti gran applicativi realizzazi in .NET di cui si sentiva la mancanza! E paint.net, che era sicuramente una cosa semplice, ha avuto inizialmente bisogno di una correttina!!! Se c'è bisogno di "correggere" ogni cosa ciao ciao compatibilità! inoltre bisognerà sempre inseguire lo sviluppo di .net arrivando per forza di cose sempre dopo! è una falsa "compatibilità". è solo più facile da programmare ma secondo me nn porta vantaggi al mondo linux!
Certo se un'azienda sviluppa da 0 un'applicativo multipiattaforma sceglie altre strade ma forse Java è una soluzione migliore ancora oggi (anche se bisogna ammettere che QT è diventata un'alternativa importante).
Quello che dico io è che il mondo open source doveva proporre in maniera "compatta" un'alternativa a .net senza dover tirare fuori mono! qual era quello strumento che poteva proporsi come alternativa a .net anche su windows e risolvere il problema della'interoperabilità? QT! allora perché nn proporlo e cercare di spingere nuovi sviluppatori, ANCHE SU WINDOWS, a usare questo toolkit? sarebbe stato da giovamento anche per linux........peccato che così ci avrebbe forse "rimesso" gnome.
Un esempio? Paint.Net, citato da te è nato su .net e trasportato su linux grazie a mono. Una riscrittura in QT sarebbe stata decisamente improbabile....
ovvio, ma sarebbe stato meglio se paint.net fosse stato paint.qt, si sarebbe portato su linux senza alcuna aggiustatina!
hildon non era + usato in moblin e me che meno in ubuntu mobile (UNR non lo usa), come ti avevo annunciato pochi post fa morirà o cmq sarà fortemente limitato dalla nuova piattaforma che baserà su QT l'intera UI.
Certo che nn è più usato da moblin, nn credo che l'accordo cn nokia sia nato da ieri :sofico: però è servito e sicuramente i "principi" su cui si basa questa interfaccia utente nn sn stati buttati via, li ritrovi anche in ubuntu remix e li ritroverai anche su maemo e meego.........diciamo che l'hanno "riscritto" in qt :sofico:
Barra
16-02-2010, 15:38
Partiamo dal significato di applicativo verticale: http://it.wikipedia.org/wiki/Applicativi_verticali
Chiarito questo rileggi questo pezzo:
Non capisci poi il mio discorso su Mono. GLI APPLICATIVI WINDOWS .NET ESISTONO GIÀ. Sono milioni e generano un volume di affari IMPRESSIONANTE (se paragonato al mercato degli applicativi linux). Tanti applicativi estremamente verticali, dedicati a nicchie di mercato (nicchie che però spesso PAGANO BENE). Ecco perchè è nato mono.
Certo se un'azienda sviluppa da 0 un'applicativo multipiattaforma sceglie altre strade ma forse Java è una soluzione migliore ancora oggi (anche se bisogna ammettere che QT è diventata un'alternativa importante).
In questi contesti spesso è impensabile una riscrittura. Novell con una spesa molto inferiore permette il porting su osx e linux. Una volta completata la transazione anche su windows l'applicativo gira 100% mono e lo sviluppo può proseguire senza ulteriori disagi.
Moblin e simili con UNR non hanno nulla a che vedere. L'idea alla base di UNR è USARE GNOME, non creare un'altro DE. Ed è proprio per questo che è la piattaforma (almeno ora) di maggiore successo tra gli OS x netbook: gli applicativi sono maturi e stabili.
@cionci:
Se come dici GTKMM sono il porting C++ di GTK perchè hanno così poco seguito?
GTK# in questo contesto come sono messe? lasciando perdere le mere questioni legali che spaventano molti (e ceh cmq dovrebbero rigaurdare al massimo C#) gtk# dovrebbero essere utilizzate anceh da vala (sbaglio?) Usare GTK#+vala+monodevelop? Io di sviluppo software non ne so mezza (o quasi) ma Monodevelop mi sembra un ottimo strumento per lo sviluppo software.
Chiarito questo rileggi questo pezzo:
Non capisci poi il mio discorso su Mono. GLI APPLICATIVI WINDOWS .NET ESISTONO GIÀ. Sono milioni e generano un volume di affari IMPRESSIONANTE (se paragonato al mercato degli applicativi linux). Tanti applicativi estremamente verticali, dedicati a nicchie di mercato (nicchie che però spesso PAGANO BENE). Ecco perchè è nato mono.
Certo se un'azienda sviluppa da 0 un'applicativo multipiattaforma sceglie altre strade ma forse Java è una soluzione migliore ancora oggi (anche se bisogna ammettere che QT è diventata un'alternativa importante).
In questi contesti spesso è impensabile una riscrittura. Novell con una spesa molto inferiore permette il porting su osx e linux. Una volta completata la transazione anche su windows l'applicativo gira 100% mono e lo sviluppo può proseguire senza ulteriori disagi.
Moblin e simili con UNR non hanno nulla a che vedere. L'idea alla base di UNR è USARE GNOME, non creare un'altro DE. Ed è proprio per questo che è la piattaforma (almeno ora) di maggiore successo tra gli OS x netbook: gli applicativi sono maturi e stabili.
@cionci:
Se come dici GTKMM sono il porting C++ di GTK perchè hanno così poco seguito?
GTK# in questo contesto come sono messe? lasciando perdere le mere questioni legali che spaventano molti (e ceh cmq dovrebbero rigaurdare al massimo C#) gtk# dovrebbero essere utilizzate anceh da vala (sbaglio?) Usare GTK#+vala+monodevelop? Io di sviluppo software non ne so mezza (o quasi) ma Monodevelop mi sembra un ottimo strumento per lo sviluppo software.
cionci
16-02-2010, 15:59
@cionci:
Se come dici GTKMM sono il porting C++ di GTK perchè hanno così poco seguito?
GTK# in questo contesto come sono messe? lasciando perdere le mere questioni legali che spaventano molti (e ceh cmq dovrebbero rigaurdare al massimo C#) gtk# dovrebbero essere utilizzate anceh da vala (sbaglio?) Usare GTK#+vala+monodevelop? Io di sviluppo software non ne so mezza (o quasi) ma Monodevelop mi sembra un ottimo strumento per lo sviluppo software.
C'è sempre il solito problema...e tutte le altre librerie ? Il problema si ripropone sia per Mono che per il C++.
Io sinceramente sono abbastanza contrario a Mono, per una questione di principio. Lo sviluppo è in mano a Novell, società che è fino troppo vicina a Microsoft. Mettere in mano tutto questo potenziale ad una società, che per giunta non ha rapporti ben chiari con MS, è secondo me molto rischioso.
Se si guarda agli strumenti di sviluppo, QtCreator è ancora migliore di Monodevelop ;) Ed esiste da poco più di un anno.
http://www.youtube.com/watch?v=AaD2-pRGkm4
http://www.youtube.com/watch?v=rkoO0mYksnE
http://www.youtube.com/watch?v=2AV9nRHJNK4
Se come dici GTKMM sono il porting C++ di GTK perchè hanno così poco seguito?
GTK# in questo contesto come sono messe? lasciando perdere le mere questioni legali che spaventano molti (e ceh cmq dovrebbero rigaurdare al massimo C#) gtk# dovrebbero essere utilizzate anceh da vala (sbaglio?) Usare GTK#+vala+monodevelop? Io di sviluppo software non ne so mezza (o quasi) ma Monodevelop mi sembra un ottimo strumento per lo sviluppo software.
C'è sempre il solito problema...e tutte le altre librerie ? Il problema si ripropone sia per Mono che per il C++.
Io sinceramente sono abbastanza contrario a Mono, per una questione di principio. Lo sviluppo è in mano a Novell, società che è fino troppo vicina a Microsoft. Mettere in mano tutto questo potenziale ad una società, che per giunta non ha rapporti ben chiari con MS, è secondo me molto rischioso.
Se si guarda agli strumenti di sviluppo, QtCreator è ancora migliore di Monodevelop ;) Ed esiste da poco più di un anno.
http://www.youtube.com/watch?v=AaD2-pRGkm4
http://www.youtube.com/watch?v=rkoO0mYksnE
http://www.youtube.com/watch?v=2AV9nRHJNK4
masand
16-02-2010, 16:14
Parlo da utilizzatore perché i discorsi sulla programmazione sono più che Arabo per me.
Lo so che è maleducato rispondere con una domanda, ma... Cosa ha GNOME che non va?
Ovviamente parlo di usabilità e fruibilità. Onestamente mi ci trovo bene e se la questione GNOME QT è nata per un discorso estetico, be', è solo questione di gusti...
La questione è nata invece per un discorso di "longevità"? Be', anche qui, stanno scrivendo (a gonfie vele, come detto da Barra) GNOME3 anch'esso rimasto nel "vecchio mondo" e, di nuovo, non ci trovo niente che non vada...
Sì, da utilizzatore finale e nemmeno tanto "expert", dico che GNOME sta bene come sta, anche esteticamente :)
Lo so che è maleducato rispondere con una domanda, ma... Cosa ha GNOME che non va?
Ovviamente parlo di usabilità e fruibilità. Onestamente mi ci trovo bene e se la questione GNOME QT è nata per un discorso estetico, be', è solo questione di gusti...
La questione è nata invece per un discorso di "longevità"? Be', anche qui, stanno scrivendo (a gonfie vele, come detto da Barra) GNOME3 anch'esso rimasto nel "vecchio mondo" e, di nuovo, non ci trovo niente che non vada...
Sì, da utilizzatore finale e nemmeno tanto "expert", dico che GNOME sta bene come sta, anche esteticamente :)
cionci
16-02-2010, 16:27
Secondo me la questione è:
- Gnome è strutturato bene ? Cosa si può fare per migliorarlo ?
- scrivere e mantenere un programma per Gnome è più semplice rispetto ad un programma scritto per Kde ?
- fare evolvere Gnome con un'altra struttura sarebbe più semplice ?
- Gnome è strutturato bene ? Cosa si può fare per migliorarlo ?
- scrivere e mantenere un programma per Gnome è più semplice rispetto ad un programma scritto per Kde ?
- fare evolvere Gnome con un'altra struttura sarebbe più semplice ?
masand
16-02-2010, 16:41
Secondo me la questione è:
- Gnome è strutturato bene ? Cosa si può fare per migliorarlo ?
- scrivere e mantenere un programma per Gnome è più semplice rispetto ad un programma scritto per Kde ?
- fare evolvere Gnome con un'altra struttura sarebbe più semplice ?
Ok, ma riguardo chi lo usa o chi lo programma, mantiene?
Perché, onestamente ed egoisticamente, per chi lo usa, credo vada più che bene così... :)
- Gnome è strutturato bene ? Cosa si può fare per migliorarlo ?
- scrivere e mantenere un programma per Gnome è più semplice rispetto ad un programma scritto per Kde ?
- fare evolvere Gnome con un'altra struttura sarebbe più semplice ?
Ok, ma riguardo chi lo usa o chi lo programma, mantiene?
Perché, onestamente ed egoisticamente, per chi lo usa, credo vada più che bene così... :)
cionci
16-02-2010, 16:50
Ok, ma riguardo chi lo usa o chi lo programma, mantiene?
Mantiene nel senso: chi aggiorna il programma per i cambiamenti delle librerie, chi fa bug fixing. Diciamo tutto quello che bisogna fare al programma dopo che si è rilasciato.
Mantiene nel senso: chi aggiorna il programma per i cambiamenti delle librerie, chi fa bug fixing. Diciamo tutto quello che bisogna fare al programma dopo che si è rilasciato.
masand
16-02-2010, 17:00
Mantiene nel senso: chi aggiorna il programma per i cambiamenti delle librerie, chi fa bug fixing. Diciamo tutto quello che bisogna fare al programma dopo che si è rilasciato.
Ah, ecco...
Perché altrimenti GNOME in GTK, QT o al ragù, per chi lo utilizza non è che cambi molto.
IMHO.
Ah, ecco...
Perché altrimenti GNOME in GTK, QT o al ragù, per chi lo utilizza non è che cambi molto.
IMHO.
cionci
16-02-2010, 17:04
Ah, ecco...
Perché altrimenti GNOME in GTK, QT o al ragù, per chi lo utilizza non è che cambi molto.
IMHO.
Sono d'accordo da un punto di vista pratico, ma in teoria se si perde meno tempo nello sviluppo l'utente può avere più programmi e anche qualitativamente migliori.
Perché altrimenti GNOME in GTK, QT o al ragù, per chi lo utilizza non è che cambi molto.
IMHO.
Sono d'accordo da un punto di vista pratico, ma in teoria se si perde meno tempo nello sviluppo l'utente può avere più programmi e anche qualitativamente migliori.
Dcromato
16-02-2010, 17:14
Parlo da utilizzatore perché i discorsi sulla programmazione sono più che Arabo per me.
Lo so che è maleducato rispondere con una domanda, ma... Cosa ha GNOME che non va?
Ovviamente parlo di usabilità e fruibilità. Onestamente mi ci trovo bene e se la questione GNOME QT è nata per un discorso estetico, be', è solo questione di gusti...
La questione è nata invece per un discorso di "longevità"? Be', anche qui, stanno scrivendo (a gonfie vele, come detto da Barra) GNOME3 anch'esso rimasto nel "vecchio mondo" e, di nuovo, non ci trovo niente che non vada...
Sì, da utilizzatore finale e nemmeno tanto "expert", dico che GNOME sta bene come sta, anche esteticamente :)
a me non veniva in mente per questioni estetiche, ma per questioni filosofiche e di prestazioni...le gtk sono nate nell'intento di contrastare le qt che non erano un esempio di libreria open...ora come ora non vedo il motivo di utilizzarle ancora visto che lo scopo è andato scemando.
Lo so che è maleducato rispondere con una domanda, ma... Cosa ha GNOME che non va?
Ovviamente parlo di usabilità e fruibilità. Onestamente mi ci trovo bene e se la questione GNOME QT è nata per un discorso estetico, be', è solo questione di gusti...
La questione è nata invece per un discorso di "longevità"? Be', anche qui, stanno scrivendo (a gonfie vele, come detto da Barra) GNOME3 anch'esso rimasto nel "vecchio mondo" e, di nuovo, non ci trovo niente che non vada...
Sì, da utilizzatore finale e nemmeno tanto "expert", dico che GNOME sta bene come sta, anche esteticamente :)
a me non veniva in mente per questioni estetiche, ma per questioni filosofiche e di prestazioni...le gtk sono nate nell'intento di contrastare le qt che non erano un esempio di libreria open...ora come ora non vedo il motivo di utilizzarle ancora visto che lo scopo è andato scemando.
Barra
16-02-2010, 17:24
@Cionci:
Si vede che sei uno sviluppatore :D
Leggevo qualche tempo fa la lamentela di uno dei responsabili di un progetto opensource (VtigerCRM). L'applicativo, sviluppato in PHP è ottimo e nessuno lo mette in dubbio. Però molti sviluppatori si lamentano per il codice 'sporco' (è fork di un altro crm opensource ed effettivamente il cambio di direzione ha portato ad avere un codice scritto da mani diverse e questo si vede in 1000 piccoli dettagli).
La persona in questione si chiedeva quale fosse il problema. Chi sviluppa il codice lo capisce, chi si lamenta cmq non è intenzionato a collaborare (spesso sono infatti partner di sugarcrm, principale concorrente opensource e origine del fork) e chi è interessato ad contribuire trova tutto l'aiuto necessario, quindi quale è il problema?
Ok, in futuro la cosa si sistemerà ma bisogna riuscire ad evolvere il programma (per tenersi stretti i clienti e magari portarne a casa di nuovi) mantenendo però una buona stabilità.
Voi programmatori guardate un pò troppo la 'perfezione del codice' senza pensare ai disagi che un cambio di direzione porta nella maggior parte delle persone che non si interessa a cosa c'è sotto il cofano!
Si vede che sei uno sviluppatore :D
Leggevo qualche tempo fa la lamentela di uno dei responsabili di un progetto opensource (VtigerCRM). L'applicativo, sviluppato in PHP è ottimo e nessuno lo mette in dubbio. Però molti sviluppatori si lamentano per il codice 'sporco' (è fork di un altro crm opensource ed effettivamente il cambio di direzione ha portato ad avere un codice scritto da mani diverse e questo si vede in 1000 piccoli dettagli).
La persona in questione si chiedeva quale fosse il problema. Chi sviluppa il codice lo capisce, chi si lamenta cmq non è intenzionato a collaborare (spesso sono infatti partner di sugarcrm, principale concorrente opensource e origine del fork) e chi è interessato ad contribuire trova tutto l'aiuto necessario, quindi quale è il problema?
Ok, in futuro la cosa si sistemerà ma bisogna riuscire ad evolvere il programma (per tenersi stretti i clienti e magari portarne a casa di nuovi) mantenendo però una buona stabilità.
Voi programmatori guardate un pò troppo la 'perfezione del codice' senza pensare ai disagi che un cambio di direzione porta nella maggior parte delle persone che non si interessa a cosa c'è sotto il cofano!
cionci
16-02-2010, 17:32
Voi programmatori guardate un pò troppo la 'perfezione del codice' senza pensare ai disagi che un cambio di direzione porta nella maggior parte delle persone che non si interessa a cosa c'è sotto il cofano!
Assolutamente no. I cambiamenti per l'utente devono essere indolori. Perché se per fare cambiamenti crei disagi all'utente finale allora significa che hai prodotto un programma nel complesso qualitativamente più basso.
Assolutamente no. I cambiamenti per l'utente devono essere indolori. Perché se per fare cambiamenti crei disagi all'utente finale allora significa che hai prodotto un programma nel complesso qualitativamente più basso.
Pixel452
16-02-2010, 18:45
Io personalmente ho un grosso dubbio su entrambe le librerie, qualcuo sa a che tipo di motore di rendering si appoggiano? Per dirla in soldoni, il rendering dell'UI è affidato ad un motore OpenGL o è fatto via software?
Per GTK credo che l'unica cosa facete uso di OpenGL sia Clutter, che non è molto perchè questo vuol dire che tutti i controlli con cui si interfaccia l'utente (Bottoni, liste, tab, griglie, ecc...) sono renderizzate via software, ma per QT? Che tanto vengono spacciate come innovative? Personalmente credo che la risposta a questa domanda abbia un grosso peso per capire che tipo di evoluzione possano avere le due librerie.
Per GTK credo che l'unica cosa facete uso di OpenGL sia Clutter, che non è molto perchè questo vuol dire che tutti i controlli con cui si interfaccia l'utente (Bottoni, liste, tab, griglie, ecc...) sono renderizzate via software, ma per QT? Che tanto vengono spacciate come innovative? Personalmente credo che la risposta a questa domanda abbia un grosso peso per capire che tipo di evoluzione possano avere le due librerie.
giova22
16-02-2010, 18:45
io sarei favorevole.
Sto lavorando proprio in questi giorni con le QT e mi trovo benissimo. Facili da usare e veloci nell'esecuzione del programma.
Con le GTK avevo provato ma mi ero trovato molto male.... Quindi per quanto mi riguarda... Viva le QT!:D
Sto lavorando proprio in questi giorni con le QT e mi trovo benissimo. Facili da usare e veloci nell'esecuzione del programma.
Con le GTK avevo provato ma mi ero trovato molto male.... Quindi per quanto mi riguarda... Viva le QT!:D
cionci
16-02-2010, 18:48
Io personalmente ho un grosso dubbio su entrambe le librerie, qualcuo sa a che tipo di motore di rendering si appoggiano? Per dirla in soldoni, il rendering dell'UI è affidato ad un motore OpenGL o è fatto via software?
Per GTK credo che l'unica cosa facete uso di OpenGL sia Clutter, che non è molto perchè questo vuol dire che tutti i controlli con cui si interfaccia l'utente (Bottoni, liste, tab, griglie, ecc...) sono renderizzate via software, ma per QT? Che tanto vengono spacciate come innovative? Personalmente credo che la risposta a questa domanda abbia un grosso peso per capire che tipo di evoluzione possano avere le due librerie.
Sono renderizzate via software, ma questo non dipende dalle Qt o dalle Gtk, ma dal server X.
Per GTK credo che l'unica cosa facete uso di OpenGL sia Clutter, che non è molto perchè questo vuol dire che tutti i controlli con cui si interfaccia l'utente (Bottoni, liste, tab, griglie, ecc...) sono renderizzate via software, ma per QT? Che tanto vengono spacciate come innovative? Personalmente credo che la risposta a questa domanda abbia un grosso peso per capire che tipo di evoluzione possano avere le due librerie.
Sono renderizzate via software, ma questo non dipende dalle Qt o dalle Gtk, ma dal server X.
Pixel452
16-02-2010, 18:58
Si ma se le due librerie non sono predisposte anche sistemando il Server X il problema non si risolve. Cmq Gnome non può ospitare Clutter? A questo punto perchè non usare Clutter per fare tutto? In che modo il Server X impedisce la cosa? So che è un pò OT però mi pare molto iteressante.
cionci
16-02-2010, 19:06
Si ma se le due librerie non sono predisposte anche sistemando il Server X il problema non si risolve.
Invece sì, perché se vai a vedere l'implementazione delle GTK per disegnare sullo schermo usa alcune di librerie di X. Quindi sarebbe tutto trasparente.
Su Windows credi che le applicazioni Qt o Gtk che ora vengono renderizzate su in DirectX secondo te erano predisposte ?
Invece sì, perché se vai a vedere l'implementazione delle GTK per disegnare sullo schermo usa alcune di librerie di X. Quindi sarebbe tutto trasparente.
Su Windows credi che le applicazioni Qt o Gtk che ora vengono renderizzate su in DirectX secondo te erano predisposte ?
Pixel452
16-02-2010, 19:23
Interessante, non sapevo questa cosa, in realtà non so quasi niente di GTK / QT, gli ho dato un occhiata tanto per farmi un idea ma nulla di più. Cmq per predisposizione intendevo una cosa a livello più ampio, insomma, avere a che fare con un sistema totalmente accellerato e vettoriale ti porta a fare le cose in modo differente, ad esempio quegli effetti di trasformazione che fanno spesso vedere in QT, sicuri che siano a carico del X? Oppure vengono gestite dalle QT? Perchè nel secondo caso è ovvio che il passaggio non sia trasparente, senza contare tutto il sistema delle animazioni, dipende tutto da com'è fatto. Mi viene da pensare che su questo fronte forse forse siano più avvantaggiate le gtk con Clutter.
Però qui sto proprio sparando per ipotesi perchè non ho idea di come funzionino non avendole mai provate.
Però qui sto proprio sparando per ipotesi perchè non ho idea di come funzionino non avendole mai provate.
zephyr83
16-02-2010, 19:59
Partiamo dal significato di applicativo verticale: http://it.wikipedia.org/wiki/Applicativi_verticali
Chiarito questo rileggi questo pezzo:
In questi contesti spesso è impensabile una riscrittura. Novell con una spesa molto inferiore permette il porting su osx e linux. Una volta completata la transazione anche su windows l'applicativo gira 100% mono e lo sviluppo può proseguire senza ulteriori disagi.
allora vediamo se ci capiamo! io nn ho detto che tutte le attuali applicazioni devono essere RISCRITTE in qt! voglio che le qt si diffondano cosicché vengano utilizzate fin da subito per realizzare programmi anche su windows!
Inoltre NON E' VERO che applicazioni realizzate cn .Net su windows girano senza problemi anche su linux cn mono! Se lo sviluppatore usa librerie per windows che fai? Inoltre mono nn implementa TUTTO .net, ci stanno provando ma nn è facile e ci vuole tempo.......mica TUTTO .net è stato ratificato come standard! Alla fine c'è una falsa interoperabilità, la stessa che c'è fra silverlight e moonlight....quest'ultimo arriva sempre dopo e nn integra tutte le funzioni!!!
Moblin e simili con UNR non hanno nulla a che vedere. L'idea alla base di UNR è USARE GNOME, non creare un'altro DE. Ed è proprio per questo che è la piattaforma (almeno ora) di maggiore successo tra gli OS x netbook: gli applicativi sono maturi e stabili.
No, era usare gnome perché in realtà si usva Hildon che era stato integrato in gnome :sofico: nokia per maemo ha abbandonato hildon per usare una nuova interfaccia tutta basata in qt e così sarà anche per moblin! alla fine ci gireranno anche le applicazioni in gtk come già adesso avviene su linux in ambiente KDE!!!
Chiarito questo rileggi questo pezzo:
In questi contesti spesso è impensabile una riscrittura. Novell con una spesa molto inferiore permette il porting su osx e linux. Una volta completata la transazione anche su windows l'applicativo gira 100% mono e lo sviluppo può proseguire senza ulteriori disagi.
allora vediamo se ci capiamo! io nn ho detto che tutte le attuali applicazioni devono essere RISCRITTE in qt! voglio che le qt si diffondano cosicché vengano utilizzate fin da subito per realizzare programmi anche su windows!
Inoltre NON E' VERO che applicazioni realizzate cn .Net su windows girano senza problemi anche su linux cn mono! Se lo sviluppatore usa librerie per windows che fai? Inoltre mono nn implementa TUTTO .net, ci stanno provando ma nn è facile e ci vuole tempo.......mica TUTTO .net è stato ratificato come standard! Alla fine c'è una falsa interoperabilità, la stessa che c'è fra silverlight e moonlight....quest'ultimo arriva sempre dopo e nn integra tutte le funzioni!!!
Moblin e simili con UNR non hanno nulla a che vedere. L'idea alla base di UNR è USARE GNOME, non creare un'altro DE. Ed è proprio per questo che è la piattaforma (almeno ora) di maggiore successo tra gli OS x netbook: gli applicativi sono maturi e stabili.
No, era usare gnome perché in realtà si usva Hildon che era stato integrato in gnome :sofico: nokia per maemo ha abbandonato hildon per usare una nuova interfaccia tutta basata in qt e così sarà anche per moblin! alla fine ci gireranno anche le applicazioni in gtk come già adesso avviene su linux in ambiente KDE!!!
cionci
16-02-2010, 20:02
Inoltre NON E' VERO che applicazioni realizzate cn .Net su windows girano senza problemi anche su linux cn mono! Se lo sviluppatore usa librerie per windows che fai? Inoltre mono nn implementa TUTTO .net, ci stanno provando ma nn è facile e ci vuole tempo.......mica TUTTO .net è stato ratificato come standard! Alla fine c'è una falsa interoperabilità, la stessa che c'è fra silverlight e moonlight....quest'ultimo arriva sempre dopo e nn integra tutte le funzioni!!!
Sarebbe interessate fare uno studio sulla realizzabilità delle GTK+ implementate tramite le Qt :D
Sarebbe interessate fare uno studio sulla realizzabilità delle GTK+ implementate tramite le Qt :D
zephyr83
16-02-2010, 20:10
Parlo da utilizzatore perché i discorsi sulla programmazione sono più che Arabo per me.
Lo so che è maleducato rispondere con una domanda, ma... Cosa ha GNOME che non va?
Ovviamente parlo di usabilità e fruibilità. Onestamente mi ci trovo bene e se la questione GNOME QT è nata per un discorso estetico, be', è solo questione di gusti...
La questione è nata invece per un discorso di "longevità"? Be', anche qui, stanno scrivendo (a gonfie vele, come detto da Barra) GNOME3 anch'esso rimasto nel "vecchio mondo" e, di nuovo, non ci trovo niente che non vada...
Sì, da utilizzatore finale e nemmeno tanto "expert", dico che GNOME sta bene come sta, anche esteticamente :)
il problema è che la questione come al solito si è spostata su gnome vs kde quando nn era questo il discorso! è che nn si può fare a meno di nominare gnome quando si parla di gtk :)
a quanto pare qualcosa in gnome manca visto che gli sviluppatori per le gtk stanno "diminuendo" e si sente tanto l'esigenza di mono e gtk#! Per me il discorso era più che altro un altro......sfruttare maggiormente le QT senza cercare soluzioni "altrove". A quanto pare nel mondo gnome va bene tutto purché nn siano le QT e il motivo nn l'ho mai capito (a me sembra solo campanilistico)
Lo so che è maleducato rispondere con una domanda, ma... Cosa ha GNOME che non va?
Ovviamente parlo di usabilità e fruibilità. Onestamente mi ci trovo bene e se la questione GNOME QT è nata per un discorso estetico, be', è solo questione di gusti...
La questione è nata invece per un discorso di "longevità"? Be', anche qui, stanno scrivendo (a gonfie vele, come detto da Barra) GNOME3 anch'esso rimasto nel "vecchio mondo" e, di nuovo, non ci trovo niente che non vada...
Sì, da utilizzatore finale e nemmeno tanto "expert", dico che GNOME sta bene come sta, anche esteticamente :)
il problema è che la questione come al solito si è spostata su gnome vs kde quando nn era questo il discorso! è che nn si può fare a meno di nominare gnome quando si parla di gtk :)
a quanto pare qualcosa in gnome manca visto che gli sviluppatori per le gtk stanno "diminuendo" e si sente tanto l'esigenza di mono e gtk#! Per me il discorso era più che altro un altro......sfruttare maggiormente le QT senza cercare soluzioni "altrove". A quanto pare nel mondo gnome va bene tutto purché nn siano le QT e il motivo nn l'ho mai capito (a me sembra solo campanilistico)
Barra
16-02-2010, 20:51
Inoltre NON E' VERO che applicazioni realizzate cn .Net su windows girano senza problemi anche su linux cn mono! Se lo sviluppatore usa librerie per windows che fai? Inoltre mono nn implementa TUTTO .net, ci stanno provando ma nn è facile e ci vuole tempo.......mica TUTTO .net è stato ratificato come standard!
Mi quoto:
In questi contesti spesso è impensabile una riscrittura. Novell con una spesa molto inferiore permette il porting su osx e linux. Una volta completata la transazione anche su windows l'applicativo gira 100% mono e lo sviluppo può proseguire senza ulteriori disagi.
No, era usare gnome perché in realtà si usva Hildon che era stato integrato in gnome :sofico:
Non capisco questa frase.
Tra l'altro Hildon era un'interfaccia utente ottimizzata per il touch (con tutte le conseguenze che questo porta a livello di usabilità), UNR richiede tastiera e mouse.
Che poi si senta tanto l'esigenza di GTK# e mono oggi può anche essere. E' però facile ipotizzare che gli sviluppatori gnome ci abbiano pensato e stiano cercando di porvi rimedio: non penso che sia un caso se l'intero gnome-shell è scritto in javascript e che i temi siano in formato CSS, due soluzioni estremamente diffuse, potenti e flessibili.
Appppproposito di questo: chi conosce GJS?
Mi quoto:
In questi contesti spesso è impensabile una riscrittura. Novell con una spesa molto inferiore permette il porting su osx e linux. Una volta completata la transazione anche su windows l'applicativo gira 100% mono e lo sviluppo può proseguire senza ulteriori disagi.
No, era usare gnome perché in realtà si usva Hildon che era stato integrato in gnome :sofico:
Non capisco questa frase.
Tra l'altro Hildon era un'interfaccia utente ottimizzata per il touch (con tutte le conseguenze che questo porta a livello di usabilità), UNR richiede tastiera e mouse.
Che poi si senta tanto l'esigenza di GTK# e mono oggi può anche essere. E' però facile ipotizzare che gli sviluppatori gnome ci abbiano pensato e stiano cercando di porvi rimedio: non penso che sia un caso se l'intero gnome-shell è scritto in javascript e che i temi siano in formato CSS, due soluzioni estremamente diffuse, potenti e flessibili.
Appppproposito di questo: chi conosce GJS?
zephyr83
16-02-2010, 20:55
Si ma se le due librerie non sono predisposte anche sistemando il Server X il problema non si risolve. Cmq Gnome non può ospitare Clutter? A questo punto perchè non usare Clutter per fare tutto? In che modo il Server X impedisce la cosa? So che è un pò OT però mi pare molto iteressante.
invece mi sa che sn "predisposte", almeno mi pareva che il vantaggio delle QT in ambito mobile era proprio questo. Cmq su come funzionano le qt a proposito ho trovato questo ma oltre nn so andare :D
Un toolkit che permetta lo
sviluppo di GUI multi-piattaforma, deve implementare una strategia per nascondere al programmatore i dettagli dovuti alle API native del sistema operativo sottostante.
Esistono fondamentalmente tre strategie differenti adatte allo scopo e prendono il nome di "API layering", "API emulation" e "GUI emulation".
La strategia di API layering (letteralmente stratificazione delle API),prevede la costruzione di una nuova API fornita da uno strato software che viene localizzato al di sopra della API nativa. I vantaggi offerti da questa soluzione sono una relativa semplicità di programmazione ed una totale conformità con il look&feel (aspetto estetico) nativo. Per contro lo svantaggio principale è dovuto alla lentezza dei programmi scritti, basandosi sulle nuove API; infatti lo strato software aggiuntivo va ad appesantire l?esecuzione con inevitabili rallentamenti.
La strategia di API emulation (letteralmente emulazione della API), consiste nell'emulare le API di un unico sistema su tutte le altre piattaforme. In
questo caso, non occorre innestare uno strato software al di sopra delle API native per la piattaforma emulata, occorre bensì inserirla per le altre piattaforme, diverse da quella usata come riferimento. Benché questa soluzione sembri risolvere i problemi di portabilità, in realtà è difficile da ottenere, in quanto se le piattaforme sono tra loro troppo differenti, l'uso di una API di riferimento è molto complicato da realizzare.
La terza strategia è quella adottata da Qt e consiste nell'emulare il vero comportamento di una GUI; per fare ciò, vengono usate solamente le primitive grafiche di base, offerte da ciascuna piattaforma, quali ad esempio le funzioni per tracciare un punto, una linea, un cerchio. Il vantaggio di questa soluzione è evidente, non si appesantisce l'applicazione con uno strato software aggiuntivo e neppure si devono uniformare tutte le API dei sistemi su cui garantire la portabilità.
Quindi da quello che mi pare di capire è quello che chiedeva Pixel452 no? io so che il "bello" (vantaggio) delle QT sta proprio in questo e si deve a questo l'elevata portabilità!
Qui si trovano altre informazioni "veloci" sulle qt http://www.slideshare.net/paolosereno/qt-framework
invece mi sa che sn "predisposte", almeno mi pareva che il vantaggio delle QT in ambito mobile era proprio questo. Cmq su come funzionano le qt a proposito ho trovato questo ma oltre nn so andare :D
Un toolkit che permetta lo
sviluppo di GUI multi-piattaforma, deve implementare una strategia per nascondere al programmatore i dettagli dovuti alle API native del sistema operativo sottostante.
Esistono fondamentalmente tre strategie differenti adatte allo scopo e prendono il nome di "API layering", "API emulation" e "GUI emulation".
La strategia di API layering (letteralmente stratificazione delle API),prevede la costruzione di una nuova API fornita da uno strato software che viene localizzato al di sopra della API nativa. I vantaggi offerti da questa soluzione sono una relativa semplicità di programmazione ed una totale conformità con il look&feel (aspetto estetico) nativo. Per contro lo svantaggio principale è dovuto alla lentezza dei programmi scritti, basandosi sulle nuove API; infatti lo strato software aggiuntivo va ad appesantire l?esecuzione con inevitabili rallentamenti.
La strategia di API emulation (letteralmente emulazione della API), consiste nell'emulare le API di un unico sistema su tutte le altre piattaforme. In
questo caso, non occorre innestare uno strato software al di sopra delle API native per la piattaforma emulata, occorre bensì inserirla per le altre piattaforme, diverse da quella usata come riferimento. Benché questa soluzione sembri risolvere i problemi di portabilità, in realtà è difficile da ottenere, in quanto se le piattaforme sono tra loro troppo differenti, l'uso di una API di riferimento è molto complicato da realizzare.
La terza strategia è quella adottata da Qt e consiste nell'emulare il vero comportamento di una GUI; per fare ciò, vengono usate solamente le primitive grafiche di base, offerte da ciascuna piattaforma, quali ad esempio le funzioni per tracciare un punto, una linea, un cerchio. Il vantaggio di questa soluzione è evidente, non si appesantisce l'applicazione con uno strato software aggiuntivo e neppure si devono uniformare tutte le API dei sistemi su cui garantire la portabilità.
Quindi da quello che mi pare di capire è quello che chiedeva Pixel452 no? io so che il "bello" (vantaggio) delle QT sta proprio in questo e si deve a questo l'elevata portabilità!
Qui si trovano altre informazioni "veloci" sulle qt http://www.slideshare.net/paolosereno/qt-framework
zephyr83
16-02-2010, 21:01
Mi quoto:
bho forse nn ci capiamo :) cn mono NON risolvi il problema dell'interoperabilità da windows verso linux! ovvio che il contrario funzioni :sofico:
Non capisco questa frase.
Tra l'altro Hildon era un'interfaccia utente ottimizzata per il touch (con tutte le conseguenze che questo porta a livello di usabilità), UNR richiede tastiera e mouse.
Hildon è stato integrato in Gnome e i "primi" sistemi mobile o mid si sn basati su questa interfaccia utente basata in gtk e realizzata da nokia! Ora si è abbandonata ma io nell'interfaccia remix ci vedo diversi aspetti di hildon! è sicuramente stato utile per passare poi ad altro e se nokia nn fosse passata alle QT probabilmente sarebbe stata sviluppata ulteriormente!
Che poi si senta tanto l'esigenza di GTK# e mono oggi può anche essere. E' però facile ipotizzare che gli sviluppatori gnome ci abbiano pensato e stiano cercando di porvi rimedio: non penso che sia un caso se l'intero gnome-shell è scritto in javascript e che i temi siano in formato CSS, due soluzioni estremamente diffuse, potenti e flessibili.
Appppproposito di questo: chi conosce GJS?
ma si spera, però magari gnome-shell aveva già iniziato a scriverlo prima così! Gnome-Do però è in mono e qualcuno lo avrebbe voluto vedere integrato in gnome!! però anche qui abbiamo un sistema realizzato usando diversi strumenti e diversi linguaggi........alla lunga nn rischia di essere un problema per lo sviluppo e la manutenzione? Cmq l'importante è che tengano lontano mono dal sistema base :sofico:
bho forse nn ci capiamo :) cn mono NON risolvi il problema dell'interoperabilità da windows verso linux! ovvio che il contrario funzioni :sofico:
Non capisco questa frase.
Tra l'altro Hildon era un'interfaccia utente ottimizzata per il touch (con tutte le conseguenze che questo porta a livello di usabilità), UNR richiede tastiera e mouse.
Hildon è stato integrato in Gnome e i "primi" sistemi mobile o mid si sn basati su questa interfaccia utente basata in gtk e realizzata da nokia! Ora si è abbandonata ma io nell'interfaccia remix ci vedo diversi aspetti di hildon! è sicuramente stato utile per passare poi ad altro e se nokia nn fosse passata alle QT probabilmente sarebbe stata sviluppata ulteriormente!
Che poi si senta tanto l'esigenza di GTK# e mono oggi può anche essere. E' però facile ipotizzare che gli sviluppatori gnome ci abbiano pensato e stiano cercando di porvi rimedio: non penso che sia un caso se l'intero gnome-shell è scritto in javascript e che i temi siano in formato CSS, due soluzioni estremamente diffuse, potenti e flessibili.
Appppproposito di questo: chi conosce GJS?
ma si spera, però magari gnome-shell aveva già iniziato a scriverlo prima così! Gnome-Do però è in mono e qualcuno lo avrebbe voluto vedere integrato in gnome!! però anche qui abbiamo un sistema realizzato usando diversi strumenti e diversi linguaggi........alla lunga nn rischia di essere un problema per lo sviluppo e la manutenzione? Cmq l'importante è che tengano lontano mono dal sistema base :sofico:
Barra
16-02-2010, 21:31
bho forse nn ci capiamo :) cn mono NON risolvi il problema dell'interoperabilità da windows verso linux! ovvio che il contrario funzioni :sofico:
IMHO non è affatto vero. Se tu hai un software scritto in .net che funziona, vende e lo vuoi portare su linux Mono ti viene in aiuto. Ripeto è nato x questo, non per scrivere da 0 app linux. Che poi visto che è performante, rapido e semplice da usare sia spesso preferito ad altre soluzioni questo è un'altro paio di maniche.
Ora si è abbandonata ma io nell'interfaccia remix ci vedo diversi aspetti di hildon!
Non capisco dove...
uno è una soluzione touch, l'altro no. Nascono da idee completamente diverse, con target diversi e l'unica somiglianza che ci vedo io è quella di avere una UI sul desktop (come Android, Iphone, WM ecc)
ma si spera, però magari gnome-shell aveva già iniziato a scriverlo prima così! Gnome-Do però è in mono e qualcuno lo avrebbe voluto vedere integrato in gnome!! però anche qui abbiamo un sistema realizzato usando diversi strumenti e diversi linguaggi........alla lunga nn rischia di essere un problema per lo sviluppo e la manutenzione? Cmq l'importante è che tengano lontano mono dal sistema base :sofico:
io sono uno di quelli che spera in un gnome-do integrato in gnome-shell. Magari si ci arriverà con una riscrittura in Javascript che utilizzi le api di zeitgeist e tracker ma ne trovo geniali le funzionalità.
L'idea era cmq rendere Gnome-do parte delle librerie alla base di gnome3 per poterne utilizzare le funzionalità all'interno dei vari programmi. Pensa in oOo invece che cercare l'opzione nei vari menu ne scrivi il nome. In GIMP scrivi "scala" (anche solo in parte visto che il sistema ti propone l'opzione più probabile), premi tab, scrivi 800 e premi invio, lui ti scala l'immagine mantenendone le proporzioni. IMHO GENIALE!!!
IMHO non è affatto vero. Se tu hai un software scritto in .net che funziona, vende e lo vuoi portare su linux Mono ti viene in aiuto. Ripeto è nato x questo, non per scrivere da 0 app linux. Che poi visto che è performante, rapido e semplice da usare sia spesso preferito ad altre soluzioni questo è un'altro paio di maniche.
Ora si è abbandonata ma io nell'interfaccia remix ci vedo diversi aspetti di hildon!
Non capisco dove...
uno è una soluzione touch, l'altro no. Nascono da idee completamente diverse, con target diversi e l'unica somiglianza che ci vedo io è quella di avere una UI sul desktop (come Android, Iphone, WM ecc)
ma si spera, però magari gnome-shell aveva già iniziato a scriverlo prima così! Gnome-Do però è in mono e qualcuno lo avrebbe voluto vedere integrato in gnome!! però anche qui abbiamo un sistema realizzato usando diversi strumenti e diversi linguaggi........alla lunga nn rischia di essere un problema per lo sviluppo e la manutenzione? Cmq l'importante è che tengano lontano mono dal sistema base :sofico:
io sono uno di quelli che spera in un gnome-do integrato in gnome-shell. Magari si ci arriverà con una riscrittura in Javascript che utilizzi le api di zeitgeist e tracker ma ne trovo geniali le funzionalità.
L'idea era cmq rendere Gnome-do parte delle librerie alla base di gnome3 per poterne utilizzare le funzionalità all'interno dei vari programmi. Pensa in oOo invece che cercare l'opzione nei vari menu ne scrivi il nome. In GIMP scrivi "scala" (anche solo in parte visto che il sistema ti propone l'opzione più probabile), premi tab, scrivi 800 e premi invio, lui ti scala l'immagine mantenendone le proporzioni. IMHO GENIALE!!!
Pixel452
16-02-2010, 22:25
invece mi sa che sn "predisposte", almeno mi pareva che il vantaggio delle QT in ambito mobile era proprio questo. Cmq su come funzionano le qt a proposito ho trovato questo ma oltre nn so andare :D
Quindi da quello che mi pare di capire è quello che chiedeva Pixel452 no? io so che il "bello" (vantaggio) delle QT sta proprio in questo e si deve a questo l'elevata portabilità!
Qui si trovano altre informazioni "veloci" sulle qt http://www.slideshare.net/paolosereno/qt-framework
No, non è quello che chiedevo io.
Per quanto mi riguarda, possibilità aperte da Clutter a parte, che è l'unica cosa che si salva di gtk le qt mi sembrano migliori, ma ribadisco che ho solo dato un occhiatina, cmq motivo la mia opinione temporanea.
Come prima cosa trovo ridicolo che nel 2010 si scrivano programmi utente in C, non c'è motivo per non usare C++, a parte la pigrizia degli sviluppatori e di alcuni individui che sono convinti che sia più difficile. La programmazione ad oggetti porta troppi vantaggi ed aumenta brutalmente la produttività. Sto escludendo il porting delle applicazioni perchè le GTK dovevano svegliarsi anni ed anni fa a fare il passaggio da C a C++ come ha fatto il resto del mondo.
Un altra cosa molto importante sono gli ambienti di sviluppo, QCreator è molto ben fatto, molto ben integrato ed ha un buon intellisense, oltre che avere un ottima integrazione con la documentazione. Su questo discorso spezzo una lancia a favore di cionci, avere 30 librerie per coprire tutto il necessario per scrivere un programma al posto di un Framework ben fatto che ti da tutto il necessario è un autentica Ca*****a, non tiriamo in ballo questioni di libertà o cose tipo “è il bello dell'open source”, pechè se vuoi, usi un altra libreria, se no usi quella che c’è. non avere questa integrazione porta solo a disorganizzazione generale, codice orripilante, bug, lentezza nello sviluppo. Provate a passare qualche ora a capire perché il vostro programma si pianta dopo l’aggiornamento di qualche libreria esterna o dover gestire chissà quante dipendenze; senza contare lo star up, quando cominci e non sai niente diventa uno strazio scegliere una libreria da usare tra 20 che fanno la stessa cosa, con sei che sono deprecate e non lo sai, senza documentazione, senza esempi. Tutto questo è puro caos e puoi assecondarlo solo se: non sei un programmatore, sei un fanatico.
Le gtk sono troppo conservative, in linux c’è la possibilità di fare rilasci molto più frequenti, questo vuol dire: avere molte più occasioni per sviluppare cose innovative, avere molte più occasioni per rimediare alle cazzate :-D. Senza contare che le nuove funzionalità puoi farle convivere con le vecchie. Le gtk a me sembrano vecchie nell’anima e questo in informatica è una pessima cosa, ma qui io sono fissato, adoro le innovazioni anche a scapito delle ire degli utenti. Direi che per ora basta anche se si potrebbe andare avanti all’infinito.
p.s. vi faccio un esempio, io generalmente per la grafica 3D uso DirectX(beh è da molto che non le uso più), una volta mi sono messo a provare le openGL, già non sono ad oggetti e mi sono venuti i brividi cmq, sono arrivato a dover caricare una Texture (un immagine) beh, nelle DirectX la cosa consisteva a chiamare una funzione delle librerie, in openGL non c'era niente gtk style, vari tutorial consigliavano librerie di terze parti che poi si scoprivano deprecate e magari supportavano solo una parte di formati di immagini. Potete ben immaginare che le OpenGL hanno fatto il volo dalla finestra, non è possibile che per fare una banalità simile un programmatore sia costretto a peredere tutto questo tempo. Ovviamente non vuole essere un discorso sulle OpenGL che poi sicuramente ci sono Framework che integrano queste funzionalità, ma è solo un aneddoto per far capire meglio che questo problema è veramente una seccatura e per un prodotto della portata di gtk non è accettabile, almeno da parte del sottoscritto.
Quindi da quello che mi pare di capire è quello che chiedeva Pixel452 no? io so che il "bello" (vantaggio) delle QT sta proprio in questo e si deve a questo l'elevata portabilità!
Qui si trovano altre informazioni "veloci" sulle qt http://www.slideshare.net/paolosereno/qt-framework
No, non è quello che chiedevo io.
Per quanto mi riguarda, possibilità aperte da Clutter a parte, che è l'unica cosa che si salva di gtk le qt mi sembrano migliori, ma ribadisco che ho solo dato un occhiatina, cmq motivo la mia opinione temporanea.
Come prima cosa trovo ridicolo che nel 2010 si scrivano programmi utente in C, non c'è motivo per non usare C++, a parte la pigrizia degli sviluppatori e di alcuni individui che sono convinti che sia più difficile. La programmazione ad oggetti porta troppi vantaggi ed aumenta brutalmente la produttività. Sto escludendo il porting delle applicazioni perchè le GTK dovevano svegliarsi anni ed anni fa a fare il passaggio da C a C++ come ha fatto il resto del mondo.
Un altra cosa molto importante sono gli ambienti di sviluppo, QCreator è molto ben fatto, molto ben integrato ed ha un buon intellisense, oltre che avere un ottima integrazione con la documentazione. Su questo discorso spezzo una lancia a favore di cionci, avere 30 librerie per coprire tutto il necessario per scrivere un programma al posto di un Framework ben fatto che ti da tutto il necessario è un autentica Ca*****a, non tiriamo in ballo questioni di libertà o cose tipo “è il bello dell'open source”, pechè se vuoi, usi un altra libreria, se no usi quella che c’è. non avere questa integrazione porta solo a disorganizzazione generale, codice orripilante, bug, lentezza nello sviluppo. Provate a passare qualche ora a capire perché il vostro programma si pianta dopo l’aggiornamento di qualche libreria esterna o dover gestire chissà quante dipendenze; senza contare lo star up, quando cominci e non sai niente diventa uno strazio scegliere una libreria da usare tra 20 che fanno la stessa cosa, con sei che sono deprecate e non lo sai, senza documentazione, senza esempi. Tutto questo è puro caos e puoi assecondarlo solo se: non sei un programmatore, sei un fanatico.
Le gtk sono troppo conservative, in linux c’è la possibilità di fare rilasci molto più frequenti, questo vuol dire: avere molte più occasioni per sviluppare cose innovative, avere molte più occasioni per rimediare alle cazzate :-D. Senza contare che le nuove funzionalità puoi farle convivere con le vecchie. Le gtk a me sembrano vecchie nell’anima e questo in informatica è una pessima cosa, ma qui io sono fissato, adoro le innovazioni anche a scapito delle ire degli utenti. Direi che per ora basta anche se si potrebbe andare avanti all’infinito.
p.s. vi faccio un esempio, io generalmente per la grafica 3D uso DirectX(beh è da molto che non le uso più), una volta mi sono messo a provare le openGL, già non sono ad oggetti e mi sono venuti i brividi cmq, sono arrivato a dover caricare una Texture (un immagine) beh, nelle DirectX la cosa consisteva a chiamare una funzione delle librerie, in openGL non c'era niente gtk style, vari tutorial consigliavano librerie di terze parti che poi si scoprivano deprecate e magari supportavano solo una parte di formati di immagini. Potete ben immaginare che le OpenGL hanno fatto il volo dalla finestra, non è possibile che per fare una banalità simile un programmatore sia costretto a peredere tutto questo tempo. Ovviamente non vuole essere un discorso sulle OpenGL che poi sicuramente ci sono Framework che integrano queste funzionalità, ma è solo un aneddoto per far capire meglio che questo problema è veramente una seccatura e per un prodotto della portata di gtk non è accettabile, almeno da parte del sottoscritto.
javaboy
17-02-2010, 00:04
Sto lavorando in un grosso progetto c++. Utilizziamo oltre alle opengl una decina di librerie che avremmo potuto rimpiazzare con qt. Abbiamo problemi con la documentazione delle librerie, problemi con le versioni delle varie librerie, problemi a far funzionare le diverse librerie su diverse piattaforme, problemi nella manutenzione del codice, problemi di produttività di ogni genere.
Non so se sia conveniente o meno riscrivere gnome con le qt ma dovessi scrivere una nuova applicazione da zero non userei le gtk al posto di qt neanche se mi puntassero una pistola alla tempia.
Usare una libreria al posto di 10 cambia la vita.
Non so se sia conveniente o meno riscrivere gnome con le qt ma dovessi scrivere una nuova applicazione da zero non userei le gtk al posto di qt neanche se mi puntassero una pistola alla tempia.
Usare una libreria al posto di 10 cambia la vita.
cionci
17-02-2010, 09:20
invece mi sa che sn "predisposte", almeno mi pareva che il vantaggio delle QT in ambito mobile era proprio questo. Cmq su come funzionano le qt a proposito ho trovato questo ma oltre nn so andare :D
Quindi da quello che mi pare di capire è quello che chiedeva Pixel452 no? io so che il "bello" (vantaggio) delle QT sta proprio in questo e si deve a questo l'elevata portabilità!
Qui si trovano altre informazioni "veloci" sulle qt http://www.slideshare.net/paolosereno/qt-framework
Prima o poi le primitive di base per tracciare linee, punti etcetc devono essere usate. Magari GTK+ ha passaggi da altre librerie, non ne ho idea. Sta di fatto che se le librerie di base vengono riadattate per un ambiante grafico 3D (vedi Windows), entrambe funzioneranno senza problemi.
I post di Javaboy e Pixel452 rispecchiano esattamente il mio pensiero, non a caso sono programmatori. Non per tirarmela, ma chi può dare un giudizio se le GTK (e le varie librerie che si porta dietro) e le Qt sono una migliore dell'altra sono solo i programmatori.
Quindi da quello che mi pare di capire è quello che chiedeva Pixel452 no? io so che il "bello" (vantaggio) delle QT sta proprio in questo e si deve a questo l'elevata portabilità!
Qui si trovano altre informazioni "veloci" sulle qt http://www.slideshare.net/paolosereno/qt-framework
Prima o poi le primitive di base per tracciare linee, punti etcetc devono essere usate. Magari GTK+ ha passaggi da altre librerie, non ne ho idea. Sta di fatto che se le librerie di base vengono riadattate per un ambiante grafico 3D (vedi Windows), entrambe funzioneranno senza problemi.
I post di Javaboy e Pixel452 rispecchiano esattamente il mio pensiero, non a caso sono programmatori. Non per tirarmela, ma chi può dare un giudizio se le GTK (e le varie librerie che si porta dietro) e le Qt sono una migliore dell'altra sono solo i programmatori.
zephyr83
17-02-2010, 19:39
IMHO non è affatto vero. Se tu hai un software scritto in .net che funziona, vende e lo vuoi portare su linux Mono ti viene in aiuto. Ripeto è nato x questo, non per scrivere da 0 app linux. Che poi visto che è performante, rapido e semplice da usare sia spesso preferito ad altre soluzioni questo è un'altro paio di maniche.
performante è tutto da vedere :D i programmi in mono mi sembrano tutto tranne che performanenti. Se tu hai un software in .net e o vuoi portare su linux ma devi cmq aggiustarlo allora l'interoperabilità va a farsi benedire! senza cosniderare che .net è molto più completo di mono e sicuramente molti usaranno librerie di windows. Era meglio incentivare l'uso di strumenti davvero crossplatform come QT!
io sono uno di quelli che spera in un gnome-do integrato in gnome-shell. Magari si ci arriverà con una riscrittura in Javascript che utilizzi le api di zeitgeist e tracker ma ne trovo geniali le funzionalità.
L'idea era cmq rendere Gnome-do parte delle librerie alla base di gnome3 per poterne utilizzare le funzionalità all'interno dei vari programmi. Pensa in oOo invece che cercare l'opzione nei vari menu ne scrivi il nome. In GIMP scrivi "scala" (anche solo in parte visto che il sistema ti propone l'opzione più probabile), premi tab, scrivi 800 e premi invio, lui ti scala l'immagine mantenendone le proporzioni. IMHO GENIALE!!!
cioè stai dicendo di riscrivere gnome-do cn un altro linguaggio :sofico:
performante è tutto da vedere :D i programmi in mono mi sembrano tutto tranne che performanenti. Se tu hai un software in .net e o vuoi portare su linux ma devi cmq aggiustarlo allora l'interoperabilità va a farsi benedire! senza cosniderare che .net è molto più completo di mono e sicuramente molti usaranno librerie di windows. Era meglio incentivare l'uso di strumenti davvero crossplatform come QT!
io sono uno di quelli che spera in un gnome-do integrato in gnome-shell. Magari si ci arriverà con una riscrittura in Javascript che utilizzi le api di zeitgeist e tracker ma ne trovo geniali le funzionalità.
L'idea era cmq rendere Gnome-do parte delle librerie alla base di gnome3 per poterne utilizzare le funzionalità all'interno dei vari programmi. Pensa in oOo invece che cercare l'opzione nei vari menu ne scrivi il nome. In GIMP scrivi "scala" (anche solo in parte visto che il sistema ti propone l'opzione più probabile), premi tab, scrivi 800 e premi invio, lui ti scala l'immagine mantenendone le proporzioni. IMHO GENIALE!!!
cioè stai dicendo di riscrivere gnome-do cn un altro linguaggio :sofico:
cionci
17-02-2010, 19:57
Se ti dico che una cosa del genere si può fare senza grossi problemi con le Qt ci credi ?
Prima di tutto le Qt supportano già un linguaggio di scripting, secondo basterebbe raccogliere tutte le azioni dei menu in un vettore associativo (testo->azione del menu), una volta individuata l'azione basta eseguire il metodo triggered su di essa. Inoltre le Qt hanno già un motore di autocompletamento :yeah:
Prima di tutto le Qt supportano già un linguaggio di scripting, secondo basterebbe raccogliere tutte le azioni dei menu in un vettore associativo (testo->azione del menu), una volta individuata l'azione basta eseguire il metodo triggered su di essa. Inoltre le Qt hanno già un motore di autocompletamento :yeah:
zephyr83
17-02-2010, 20:02
Se ti dico che una cosa del genere si può fare senza grossi problemi con le Qt ci credi ?
Prima di tutto le Qt supportano già un linguaggio di scripting, secondo basterebbe raccogliere tutte le azioni dei menu in un vettore associativo (testo->azione del menu), una volta individuata l'azione basta eseguire il metodo triggered su di essa. Inoltre le Qt hanno già un motore di autocompletamento :yeah:
speriamo che cn nokia il toolkit qt si diffonda molto di più, magari anche sotto windows e osx :sofico: se riesco a finire la mia università mi sa che dedicherò un bel po' di tempo per iniziare a programmare usando le qt :)
Prima di tutto le Qt supportano già un linguaggio di scripting, secondo basterebbe raccogliere tutte le azioni dei menu in un vettore associativo (testo->azione del menu), una volta individuata l'azione basta eseguire il metodo triggered su di essa. Inoltre le Qt hanno già un motore di autocompletamento :yeah:
speriamo che cn nokia il toolkit qt si diffonda molto di più, magari anche sotto windows e osx :sofico: se riesco a finire la mia università mi sa che dedicherò un bel po' di tempo per iniziare a programmare usando le qt :)
masand
17-02-2010, 20:08
Prima o poi le primitive di base per tracciare linee, punti etcetc devono essere usate. Magari GTK+ ha passaggi da altre librerie, non ne ho idea. Sta di fatto che se le librerie di base vengono riadattate per un ambiante grafico 3D (vedi Windows), entrambe funzioneranno senza problemi.
I post di Javaboy e Pixel452 rispecchiano esattamente il mio pensiero, non a caso sono programmatori. Non per tirarmela, ma chi può dare un giudizio se le GTK (e le varie librerie che si porta dietro) e le Qt sono una migliore dell'altra sono solo i programmatori.
Ah, be', su questo non ci piove... ;)
I post di Javaboy e Pixel452 rispecchiano esattamente il mio pensiero, non a caso sono programmatori. Non per tirarmela, ma chi può dare un giudizio se le GTK (e le varie librerie che si porta dietro) e le Qt sono una migliore dell'altra sono solo i programmatori.
Ah, be', su questo non ci piove... ;)
sonnet
18-02-2010, 10:11
Premesso che per me riscrivere Gnome su qt sarebbe stata la scelta migliore sia per gli utenti linux che per gli sviluppatori gnome, che senso ha parlarne ora?
Questa possibilita' fu ventilata nell'estate 2008 da Shuttleworth , alla fine non se ne e' piu' fatto nulla e non se ne fara' nulla, visto che fra pochi mesi rilasceranno Gnome 3.0 in gtk+.
Questa possibilita' fu ventilata nell'estate 2008 da Shuttleworth , alla fine non se ne e' piu' fatto nulla e non se ne fara' nulla, visto che fra pochi mesi rilasceranno Gnome 3.0 in gtk+.
Dcromato
18-02-2010, 11:34
Premesso che per me riscrivere Gnome su qt sarebbe stata la scelta migliore sia per gli utenti linux che per gli sviluppatori gnome, che senso ha parlarne ora?
Questa possibilita' fu ventilata nell'estate 2008 da Shuttleworth , alla fine non se ne e' piu' fatto nulla e non se ne fara' nulla, visto che fra pochi mesi rilasceranno Gnome 3.0 in gtk+.
Si ma io ho aperto un sondaggio per sapere se piaceva l'idea, non è che poi decido io....:sofico:
Questa possibilita' fu ventilata nell'estate 2008 da Shuttleworth , alla fine non se ne e' piu' fatto nulla e non se ne fara' nulla, visto che fra pochi mesi rilasceranno Gnome 3.0 in gtk+.
Si ma io ho aperto un sondaggio per sapere se piaceva l'idea, non è che poi decido io....:sofico:
sonnet
18-02-2010, 12:09
Si ma io ho aperto un sondaggio per sapere se piaceva l'idea, non è che poi decido io....:sofico:
Ah ok, la mia non era una critica, era solo un appunto perche' non capivo il senso del thread. Cmq anche nel 2008 quando se ne parlava, non ho mai pensato potessero farlo. Purtroppo la maggior parte delle persone sono testarde e preferiscono perseverare nell'errore piuttosto che ammettere l'errore stesso e cambiare.
Progettare Gnome in qt avrebbe voluto dire che le qt sono librerie migliori e piu' complete per svilupparci un DE intorno. Avrebbe voluto dire:"ehi ragazzi finora abbiamo usato le gtk solo per motivi di licenza, cioe' le qt sono sempre state le migliori, ma non potevamo dirlo prima perche' sviluppavamo su gtk..".
Oltre al fatto, che dietro questa malsana scelta di perseverare sulle gtk ci sia l'ombra della politica di alcune grandi compagnie.
Gnome e gtk+, come molti grandi progetti OS vanno avanti con i contributi delle grosse compagnie. Molte di esse (vedi Google) hanno interessi opposti a quelli di Nokia che ora ha in mano lo sviluppo delle qt.
Ah ok, la mia non era una critica, era solo un appunto perche' non capivo il senso del thread. Cmq anche nel 2008 quando se ne parlava, non ho mai pensato potessero farlo. Purtroppo la maggior parte delle persone sono testarde e preferiscono perseverare nell'errore piuttosto che ammettere l'errore stesso e cambiare.
Progettare Gnome in qt avrebbe voluto dire che le qt sono librerie migliori e piu' complete per svilupparci un DE intorno. Avrebbe voluto dire:"ehi ragazzi finora abbiamo usato le gtk solo per motivi di licenza, cioe' le qt sono sempre state le migliori, ma non potevamo dirlo prima perche' sviluppavamo su gtk..".
Oltre al fatto, che dietro questa malsana scelta di perseverare sulle gtk ci sia l'ombra della politica di alcune grandi compagnie.
Gnome e gtk+, come molti grandi progetti OS vanno avanti con i contributi delle grosse compagnie. Molte di esse (vedi Google) hanno interessi opposti a quelli di Nokia che ora ha in mano lo sviluppo delle qt.
cionci
18-02-2010, 18:02
Ah ok, la mia non era una critica, era solo un appunto perche' non capivo il senso del thread. Cmq anche nel 2008 quando se ne parlava, non ho mai pensato potessero farlo. Purtroppo la maggior parte delle persone sono testarde e preferiscono perseverare nell'errore piuttosto che ammettere l'errore stesso e cambiare.
Progettare Gnome in qt avrebbe voluto dire che le qt sono librerie migliori e piu' complete per svilupparci un DE intorno. Avrebbe voluto dire:"ehi ragazzi finora abbiamo usato le gtk solo per motivi di licenza, cioe' le qt sono sempre state le migliori, ma non potevamo dirlo prima perche' sviluppavamo su gtk..".
Oltre al fatto, che dietro questa malsana scelta di perseverare sulle gtk ci sia l'ombra della politica di alcune grandi compagnie.
Gnome e gtk+, come molti grandi progetti OS vanno avanti con i contributi delle grosse compagnie. Molte di esse (vedi Google) hanno interessi opposti a quelli di Nokia che ora ha in mano lo sviluppo delle qt.
Concordo in toto su questa analisi...soprattutto per quanto riguarda gli interessi.
Progettare Gnome in qt avrebbe voluto dire che le qt sono librerie migliori e piu' complete per svilupparci un DE intorno. Avrebbe voluto dire:"ehi ragazzi finora abbiamo usato le gtk solo per motivi di licenza, cioe' le qt sono sempre state le migliori, ma non potevamo dirlo prima perche' sviluppavamo su gtk..".
Oltre al fatto, che dietro questa malsana scelta di perseverare sulle gtk ci sia l'ombra della politica di alcune grandi compagnie.
Gnome e gtk+, come molti grandi progetti OS vanno avanti con i contributi delle grosse compagnie. Molte di esse (vedi Google) hanno interessi opposti a quelli di Nokia che ora ha in mano lo sviluppo delle qt.
Concordo in toto su questa analisi...soprattutto per quanto riguarda gli interessi.
cionci
18-02-2010, 19:51
io sono uno di quelli che spera in un gnome-do integrato in gnome-shell. Magari si ci arriverà con una riscrittura in Javascript che utilizzi le api di zeitgeist e tracker ma ne trovo geniali le funzionalità.
L'idea era cmq rendere Gnome-do parte delle librerie alla base di gnome3 per poterne utilizzare le funzionalità all'interno dei vari programmi. Pensa in oOo invece che cercare l'opzione nei vari menu ne scrivi il nome. In GIMP scrivi "scala" (anche solo in parte visto che il sistema ti propone l'opzione più probabile), premi tab, scrivi 800 e premi invio, lui ti scala l'immagine mantenendone le proporzioni. IMHO GENIALE!!!
Se ti dico che una cosa del genere si può fare senza grossi problemi con le Qt ci credi ?
Prima di tutto le Qt supportano già un linguaggio di scripting, secondo basterebbe raccogliere tutte le azioni dei menu in un vettore associativo (testo->azione del menu), una volta individuata l'azione basta eseguire il metodo triggered su di essa. Inoltre le Qt hanno già un motore di autocompletamento :yeah:
#include "mainwindow.h"
#include "ui_mainwindow.h"
#include <QCompleter>
#include <QFileDialog>
MainWindow::MainWindow(QWidget *parent)
: QMainWindow(parent), ui(new Ui::MainWindow)
{
ui->setupUi(this);
ui->mainToolBar->addWidget(ui->label);
ui->mainToolBar->addWidget(ui->lineEdit);
setCentralWidget(ui->plainTextEdit);
buildActionMap(ui->menuFile);
buildActionMap(ui->menuModifica);
QCompleter * completer = new QCompleter(actionMap.keys(), this);
completer->setCaseSensitivity(Qt::CaseInsensitive);
ui->lineEdit->setCompleter(completer);
}
void MainWindow::buildActionMap(QMenu * menu)
{
QList<QAction *> actions = menu->actions();
QList<QAction *>::const_iterator it = actions.begin();
for(; it != actions.end(); it++)
{
actionMap.insert((*it)->text(), *it);
}
}
void MainWindow::on_lineEdit_returnPressed()
{
if(actionMap.contains(ui->lineEdit->text()))
{
actionMap[ui->lineEdit->text()]->activate(QAction::Trigger);
}
}
void MainWindow::on_lineEdit_textChanged(QString )
{
QPalette pal;
if(actionMap.contains(ui->lineEdit->text()))
{
pal.setColor(QPalette::Text, Qt::darkGreen);
}
else
{
pal.setColor(QPalette::Text, Qt::red);
}
ui->lineEdit->setPalette(pal);
}
Risolto in 30 linee. C'è anche la finezza del cambio di colore del testo (verde quando la parola c'è, rosso quando non c'è).
Per il progetto: http://www.megaupload.com/?d=SQ7QG7EW
PS: c'è un memory leak, le azioni in realtà non fanno quello che c'è scritto, sono solo dei place holder, però quello che fa dal menu lo fa anche dalla text box.
PPS: credo che si possa ricostruire tutto il menu a partire dalla menu bar, questo implicherebbe poter aggiungere togliere menu a piacimento mantenendo l'autocompletamento. Ora come ora l'autocompletamento viene mantenuto solo sul menu File e sul menu Modifica, però si possono togliere ed aggiungere elementi a piacere al menu (dal form editor ovviamente) e l'autompletamento viene mantenuto.
L'idea era cmq rendere Gnome-do parte delle librerie alla base di gnome3 per poterne utilizzare le funzionalità all'interno dei vari programmi. Pensa in oOo invece che cercare l'opzione nei vari menu ne scrivi il nome. In GIMP scrivi "scala" (anche solo in parte visto che il sistema ti propone l'opzione più probabile), premi tab, scrivi 800 e premi invio, lui ti scala l'immagine mantenendone le proporzioni. IMHO GENIALE!!!
Se ti dico che una cosa del genere si può fare senza grossi problemi con le Qt ci credi ?
Prima di tutto le Qt supportano già un linguaggio di scripting, secondo basterebbe raccogliere tutte le azioni dei menu in un vettore associativo (testo->azione del menu), una volta individuata l'azione basta eseguire il metodo triggered su di essa. Inoltre le Qt hanno già un motore di autocompletamento :yeah:
#include "mainwindow.h"
#include "ui_mainwindow.h"
#include <QCompleter>
#include <QFileDialog>
MainWindow::MainWindow(QWidget *parent)
: QMainWindow(parent), ui(new Ui::MainWindow)
{
ui->setupUi(this);
ui->mainToolBar->addWidget(ui->label);
ui->mainToolBar->addWidget(ui->lineEdit);
setCentralWidget(ui->plainTextEdit);
buildActionMap(ui->menuFile);
buildActionMap(ui->menuModifica);
QCompleter * completer = new QCompleter(actionMap.keys(), this);
completer->setCaseSensitivity(Qt::CaseInsensitive);
ui->lineEdit->setCompleter(completer);
}
void MainWindow::buildActionMap(QMenu * menu)
{
QList<QAction *> actions = menu->actions();
QList<QAction *>::const_iterator it = actions.begin();
for(; it != actions.end(); it++)
{
actionMap.insert((*it)->text(), *it);
}
}
void MainWindow::on_lineEdit_returnPressed()
{
if(actionMap.contains(ui->lineEdit->text()))
{
actionMap[ui->lineEdit->text()]->activate(QAction::Trigger);
}
}
void MainWindow::on_lineEdit_textChanged(QString )
{
QPalette pal;
if(actionMap.contains(ui->lineEdit->text()))
{
pal.setColor(QPalette::Text, Qt::darkGreen);
}
else
{
pal.setColor(QPalette::Text, Qt::red);
}
ui->lineEdit->setPalette(pal);
}
Risolto in 30 linee. C'è anche la finezza del cambio di colore del testo (verde quando la parola c'è, rosso quando non c'è).
Per il progetto: http://www.megaupload.com/?d=SQ7QG7EW
PS: c'è un memory leak, le azioni in realtà non fanno quello che c'è scritto, sono solo dei place holder, però quello che fa dal menu lo fa anche dalla text box.
PPS: credo che si possa ricostruire tutto il menu a partire dalla menu bar, questo implicherebbe poter aggiungere togliere menu a piacimento mantenendo l'autocompletamento. Ora come ora l'autocompletamento viene mantenuto solo sul menu File e sul menu Modifica, però si possono togliere ed aggiungere elementi a piacere al menu (dal form editor ovviamente) e l'autompletamento viene mantenuto.
_Reve_
20-02-2010, 16:34
Ah ok, la mia non era una critica, era solo un appunto perche' non capivo il senso del thread. Cmq anche nel 2008 quando se ne parlava, non ho mai pensato potessero farlo. Purtroppo la maggior parte delle persone sono testarde e preferiscono perseverare nell'errore piuttosto che ammettere l'errore stesso e cambiare.
Progettare Gnome in qt avrebbe voluto dire che le qt sono librerie migliori e piu' complete per svilupparci un DE intorno. Avrebbe voluto dire:"ehi ragazzi finora abbiamo usato le gtk solo per motivi di licenza, cioe' le qt sono sempre state le migliori, ma non potevamo dirlo prima perche' sviluppavamo su gtk..".
Oltre al fatto, che dietro questa malsana scelta di perseverare sulle gtk ci sia l'ombra della politica di alcune grandi compagnie.
Gnome e gtk+, come molti grandi progetti OS vanno avanti con i contributi delle grosse compagnie. Molte di esse (vedi Google) hanno interessi opposti a quelli di Nokia che ora ha in mano lo sviluppo delle qt.
o forse semplicemente è una questione di gusti...c'è chi preferisce usare c al posto di c++ (come il sottoscritto)...se le qt saranno davvero questa grande rivoluzione, ben venga ma adesso non si può certo dire che i programmatori di gnome siano solo testardi....e poi mi chiedo, che errore? le gtk stanno puntando a quello che vogliono arrivare....non hanno mai ammesso di aver fallito perchè così non è stato....
se proprio vogliamo cercare chi, in questi anni, ha cercato (invano) di "tenersi" gli utenti, quello è proprio kde che, nonostante basato su qt, non riesce a trovare un elevato consenso da parte degli utenti...
e non venitemi a dire che è colpa del fatto che ubuntu installi di default gnome perchè si sa che esiste anche la controparte con kde...
attualmente, gnome ne esce vincitore anche se basato sulle gtk...quindi dove hanno sbagliato?
ciao :Prrr:
Progettare Gnome in qt avrebbe voluto dire che le qt sono librerie migliori e piu' complete per svilupparci un DE intorno. Avrebbe voluto dire:"ehi ragazzi finora abbiamo usato le gtk solo per motivi di licenza, cioe' le qt sono sempre state le migliori, ma non potevamo dirlo prima perche' sviluppavamo su gtk..".
Oltre al fatto, che dietro questa malsana scelta di perseverare sulle gtk ci sia l'ombra della politica di alcune grandi compagnie.
Gnome e gtk+, come molti grandi progetti OS vanno avanti con i contributi delle grosse compagnie. Molte di esse (vedi Google) hanno interessi opposti a quelli di Nokia che ora ha in mano lo sviluppo delle qt.
o forse semplicemente è una questione di gusti...c'è chi preferisce usare c al posto di c++ (come il sottoscritto)...se le qt saranno davvero questa grande rivoluzione, ben venga ma adesso non si può certo dire che i programmatori di gnome siano solo testardi....e poi mi chiedo, che errore? le gtk stanno puntando a quello che vogliono arrivare....non hanno mai ammesso di aver fallito perchè così non è stato....
se proprio vogliamo cercare chi, in questi anni, ha cercato (invano) di "tenersi" gli utenti, quello è proprio kde che, nonostante basato su qt, non riesce a trovare un elevato consenso da parte degli utenti...
e non venitemi a dire che è colpa del fatto che ubuntu installi di default gnome perchè si sa che esiste anche la controparte con kde...
attualmente, gnome ne esce vincitore anche se basato sulle gtk...quindi dove hanno sbagliato?
ciao :Prrr:
cionci
20-02-2010, 16:40
attualmente, gnome ne esce vincitore anche se basato sulle gtk...quindi dove hanno sbagliato?
E' questa che è la cosa bella, se nonostante questo riesce a stare davanti a KDE, non mi immagino cosa possa se lo riscrivessero basato sulle QT :D
Ci sarà qualche motivo per cui su Gnome si stanno sviluppando a dismisura Python e Mono e non viene usata la piattaforma di sviluppo principale di Gnome ? Evidentemente c'è qualcosa che non va nelle piattaforma principale di sviluppo.
E' questa che è la cosa bella, se nonostante questo riesce a stare davanti a KDE, non mi immagino cosa possa se lo riscrivessero basato sulle QT :D
Ci sarà qualche motivo per cui su Gnome si stanno sviluppando a dismisura Python e Mono e non viene usata la piattaforma di sviluppo principale di Gnome ? Evidentemente c'è qualcosa che non va nelle piattaforma principale di sviluppo.
Pixel452
20-02-2010, 17:04
Non sono d’accordo, un conto è cosa fai con gli strumenti che hai a disposizione, un altro conto è che strumenti hai a disposizione. Il fatto che Gnome sia preferito a KDE non vuol dire che siano meglio le gtk rispetto alle Qt ma solo che il programma finale (in questo caso il DE) è preferito dagli utenti.
Sinceramente Gnome a me non dispiace, se non fosse per quel senso di retrò e di minimalismo che si porta dietro, lo trovo molto pulito e chiaro al contrario di KDE che è veramente confusionario e poco curato(IMHO). Ma queste sono solo considerazione sul risultato non sugli strumenti.
Sinceramente Gnome a me non dispiace, se non fosse per quel senso di retrò e di minimalismo che si porta dietro, lo trovo molto pulito e chiaro al contrario di KDE che è veramente confusionario e poco curato(IMHO). Ma queste sono solo considerazione sul risultato non sugli strumenti.
Barra
20-02-2010, 21:49
Mark shuttleworth ha più volte ribadito come i linguaggi di scripting siano la soluzione più giusta per scrivere UI per la rapidità con la quale possono essre poi modificate (e l'esperienza UNR deve avere insegnato loro molto da questo punto di vista).
E gnome sembra andare in questa direzione: gnome-shell è javascript, zeitgeist e gnome-activity-journal python.
La volontà di gnome foundation è ormai usare C x GTK e scripting x tutto il resto. In questo mono non si sa bene dove vada a parare, penso per colpa delle grandi aziende: Novell ci sta spingendo molto, Canonical non si pone il problema (ma di contro non lo usa per i suoi applicativi), RH invece nega tutto quello che è mono.
@Cionci
Sono certo che quanto postato funzioni perfettamente ma Gnome-do fa qualcosina in +. Già ora gnome-shell fa quello che tu hai indicato. La cosa bella di gnome-do è che si adatta alle tue abitudini, si ricorda quali comandi usi di + e quali meno, offriva plugin per controllare varie parti del DE (ad esempio io spengo sempre il pc da tastiera premendo 5 tasti in sequenza, sembra scomodo ma è invece estremamente razionale.
E gnome sembra andare in questa direzione: gnome-shell è javascript, zeitgeist e gnome-activity-journal python.
La volontà di gnome foundation è ormai usare C x GTK e scripting x tutto il resto. In questo mono non si sa bene dove vada a parare, penso per colpa delle grandi aziende: Novell ci sta spingendo molto, Canonical non si pone il problema (ma di contro non lo usa per i suoi applicativi), RH invece nega tutto quello che è mono.
@Cionci
Sono certo che quanto postato funzioni perfettamente ma Gnome-do fa qualcosina in +. Già ora gnome-shell fa quello che tu hai indicato. La cosa bella di gnome-do è che si adatta alle tue abitudini, si ricorda quali comandi usi di + e quali meno, offriva plugin per controllare varie parti del DE (ad esempio io spengo sempre il pc da tastiera premendo 5 tasti in sequenza, sembra scomodo ma è invece estremamente razionale.
cionci
21-02-2010, 09:42
Mark shuttleworth ha più volte ribadito come i linguaggi di scripting siano la soluzione più giusta per scrivere UI per la rapidità con la quale possono essre poi modificate (e l'esperienza UNR deve avere insegnato loro molto da questo punto di vista).
Sempre e solo per le limitazioni del framework principale di sviluppo, stai sicuro che se avessero avuto un framwork unificato e ben scritto non avrebbero avuto di questi problemi.
Si ritorna sempre al solito discorso: C + GTK + altre 100 librerie = maggiori difficoltà di scrittura + difficoltà nella manutenzione del codice + difficoltà di modifica per chi non ha scritto il codice + codice buggato + software di minore qualità
@Cionci
Sono certo che quanto postato funzioni perfettamente ma Gnome-do fa qualcosina in +. Già ora gnome-shell fa quello che tu hai indicato. La cosa bella di gnome-do è che si adatta alle tue abitudini, si ricorda quali comandi usi di + e quali meno, offriva plugin per controllare varie parti del DE (ad esempio io spengo sempre il pc da tastiera premendo 5 tasti in sequenza, sembra scomodo ma è invece estremamente razionale.
Sicuramente fa molto di più, ma quello che ho scritto è solo un esempio per far capire quanto sia banale scrivere una cosa del genere con le Qt.
Mi piacerebbe sapere quanto ci metteresti con le varie librerie di Gnome. Non solo come tempo, ma anche come numero di linee di codice. E ricordo che il numero dei bug è proporzionale al numero delle linee di codice.
Sempre e solo per le limitazioni del framework principale di sviluppo, stai sicuro che se avessero avuto un framwork unificato e ben scritto non avrebbero avuto di questi problemi.
Si ritorna sempre al solito discorso: C + GTK + altre 100 librerie = maggiori difficoltà di scrittura + difficoltà nella manutenzione del codice + difficoltà di modifica per chi non ha scritto il codice + codice buggato + software di minore qualità
@Cionci
Sono certo che quanto postato funzioni perfettamente ma Gnome-do fa qualcosina in +. Già ora gnome-shell fa quello che tu hai indicato. La cosa bella di gnome-do è che si adatta alle tue abitudini, si ricorda quali comandi usi di + e quali meno, offriva plugin per controllare varie parti del DE (ad esempio io spengo sempre il pc da tastiera premendo 5 tasti in sequenza, sembra scomodo ma è invece estremamente razionale.
Sicuramente fa molto di più, ma quello che ho scritto è solo un esempio per far capire quanto sia banale scrivere una cosa del genere con le Qt.
Mi piacerebbe sapere quanto ci metteresti con le varie librerie di Gnome. Non solo come tempo, ma anche come numero di linee di codice. E ricordo che il numero dei bug è proporzionale al numero delle linee di codice.
Barra
21-02-2010, 11:30
Sempre e solo per le limitazioni del framework principale di sviluppo, stai sicuro che se avessero avuto un framwork unificato e ben scritto non avrebbero avuto di questi problemi.
Si ritorna sempre al solito discorso: C + GTK + altre 100 librerie = maggiori difficoltà di scrittura + difficoltà nella manutenzione del codice + difficoltà di modifica per chi non ha scritto il codice + codice buggato + software di minore qualità
Scusami ma la tua affermazione è (forse volutamente) eccessiva. A sentir te i linguaggi di scripting non avrebbero senso di esistere. Python esiste e sta diventando sempre più diffuso, non solo in ambiente linux.
Sicuramente fa molto di più, ma quello che ho scritto è solo un esempio per far capire quanto sia banale scrivere una cosa del genere con le Qt.
Mi piacerebbe sapere quanto ci metteresti con le varie librerie di Gnome. Non solo come tempo, ma anche come numero di linee di codice. E ricordo che il numero dei bug è proporzionale al numero delle linee di codice.
Anche qui esageri perchè quello che non fai tu con il tuo codice lo fanno le QT che, come tutti gli altri software contengono bug. Poi è vero che sono molto più diffuse di gnome-do e che quindi i bug dovrebbero essere meno.
Non ho poi le compentenze per dire se usando gobject, gtkmm o mono lo sviluppo richiederebbe maggiori righe di codice. So per certo che gnome-do, sviluppato in mono è nato nel giro di pochi mesi e da subito si è rivelato veloce, stabile e funzionale. Con il lavoro un'unico sviluppatore al lavoro.
Si ritorna sempre al solito discorso: C + GTK + altre 100 librerie = maggiori difficoltà di scrittura + difficoltà nella manutenzione del codice + difficoltà di modifica per chi non ha scritto il codice + codice buggato + software di minore qualità
Scusami ma la tua affermazione è (forse volutamente) eccessiva. A sentir te i linguaggi di scripting non avrebbero senso di esistere. Python esiste e sta diventando sempre più diffuso, non solo in ambiente linux.
Sicuramente fa molto di più, ma quello che ho scritto è solo un esempio per far capire quanto sia banale scrivere una cosa del genere con le Qt.
Mi piacerebbe sapere quanto ci metteresti con le varie librerie di Gnome. Non solo come tempo, ma anche come numero di linee di codice. E ricordo che il numero dei bug è proporzionale al numero delle linee di codice.
Anche qui esageri perchè quello che non fai tu con il tuo codice lo fanno le QT che, come tutti gli altri software contengono bug. Poi è vero che sono molto più diffuse di gnome-do e che quindi i bug dovrebbero essere meno.
Non ho poi le compentenze per dire se usando gobject, gtkmm o mono lo sviluppo richiederebbe maggiori righe di codice. So per certo che gnome-do, sviluppato in mono è nato nel giro di pochi mesi e da subito si è rivelato veloce, stabile e funzionale. Con il lavoro un'unico sviluppatore al lavoro.
cionci
21-02-2010, 11:45
Scusami ma la tua affermazione è (forse volutamente) eccessiva. A sentir te i linguaggi di scripting non avrebbero senso di esistere. Python esiste e sta diventando sempre più diffuso, non solo in ambiente linux.
Non solo in ambiente Linux sicuramente, ma si sta diffondendo in maniera massiva per componenti di sistema solo su Gnome ;)
I linguaggi di scripting hanno senso, non ho detto questo.
Anche qui esageri perchè quello che non fai tu con il tuo codice lo fanno le QT che, come tutti gli altri software contengono bug. Poi è vero che sono molto più diffuse di gnome-do e che quindi i bug dovrebbero essere meno.
A debuggare le Qt ci sono decine di migliaia di persone (tutti i programmatori che le usano ed eventualmente segnalano i problemi), a debuggare la mia applicazione ci siamo io e il mio team.
Non ho poi le compentenze per dire se usando gobject, gtkmm o mono lo sviluppo richiederebbe maggiori righe di codice. So per certo che gnome-do, sviluppato in mono è nato nel giro di pochi mesi e da subito si è rivelato veloce, stabile e funzionale. Con il lavoro un'unico sviluppatore al lavoro.
E perché è stato scritto sotto Mono e non con C + GTK + 100 librerie diverse ?
Non solo in ambiente Linux sicuramente, ma si sta diffondendo in maniera massiva per componenti di sistema solo su Gnome ;)
I linguaggi di scripting hanno senso, non ho detto questo.
Anche qui esageri perchè quello che non fai tu con il tuo codice lo fanno le QT che, come tutti gli altri software contengono bug. Poi è vero che sono molto più diffuse di gnome-do e che quindi i bug dovrebbero essere meno.
A debuggare le Qt ci sono decine di migliaia di persone (tutti i programmatori che le usano ed eventualmente segnalano i problemi), a debuggare la mia applicazione ci siamo io e il mio team.
Non ho poi le compentenze per dire se usando gobject, gtkmm o mono lo sviluppo richiederebbe maggiori righe di codice. So per certo che gnome-do, sviluppato in mono è nato nel giro di pochi mesi e da subito si è rivelato veloce, stabile e funzionale. Con il lavoro un'unico sviluppatore al lavoro.
E perché è stato scritto sotto Mono e non con C + GTK + 100 librerie diverse ?
Pixel452
21-02-2010, 12:18
A mio avviso i linguaggi di script hanno senso se vengono usati come script per l’appunto, se uno ci fa un applicazione intera a me qualche dubbio viene, anche perché questi linguaggi non sono proprio sinonimo di prestazioni, poi dipende anche da che applicazione devi sviluppare. C# secondo me è un ottima via di mezzo e per fare interfacce è perfetto anche se la differenze vera la fa il .NET non tanto il C#. Credo che nello sviluppo la cosa che conti di più sia il Framework, cosa che gnome non ha e i linguaggi di script sono solo un ripiego per non suicidarsi con decide di librerie integrate male. Paragonare le Qt al codice che scrive il singolo sviluppatore mi sembra un pesante azzardo, io non ho quasi mai trovato bug nei Framework ed anche nel caso erano documentati, non dico di prendere quel codice come oro colato ma quasi, almeno dalla mia esperienza personale, poi magari le Qt sono scritte da dei cani ma ne dubito.
zephyr83
22-02-2010, 13:15
e non venitemi a dire che è colpa del fatto che ubuntu installi di default gnome perchè si sa che esiste anche la controparte con kde...
attualmente, gnome ne esce vincitore anche se basato sulle gtk...quindi dove hanno sbagliato?
ciao :Prrr:
e invece si! una volta era proprio KDE il più diffuso! guarda su distrowatch dal 2002 (prima nn c'è) fino al 2007 quanti e quali distro usavano kde! praticamente tutte le distro livecd più diffuse (knoppix e mepis su tutte)! Suse era la prima per nn parlare di mandrake (poi diventata mandriva) e slackware (e altre "sparite")! Cn l'arrivo di ubuntu le cose sn cambiate! oggi le prime 3 sn ubuntu, fedora e mint (sempre ubuntu cn gnome) e fra la prima e la seconda c'è anche una bella differenza. Kubuntu è meno curata e ha sempre dato più problemi della sorella. Gnome è vincitore perché canonical e altre hanno preferito puntare su questa (fra cui redhat cn fedora). Nn è detto che si imponga il prodotto "migliore", vedi windows, internet explorer, ipod e compagnia :sofico:
attualmente, gnome ne esce vincitore anche se basato sulle gtk...quindi dove hanno sbagliato?
ciao :Prrr:
e invece si! una volta era proprio KDE il più diffuso! guarda su distrowatch dal 2002 (prima nn c'è) fino al 2007 quanti e quali distro usavano kde! praticamente tutte le distro livecd più diffuse (knoppix e mepis su tutte)! Suse era la prima per nn parlare di mandrake (poi diventata mandriva) e slackware (e altre "sparite")! Cn l'arrivo di ubuntu le cose sn cambiate! oggi le prime 3 sn ubuntu, fedora e mint (sempre ubuntu cn gnome) e fra la prima e la seconda c'è anche una bella differenza. Kubuntu è meno curata e ha sempre dato più problemi della sorella. Gnome è vincitore perché canonical e altre hanno preferito puntare su questa (fra cui redhat cn fedora). Nn è detto che si imponga il prodotto "migliore", vedi windows, internet explorer, ipod e compagnia :sofico:
marco.r
22-02-2010, 13:59
E' questa che è la cosa bella, se nonostante questo riesce a stare davanti a KDE, non mi immagino cosa possa se lo riscrivessero basato sulle QT :D
Ci sarà qualche motivo per cui su Gnome si stanno sviluppando a dismisura Python e Mono e non viene usata la piattaforma di sviluppo principale di Gnome ?
Perche' questa era l'intenzione degli autori fin da subito, ovvero lasciare fare l'interfaccia utente in linguaggi di piu' alto livello.
E una ABI in C permette di far usare la libreria ad numero elevato di linguaggi.
Tieni presente che stiamo parlando dei tempi in cui Gnome voleva fornire solo "policy" per cui tutto doveva poter essere a discrezione dell'utente e dello sviluppatore , dal window manager al linguaggio di programmazione.
Ora le cose sono un po' cambiate per alcuni aspetti, ma se guardi per quali linguaggi sono disponibili i binding in QT e quali Gtk, la differenza e' ancora evidente.
E poi il C++ delle QT e' un po' balordo, non mi piace affatto (ma questa e' un'opinione personale :D).
Ci sarà qualche motivo per cui su Gnome si stanno sviluppando a dismisura Python e Mono e non viene usata la piattaforma di sviluppo principale di Gnome ?
Perche' questa era l'intenzione degli autori fin da subito, ovvero lasciare fare l'interfaccia utente in linguaggi di piu' alto livello.
E una ABI in C permette di far usare la libreria ad numero elevato di linguaggi.
Tieni presente che stiamo parlando dei tempi in cui Gnome voleva fornire solo "policy" per cui tutto doveva poter essere a discrezione dell'utente e dello sviluppatore , dal window manager al linguaggio di programmazione.
Ora le cose sono un po' cambiate per alcuni aspetti, ma se guardi per quali linguaggi sono disponibili i binding in QT e quali Gtk, la differenza e' ancora evidente.
E poi il C++ delle QT e' un po' balordo, non mi piace affatto (ma questa e' un'opinione personale :D).
cionci
22-02-2010, 14:11
Perche' questa era l'intenzione degli autori fin da subito, ovvero lasciare fare l'interfaccia utente in linguaggi di piu' alto livello.
Come fa ad essere nelle intenzioni degli autori ? Python e Mono si sono sviluppati solo negli ultimi anni. Quali erano gli altri linguaggi prima di questi ?
Ora le cose sono un po' cambiate per alcuni aspetti, ma se guardi per quali linguaggi sono disponibili i binding in QT e quali Gtk, la differenza e' ancora evidente.
Un binding si sviluppa se se ne sente la necessità. Inoltre fino a poco tempo fa c'erano molti problemi di licenza per le Qt su Windows.
Come fa ad essere nelle intenzioni degli autori ? Python e Mono si sono sviluppati solo negli ultimi anni. Quali erano gli altri linguaggi prima di questi ?
Ora le cose sono un po' cambiate per alcuni aspetti, ma se guardi per quali linguaggi sono disponibili i binding in QT e quali Gtk, la differenza e' ancora evidente.
Un binding si sviluppa se se ne sente la necessità. Inoltre fino a poco tempo fa c'erano molti problemi di licenza per le Qt su Windows.
Barra
22-02-2010, 14:18
Ci sarà un motivo se già ai tempi RH e Novell (e ancor prima SUSE) decisero di puntare su Gnome. IMHO molto semplicemente la gnome-foundation è stata più attenta alle necessità delle aziende che lavorano (e di conseguenza investono) su linux.
KDE3 era bello, flessibile, pratico. Per uno smanettone.
L'utente medio si perdeva nei 1000 menu di mandriva (e capita ancora oggi) mentre in gnome tutto è talmente semplice, ordinato e minimalista che difficilmente ci si perde nei menu.
http://www.ibiblio.org/pub/linux/docs/LDP/linuxfocus/common/images/article246/snapshot_big.png
Questa è una classica schermata di un pc KDE3 ai tempi e non era alla portata di tutti.
Oggi le cose sono cambiate e KDE4 ha corretto molti dei difetti del passato ma nel frattempo si è persa molta strada.
Ti sei mai chiesto perchè Mandriva ha spinto per anni Linux in ambiente dekstop senza ottenere risultati mentre Canonical è riuscita ad ottenere piccoli ma importanti risultati? (Ubuntu su pc dell, hp, toshiba e sharp ad esempio)
Forse la colpa è proprio di KDE3.
Ora la questione è differente: Queste grandi aziende hanno speso e necessitano di continuità, gnome può garantire, KDE per ora no. Tra un paio di anni un ipotetico QT5 potrebbe portare a una completa riscrittura dell'intero DE con il rischio di spiazzare clienti che invece necessitano di continuità (non è un caso che XP sia vissuto così a lungo!)
KDE3 era bello, flessibile, pratico. Per uno smanettone.
L'utente medio si perdeva nei 1000 menu di mandriva (e capita ancora oggi) mentre in gnome tutto è talmente semplice, ordinato e minimalista che difficilmente ci si perde nei menu.
http://www.ibiblio.org/pub/linux/docs/LDP/linuxfocus/common/images/article246/snapshot_big.png
Questa è una classica schermata di un pc KDE3 ai tempi e non era alla portata di tutti.
Oggi le cose sono cambiate e KDE4 ha corretto molti dei difetti del passato ma nel frattempo si è persa molta strada.
Ti sei mai chiesto perchè Mandriva ha spinto per anni Linux in ambiente dekstop senza ottenere risultati mentre Canonical è riuscita ad ottenere piccoli ma importanti risultati? (Ubuntu su pc dell, hp, toshiba e sharp ad esempio)
Forse la colpa è proprio di KDE3.
Ora la questione è differente: Queste grandi aziende hanno speso e necessitano di continuità, gnome può garantire, KDE per ora no. Tra un paio di anni un ipotetico QT5 potrebbe portare a una completa riscrittura dell'intero DE con il rischio di spiazzare clienti che invece necessitano di continuità (non è un caso che XP sia vissuto così a lungo!)
cionci
22-02-2010, 14:36
Ci sarà un motivo se già ai tempi RH e Novell (e ancor prima SUSE) decisero di puntare su Gnome. IMHO molto semplicemente la gnome-foundation è stata più attenta alle necessità delle aziende che lavorano (e di conseguenza investono) su linux.
Era semplicemente un motivo ideologico dovuto alla licenza.
Ti sei mai chiesto perchè Mandriva ha spinto per anni Linux in ambiente dekstop senza ottenere risultati mentre Canonical è riuscita ad ottenere piccoli ma importanti risultati? (Ubuntu su pc dell, hp, toshiba e sharp ad esempio)
Forse la colpa è proprio di KDE3.
Magari la colpa sarà anche di KDE3, ma secondo me la motivazione principale è la quantità dei fondi investiti.
Ripeto che sono un fan di Gnome e KDE lo trovo troppo anche io troppo confusionario. Questo comunque non va ad influire sul discorso originale, perché non stiamo parlando di Gnome vs KDE.
Ora la questione è differente: Queste grandi aziende hanno speso e necessitano di continuità, gnome può garantire, KDE per ora no. Tra un paio di anni un ipotetico QT5 potrebbe portare a una completa riscrittura dell'intero DE con il rischio di spiazzare clienti che invece necessitano di continuità (non è un caso che XP sia vissuto così a lungo!)
Non vedo un grosso problema adattarsi ad un cambiamento di versione (ben documentato tra l'altro e con la possibilità di sfruttare la retrocompatibilità così come è stato per il passaggio da Qt3 a Qt4) ogni 5-6 anni. C'è chi con i cambiamenti di versione ci deve lottare ogni 2-3 mesi (chi programma in C su Gnome o chi scrive i binding per i linguaggi di alto livello).
Inoltre un avanzamento di versione non può andare ad influire su KDE se non marginalmente, come già detto sicuramente inseriranno la retrocompatibilità (così come è stato fatto per le Qt3).
Era semplicemente un motivo ideologico dovuto alla licenza.
Ti sei mai chiesto perchè Mandriva ha spinto per anni Linux in ambiente dekstop senza ottenere risultati mentre Canonical è riuscita ad ottenere piccoli ma importanti risultati? (Ubuntu su pc dell, hp, toshiba e sharp ad esempio)
Forse la colpa è proprio di KDE3.
Magari la colpa sarà anche di KDE3, ma secondo me la motivazione principale è la quantità dei fondi investiti.
Ripeto che sono un fan di Gnome e KDE lo trovo troppo anche io troppo confusionario. Questo comunque non va ad influire sul discorso originale, perché non stiamo parlando di Gnome vs KDE.
Ora la questione è differente: Queste grandi aziende hanno speso e necessitano di continuità, gnome può garantire, KDE per ora no. Tra un paio di anni un ipotetico QT5 potrebbe portare a una completa riscrittura dell'intero DE con il rischio di spiazzare clienti che invece necessitano di continuità (non è un caso che XP sia vissuto così a lungo!)
Non vedo un grosso problema adattarsi ad un cambiamento di versione (ben documentato tra l'altro e con la possibilità di sfruttare la retrocompatibilità così come è stato per il passaggio da Qt3 a Qt4) ogni 5-6 anni. C'è chi con i cambiamenti di versione ci deve lottare ogni 2-3 mesi (chi programma in C su Gnome o chi scrive i binding per i linguaggi di alto livello).
Inoltre un avanzamento di versione non può andare ad influire su KDE se non marginalmente, come già detto sicuramente inseriranno la retrocompatibilità (così come è stato fatto per le Qt3).
insane74
22-02-2010, 15:20
cmq secondo me il futuro delle qt non è roseo.
qt = nokia -> nokia vs google+android/apple+iphone
qt ormai significa nokia, che è in guerra con google e il suo android (sempre + diffuso e apprezzato, e "svincolato" dal produttore hw) e con apple e il suo iphone.
sempre google ha scelto le gtk per il suo browser, opera a quanto pare abbandonerà le qt...
forse sulla carta sono migliori delle gtk (non ho certo le capacità per esprimere un giudizio), ma da come tira l'aria sul mercato secondo me non andranno tanto lontano...
alla fin fine, come in quasi tutti i campi in cui s'è mossa, vincerà la scelta di google... gtk, java...
e deve ancora uscire google os... con cosa è fatto? qt? ah no, gtk...
scelta politica, ma quando sono tali "big" a scegliere...
qt = nokia -> nokia vs google+android/apple+iphone
qt ormai significa nokia, che è in guerra con google e il suo android (sempre + diffuso e apprezzato, e "svincolato" dal produttore hw) e con apple e il suo iphone.
sempre google ha scelto le gtk per il suo browser, opera a quanto pare abbandonerà le qt...
forse sulla carta sono migliori delle gtk (non ho certo le capacità per esprimere un giudizio), ma da come tira l'aria sul mercato secondo me non andranno tanto lontano...
alla fin fine, come in quasi tutti i campi in cui s'è mossa, vincerà la scelta di google... gtk, java...
e deve ancora uscire google os... con cosa è fatto? qt? ah no, gtk...
scelta politica, ma quando sono tali "big" a scegliere...
cionci
22-02-2010, 15:39
Però ti sei dimenticato di Intel. Non mi sembra che Intel + Nokia siano piccoli competitor per Chromium e Android.
insane74
22-02-2010, 15:41
Però ti sei dimenticato di Intel. Non mi sembra che Intel + Nokia siano piccoli competitor per Chromium e Android.
a livello industriale ti posso dare ragione, ma a livello mediatico "google" tira di sicuro più di intel.
anche mio nonno ha sentito parlare di google, ma "intel" non significa nulla, nemmeno in bergamasco! :p
cmq solo il tempo ci darà un vincitore, ma se dovessi scommettere dei soldi li punterei sulla g.;)
a livello industriale ti posso dare ragione, ma a livello mediatico "google" tira di sicuro più di intel.
anche mio nonno ha sentito parlare di google, ma "intel" non significa nulla, nemmeno in bergamasco! :p
cmq solo il tempo ci darà un vincitore, ma se dovessi scommettere dei soldi li punterei sulla g.;)
cionci
22-02-2010, 15:52
Secondo me ci sarà mercato per tutti:
- Chrome OS andrà sui nettop
- Meego su slate PC, netbook, palmari e palm phone.
- Android sui cellulari di medio e alto livello
- Symbian per quelli di basso livello
- Chrome OS andrà sui nettop
- Meego su slate PC, netbook, palmari e palm phone.
- Android sui cellulari di medio e alto livello
- Symbian per quelli di basso livello
insane74
22-02-2010, 15:59
Secondo me ci sarà mercato per tutti:
- Chrome OS andrà sui nettop
- Meego su slate PC, netbook, palmari e palm phone.
- Android sui cellulari di medio e alto livello
- Symbian per quelli di basso livello
il problema sarà il market share: le qt vanno su android/iphone? non a livello tecnico intendo, ma politico.
le gtk? mono? c'è pure l'sdk per l'iphone (a pagamento)...
alla fin fine se si diffondono di più le piattaforme che "partono" su base gtk/java/quello-che-volete, le qt resterebbero troppo "legate" al mondo nokia, che viene attaccato sul cel "normali" da samsung e da lg (che hanno roso molte fette di mercato ai cari finlandesi).
siamo sempre lì: devo fare un'app nuova. sviluppo per il fico iphone e per mamma google? con che linguaggio? poi lo faccio anche per nokia? ma devo rifare l'interfaccia con le qt? uff!
e così via...
PS: e non dimentichiamo canonical, che ormai è "l'unica" voce che la massa associa a linux. cosa usano? gnome. quindi gtk e tutti gli annessi e connessi. netbook remix? ubuntu one? il nuovo "centro software"? tutto gtk...
- Chrome OS andrà sui nettop
- Meego su slate PC, netbook, palmari e palm phone.
- Android sui cellulari di medio e alto livello
- Symbian per quelli di basso livello
il problema sarà il market share: le qt vanno su android/iphone? non a livello tecnico intendo, ma politico.
le gtk? mono? c'è pure l'sdk per l'iphone (a pagamento)...
alla fin fine se si diffondono di più le piattaforme che "partono" su base gtk/java/quello-che-volete, le qt resterebbero troppo "legate" al mondo nokia, che viene attaccato sul cel "normali" da samsung e da lg (che hanno roso molte fette di mercato ai cari finlandesi).
siamo sempre lì: devo fare un'app nuova. sviluppo per il fico iphone e per mamma google? con che linguaggio? poi lo faccio anche per nokia? ma devo rifare l'interfaccia con le qt? uff!
e così via...
PS: e non dimentichiamo canonical, che ormai è "l'unica" voce che la massa associa a linux. cosa usano? gnome. quindi gtk e tutti gli annessi e connessi. netbook remix? ubuntu one? il nuovo "centro software"? tutto gtk...
cionci
22-02-2010, 16:11
Meego non è è un OS per cellulari. E' chiaro che se sviluppo un'applicazione per cellulari non scelgo Qt (a meno di avere come obiettivo il solo Symbian).
Se invece devo sviluppare un'applicazione desktop le Qt diventano ancora più papabili rispetto a prima, permettendomi di scrivere applicazioni compatibili, previa ricompilazione, con i desktop Linux, Windows, Mac e con i dispositivi portatili equipaggiati con Meego.
Se invece devo sviluppare un'applicazione desktop le Qt diventano ancora più papabili rispetto a prima, permettendomi di scrivere applicazioni compatibili, previa ricompilazione, con i desktop Linux, Windows, Mac e con i dispositivi portatili equipaggiati con Meego.
insane74
22-02-2010, 16:18
Meego non è è un OS per cellulari. E' chiaro che se sviluppo un'applicazione per cellulari non scelgo Qt (a meno di avere come obiettivo il solo Symbian).
Se invece devo sviluppare un'applicazione desktop le Qt diventano ancora più papabili rispetto a prima, permettendomi di scrivere applicazioni compatibili, previa ricompilazione, con i desktop Linux, Windows, Mac e con i dispositivi portatili equipaggiati con Meego.
concordo, ma java/.net/mono/python non hanno bisogno della ricompilazione.
poi si sta spostando tutto verso il "cloud", e li le qt non servono a nulla.
non so, come già detto non sono certo un esperto e mi guardo bene dal discutere dei meriti tecnici di una soluzione rispetto ad un'altra (per dire, mi "piacciono" le qt perché qt-creator è figo, mentre detesto il python (oltre al fatto che come linguaggio è un'offesa) perché non ha un IDE come si deve), ma come "sbocchi" sul mercato, vedo le qt troppo "limitate".
sbaglierò di sicuro, ma l'impressione è questa.
Se invece devo sviluppare un'applicazione desktop le Qt diventano ancora più papabili rispetto a prima, permettendomi di scrivere applicazioni compatibili, previa ricompilazione, con i desktop Linux, Windows, Mac e con i dispositivi portatili equipaggiati con Meego.
concordo, ma java/.net/mono/python non hanno bisogno della ricompilazione.
poi si sta spostando tutto verso il "cloud", e li le qt non servono a nulla.
non so, come già detto non sono certo un esperto e mi guardo bene dal discutere dei meriti tecnici di una soluzione rispetto ad un'altra (per dire, mi "piacciono" le qt perché qt-creator è figo, mentre detesto il python (oltre al fatto che come linguaggio è un'offesa) perché non ha un IDE come si deve), ma come "sbocchi" sul mercato, vedo le qt troppo "limitate".
sbaglierò di sicuro, ma l'impressione è questa.
cionci
22-02-2010, 16:45
concordo, ma java/.net/mono/python non hanno bisogno della ricompilazione.
Invece sì. Da Java su desktop a Java su cellulare c'è bisogno di riscrivere quasi tutto il programma (nota che c'è da modificarlo spesso anche da cellulare a cellulare). Da .Net a Mono su desktop c'è bisogno spesso di riscrivere buona parte dell'applicazione. Da Mono su desktop a Mono su Iphone c'è da riscrivere almeno tutta la parte della GUI.
Per C++ e Qt invece c'è solo da ricompilare per portare da Windows a Linux e viceversa (sempre che non si usino API o system call di più basso livello).
A parte la ricompilazione, la portabilità per quanto concerne i sistemi operativi desktop classici e mobili con Meego è simile a quella di Python e Java. Solo che Java si autoesclude perché su dispositivi con scarse prestazioni (come i dispositivi su cui si andrà ad usare Meego) usare Java SE credo che sia un suicidio.
Per Python, usando pyGTK non si avrebbe un look&feel coerente con le scelte di sistema di Meego. Però Python può usare anche pyQt ;)
Per Mono che io sappia questa possibilità non c'è.
Invece sì. Da Java su desktop a Java su cellulare c'è bisogno di riscrivere quasi tutto il programma (nota che c'è da modificarlo spesso anche da cellulare a cellulare). Da .Net a Mono su desktop c'è bisogno spesso di riscrivere buona parte dell'applicazione. Da Mono su desktop a Mono su Iphone c'è da riscrivere almeno tutta la parte della GUI.
Per C++ e Qt invece c'è solo da ricompilare per portare da Windows a Linux e viceversa (sempre che non si usino API o system call di più basso livello).
A parte la ricompilazione, la portabilità per quanto concerne i sistemi operativi desktop classici e mobili con Meego è simile a quella di Python e Java. Solo che Java si autoesclude perché su dispositivi con scarse prestazioni (come i dispositivi su cui si andrà ad usare Meego) usare Java SE credo che sia un suicidio.
Per Python, usando pyGTK non si avrebbe un look&feel coerente con le scelte di sistema di Meego. Però Python può usare anche pyQt ;)
Per Mono che io sappia questa possibilità non c'è.
zappy
22-02-2010, 16:51
o gnome in qt o kde in gtk.
mi sono fracassato di avere millemila librerie in ram, magaro per solo un programma, e avere una GUI non omogenea.
quoto.
mi sono fracassato di avere millemila librerie in ram, magaro per solo un programma, e avere una GUI non omogenea.
quoto.
insane74
22-02-2010, 16:55
Invece sì. Da Java su desktop a Java su cellulare c'è bisogno di riscrivere quasi tutto il programma (nota che c'è da modificarlo spesso anche da cellulare a cellulare). Da .Net a Mono su desktop c'è bisogno spesso di riscrivere buona parte dell'applicazione. Da Mono su desktop a Mono su Iphone c'è da riscrivere almeno tutta la parte della GUI.
Per C++ e Qt invece c'è solo da ricompilare per portare da Windows a Linux e viceversa (sempre che non si usino API o system call di più basso livello).
A parte la ricompilazione, la portabilità per quanto concerne i sistemi operativi desktop classici e mobili con Meego è simile a quella di Python e Java. Solo che Java si autoesclude perché su dispositivi con scarse prestazioni (come i dispositivi su cui si andrà ad usare Meego) usare Java SE credo che sia un suicidio.
Per Python, usando pyGTK non si avrebbe un look&feel coerente con le scelte di sistema di Meego. Però Python può usare anche pyQt ;)
Per Mono che io sappia questa possibilità non c'è.
ecco, l'ho detto che "sbaglierò di sicuro"... :doh: :banned:
Per C++ e Qt invece c'è solo da ricompilare per portare da Windows a Linux e viceversa (sempre che non si usino API o system call di più basso livello).
A parte la ricompilazione, la portabilità per quanto concerne i sistemi operativi desktop classici e mobili con Meego è simile a quella di Python e Java. Solo che Java si autoesclude perché su dispositivi con scarse prestazioni (come i dispositivi su cui si andrà ad usare Meego) usare Java SE credo che sia un suicidio.
Per Python, usando pyGTK non si avrebbe un look&feel coerente con le scelte di sistema di Meego. Però Python può usare anche pyQt ;)
Per Mono che io sappia questa possibilità non c'è.
ecco, l'ho detto che "sbaglierò di sicuro"... :doh: :banned:
zephyr83
22-02-2010, 18:57
Ci sarà un motivo se già ai tempi RH e Novell (e ancor prima SUSE) decisero di puntare su Gnome. IMHO molto semplicemente la gnome-foundation è stata più attenta alle necessità delle aziende che lavorano (e di conseguenza investono) su linux.
KDE3 era bello, flessibile, pratico. Per uno smanettone.
L'utente medio si perdeva nei 1000 menu di mandriva (e capita ancora oggi) mentre in gnome tutto è talmente semplice, ordinato e minimalista che difficilmente ci si perde nei menu.
http://www.ibiblio.org/pub/linux/docs/LDP/linuxfocus/common/images/article246/snapshot_big.png
Questa è una classica schermata di un pc KDE3 ai tempi e non era alla portata di tutti.
Oggi le cose sono cambiate e KDE4 ha corretto molti dei difetti del passato ma nel frattempo si è persa molta strada.
Ti sei mai chiesto perchè Mandriva ha spinto per anni Linux in ambiente dekstop senza ottenere risultati mentre Canonical è riuscita ad ottenere piccoli ma importanti risultati? (Ubuntu su pc dell, hp, toshiba e sharp ad esempio)
Forse la colpa è proprio di KDE3.
Ora la questione è differente: Queste grandi aziende hanno speso e necessitano di continuità, gnome può garantire, KDE per ora no. Tra un paio di anni un ipotetico QT5 potrebbe portare a una completa riscrittura dell'intero DE con il rischio di spiazzare clienti che invece necessitano di continuità (non è un caso che XP sia vissuto così a lungo!)
ma che dici! Molti hanno scelto inizialmente gnome per questioni "ideologiche", per il fatto che le gtk fossero LGPL (nn gpl, LGPL) e, aggiungo io, anche per questioni "nazionalistiche" (aziende americane hanno preferito "l'americano" gnome all'"europeo" kde). inoltre novell ha smepre usato KDE come DE predefinito, aprendosi a gnome nn da tanto!! Consiglio anche a te di guardare su distrowatch dal 2002 al 2007, l'unica vero grande distro cn gnome predefinito era redhat (poi sostituita da fedora). Al primo posto c'era Suse (cn kde) e fra le prime 4 c'era mandrake (poi diventata mandriva). Quella delle semplicità è proprio una "sciocchezza" :) ti ricordo che le prime varie distro live FACILI avevano tutte kde (knoppix, mepis)! inoltre su gnome modificare l'aspetto grafico era un SUICIDIO :sofico: su kde era molto più semplice!
Canonical si sarebbe imposta anche cn gnome! Ubuntu ha avuto la meglio di mandriva grazie a Canonical non grazie a gnome :rolleyes: Poi anche se uscissero le QT5 nn è detto che bisognerebbe riscrivere KDE, così come nn era necessario farlo per kde4......è stata una scelta degli sviluppatori!!! si poteva benissimo fare un pasaggio più lungo e graduale come sta avvenendo per gnome!
KDE3 era bello, flessibile, pratico. Per uno smanettone.
L'utente medio si perdeva nei 1000 menu di mandriva (e capita ancora oggi) mentre in gnome tutto è talmente semplice, ordinato e minimalista che difficilmente ci si perde nei menu.
http://www.ibiblio.org/pub/linux/docs/LDP/linuxfocus/common/images/article246/snapshot_big.png
Questa è una classica schermata di un pc KDE3 ai tempi e non era alla portata di tutti.
Oggi le cose sono cambiate e KDE4 ha corretto molti dei difetti del passato ma nel frattempo si è persa molta strada.
Ti sei mai chiesto perchè Mandriva ha spinto per anni Linux in ambiente dekstop senza ottenere risultati mentre Canonical è riuscita ad ottenere piccoli ma importanti risultati? (Ubuntu su pc dell, hp, toshiba e sharp ad esempio)
Forse la colpa è proprio di KDE3.
Ora la questione è differente: Queste grandi aziende hanno speso e necessitano di continuità, gnome può garantire, KDE per ora no. Tra un paio di anni un ipotetico QT5 potrebbe portare a una completa riscrittura dell'intero DE con il rischio di spiazzare clienti che invece necessitano di continuità (non è un caso che XP sia vissuto così a lungo!)
ma che dici! Molti hanno scelto inizialmente gnome per questioni "ideologiche", per il fatto che le gtk fossero LGPL (nn gpl, LGPL) e, aggiungo io, anche per questioni "nazionalistiche" (aziende americane hanno preferito "l'americano" gnome all'"europeo" kde). inoltre novell ha smepre usato KDE come DE predefinito, aprendosi a gnome nn da tanto!! Consiglio anche a te di guardare su distrowatch dal 2002 al 2007, l'unica vero grande distro cn gnome predefinito era redhat (poi sostituita da fedora). Al primo posto c'era Suse (cn kde) e fra le prime 4 c'era mandrake (poi diventata mandriva). Quella delle semplicità è proprio una "sciocchezza" :) ti ricordo che le prime varie distro live FACILI avevano tutte kde (knoppix, mepis)! inoltre su gnome modificare l'aspetto grafico era un SUICIDIO :sofico: su kde era molto più semplice!
Canonical si sarebbe imposta anche cn gnome! Ubuntu ha avuto la meglio di mandriva grazie a Canonical non grazie a gnome :rolleyes: Poi anche se uscissero le QT5 nn è detto che bisognerebbe riscrivere KDE, così come nn era necessario farlo per kde4......è stata una scelta degli sviluppatori!!! si poteva benissimo fare un pasaggio più lungo e graduale come sta avvenendo per gnome!
Dcromato
22-02-2010, 19:05
A me pare si stia perdendo il senso della discussion...non vedo il motivo di paragonare i due de maggiori.
zephyr83
22-02-2010, 19:18
il problema sarà il market share: le qt vanno su android/iphone? non a livello tecnico intendo, ma politico.
le gtk? mono? c'è pure l'sdk per l'iphone (a pagamento)...
alla fin fine se si diffondono di più le piattaforme che "partono" su base gtk/java/quello-che-volete, le qt resterebbero troppo "legate" al mondo nokia, che viene attaccato sul cel "normali" da samsung e da lg (che hanno roso molte fette di mercato ai cari finlandesi).
siamo sempre lì: devo fare un'app nuova. sviluppo per il fico iphone e per mamma google? con che linguaggio? poi lo faccio anche per nokia? ma devo rifare l'interfaccia con le qt? uff!
e così via...
PS: e non dimentichiamo canonical, che ormai è "l'unica" voce che la massa associa a linux. cosa usano? gnome. quindi gtk e tutti gli annessi e connessi. netbook remix? ubuntu one? il nuovo "centro software"? tutto gtk...
guarda che gli smartphone più diffusi di tutti sn quelli nokia e cn un bel distacco da android e da iphone! Inoltre lo sviluppatore grazie alle qt potrà programmare per symbian, maemo/meego e windows mobile (è da vedere però come andranno le cose per windows phone 7), inoltre il toolkit è lo stesso per sviluppare su pc e i porting sn facili! a me lo sviluppatore sembra più invogliato a sviluppare in QT se ragioniamo così! Io guarderei la diffusione dei cellulari, i primi 5 produttori sn Nokia, samsung, lg, motorola e sonyericsson Poi vengono rim, apple, htc! Inoltre gli smartphone in assoluto più diffusi sn appunto i symbian! Apple vende tanto nella fascia Alta del mercato ma il numero totale di dispositivi è minore di quello nokia che pizza symbian anche su telefoni di 200 euro!!! inoltre secondo questo ragionamento RIM /blackbarry) dovrebbe chiudere i battenti :sofico:
Cmq, per chi interessa http://www.qt-iphone.com/Introduction.html
le gtk? mono? c'è pure l'sdk per l'iphone (a pagamento)...
alla fin fine se si diffondono di più le piattaforme che "partono" su base gtk/java/quello-che-volete, le qt resterebbero troppo "legate" al mondo nokia, che viene attaccato sul cel "normali" da samsung e da lg (che hanno roso molte fette di mercato ai cari finlandesi).
siamo sempre lì: devo fare un'app nuova. sviluppo per il fico iphone e per mamma google? con che linguaggio? poi lo faccio anche per nokia? ma devo rifare l'interfaccia con le qt? uff!
e così via...
PS: e non dimentichiamo canonical, che ormai è "l'unica" voce che la massa associa a linux. cosa usano? gnome. quindi gtk e tutti gli annessi e connessi. netbook remix? ubuntu one? il nuovo "centro software"? tutto gtk...
guarda che gli smartphone più diffusi di tutti sn quelli nokia e cn un bel distacco da android e da iphone! Inoltre lo sviluppatore grazie alle qt potrà programmare per symbian, maemo/meego e windows mobile (è da vedere però come andranno le cose per windows phone 7), inoltre il toolkit è lo stesso per sviluppare su pc e i porting sn facili! a me lo sviluppatore sembra più invogliato a sviluppare in QT se ragioniamo così! Io guarderei la diffusione dei cellulari, i primi 5 produttori sn Nokia, samsung, lg, motorola e sonyericsson Poi vengono rim, apple, htc! Inoltre gli smartphone in assoluto più diffusi sn appunto i symbian! Apple vende tanto nella fascia Alta del mercato ma il numero totale di dispositivi è minore di quello nokia che pizza symbian anche su telefoni di 200 euro!!! inoltre secondo questo ragionamento RIM /blackbarry) dovrebbe chiudere i battenti :sofico:
Cmq, per chi interessa http://www.qt-iphone.com/Introduction.html
zephyr83
22-02-2010, 19:19
A me pare si stia perdendo il senso della discussion...non vedo il motivo di paragonare i due de maggiori.
ah ma perché se no le gtk nn possono sostenere un confronto diretto cn le qt :D quindi per forza di cosa si tira in ballo gnome!! Siamo partiti cn alcuni che dicevano che le gtk nn è vero che sn inferiori alle qt e si è arrivati a dire che sn meglio perché gnome è più diffuso :D
ah ma perché se no le gtk nn possono sostenere un confronto diretto cn le qt :D quindi per forza di cosa si tira in ballo gnome!! Siamo partiti cn alcuni che dicevano che le gtk nn è vero che sn inferiori alle qt e si è arrivati a dire che sn meglio perché gnome è più diffuso :D
zephyr83
22-02-2010, 19:23
Meego non è è un OS per cellulari. E' chiaro che se sviluppo un'applicazione per cellulari non scelgo Qt (a meno di avere come obiettivo il solo Symbian).
Se invece devo sviluppare un'applicazione desktop le Qt diventano ancora più papabili rispetto a prima, permettendomi di scrivere applicazioni compatibili, previa ricompilazione, con i desktop Linux, Windows, Mac e con i dispositivi portatili equipaggiati con Meego.
lo puoi fare anche per cellulari! basta vedere il poting di Marble su windows mobile http://labs.trolltech.com/blogs/2008/04/04/marble-running-on-windows-ce/
Se invece devo sviluppare un'applicazione desktop le Qt diventano ancora più papabili rispetto a prima, permettendomi di scrivere applicazioni compatibili, previa ricompilazione, con i desktop Linux, Windows, Mac e con i dispositivi portatili equipaggiati con Meego.
lo puoi fare anche per cellulari! basta vedere il poting di Marble su windows mobile http://labs.trolltech.com/blogs/2008/04/04/marble-running-on-windows-ce/
cionci
22-02-2010, 19:28
lo puoi fare anche per cellulari! basta vedere il poting di Marble su windows mobile http://labs.trolltech.com/blogs/2008/04/04/marble-running-on-windows-ce/
In effetti nell'analisi mi ero scordato di Windows CE/Mobile :D
Anche qui Java non è praticamente utilizzabile se non con virtual machine a pagamento e con un framework ridotto o addirittura diverso.
Python dovrebbe avere un porting, ma non so se c'è un porting di pyGtk.
In effetti nell'analisi mi ero scordato di Windows CE/Mobile :D
Anche qui Java non è praticamente utilizzabile se non con virtual machine a pagamento e con un framework ridotto o addirittura diverso.
Python dovrebbe avere un porting, ma non so se c'è un porting di pyGtk.
insane74
22-02-2010, 22:43
guarda che gli smartphone più diffusi di tutti sn quelli nokia e cn un bel distacco da android e da iphone! Inoltre lo sviluppatore grazie alle qt potrà programmare per symbian, maemo/meego e windows mobile (è da vedere però come andranno le cose per windows phone 7), inoltre il toolkit è lo stesso per sviluppare su pc e i porting sn facili! a me lo sviluppatore sembra più invogliato a sviluppare in QT se ragioniamo così! Io guarderei la diffusione dei cellulari, i primi 5 produttori sn Nokia, samsung, lg, motorola e sonyericsson Poi vengono rim, apple, htc! Inoltre gli smartphone in assoluto più diffusi sn appunto i symbian! Apple vende tanto nella fascia Alta del mercato ma il numero totale di dispositivi è minore di quello nokia che pizza symbian anche su telefoni di 200 euro!!! inoltre secondo questo ragionamento RIM /blackbarry) dovrebbe chiudere i battenti :sofico:
Cmq, per chi interessa http://www.qt-iphone.com/Introduction.html
tutte cose condivisibili...
ora però guardiamo un pò in ottica "di mercato"...
facciamo qualche ricerca del tipo "offerte di lavoro"...
quante ne trovi in cui è richiesta la conoscenza delle qt?
0?
guarda un pò quanti chiedono iphone? ehi, ma è appena nato! è poco diffuso!
;)
noi che siamo "fuori" dai giri possiamo anche farci dei bei viaggi su chi/cosa/quando è meglio, ma quando si scende nel mondo del lavoro, quando si devono fare scelte "con un budget da rispettare", ecco che "qt vs gtk" o "kde vs gnome" interessa solo ai blogger.
a quelli che investono soldi interessa solo questo: se scrivo l'applicazione X con il linguaggio Y che target raggiungo? e che visibilità ho?
dove stanno spostando il mercato? tutto su internet, sul cloud computing, sulla connessione permanente alla rete, sulle applicazioni remote.
e qui entrano in ballo le tecnologie per sviluppare questo genere di applicazioni.
con le qt si faranno delle belle interfacce, un buon DE, ma le app "cloud" non le fai con le qt, le fai in java/.net. e se in java sviluppi per virtualmente qualunque piattaforma (ok, con i dovuti aggiustamenti) e girano in qualunque browser, se con un'app .NET raggiungi il 90% dei desktop mondiali... chi se le fila le qt?
qua si parla di "sesso degli angeli". possiamo anche tirar notte, ma alla fine contano le scelte di quelli che ci buttano i milioni.
vedremo se sono di più quelli di intel/nokia o di google o di apple.
il tutto ovviamente è solo una mia opinione.
http://google.com/trends?q=iphone%2C+android%2C+symbian&ctab=0&geo=all&date=all&sort=0
http://google.com/trends?q=gtk%2C+qt&ctab=0&geo=all&date=all&sort=0
http://google.com/trends?q=.net%2C+java%2C+c%2B%2B%2C+python&ctab=0&geo=all&date=all&sort=0
Cmq, per chi interessa http://www.qt-iphone.com/Introduction.html
tutte cose condivisibili...
ora però guardiamo un pò in ottica "di mercato"...
facciamo qualche ricerca del tipo "offerte di lavoro"...
quante ne trovi in cui è richiesta la conoscenza delle qt?
0?
guarda un pò quanti chiedono iphone? ehi, ma è appena nato! è poco diffuso!
;)
noi che siamo "fuori" dai giri possiamo anche farci dei bei viaggi su chi/cosa/quando è meglio, ma quando si scende nel mondo del lavoro, quando si devono fare scelte "con un budget da rispettare", ecco che "qt vs gtk" o "kde vs gnome" interessa solo ai blogger.
a quelli che investono soldi interessa solo questo: se scrivo l'applicazione X con il linguaggio Y che target raggiungo? e che visibilità ho?
dove stanno spostando il mercato? tutto su internet, sul cloud computing, sulla connessione permanente alla rete, sulle applicazioni remote.
e qui entrano in ballo le tecnologie per sviluppare questo genere di applicazioni.
con le qt si faranno delle belle interfacce, un buon DE, ma le app "cloud" non le fai con le qt, le fai in java/.net. e se in java sviluppi per virtualmente qualunque piattaforma (ok, con i dovuti aggiustamenti) e girano in qualunque browser, se con un'app .NET raggiungi il 90% dei desktop mondiali... chi se le fila le qt?
qua si parla di "sesso degli angeli". possiamo anche tirar notte, ma alla fine contano le scelte di quelli che ci buttano i milioni.
vedremo se sono di più quelli di intel/nokia o di google o di apple.
il tutto ovviamente è solo una mia opinione.
http://google.com/trends?q=iphone%2C+android%2C+symbian&ctab=0&geo=all&date=all&sort=0
http://google.com/trends?q=gtk%2C+qt&ctab=0&geo=all&date=all&sort=0
http://google.com/trends?q=.net%2C+java%2C+c%2B%2B%2C+python&ctab=0&geo=all&date=all&sort=0
zephyr83
22-02-2010, 23:21
tutte cose condivisibili...
ora però guardiamo un pò in ottica "di mercato"...
facciamo qualche ricerca del tipo "offerte di lavoro"...
quante ne trovi in cui è richiesta la conoscenza delle qt?
0?
guarda un pò quanti chiedono iphone? ehi, ma è appena nato! è poco diffuso!
;)
noi che siamo "fuori" dai giri possiamo anche farci dei bei viaggi su chi/cosa/quando è meglio, ma quando si scende nel mondo del lavoro, quando si devono fare scelte "con un budget da rispettare", ecco che "qt vs gtk" o "kde vs gnome" interessa solo ai blogger.
a quelli che investono soldi interessa solo questo: se scrivo l'applicazione X con il linguaggio Y che target raggiungo? e che visibilità ho?
dove stanno spostando il mercato? tutto su internet, sul cloud computing, sulla connessione permanente alla rete, sulle applicazioni remote.
e qui entrano in ballo le tecnologie per sviluppare questo genere di applicazioni.
con le qt si faranno delle belle interfacce, un buon DE, ma le app "cloud" non le fai con le qt, le fai in java/.net. e se in java sviluppi per virtualmente qualunque piattaforma (ok, con i dovuti aggiustamenti) e girano in qualunque browser, se con un'app .NET raggiungi il 90% dei desktop mondiali... chi se le fila le qt?
qua si parla di "sesso degli angeli". possiamo anche tirar notte, ma alla fine contano le scelte di quelli che ci buttano i milioni.
vedremo se sono di più quelli di intel/nokia o di google o di apple.
il tutto ovviamente è solo una mia opinione.
http://google.com/trends?q=iphone%2C+android%2C+symbian&ctab=0&geo=all&date=all&sort=0
http://google.com/trends?q=gtk%2C+qt&ctab=0&geo=all&date=all&sort=0
http://google.com/trends?q=.net%2C+java%2C+c%2B%2B%2C+python&ctab=0&geo=all&date=all&sort=0
:confused: ma chi ti chiede per lavoro di programmare per l'iphone??? poi perché cn le qt nn puoi fare could e cn .net si? e se cn .NET raggiungi il 90% dei desktop mondiali, cn le qt raggiungi il 99%! Quello che fai cn .net lo fai anche cn QT e l'applicazione gira su windows, osx e mac! cn .net sei fermo a windows! nn capisco quale sia la limitazione di usare le QT per applicazioni could dove in realtà puoi benissimo fare a meno di tutti i linguaggi sopracitati, basta php volendo!! La diffusione di una cosa nn è in diretta relazione cn le sue capacità perché altrimenti linux fa schifo e windows è il migliore del mondo ;) secondo il tuo ragionamento gnu/linux nn avrebbe senso di esistere ed è meglio windows! A sto punto anche le gtk sn totalmente inutili :sofico:
Cmq solitamente a un programmatore chiedono come prima cosa di conoscere bene un linguaggio di programmazione tipo C, C++, python, java, ecc ecc......poi al massimo può essere espressamente richiesto di conoscere anche un toolkit come può essere .net che ovviamente su windows va per la maggiore. ma se uno conosce C++ fa presto a passare a programmare in QT, idem epr chi conosce python!
ora però guardiamo un pò in ottica "di mercato"...
facciamo qualche ricerca del tipo "offerte di lavoro"...
quante ne trovi in cui è richiesta la conoscenza delle qt?
0?
guarda un pò quanti chiedono iphone? ehi, ma è appena nato! è poco diffuso!
;)
noi che siamo "fuori" dai giri possiamo anche farci dei bei viaggi su chi/cosa/quando è meglio, ma quando si scende nel mondo del lavoro, quando si devono fare scelte "con un budget da rispettare", ecco che "qt vs gtk" o "kde vs gnome" interessa solo ai blogger.
a quelli che investono soldi interessa solo questo: se scrivo l'applicazione X con il linguaggio Y che target raggiungo? e che visibilità ho?
dove stanno spostando il mercato? tutto su internet, sul cloud computing, sulla connessione permanente alla rete, sulle applicazioni remote.
e qui entrano in ballo le tecnologie per sviluppare questo genere di applicazioni.
con le qt si faranno delle belle interfacce, un buon DE, ma le app "cloud" non le fai con le qt, le fai in java/.net. e se in java sviluppi per virtualmente qualunque piattaforma (ok, con i dovuti aggiustamenti) e girano in qualunque browser, se con un'app .NET raggiungi il 90% dei desktop mondiali... chi se le fila le qt?
qua si parla di "sesso degli angeli". possiamo anche tirar notte, ma alla fine contano le scelte di quelli che ci buttano i milioni.
vedremo se sono di più quelli di intel/nokia o di google o di apple.
il tutto ovviamente è solo una mia opinione.
http://google.com/trends?q=iphone%2C+android%2C+symbian&ctab=0&geo=all&date=all&sort=0
http://google.com/trends?q=gtk%2C+qt&ctab=0&geo=all&date=all&sort=0
http://google.com/trends?q=.net%2C+java%2C+c%2B%2B%2C+python&ctab=0&geo=all&date=all&sort=0
:confused: ma chi ti chiede per lavoro di programmare per l'iphone??? poi perché cn le qt nn puoi fare could e cn .net si? e se cn .NET raggiungi il 90% dei desktop mondiali, cn le qt raggiungi il 99%! Quello che fai cn .net lo fai anche cn QT e l'applicazione gira su windows, osx e mac! cn .net sei fermo a windows! nn capisco quale sia la limitazione di usare le QT per applicazioni could dove in realtà puoi benissimo fare a meno di tutti i linguaggi sopracitati, basta php volendo!! La diffusione di una cosa nn è in diretta relazione cn le sue capacità perché altrimenti linux fa schifo e windows è il migliore del mondo ;) secondo il tuo ragionamento gnu/linux nn avrebbe senso di esistere ed è meglio windows! A sto punto anche le gtk sn totalmente inutili :sofico:
Cmq solitamente a un programmatore chiedono come prima cosa di conoscere bene un linguaggio di programmazione tipo C, C++, python, java, ecc ecc......poi al massimo può essere espressamente richiesto di conoscere anche un toolkit come può essere .net che ovviamente su windows va per la maggiore. ma se uno conosce C++ fa presto a passare a programmare in QT, idem epr chi conosce python!
insane74
22-02-2010, 23:35
:confused: ma chi ti chiede per lavoro di programmare per l'iphone??? poi perché cn le qt nn puoi fare could e cn .net si? e se cn .NET raggiungi il 90% dei desktop mondiali, cn le qt raggiungi il 99%! Quello che fai cn .net lo fai anche cn QT e l'applicazione gira su windows, osx e mac! cn .net sei fermo a windows! nn capisco quale sia la limitazione di usare le QT per applicazioni could dove in realtà puoi benissimo fare a meno di tutti i linguaggi sopracitati, basta php volendo!! La diffusione di una cosa nn è in diretta relazione cn le sue capacità perché altrimenti linux fa schifo e windows è il migliore del mondo ;) secondo il tuo ragionamento gnu/linux nn avrebbe senso di esistere ed è meglio windows! A sto punto anche le gtk sn totalmente inutili :sofico:
Cmq solitamente a un programmatore chiedono come prima cosa di conoscere bene un linguaggio di programmazione tipo C, C++, python, java, ecc ecc......poi al massimo può essere espressamente richiesto di conoscere anche un toolkit come può essere .net che ovviamente su windows va per la maggiore. ma se uno conosce C++ fa presto a passare a programmare in QT, idem epr chi conosce python!
evidentemente mi sono espresso male o non riesco a farmi intendere...
è facile dire "le qt girano su più piattaforme che .NET, quindi l'app X girerà ovunque, quindi sviluppo con le qt perché mi conviene".
la realtà è che il 90% del mercato desktop è MS, quindi è più "facile" sviluppare per quell'ambiente, ed quasi sempre "naturale" scegliere tecnologie MS per sviluppare in ambiente MS (e te lo dice uno che dal 99 lavora nell'IT, sviluppo solo su win, e che settimana scorsa ha aperto una discussione proprio qui su come "scappare" da MS per poter lavorare solo in ambiente linux!).
ripeto: al di la di "conoscere c++", in quanti annunci hai letto "richiesta conoscenza librerie QT" e in quanti ".NET" o "java EE"?
spassionatamente, se dovessi dire ad un tizio che deve iniziare a studiare per la sua futura carriera, gli diresti di puntare su .net? su java? o su c++/qt?
i numeri in gioco parlano chiaro, e si tirano appresso tutto quello che gravita attorno.
sicuramente intel & nokia sono colossi con molti assi nella manica.
potete continuare a dire "con le qt scrivi ovunque", ma io di app qt che girano su win, linux, osx, telefoni & co non ne ho vista manco una.
se ne avete una (e dico, la stessa app su tutte le piattaforme) aspetto di essere smentito.
altrimenti, è "solo" un ottimo toolkit che usano in pochissimi.
non significa che non sia ottimo, significa solo che "non conta".
ripeto cmq per l'ennesima volta, vedremo nel prossimo futuro dove ci porterà il mercato.
ciauz a tutti. :cincin:
PS: in merito all'iphone, a me non lo chiede nessuno, perché lavoro in tutt'altro settore (logistica), però "mi guardo attorno", e c'è molto "movimento" in tale proposito. non tanto per i numeri in gioco (i terminali iphone sono pochissimi rispetto ad altre marche) quanto ovviamente per la "visibilità". e come si sa, porta soldi!
Cmq solitamente a un programmatore chiedono come prima cosa di conoscere bene un linguaggio di programmazione tipo C, C++, python, java, ecc ecc......poi al massimo può essere espressamente richiesto di conoscere anche un toolkit come può essere .net che ovviamente su windows va per la maggiore. ma se uno conosce C++ fa presto a passare a programmare in QT, idem epr chi conosce python!
evidentemente mi sono espresso male o non riesco a farmi intendere...
è facile dire "le qt girano su più piattaforme che .NET, quindi l'app X girerà ovunque, quindi sviluppo con le qt perché mi conviene".
la realtà è che il 90% del mercato desktop è MS, quindi è più "facile" sviluppare per quell'ambiente, ed quasi sempre "naturale" scegliere tecnologie MS per sviluppare in ambiente MS (e te lo dice uno che dal 99 lavora nell'IT, sviluppo solo su win, e che settimana scorsa ha aperto una discussione proprio qui su come "scappare" da MS per poter lavorare solo in ambiente linux!).
ripeto: al di la di "conoscere c++", in quanti annunci hai letto "richiesta conoscenza librerie QT" e in quanti ".NET" o "java EE"?
spassionatamente, se dovessi dire ad un tizio che deve iniziare a studiare per la sua futura carriera, gli diresti di puntare su .net? su java? o su c++/qt?
i numeri in gioco parlano chiaro, e si tirano appresso tutto quello che gravita attorno.
sicuramente intel & nokia sono colossi con molti assi nella manica.
potete continuare a dire "con le qt scrivi ovunque", ma io di app qt che girano su win, linux, osx, telefoni & co non ne ho vista manco una.
se ne avete una (e dico, la stessa app su tutte le piattaforme) aspetto di essere smentito.
altrimenti, è "solo" un ottimo toolkit che usano in pochissimi.
non significa che non sia ottimo, significa solo che "non conta".
ripeto cmq per l'ennesima volta, vedremo nel prossimo futuro dove ci porterà il mercato.
ciauz a tutti. :cincin:
PS: in merito all'iphone, a me non lo chiede nessuno, perché lavoro in tutt'altro settore (logistica), però "mi guardo attorno", e c'è molto "movimento" in tale proposito. non tanto per i numeri in gioco (i terminali iphone sono pochissimi rispetto ad altre marche) quanto ovviamente per la "visibilità". e come si sa, porta soldi!
zephyr83
23-02-2010, 00:04
evidentemente mi sono espresso male o non riesco a farmi intendere...
è facile dire "le qt girano su più piattaforme che .NET, quindi l'app X girerà ovunque, quindi sviluppo con le qt perché mi conviene".
la realtà è che il 90% del mercato desktop è MS, quindi è più "facile" sviluppare per quell'ambiente, ed quasi sempre "naturale" scegliere tecnologie MS per sviluppare in ambiente MS (e te lo dice uno che dal 99 lavora nell'IT, sviluppo solo su win, e che settimana scorsa ha aperto una discussione proprio qui su come "scappare" da MS per poter lavorare solo in ambiente linux!).
ripeto: al di la di "conoscere c++", in quanti annunci hai letto "richiesta conoscenza librerie QT" e in quanti ".NET" o "java EE"?
spassionatamente, se dovessi dire ad un tizio che deve iniziare a studiare per la sua futura carriera, gli diresti di puntare su .net? su java? o su c++/qt?
i numeri in gioco parlano chiaro, e si tirano appresso tutto quello che gravita attorno.
sicuramente intel & nokia sono colossi con molti assi nella manica.
potete continuare a dire "con le qt scrivi ovunque", ma io di app qt che girano su win, linux, osx, telefoni & co non ne ho vista manco una.
se ne avete una (e dico, la stessa app su tutte le piattaforme) aspetto di essere smentito.
altrimenti, è "solo" un ottimo toolkit che usano in pochissimi.
non significa che non sia ottimo, significa solo che "non conta".
ripeto cmq per l'ennesima volta, vedremo nel prossimo futuro dove ci porterà il mercato.
ciauz a tutti. :cincin:
PS: in merito all'iphone, a me non lo chiede nessuno, perché lavoro in tutt'altro settore (logistica), però "mi guardo attorno", e c'è molto "movimento" in tale proposito. non tanto per i numeri in gioco (i terminali iphone sono pochissimi rispetto ad altre marche) quanto ovviamente per la "visibilità". e come si sa, porta soldi!
vlc nn lo conosci? :sofico: e questo gira pure sui telefoni!! virtualbox? google earth? scribus? :) anche skype usa le QT e pure adobe elements (ma quest'ultimo per linux nn c'è), tutte applicazioni presenti su linux, osx e windows! Ci sn anche alcuni software "professionali" (o specifici) realizzati in qt che girano su windows, linux e osx tipo FECO in campo aerospaziale
http://www.feko.info/industries/aerospace
http://qt.nokia.com/qt-in-use/qt-in-aerospace
Il problema è sempre il solito relativo alla "diffusione" e sempre e solo relativo a windows su desktop! Java su windows in ambiente desktop nn mi pare si veda tanto! in altri campi invece è utilizzatissimo. QT è vero che è usato pochissimo ed è quello di cui si rammaricano in diversi in questo topic! C'era un eccellente strumento nel mondo linux che nn è stato adeguatamente supportato! anziché spingere su mono perché nn si poteva spingere su QT? Inoltre adesso cn nokia e i propri smartphone (e pure cn intel cn meego) la possibilità di diffusione c'è eccome!!
Inoltre voglio ricordarti che le applicazioni su iphone sn nate prima ancora che uscisse l'SDK e c'è pure VLC (ovviamente per quelli cn Jailbreak). Quindi gli strumenti e la diffusione contano fino a un certo punto!! Altro esempio noto è il java2me sui cellulari che nn è mai riuscito a diffondersi e a essere supportato adeguatamente! Oppure prendiamo il caso symbian vs windows mobile! quest'ultimo c'era da più tempo, aveva un sdk decisamente migliore (poi è arrivato anche .net) eppure ci sn sempre stati più smartphone symbian e questo grazie solo a nokia.
Se uno deve sempre e solo guardare a quello che offre il mercato al momento nn si va mai avanti :) Adesso per le QT c'è un enorme possibilità grazie a nokia (e a quanto pare pure intel) e saranno senza ombra di dubbio le librerie usate sul maggior numero di dispositivi (su questo proprio nn ci piove). Se nokia sarà brava a creare un'ottima struttura, cioè un ottimo store (l'ovi store attualmente è pietoso) gli sviluppatori saranno sicuramente portati a sviluppare per questa piattaforma che raggiunge MOLTI più clienti di quanto ne possono raggiungere apple, htc o rim! Se poi aggiungiamo i tablet e gli smartbook/netbook il passaggio ai pc è breve. io vedo grandi possibilità e ci spero :) se dietro ci fossero grosse aziende nel mondo linux ad appoggiare la cosa magari qualche software house potrebbe decidere di spostarsi su qt piuttosto che su .net. Ad esempio una canonical o una novell potrebbero stringere accordi cn adobe e magari chiederle di potare adobe elements (visto che è già in qt) su linux e sperare in futuro in una versione di photoshop!! Il problema dell'interoperabilità è da superare se no la diffusione di qualsiasi altro sistema operativo al difuori di windows è quasi impossibile (almeno in ambito lavorativo). Fortuna che cn la virtualizzazione si stanno facendo passi da gigante e si può ovviare ma ancora è presto!!!
Poi ovviamente, sui forum capita anche di discutere del sesso degli angeli ma è un po' quello che facevano i "padri fondatori" del software libero e di linux :) sembrava tutto impossibile e invece.......;)
è facile dire "le qt girano su più piattaforme che .NET, quindi l'app X girerà ovunque, quindi sviluppo con le qt perché mi conviene".
la realtà è che il 90% del mercato desktop è MS, quindi è più "facile" sviluppare per quell'ambiente, ed quasi sempre "naturale" scegliere tecnologie MS per sviluppare in ambiente MS (e te lo dice uno che dal 99 lavora nell'IT, sviluppo solo su win, e che settimana scorsa ha aperto una discussione proprio qui su come "scappare" da MS per poter lavorare solo in ambiente linux!).
ripeto: al di la di "conoscere c++", in quanti annunci hai letto "richiesta conoscenza librerie QT" e in quanti ".NET" o "java EE"?
spassionatamente, se dovessi dire ad un tizio che deve iniziare a studiare per la sua futura carriera, gli diresti di puntare su .net? su java? o su c++/qt?
i numeri in gioco parlano chiaro, e si tirano appresso tutto quello che gravita attorno.
sicuramente intel & nokia sono colossi con molti assi nella manica.
potete continuare a dire "con le qt scrivi ovunque", ma io di app qt che girano su win, linux, osx, telefoni & co non ne ho vista manco una.
se ne avete una (e dico, la stessa app su tutte le piattaforme) aspetto di essere smentito.
altrimenti, è "solo" un ottimo toolkit che usano in pochissimi.
non significa che non sia ottimo, significa solo che "non conta".
ripeto cmq per l'ennesima volta, vedremo nel prossimo futuro dove ci porterà il mercato.
ciauz a tutti. :cincin:
PS: in merito all'iphone, a me non lo chiede nessuno, perché lavoro in tutt'altro settore (logistica), però "mi guardo attorno", e c'è molto "movimento" in tale proposito. non tanto per i numeri in gioco (i terminali iphone sono pochissimi rispetto ad altre marche) quanto ovviamente per la "visibilità". e come si sa, porta soldi!
vlc nn lo conosci? :sofico: e questo gira pure sui telefoni!! virtualbox? google earth? scribus? :) anche skype usa le QT e pure adobe elements (ma quest'ultimo per linux nn c'è), tutte applicazioni presenti su linux, osx e windows! Ci sn anche alcuni software "professionali" (o specifici) realizzati in qt che girano su windows, linux e osx tipo FECO in campo aerospaziale
http://www.feko.info/industries/aerospace
http://qt.nokia.com/qt-in-use/qt-in-aerospace
Il problema è sempre il solito relativo alla "diffusione" e sempre e solo relativo a windows su desktop! Java su windows in ambiente desktop nn mi pare si veda tanto! in altri campi invece è utilizzatissimo. QT è vero che è usato pochissimo ed è quello di cui si rammaricano in diversi in questo topic! C'era un eccellente strumento nel mondo linux che nn è stato adeguatamente supportato! anziché spingere su mono perché nn si poteva spingere su QT? Inoltre adesso cn nokia e i propri smartphone (e pure cn intel cn meego) la possibilità di diffusione c'è eccome!!
Inoltre voglio ricordarti che le applicazioni su iphone sn nate prima ancora che uscisse l'SDK e c'è pure VLC (ovviamente per quelli cn Jailbreak). Quindi gli strumenti e la diffusione contano fino a un certo punto!! Altro esempio noto è il java2me sui cellulari che nn è mai riuscito a diffondersi e a essere supportato adeguatamente! Oppure prendiamo il caso symbian vs windows mobile! quest'ultimo c'era da più tempo, aveva un sdk decisamente migliore (poi è arrivato anche .net) eppure ci sn sempre stati più smartphone symbian e questo grazie solo a nokia.
Se uno deve sempre e solo guardare a quello che offre il mercato al momento nn si va mai avanti :) Adesso per le QT c'è un enorme possibilità grazie a nokia (e a quanto pare pure intel) e saranno senza ombra di dubbio le librerie usate sul maggior numero di dispositivi (su questo proprio nn ci piove). Se nokia sarà brava a creare un'ottima struttura, cioè un ottimo store (l'ovi store attualmente è pietoso) gli sviluppatori saranno sicuramente portati a sviluppare per questa piattaforma che raggiunge MOLTI più clienti di quanto ne possono raggiungere apple, htc o rim! Se poi aggiungiamo i tablet e gli smartbook/netbook il passaggio ai pc è breve. io vedo grandi possibilità e ci spero :) se dietro ci fossero grosse aziende nel mondo linux ad appoggiare la cosa magari qualche software house potrebbe decidere di spostarsi su qt piuttosto che su .net. Ad esempio una canonical o una novell potrebbero stringere accordi cn adobe e magari chiederle di potare adobe elements (visto che è già in qt) su linux e sperare in futuro in una versione di photoshop!! Il problema dell'interoperabilità è da superare se no la diffusione di qualsiasi altro sistema operativo al difuori di windows è quasi impossibile (almeno in ambito lavorativo). Fortuna che cn la virtualizzazione si stanno facendo passi da gigante e si può ovviare ma ancora è presto!!!
Poi ovviamente, sui forum capita anche di discutere del sesso degli angeli ma è un po' quello che facevano i "padri fondatori" del software libero e di linux :) sembrava tutto impossibile e invece.......;)
insane74
23-02-2010, 00:15
vlc nn lo conosci? :sofico: e questo gira pure sui telefoni!! virtualbox? google earth? scribus? :) anche skype usa le QT e pure adobe elements (ma quest'ultimo per linux nn c'è), tutte applicazioni presenti su linux, osx e windows! Ci sn anche alcuni software "professionali" (o specifici) realizzati in qt che girano su windows, linux e osx tipo FECO in campo aerospaziale
http://www.feko.info/industries/aerospace
http://qt.nokia.com/qt-in-use/qt-in-aerospace
Il problema è sempre il solito relativo alla "diffusione" e sempre e solo relativo a windows su desktop! Java su windows in ambiente desktop nn mi pare si veda tanto! in altri campi invece è utilizzatissimo. QT è vero che è usato pochissimo ed è quello di cui si rammaricano in diversi in questo topic! C'era un eccellente strumento nel mondo linux che nn è stato adeguatamente supportato! anziché spingere su mono perché nn si poteva spingere su QT? Inoltre adesso cn nokia e i propri smartphone (e pure cn intel cn meego) la possibilità di diffusione c'è eccome!!
Inoltre voglio ricordarti che le applicazioni su iphone sn nate prima ancora che uscisse l'SDK e c'è pure VLC (ovviamente per quelli cn Jailbreak). Quindi gli strumenti e la diffusione contano fino a un certo punto!! Altro esempio noto è il java2me sui cellulari che nn è mai riuscito a diffondersi e a essere supportato adeguatamente! Oppure prendiamo il caso symbian vs windows mobile! quest'ultimo c'era da più tempo, aveva un sdk decisamente migliore (poi è arrivato anche .net) eppure ci sn sempre stati più smartphone symbian e questo grazie solo a nokia.
Se uno deve sempre e solo guardare a quello che offre il mercato al momento nn si va mai avanti :) Adesso per le QT c'è un enorme possibilità grazie a nokia (e a quanto pare pure intel) e saranno senza ombra di dubbio le librerie usate sul maggior numero di dispositivi (su questo proprio nn ci piove). Se nokia sarà brava a creare un'ottima struttura, cioè un ottimo store (l'ovi store attualmente è pietoso) gli sviluppatori saranno sicuramente portati a sviluppare per questa piattaforma che raggiunge MOLTI più clienti di quanto ne possono raggiungere apple, htc o rim! Se poi aggiungiamo i tablet e gli smartbook/netbook il passaggio ai pc è breve. io vedo grandi possibilità e ci spero :) se dietro ci fossero grosse aziende nel mondo linux ad appoggiare la cosa magari qualche software house potrebbe decidere di spostarsi su qt piuttosto che su .net. Ad esempio una canonical o una novell potrebbero stringere accordi cn adobe e magari chiederle di potare adobe elements (visto che è già in qt) su linux e sperare in futuro in una versione di photoshop!! Il problema dell'interoperabilità è da superare se no la diffusione di qualsiasi altro sistema operativo al difuori di windows è quasi impossibile (almeno in ambito lavorativo). Fortuna che cn la virtualizzazione si stanno facendo passi da gigante e si può ovviare ma ancora è presto!!!
Poi ovviamente, sui forum capita anche di discutere del sesso degli angeli ma è un po' quello che facevano i "padri fondatori" del software libero e di linux :) sembrava tutto impossibile e invece.......;)
concordo su tutto e contemporaneamente dissento! :p
posso solo dire: vedremo.
personalmente non credo che "vinceranno" le qt (intel/nokia) ma le soluzioni google/apple.
win insegna che non sempre vince il "migliore"... :oink:
buonanotte! ;)
http://www.feko.info/industries/aerospace
http://qt.nokia.com/qt-in-use/qt-in-aerospace
Il problema è sempre il solito relativo alla "diffusione" e sempre e solo relativo a windows su desktop! Java su windows in ambiente desktop nn mi pare si veda tanto! in altri campi invece è utilizzatissimo. QT è vero che è usato pochissimo ed è quello di cui si rammaricano in diversi in questo topic! C'era un eccellente strumento nel mondo linux che nn è stato adeguatamente supportato! anziché spingere su mono perché nn si poteva spingere su QT? Inoltre adesso cn nokia e i propri smartphone (e pure cn intel cn meego) la possibilità di diffusione c'è eccome!!
Inoltre voglio ricordarti che le applicazioni su iphone sn nate prima ancora che uscisse l'SDK e c'è pure VLC (ovviamente per quelli cn Jailbreak). Quindi gli strumenti e la diffusione contano fino a un certo punto!! Altro esempio noto è il java2me sui cellulari che nn è mai riuscito a diffondersi e a essere supportato adeguatamente! Oppure prendiamo il caso symbian vs windows mobile! quest'ultimo c'era da più tempo, aveva un sdk decisamente migliore (poi è arrivato anche .net) eppure ci sn sempre stati più smartphone symbian e questo grazie solo a nokia.
Se uno deve sempre e solo guardare a quello che offre il mercato al momento nn si va mai avanti :) Adesso per le QT c'è un enorme possibilità grazie a nokia (e a quanto pare pure intel) e saranno senza ombra di dubbio le librerie usate sul maggior numero di dispositivi (su questo proprio nn ci piove). Se nokia sarà brava a creare un'ottima struttura, cioè un ottimo store (l'ovi store attualmente è pietoso) gli sviluppatori saranno sicuramente portati a sviluppare per questa piattaforma che raggiunge MOLTI più clienti di quanto ne possono raggiungere apple, htc o rim! Se poi aggiungiamo i tablet e gli smartbook/netbook il passaggio ai pc è breve. io vedo grandi possibilità e ci spero :) se dietro ci fossero grosse aziende nel mondo linux ad appoggiare la cosa magari qualche software house potrebbe decidere di spostarsi su qt piuttosto che su .net. Ad esempio una canonical o una novell potrebbero stringere accordi cn adobe e magari chiederle di potare adobe elements (visto che è già in qt) su linux e sperare in futuro in una versione di photoshop!! Il problema dell'interoperabilità è da superare se no la diffusione di qualsiasi altro sistema operativo al difuori di windows è quasi impossibile (almeno in ambito lavorativo). Fortuna che cn la virtualizzazione si stanno facendo passi da gigante e si può ovviare ma ancora è presto!!!
Poi ovviamente, sui forum capita anche di discutere del sesso degli angeli ma è un po' quello che facevano i "padri fondatori" del software libero e di linux :) sembrava tutto impossibile e invece.......;)
concordo su tutto e contemporaneamente dissento! :p
posso solo dire: vedremo.
personalmente non credo che "vinceranno" le qt (intel/nokia) ma le soluzioni google/apple.
win insegna che non sempre vince il "migliore"... :oink:
buonanotte! ;)
zephyr83
23-02-2010, 00:43
concordo su tutto e contemporaneamente dissento! :p
posso solo dire: vedremo.
personalmente non credo che "vinceranno" le qt (intel/nokia) ma le soluzioni google/apple.
win insegna che non sempre vince il "migliore"... :oink:
buonanotte! ;)
ah bhe sul vincere nn ho mai detto niente :) anzi, mi sa che nessuno l'ha mai pronosticato, anzi "noi sostenitori" sembriamo al quanto amareggiati a riguarod :D La soluzione apple vince solo per se stessa.......è l'insieme iphone che vince ma stiamo sempre parlando di applicazioni per cellulari :) sicuramente android è quello più promettete e cn la maggior espansione soprattutto se verrà potato sui netbook (chromeos è Cloud e nn gireranno applicazioni "native", questo sistema è una bella incognita). Ma se tutto si basa sulla diffusione dei dispositivi per le qt nn dovrebbe esserci nessun rischio perché una NON diffusione di questo toolkit vorrebbe dire il morte di nokia e la vedo assai dura come cosa :sofico: In ambito mobile la cosa "non mi preoccupa".....spero però che la diffusione in questo settore possa riflettersi almeno in parte in ambito desktop. La mia speranza è questa :)
posso solo dire: vedremo.
personalmente non credo che "vinceranno" le qt (intel/nokia) ma le soluzioni google/apple.
win insegna che non sempre vince il "migliore"... :oink:
buonanotte! ;)
ah bhe sul vincere nn ho mai detto niente :) anzi, mi sa che nessuno l'ha mai pronosticato, anzi "noi sostenitori" sembriamo al quanto amareggiati a riguarod :D La soluzione apple vince solo per se stessa.......è l'insieme iphone che vince ma stiamo sempre parlando di applicazioni per cellulari :) sicuramente android è quello più promettete e cn la maggior espansione soprattutto se verrà potato sui netbook (chromeos è Cloud e nn gireranno applicazioni "native", questo sistema è una bella incognita). Ma se tutto si basa sulla diffusione dei dispositivi per le qt nn dovrebbe esserci nessun rischio perché una NON diffusione di questo toolkit vorrebbe dire il morte di nokia e la vedo assai dura come cosa :sofico: In ambito mobile la cosa "non mi preoccupa".....spero però che la diffusione in questo settore possa riflettersi almeno in parte in ambito desktop. La mia speranza è questa :)
cionci
23-02-2010, 07:55
personalmente non credo che "vinceranno" le qt (intel/nokia) ma le soluzioni google/apple.
E' anche possibile che non siano in gara ;)
Meego andrà su CPU x86, Android su CPU Arm, iPhone invece è una cosa a parte. ChromeOS sinceramente lo vedo solo per sistemi diskless (altrimenti a cosa servirebbe il disco fisso ?) o comunque con connessione sempre disponibile (purtroppo non credo che sarà mai sempre disponibile sui dispositivi mobile, almeno a prezzi decenti).
E' anche possibile che non siano in gara ;)
Meego andrà su CPU x86, Android su CPU Arm, iPhone invece è una cosa a parte. ChromeOS sinceramente lo vedo solo per sistemi diskless (altrimenti a cosa servirebbe il disco fisso ?) o comunque con connessione sempre disponibile (purtroppo non credo che sarà mai sempre disponibile sui dispositivi mobile, almeno a prezzi decenti).
insane74
23-02-2010, 08:53
E' anche possibile che non siano in gara ;)
beh, io invece credo di si. la lotta è serrata. intel&nokia producono hw e sw. google principalmente sw, ma ha già presentato il suo smartphone e si vocifera che produrrà netbook con preinstallato chrome os, apple fa sia hw che sw...
ognuno cerca di portare acqua al suo mulino.
ora, sempre a prescindere dalla soluzione migliore sulla carta, su che cavallo scommettereste i vostri soldi?
ad uno sviluppatore "in erba", su cosa consigliereste di concentrare le sue forze?
escludendo discorsi "filosofici", di libertà, ecc ecc.
proprio mero opportunismo: se imparo bene X troverò lavoro perché Y è la soluzione che andrà per la maggiore.
in fondo lo dobbiamo pagare, sto mutuo, no?
ecco, sarà che io c'ho un bel 25 anni di mutuo da pagare, ma se penso in quest'ottica, salterei sul treno di google. e su quei vagoni le qt... :fagiano:
beh, io invece credo di si. la lotta è serrata. intel&nokia producono hw e sw. google principalmente sw, ma ha già presentato il suo smartphone e si vocifera che produrrà netbook con preinstallato chrome os, apple fa sia hw che sw...
ognuno cerca di portare acqua al suo mulino.
ora, sempre a prescindere dalla soluzione migliore sulla carta, su che cavallo scommettereste i vostri soldi?
ad uno sviluppatore "in erba", su cosa consigliereste di concentrare le sue forze?
escludendo discorsi "filosofici", di libertà, ecc ecc.
proprio mero opportunismo: se imparo bene X troverò lavoro perché Y è la soluzione che andrà per la maggiore.
in fondo lo dobbiamo pagare, sto mutuo, no?
ecco, sarà che io c'ho un bel 25 anni di mutuo da pagare, ma se penso in quest'ottica, salterei sul treno di google. e su quei vagoni le qt... :fagiano:
zephyr83
23-02-2010, 12:53
beh, io invece credo di si. la lotta è serrata. intel&nokia producono hw e sw. google principalmente sw, ma ha già presentato il suo smartphone e si vocifera che produrrà netbook con preinstallato chrome os, apple fa sia hw che sw...
ognuno cerca di portare acqua al suo mulino.
ora, sempre a prescindere dalla soluzione migliore sulla carta, su che cavallo scommettereste i vostri soldi?
ad uno sviluppatore "in erba", su cosa consigliereste di concentrare le sue forze?
escludendo discorsi "filosofici", di libertà, ecc ecc.
proprio mero opportunismo: se imparo bene X troverò lavoro perché Y è la soluzione che andrà per la maggiore.
in fondo lo dobbiamo pagare, sto mutuo, no?
ecco, sarà che io c'ho un bel 25 anni di mutuo da pagare, ma se penso in quest'ottica, salterei sul treno di google. e su quei vagoni le qt... :fagiano:
credo che per uno sviluppatore nn dovrebbe essere un problema grosso conoscere almeno 2 linguaggi/framework :) cmq se parliamo in ottica di "possibilità" io direi QT visto che ci programmi per symbian (gli smartphone più diffusi), maemo/meego e windows mobile! Ma chi sa programmare in C++ fa presto a spostarsi su iphone mentre è un po' diversa la questione java....basta vedere quanti poting per iphone sn stati fatti subito (vlc su tutti) mentre NISBA per android (ancora nn c'è un lettore multimediale decente).
Cmq per me il problema nn è quello delle grosse software house che mi pare finora abbiano supportato sempre tutti i vari sistemi operativi da cellulari......il problema è per i "piccoli" programmatori, è loro che bisogna invogliare. Apple è quella che c'è riuscita meglio, google ha seguito bene e promette bene! però nokia ha un mercato vastissimo!!! inoltre ci sn anche RIM e Palm (con WebOs) che hanno "aperto" anche loro i propri sistemi alle applicazioni di terzi! io dico che, finché si vende hardware, c'è spazio per tutti!
Se dovessi buttarmi io nella programmazione inizierei sicuramente cn QT e Java :)
ognuno cerca di portare acqua al suo mulino.
ora, sempre a prescindere dalla soluzione migliore sulla carta, su che cavallo scommettereste i vostri soldi?
ad uno sviluppatore "in erba", su cosa consigliereste di concentrare le sue forze?
escludendo discorsi "filosofici", di libertà, ecc ecc.
proprio mero opportunismo: se imparo bene X troverò lavoro perché Y è la soluzione che andrà per la maggiore.
in fondo lo dobbiamo pagare, sto mutuo, no?
ecco, sarà che io c'ho un bel 25 anni di mutuo da pagare, ma se penso in quest'ottica, salterei sul treno di google. e su quei vagoni le qt... :fagiano:
credo che per uno sviluppatore nn dovrebbe essere un problema grosso conoscere almeno 2 linguaggi/framework :) cmq se parliamo in ottica di "possibilità" io direi QT visto che ci programmi per symbian (gli smartphone più diffusi), maemo/meego e windows mobile! Ma chi sa programmare in C++ fa presto a spostarsi su iphone mentre è un po' diversa la questione java....basta vedere quanti poting per iphone sn stati fatti subito (vlc su tutti) mentre NISBA per android (ancora nn c'è un lettore multimediale decente).
Cmq per me il problema nn è quello delle grosse software house che mi pare finora abbiano supportato sempre tutti i vari sistemi operativi da cellulari......il problema è per i "piccoli" programmatori, è loro che bisogna invogliare. Apple è quella che c'è riuscita meglio, google ha seguito bene e promette bene! però nokia ha un mercato vastissimo!!! inoltre ci sn anche RIM e Palm (con WebOs) che hanno "aperto" anche loro i propri sistemi alle applicazioni di terzi! io dico che, finché si vende hardware, c'è spazio per tutti!
Se dovessi buttarmi io nella programmazione inizierei sicuramente cn QT e Java :)
Barra
23-02-2010, 13:11
Tenendo conto che il 90% del fatturato nel settore mobile è dato dal software per iphone/ipod touch (con Android ben messo con gli applicativi opensource ma in difficoltà nel trovare una buona soluzione commerciale e symbian/blackberry e C messi maluccio) se si ha come target il settore mobile direi che la scelta migliore è sviluppare sul framework apple.
Dovessi però mettermi li a fare un gioco (o un app multipiattaforma) penso che la scelta più logica sarebbe Mono (e ridaje direte voi!). Mono gira su iphone, android, symbian, meego e mi permetterebbe il porting di un gioco su tutte queste piattaforme. Già è stato portato non ricordo quale engine 3d su iphone. stando al blog di de icaza il lavoro è stato completato in poche ore.
P.s. perchè avete più volte detto che GTK# non sono uguali a GTK+? Su http://en.wikipedia.org/wiki/Gtk_Sharp si parla di bingings a gtk+ (e non solo). Su http://www.mono-project.com/FAQ:_General#GUI_applications viene detto che mono può essere usato anche con python, java, javascipt e molti altri linuguaggi. Quindi quale resta il problema per una piena adozione?
Dovessi però mettermi li a fare un gioco (o un app multipiattaforma) penso che la scelta più logica sarebbe Mono (e ridaje direte voi!). Mono gira su iphone, android, symbian, meego e mi permetterebbe il porting di un gioco su tutte queste piattaforme. Già è stato portato non ricordo quale engine 3d su iphone. stando al blog di de icaza il lavoro è stato completato in poche ore.
P.s. perchè avete più volte detto che GTK# non sono uguali a GTK+? Su http://en.wikipedia.org/wiki/Gtk_Sharp si parla di bingings a gtk+ (e non solo). Su http://www.mono-project.com/FAQ:_General#GUI_applications viene detto che mono può essere usato anche con python, java, javascipt e molti altri linuguaggi. Quindi quale resta il problema per una piena adozione?
cionci
23-02-2010, 13:21
P.s. perchè avete più volte detto che GTK# non sono uguali a GTK+? Su http://en.wikipedia.org/wiki/Gtk_Sharp si parla di bingings a gtk+ (e non solo).
Perché GTK# è un binding ad oggetti.
Perché GTK# è un binding ad oggetti.
zephyr83
23-02-2010, 15:48
Tenendo conto che il 90% del fatturato nel settore mobile è dato dal software per iphone/ipod touch (con Android ben messo con gli applicativi opensource ma in difficoltà nel trovare una buona soluzione commerciale e symbian/blackberry e C messi maluccio) se si ha come target il settore mobile direi che la scelta migliore è sviluppare sul framework apple.
Dovessi però mettermi li a fare un gioco (o un app multipiattaforma) penso che la scelta più logica sarebbe Mono (e ridaje direte voi!). Mono gira su iphone, android, symbian, meego e mi permetterebbe il porting di un gioco su tutte queste piattaforme. Già è stato portato non ricordo quale engine 3d su iphone. stando al blog di de icaza il lavoro è stato completato in poche ore.
P.s. perchè avete più volte detto che GTK# non sono uguali a GTK+? Su http://en.wikipedia.org/wiki/Gtk_Sharp si parla di bingings a gtk+ (e non solo). Su http://www.mono-project.com/FAQ:_General#GUI_applications viene detto che mono può essere usato anche con python, java, javascipt e molti altri linguaggi. Quindi quale resta il problema per una piena adozione?
perché NON è la stessa cosa!! mono su iphone è un in pratica un "convertitore" altrimenti nn potrebbe esistere. Tutti i vari vantaggi di mono vanno a farsi benedire, devi ugualmente avere un mac e l'sdk dell'iphone e nn puoi riutilizzare il codice ".Net" di applicazioni "desktop" come si legge nelle faq
http://monotouch.net/FAQ#Can_I.c2.a0use_standard_desktop_Mono_assemblies_or_.NET.c2.a0assemblies_with_MonoTouch.3f
inoltre è anche un progetto commerciale e costa un sacco di soldi :sofico:
http://monotouch.net/Store
quale vantaggio ha lo sviluppatore a usare monotouch anziché l'sdk originaria di apple (che cmq ti serve)?
Cmq la stessa cosa si potrebbe fare cn le qt (e lo stanno facendo). su android le cose mi paiono ancora messe maluccio, idem su symbian! alla fine nn si risolve il problema dell'interoperabilità. Alla fine uno programma in mono perché questo conosce e si sta spingendo su questo, mica per chissà quali vantaggi.......e lo sviluppo dovrà sempre seguire quello di .Net dettato da microsoft! io continuo a dire che le QT sarebbero una soluzione decisamente migliore per tutto il mondo linux e open source (ma nn solo). Ovvio che se tutti continuano a spingere su mono e questo si diffonderà a dismisurà sarà la soluzione preferita da molti........ma nn sarebbe stato meglio spingere sulle qt? :stordita: è questo che voglio capire.......perché nn si è spinto sulle qt? Io ci vedo solo motivi "campanilistici" o di interesse di alcune aziende!
Cmq, vediamo cosa farà nokia! è vero che attualmente l'app store è quello che va meglio, ma è praticamente l'unico! Android segue ma è ancora molto distante e mancano molte applicazioni di un certo tipo (si sta aspettando C e C++ per realizzarle). nokia è quella che vende più terminali di tutti e se riesce a tirare su un bello store il toolkit QT avrà modo di diffondersi molto
Dovessi però mettermi li a fare un gioco (o un app multipiattaforma) penso che la scelta più logica sarebbe Mono (e ridaje direte voi!). Mono gira su iphone, android, symbian, meego e mi permetterebbe il porting di un gioco su tutte queste piattaforme. Già è stato portato non ricordo quale engine 3d su iphone. stando al blog di de icaza il lavoro è stato completato in poche ore.
P.s. perchè avete più volte detto che GTK# non sono uguali a GTK+? Su http://en.wikipedia.org/wiki/Gtk_Sharp si parla di bingings a gtk+ (e non solo). Su http://www.mono-project.com/FAQ:_General#GUI_applications viene detto che mono può essere usato anche con python, java, javascipt e molti altri linguaggi. Quindi quale resta il problema per una piena adozione?
perché NON è la stessa cosa!! mono su iphone è un in pratica un "convertitore" altrimenti nn potrebbe esistere. Tutti i vari vantaggi di mono vanno a farsi benedire, devi ugualmente avere un mac e l'sdk dell'iphone e nn puoi riutilizzare il codice ".Net" di applicazioni "desktop" come si legge nelle faq
http://monotouch.net/FAQ#Can_I.c2.a0use_standard_desktop_Mono_assemblies_or_.NET.c2.a0assemblies_with_MonoTouch.3f
inoltre è anche un progetto commerciale e costa un sacco di soldi :sofico:
http://monotouch.net/Store
quale vantaggio ha lo sviluppatore a usare monotouch anziché l'sdk originaria di apple (che cmq ti serve)?
Cmq la stessa cosa si potrebbe fare cn le qt (e lo stanno facendo). su android le cose mi paiono ancora messe maluccio, idem su symbian! alla fine nn si risolve il problema dell'interoperabilità. Alla fine uno programma in mono perché questo conosce e si sta spingendo su questo, mica per chissà quali vantaggi.......e lo sviluppo dovrà sempre seguire quello di .Net dettato da microsoft! io continuo a dire che le QT sarebbero una soluzione decisamente migliore per tutto il mondo linux e open source (ma nn solo). Ovvio che se tutti continuano a spingere su mono e questo si diffonderà a dismisurà sarà la soluzione preferita da molti........ma nn sarebbe stato meglio spingere sulle qt? :stordita: è questo che voglio capire.......perché nn si è spinto sulle qt? Io ci vedo solo motivi "campanilistici" o di interesse di alcune aziende!
Cmq, vediamo cosa farà nokia! è vero che attualmente l'app store è quello che va meglio, ma è praticamente l'unico! Android segue ma è ancora molto distante e mancano molte applicazioni di un certo tipo (si sta aspettando C e C++ per realizzarle). nokia è quella che vende più terminali di tutti e se riesce a tirare su un bello store il toolkit QT avrà modo di diffondersi molto
Barra
23-02-2010, 16:54
Il link che postato IMHO dice l'esatto contrario...
To reuse existing .NET code with MonoTouch, you must recompile your libraries with MonoTouch's compiler and base assemblies.
Quindi ricompilando con monotouch dovrebbe andare....
http://unity3d.com/ questo è un esempio di software portato su iphone grazie a mono, il risultato non è male, da quel che vedo è possibile compilare un gioco per windows, mac, osx e iphone, linue e presto android senza modifiche.
Tornando un pò + IT (ma non troppo): http://www.mono-project.com/Companies_Using_Mono. Tra le tante cito:
Versora (http://versora.com): Windows-to-Linux migration specialists Versora used Mono and C# to produce a cross-platform tool that helps companies move system and application setttings and user data.
Evidentemente a qualcuno il porting da windows a linux interessa....
Hai poi perfettamente ragione quando dici che mono e gtk in generale sono spinti dall'interesse di alcune aziende. Ma perché pensi che esistano RH, Oracle, Canonical, mandriva ecc cercano di fare soldi e Nokia ha investito nell'acquisto di trolltech per interessi economici, non certo per beneficenza...
Il numero di terminali venduti cmq poco incide in questo discorso. Il 99% dei cellulari venduti finiscono im mano a gente che non è interessata ad applicativi aggiuntivi, software store e simili. Usano quanto fornito di serie e fine li.
Il mio punto di vista non cambia (anche non prendendo in considerazione mono). sono moltissime le aziende interessate ad investire in GTK: Intel(rinuncerà a clutter? IMHO no), RH, Oracle (anche se non si sa che fine farà opensolaris), Google, Novell ecc. Se queste investono in GTK allora perchè riscrivere Gnome in QT? Probabilmente tra qualche tempo gli strumenti gtk diventeranno (per rincorrere QT) qualcosa di meglio di quanto sono ora.
D'altro canto basterebbe includere in GTK delle librerie di gnome, documentarle bene e scegliere uno dei tanti ide disponibili lo strumento predefinito.
Le prestazioni già in gtk3 miglioreranno molto (ricordiamoci che molte di queste ora "duplicate", conle vecchie ancora vive per questioni di compatibilità) e graficamente le trovo più "gradevoli", anche se forse la colpa è di KDE (sto provando kde4.4 ma non riesco a trovare un tema decente...).
To reuse existing .NET code with MonoTouch, you must recompile your libraries with MonoTouch's compiler and base assemblies.
Quindi ricompilando con monotouch dovrebbe andare....
http://unity3d.com/ questo è un esempio di software portato su iphone grazie a mono, il risultato non è male, da quel che vedo è possibile compilare un gioco per windows, mac, osx e iphone, linue e presto android senza modifiche.
Tornando un pò + IT (ma non troppo): http://www.mono-project.com/Companies_Using_Mono. Tra le tante cito:
Versora (http://versora.com): Windows-to-Linux migration specialists Versora used Mono and C# to produce a cross-platform tool that helps companies move system and application setttings and user data.
Evidentemente a qualcuno il porting da windows a linux interessa....
Hai poi perfettamente ragione quando dici che mono e gtk in generale sono spinti dall'interesse di alcune aziende. Ma perché pensi che esistano RH, Oracle, Canonical, mandriva ecc cercano di fare soldi e Nokia ha investito nell'acquisto di trolltech per interessi economici, non certo per beneficenza...
Il numero di terminali venduti cmq poco incide in questo discorso. Il 99% dei cellulari venduti finiscono im mano a gente che non è interessata ad applicativi aggiuntivi, software store e simili. Usano quanto fornito di serie e fine li.
Il mio punto di vista non cambia (anche non prendendo in considerazione mono). sono moltissime le aziende interessate ad investire in GTK: Intel(rinuncerà a clutter? IMHO no), RH, Oracle (anche se non si sa che fine farà opensolaris), Google, Novell ecc. Se queste investono in GTK allora perchè riscrivere Gnome in QT? Probabilmente tra qualche tempo gli strumenti gtk diventeranno (per rincorrere QT) qualcosa di meglio di quanto sono ora.
D'altro canto basterebbe includere in GTK delle librerie di gnome, documentarle bene e scegliere uno dei tanti ide disponibili lo strumento predefinito.
Le prestazioni già in gtk3 miglioreranno molto (ricordiamoci che molte di queste ora "duplicate", conle vecchie ancora vive per questioni di compatibilità) e graficamente le trovo più "gradevoli", anche se forse la colpa è di KDE (sto provando kde4.4 ma non riesco a trovare un tema decente...).
marco.r
23-02-2010, 17:31
Come fa ad essere nelle intenzioni degli autori ? Python e Mono si sono sviluppati solo negli ultimi anni. Quali erano gli altri linguaggi prima di questi ?
Io non ho parlato di linguaggi specifici, ma mi riferivo in generale.
Tieni presente che praticamente qualsiasi linguaggio, almeno sotto Unix, ha una FFI per il C, per cui la scelta del C e' ragionevole da questo punto di vista.
In ogni caso i primi binding di Python sono del '99, seguendo quindi di poco l'uscita di Gtk come toolkit generico e non piu' del solo Gimp.
Un binding si sviluppa se se ne sente la necessità. Inoltre fino a poco tempo fa c'erano molti problemi di licenza per le Qt su Windows.
Direi che questo è un discorso ortogonale a quelli di prima.
Io non ho parlato di linguaggi specifici, ma mi riferivo in generale.
Tieni presente che praticamente qualsiasi linguaggio, almeno sotto Unix, ha una FFI per il C, per cui la scelta del C e' ragionevole da questo punto di vista.
In ogni caso i primi binding di Python sono del '99, seguendo quindi di poco l'uscita di Gtk come toolkit generico e non piu' del solo Gimp.
Un binding si sviluppa se se ne sente la necessità. Inoltre fino a poco tempo fa c'erano molti problemi di licenza per le Qt su Windows.
Direi che questo è un discorso ortogonale a quelli di prima.
marco.r
23-02-2010, 17:35
Perché GTK# è un binding ad oggetti.
Anche le GTK+ sono object oriented, nonostante le limitazioni del linguaggio sottostante (e infatti programmarle direttamente in C è una follia secondo me).
Anche le GTK+ sono object oriented, nonostante le limitazioni del linguaggio sottostante (e infatti programmarle direttamente in C è una follia secondo me).
zephyr83
23-02-2010, 17:39
Il link che postato IMHO dice l'esatto contrario...
Quindi ricompilando con monotouch dovrebbe andare....
e poi continua dicendo
In particular, replacing the assemblies from MonoTouch with assemblies from the desktop Mono edition will not work since many APIs are missing from the MonoTouch lightweight Mono profile.
Alla fine i vari vantaggi di mono vanno a farsi benedire ed è solo un altro strumento per programmare per iphone, neanche tanto conveniente!! Inoltre una cosa del genere si potrà fare anche cn le qt.
http://unity3d.com/ questo è un esempio di software portato su iphone grazie a mono, il risultato non è male, da quel che vedo è possibile compilare un gioco per windows, mac, osx e iphone, linux e presto android senza modifiche.
se nn sbaglio quel game engine serve appunto per realizzare giochi! Ed esisteva già sia per windows che per osx (oltre che per wii e xbox360)! ovvio che se realizzi un gioco cn unity per windows, riesci a portare su iphone! Ma mi pare si appoggi a mono, è un po' diverso! ma cose simili esistono anche senza mono, tipo http://www.airplaysdk.com/
Tornando un pò + IT (ma non troppo): http://www.mono-project.com/Companies_Using_Mono. Tra le tante cito:
Evidentemente a qualcuno il porting da windows a linux interessa....
certo che a qualcuno interesserà (si spera) ma mono nn mi sembra la soluzione migliore! cn qt si ottiene decisamente un risultato migliore, o meglio! se un'azienda decide di passare a mono e usare solo mono sia su windows che su linux allora l'interoperabilità è sempre garantita! ma se un'azienda usa .net col piffero che passare a linux è così semplice! può aiutare ma nn è garantito!! Inoltre mono per lo sviluppo deve sempre inseguire .net (se nn sbaglio ancora nn c'è supporto per .net 3.5) e questo è un bel problema per le parti nn standardizzate che devono essere implementate dagli sviluppatori di mono (cn tutti i ritardi e i problemi del caso).
Hai poi perfettamente ragione quando dici che mono e gtk in generale sono spinti dall'interesse di alcune aziende. Ma perché pensi che esistano RH, Oracle, Canonical, mandriva ecc cercano di fare soldi e Nokia ha investito nell'acquisto di trolltech per interessi economici, non certo per beneficenza...
Ovvio che nokia nn lo fa per beneficenza! Era per dire che le motivazioni per cui nn si sn scelte le qt non sn mai state di natura tecnica ma sempre per altri motivi anche se erano la scelta migliore (all'inizio soprattutto visto che nn c'era altro :sofico: )
Il numero di terminali venduti cmq poco incide in questo discorso. Il 99% dei cellulari venduti finiscono im mano a gente che non è interessata ad applicativi aggiuntivi, software store e simili. Usano quanto fornito di serie e fine li.
Questo vale un po' per tutti! certo che l'iphone ha spinto maggiormente sulle applicazioni visto che in america viene venduto cn contratto obbligatorio e lo store è stato molto pubblicizzato!! in europa nn tutti comprano l'iphone cn contratto e molti lo usano senza una tariffa dati. Nokia e la concorrenza devono migliorare questi aspetti e soprattutto puntare di più sullo store!! per ora l'ovi store di nokia o il marketplace di microsoft fanno schifo (quest'ultimo mi sembra abbia solo 60 applicazioni), in futuro spero per loro possano riprendersi sotto questo aspetto!
pensare che nn si diffonderanno programmi in qt per symbian e maemo/meego vuol dire prevedere il fallimento di nokia almeno per il settore smartphone :) mi sembra difficile che possa avvenire una cosa del genere ma in fondo sn caduti imperi ben più solidi e duraturi! :)
Il mio punto di vista non cambia (anche non prendendo in considerazione mono). sono moltissime le aziende interessate ad investire in GTK: Intel(rinuncerà a clutter? IMHO no), RH, Oracle (anche se non si sa che fine farà opensolaris), Google, Novell ecc. Se queste investono in GTK allora perchè riscrivere Gnome in QT? Probabilmente tra qualche tempo gli strumenti gtk diventeranno (per rincorrere QT) qualcosa di meglio di quanto sono ora.
D'altro canto basterebbe includere in GTK delle librerie di gnome, documentarle bene e scegliere uno dei tanti ide disponibili lo strumento predefinito.
Le prestazioni già in gtk3 miglioreranno molto (ricordiamoci che molte di queste ora "duplicate", conle vecchie ancora vive per questioni di compatibilità) e graficamente le trovo più "gradevoli", anche se forse la colpa è di KDE (sto provando kde4.4 ma non riesco a trovare un tema decente...).
bhe anche tantissime aziende supportano QT! La riscrittura di gnome in qt nn avverrà mai ma su un forum è bello fantasticare :) vantaggi per linux e l'interoperabilità ce ne sarebbero stati tanti! almeno siamo riusciti ad "ammettere" che le qt come librerie in se sn superiori alle gtk e che vengono "snobbate" da linux per tutt'altro motivo :)
vedremo nei prossimi anni come andranno le cose!! io scommetto che se mono dovesse imporsi molto e diventare parte di gnome alcune aziende come redhat (ovviamente contrarissima) potrebbero spostarti su QT (oppure tirare fuori qualcosa di nuovo)!! chi vivrà vedrà!!
Quindi ricompilando con monotouch dovrebbe andare....
e poi continua dicendo
In particular, replacing the assemblies from MonoTouch with assemblies from the desktop Mono edition will not work since many APIs are missing from the MonoTouch lightweight Mono profile.
Alla fine i vari vantaggi di mono vanno a farsi benedire ed è solo un altro strumento per programmare per iphone, neanche tanto conveniente!! Inoltre una cosa del genere si potrà fare anche cn le qt.
http://unity3d.com/ questo è un esempio di software portato su iphone grazie a mono, il risultato non è male, da quel che vedo è possibile compilare un gioco per windows, mac, osx e iphone, linux e presto android senza modifiche.
se nn sbaglio quel game engine serve appunto per realizzare giochi! Ed esisteva già sia per windows che per osx (oltre che per wii e xbox360)! ovvio che se realizzi un gioco cn unity per windows, riesci a portare su iphone! Ma mi pare si appoggi a mono, è un po' diverso! ma cose simili esistono anche senza mono, tipo http://www.airplaysdk.com/
Tornando un pò + IT (ma non troppo): http://www.mono-project.com/Companies_Using_Mono. Tra le tante cito:
Evidentemente a qualcuno il porting da windows a linux interessa....
certo che a qualcuno interesserà (si spera) ma mono nn mi sembra la soluzione migliore! cn qt si ottiene decisamente un risultato migliore, o meglio! se un'azienda decide di passare a mono e usare solo mono sia su windows che su linux allora l'interoperabilità è sempre garantita! ma se un'azienda usa .net col piffero che passare a linux è così semplice! può aiutare ma nn è garantito!! Inoltre mono per lo sviluppo deve sempre inseguire .net (se nn sbaglio ancora nn c'è supporto per .net 3.5) e questo è un bel problema per le parti nn standardizzate che devono essere implementate dagli sviluppatori di mono (cn tutti i ritardi e i problemi del caso).
Hai poi perfettamente ragione quando dici che mono e gtk in generale sono spinti dall'interesse di alcune aziende. Ma perché pensi che esistano RH, Oracle, Canonical, mandriva ecc cercano di fare soldi e Nokia ha investito nell'acquisto di trolltech per interessi economici, non certo per beneficenza...
Ovvio che nokia nn lo fa per beneficenza! Era per dire che le motivazioni per cui nn si sn scelte le qt non sn mai state di natura tecnica ma sempre per altri motivi anche se erano la scelta migliore (all'inizio soprattutto visto che nn c'era altro :sofico: )
Il numero di terminali venduti cmq poco incide in questo discorso. Il 99% dei cellulari venduti finiscono im mano a gente che non è interessata ad applicativi aggiuntivi, software store e simili. Usano quanto fornito di serie e fine li.
Questo vale un po' per tutti! certo che l'iphone ha spinto maggiormente sulle applicazioni visto che in america viene venduto cn contratto obbligatorio e lo store è stato molto pubblicizzato!! in europa nn tutti comprano l'iphone cn contratto e molti lo usano senza una tariffa dati. Nokia e la concorrenza devono migliorare questi aspetti e soprattutto puntare di più sullo store!! per ora l'ovi store di nokia o il marketplace di microsoft fanno schifo (quest'ultimo mi sembra abbia solo 60 applicazioni), in futuro spero per loro possano riprendersi sotto questo aspetto!
pensare che nn si diffonderanno programmi in qt per symbian e maemo/meego vuol dire prevedere il fallimento di nokia almeno per il settore smartphone :) mi sembra difficile che possa avvenire una cosa del genere ma in fondo sn caduti imperi ben più solidi e duraturi! :)
Il mio punto di vista non cambia (anche non prendendo in considerazione mono). sono moltissime le aziende interessate ad investire in GTK: Intel(rinuncerà a clutter? IMHO no), RH, Oracle (anche se non si sa che fine farà opensolaris), Google, Novell ecc. Se queste investono in GTK allora perchè riscrivere Gnome in QT? Probabilmente tra qualche tempo gli strumenti gtk diventeranno (per rincorrere QT) qualcosa di meglio di quanto sono ora.
D'altro canto basterebbe includere in GTK delle librerie di gnome, documentarle bene e scegliere uno dei tanti ide disponibili lo strumento predefinito.
Le prestazioni già in gtk3 miglioreranno molto (ricordiamoci che molte di queste ora "duplicate", conle vecchie ancora vive per questioni di compatibilità) e graficamente le trovo più "gradevoli", anche se forse la colpa è di KDE (sto provando kde4.4 ma non riesco a trovare un tema decente...).
bhe anche tantissime aziende supportano QT! La riscrittura di gnome in qt nn avverrà mai ma su un forum è bello fantasticare :) vantaggi per linux e l'interoperabilità ce ne sarebbero stati tanti! almeno siamo riusciti ad "ammettere" che le qt come librerie in se sn superiori alle gtk e che vengono "snobbate" da linux per tutt'altro motivo :)
vedremo nei prossimi anni come andranno le cose!! io scommetto che se mono dovesse imporsi molto e diventare parte di gnome alcune aziende come redhat (ovviamente contrarissima) potrebbero spostarti su QT (oppure tirare fuori qualcosa di nuovo)!! chi vivrà vedrà!!
cionci
23-02-2010, 17:54
Tieni presente che praticamente qualsiasi linguaggio, almeno sotto Unix, ha una FFI per il C, per cui la scelta del C e' ragionevole da questo punto di vista.
E il C++ scrivendo un framework per Gnome che racchiudesse GTK+ e tutte le decine di librerie necessarie non sarebbe stata una scelta altrettanto valida ?
In ogni caso i primi binding di Python sono del '99, seguendo quindi di poco l'uscita di Gtk come toolkit generico e non piu' del solo Gimp.
Quando in Python programmavano 10 persone ;)
Anche le GTK+ sono object oriented, nonostante le limitazioni del linguaggio sottostante (e infatti programmarle direttamente in C è una follia secondo me).
Diciamo che tentano di essere object oriented...alla fine chiamarle object oriented è solo una dicitura di comodo se non si può sfruttare l'ereditarietà e il polimorfismo.
Limitazioni che nelle GTK# non ci sono ;) Ecco perché sono diverse.
E il C++ scrivendo un framework per Gnome che racchiudesse GTK+ e tutte le decine di librerie necessarie non sarebbe stata una scelta altrettanto valida ?
In ogni caso i primi binding di Python sono del '99, seguendo quindi di poco l'uscita di Gtk come toolkit generico e non piu' del solo Gimp.
Quando in Python programmavano 10 persone ;)
Anche le GTK+ sono object oriented, nonostante le limitazioni del linguaggio sottostante (e infatti programmarle direttamente in C è una follia secondo me).
Diciamo che tentano di essere object oriented...alla fine chiamarle object oriented è solo una dicitura di comodo se non si può sfruttare l'ereditarietà e il polimorfismo.
Limitazioni che nelle GTK# non ci sono ;) Ecco perché sono diverse.
Barra
23-02-2010, 18:23
@cionci:
usare GTK# + altri linguaggi (evitando così le "paure" c#) non sarebbe possibile? Facciamo un GTK# VS QT? :sofico:
@zephyr83:
Unity3d gira su windows, linux, mac, iphone, wii e arriverà immagino anche su altri dispositivi. Poter lavorare con un unico sistema è certamente più comodo, pensa a quanto lavoro puoi "riciclare" in un progetto impegnativo come un videogioco.
tornando a QT però non penso che prevedere il fallimento di uno store nokia significhi prevedere il fallimento di nokia nel settore smartphone, ti ripeto che il 99% degli utenti cambia uno smartphone (nahce evoluto) senza sentire la necessità di acquistare applicativi (vedi BB ad esempio).
usare GTK# + altri linguaggi (evitando così le "paure" c#) non sarebbe possibile? Facciamo un GTK# VS QT? :sofico:
@zephyr83:
Unity3d gira su windows, linux, mac, iphone, wii e arriverà immagino anche su altri dispositivi. Poter lavorare con un unico sistema è certamente più comodo, pensa a quanto lavoro puoi "riciclare" in un progetto impegnativo come un videogioco.
tornando a QT però non penso che prevedere il fallimento di uno store nokia significhi prevedere il fallimento di nokia nel settore smartphone, ti ripeto che il 99% degli utenti cambia uno smartphone (nahce evoluto) senza sentire la necessità di acquistare applicativi (vedi BB ad esempio).
zephyr83
23-02-2010, 20:03
@cionci:
usare GTK# + altri linguaggi (evitando così le "paure" c#) non sarebbe possibile? Facciamo un GTK# VS QT? :sofico:
E usare direttamente le qt? :sofico: però credo che il problema principale sia il framework! qualcosa di veramente valido sotto gnome mancava ed è anche per questo che mono è apprezzato!
@zephyr83:
Unity3d gira su windows, linux, mac, iphone, wii e arriverà immagino anche su altri dispositivi. Poter lavorare con un unico sistema è certamente più comodo, pensa a quanto lavoro puoi "riciclare" in un progetto impegnativo come un videogioco.
si ma unity3D nn qualcosa realizzata in mono o in .net! è un game engine. Grazie a mono si è portato anche su iphone e si appoggia ad esso ma è sempre una cosa diversa da mono! certo che riciclare è sempre utile, infatti è per questo che speravo nelle QT :sofico: stesso programma gira sia su windows, linux e osx e c'è da DECENNI :sofico: Si fosse fatto meno ostruzionismo magari le situazione per il pinguino poteva essere migliore adesso
tornando a QT però non penso che prevedere il fallimento di uno store nokia significhi prevedere il fallimento di nokia nel settore smartphone, ti ripeto che il 99% degli utenti cambia uno smartphone (nahce evoluto) senza sentire la necessità di acquistare applicativi (vedi BB ad esempio).
Ma se nokia nn riesce realizzare un ottimo store e a invogliare programmatori a realizzare programmi per i propri smartphone perde di sicuro la fascia alta di questo mercato e nn se lo può permettere! inoltre se symbian nn ricomincia ad acquistare consensi verrà abbandonato anche dalle altre marche come samsung, sonyericsson ed LG che sempre più puntano su android! sarebbe un duro colpo per nokia, potrebbe perdere la leadership. Sarebbe un bel problema visti tutti gli investimenti fatti!
BB vende sempre molto meno di nokia ma ha avuto successo per via del servizio email e anche perché ha potuto contare sull'enorme mercato americano, molto nazionalista per ste cose! nokia nn ci può contare :) cmq anche RIM ha creato l'SDK e uno store. Samsung ha realizzato Bada e anche lei avrà uno store! La strada è quella per continuare a crescere in questo settore! se nokia vuole continuare ad essere la leader del mercato nn può fallire. Cmq mi pare che le premesse ci siano tutte! prima programmare per symbian era uno schifo! ora hanno un'eccellente SDK! il nome nn le manca e vende un sacco di dispositivi!! Nn vedo perché nn dovrebbe avere successo! nn è che si poteva mettere a usare l'sdk di iphone o android :sofico:
usare GTK# + altri linguaggi (evitando così le "paure" c#) non sarebbe possibile? Facciamo un GTK# VS QT? :sofico:
E usare direttamente le qt? :sofico: però credo che il problema principale sia il framework! qualcosa di veramente valido sotto gnome mancava ed è anche per questo che mono è apprezzato!
@zephyr83:
Unity3d gira su windows, linux, mac, iphone, wii e arriverà immagino anche su altri dispositivi. Poter lavorare con un unico sistema è certamente più comodo, pensa a quanto lavoro puoi "riciclare" in un progetto impegnativo come un videogioco.
si ma unity3D nn qualcosa realizzata in mono o in .net! è un game engine. Grazie a mono si è portato anche su iphone e si appoggia ad esso ma è sempre una cosa diversa da mono! certo che riciclare è sempre utile, infatti è per questo che speravo nelle QT :sofico: stesso programma gira sia su windows, linux e osx e c'è da DECENNI :sofico: Si fosse fatto meno ostruzionismo magari le situazione per il pinguino poteva essere migliore adesso
tornando a QT però non penso che prevedere il fallimento di uno store nokia significhi prevedere il fallimento di nokia nel settore smartphone, ti ripeto che il 99% degli utenti cambia uno smartphone (nahce evoluto) senza sentire la necessità di acquistare applicativi (vedi BB ad esempio).
Ma se nokia nn riesce realizzare un ottimo store e a invogliare programmatori a realizzare programmi per i propri smartphone perde di sicuro la fascia alta di questo mercato e nn se lo può permettere! inoltre se symbian nn ricomincia ad acquistare consensi verrà abbandonato anche dalle altre marche come samsung, sonyericsson ed LG che sempre più puntano su android! sarebbe un duro colpo per nokia, potrebbe perdere la leadership. Sarebbe un bel problema visti tutti gli investimenti fatti!
BB vende sempre molto meno di nokia ma ha avuto successo per via del servizio email e anche perché ha potuto contare sull'enorme mercato americano, molto nazionalista per ste cose! nokia nn ci può contare :) cmq anche RIM ha creato l'SDK e uno store. Samsung ha realizzato Bada e anche lei avrà uno store! La strada è quella per continuare a crescere in questo settore! se nokia vuole continuare ad essere la leader del mercato nn può fallire. Cmq mi pare che le premesse ci siano tutte! prima programmare per symbian era uno schifo! ora hanno un'eccellente SDK! il nome nn le manca e vende un sacco di dispositivi!! Nn vedo perché nn dovrebbe avere successo! nn è che si poteva mettere a usare l'sdk di iphone o android :sofico:
Barra
27-02-2010, 10:24
http://soluzionisoftware.blogspot.com/2010/02/riflessione-microsoft-e-il-futuro-delle.html
http://www.reuters.com/article/idUSTRE61I54A20100219
http://www.phonearena.com/htmls/Will-Microsoft-buy-RIM-or-Nokia-article-a_9807.html
Ok, sono + fantasie che altro questo è il rischio causato dall'usare un framework sviluppato da un'unica azienda. Può essere acquisita da un'altra (vedi sun) o può venir meno l'interesse economico che questa ha nel mantenere aggiornato l'applicativo. Vero che è opensource e quindi si potrebbe forkare o continuare lo sviluppo senza di loro ma se gli sviluppatori "ex trolltech" sono costretti dalla dirigenza ad occuparsi di altro mancherebbero forse troppe risorse per poterne portare avanti lo sviluppo al meglio.
@Zephir:
non capisco il discorso su unity3d. Unity3d non è scritto in mono? Da quel che so è sviluppato in c# su mono-develop.
Tornando sulla difficoltà di sviluppo di applicativi GTK ho recentemente provato quickly (https://wiki.ubuntu.com/Quickly). Sembra essere estremamente semplice da utilizzare.
http://www.reuters.com/article/idUSTRE61I54A20100219
http://www.phonearena.com/htmls/Will-Microsoft-buy-RIM-or-Nokia-article-a_9807.html
Ok, sono + fantasie che altro questo è il rischio causato dall'usare un framework sviluppato da un'unica azienda. Può essere acquisita da un'altra (vedi sun) o può venir meno l'interesse economico che questa ha nel mantenere aggiornato l'applicativo. Vero che è opensource e quindi si potrebbe forkare o continuare lo sviluppo senza di loro ma se gli sviluppatori "ex trolltech" sono costretti dalla dirigenza ad occuparsi di altro mancherebbero forse troppe risorse per poterne portare avanti lo sviluppo al meglio.
@Zephir:
non capisco il discorso su unity3d. Unity3d non è scritto in mono? Da quel che so è sviluppato in c# su mono-develop.
Tornando sulla difficoltà di sviluppo di applicativi GTK ho recentemente provato quickly (https://wiki.ubuntu.com/Quickly). Sembra essere estremamente semplice da utilizzare.
cionci
27-02-2010, 10:34
http://soluzionisoftware.blogspot.com/2010/02/riflessione-microsoft-e-il-futuro-delle.html
http://www.reuters.com/article/idUSTRE61I54A20100219
http://www.phonearena.com/htmls/Will-Microsoft-buy-RIM-or-Nokia-article-a_9807.html
Ok, sono + fantasie che altro questo è il rischio causato dall'usare un framework sviluppato da un'unica azienda. Può essere acquisita da un'altra (vedi sun) o può venir meno l'interesse economico che questa ha nel mantenere aggiornato l'applicativo. Vero che è opensource e quindi si potrebbe forkare o continuare lo sviluppo senza di loro ma se gli sviluppatori "ex trolltech" sono costretti dalla dirigenza ad occuparsi di altro mancherebbero forse troppe risorse per poterne portare avanti lo sviluppo al meglio.
Secondo me l'antitrust non lascerebbe mai acquistare Nokia o RIM da Microsoft.
http://www.reuters.com/article/idUSTRE61I54A20100219
http://www.phonearena.com/htmls/Will-Microsoft-buy-RIM-or-Nokia-article-a_9807.html
Ok, sono + fantasie che altro questo è il rischio causato dall'usare un framework sviluppato da un'unica azienda. Può essere acquisita da un'altra (vedi sun) o può venir meno l'interesse economico che questa ha nel mantenere aggiornato l'applicativo. Vero che è opensource e quindi si potrebbe forkare o continuare lo sviluppo senza di loro ma se gli sviluppatori "ex trolltech" sono costretti dalla dirigenza ad occuparsi di altro mancherebbero forse troppe risorse per poterne portare avanti lo sviluppo al meglio.
Secondo me l'antitrust non lascerebbe mai acquistare Nokia o RIM da Microsoft.
zephyr83
27-02-2010, 18:34
http://soluzionisoftware.blogspot.com/2010/02/riflessione-microsoft-e-il-futuro-delle.html
http://www.reuters.com/article/idUSTRE61I54A20100219
http://www.phonearena.com/htmls/Will-Microsoft-buy-RIM-or-Nokia-article-a_9807.html
Ok, sono + fantasie che altro questo è il rischio causato dall'usare un framework sviluppato da un'unica azienda. Può essere acquisita da un'altra (vedi sun) o può venir meno l'interesse economico che questa ha nel mantenere aggiornato l'applicativo. Vero che è opensource e quindi si potrebbe forkare o continuare lo sviluppo senza di loro ma se gli sviluppatori "ex trolltech" sono costretti dalla dirigenza ad occuparsi di altro mancherebbero forse troppe risorse per poterne portare avanti lo sviluppo al meglio.
Mha, si dicevano cose simili anche quando naque KDE......eppure le qt sn addirittura opengl mentre le gtk+ sn solo lgpl :sofico: Cmq la risposta l'hai data, sn open source, si forkerebbero!
@Zephir:
non capisco il discorso su unity3d. Unity3d non è scritto in mono? Da quel che so è sviluppato in c# su mono-develop.
a me unity3d mi pare solo un "engine game", http://en.wikipedia.org/wiki/Unity_(game_engine)
Su windows prima e su osx nn era certo sviluppato cn mono!!
http://www.reuters.com/article/idUSTRE61I54A20100219
http://www.phonearena.com/htmls/Will-Microsoft-buy-RIM-or-Nokia-article-a_9807.html
Ok, sono + fantasie che altro questo è il rischio causato dall'usare un framework sviluppato da un'unica azienda. Può essere acquisita da un'altra (vedi sun) o può venir meno l'interesse economico che questa ha nel mantenere aggiornato l'applicativo. Vero che è opensource e quindi si potrebbe forkare o continuare lo sviluppo senza di loro ma se gli sviluppatori "ex trolltech" sono costretti dalla dirigenza ad occuparsi di altro mancherebbero forse troppe risorse per poterne portare avanti lo sviluppo al meglio.
Mha, si dicevano cose simili anche quando naque KDE......eppure le qt sn addirittura opengl mentre le gtk+ sn solo lgpl :sofico: Cmq la risposta l'hai data, sn open source, si forkerebbero!
@Zephir:
non capisco il discorso su unity3d. Unity3d non è scritto in mono? Da quel che so è sviluppato in c# su mono-develop.
a me unity3d mi pare solo un "engine game", http://en.wikipedia.org/wiki/Unity_(game_engine)
Su windows prima e su osx nn era certo sviluppato cn mono!!
zephyr83
27-02-2010, 18:36
Secondo me l'antitrust non lascerebbe mai acquistare Nokia o RIM da Microsoft.
bhe nn so, potrebbe anche essere e poi nokia è europea nn americana e microsoft nn ha alcun monopolio, anzi è la più piccola di tutte in questo campo :D Potrebbe forse acquisire RIM ma nn avrebbe senso perché questa va già benone così! cn nokia peggio ancora.....cosa ci guadagnerebbe la casa finnica? proprio nulla, anzi sarebbe la sua fine!! L'unica papabile è palm che se la passa male ma anche li microsoft nn se ne fa niente visto che nn potrebbe mica mettersi a riutilizzare webos che sfrutta linux come kernel
bhe nn so, potrebbe anche essere e poi nokia è europea nn americana e microsoft nn ha alcun monopolio, anzi è la più piccola di tutte in questo campo :D Potrebbe forse acquisire RIM ma nn avrebbe senso perché questa va già benone così! cn nokia peggio ancora.....cosa ci guadagnerebbe la casa finnica? proprio nulla, anzi sarebbe la sua fine!! L'unica papabile è palm che se la passa male ma anche li microsoft nn se ne fa niente visto che nn potrebbe mica mettersi a riutilizzare webos che sfrutta linux come kernel
killercode
27-02-2010, 19:51
Certo che però è starno che nessuna azienda abbia unito il DE più professionale (gnome) con le librerie più professionali (QT).
Cioè, tutti i produttori si sistemi linux enterprise usano gnome (non sò se per meriti tecnici o motivi politichi) e tutte le aziende software puntano sulle QT. Insomma, sembrerebbe un binomio ovvio....
Cioè, tutti i produttori si sistemi linux enterprise usano gnome (non sò se per meriti tecnici o motivi politichi) e tutte le aziende software puntano sulle QT. Insomma, sembrerebbe un binomio ovvio....
cionci
27-02-2010, 19:55
Certo che però è starno che nessuna azienda abbia unito il DE più professionale (gnome) con le librerie più professionali (QT).
Non è strano, o almeno non lo era fino a quando per sviluppare un software con le Qt per Windows era necessario spendere sui 2-3000€ a postazione per la licenza ;)
Non è strano, o almeno non lo era fino a quando per sviluppare un software con le Qt per Windows era necessario spendere sui 2-3000€ a postazione per la licenza ;)
zephyr83
27-02-2010, 19:59
Certo che però è starno che nessuna azienda abbia unito il DE più professionale (gnome) con le librerie più professionali (QT).
Cioè, tutti i produttori si sistemi linux enterprise usano gnome (non sò se per meriti tecnici o motivi politichi) e tutte le aziende software puntano sulle QT. Insomma, sembrerebbe un binomio ovvio....
secondo me il motivo della preferenza di gnome su kde era quello legato alle gtk che erano sotto licenza lgpl
Cioè, tutti i produttori si sistemi linux enterprise usano gnome (non sò se per meriti tecnici o motivi politichi) e tutte le aziende software puntano sulle QT. Insomma, sembrerebbe un binomio ovvio....
secondo me il motivo della preferenza di gnome su kde era quello legato alle gtk che erano sotto licenza lgpl
killercode
27-02-2010, 20:34
secondo me il motivo della preferenza di gnome su kde era quello legato alle gtk che erano sotto licenza lgpl
beh, red hat usava kde in un lontano passato....però c'è anche da dire che allora gnome era una mezza sega...
Non è strano, o almeno non lo era fino a quando per sviluppare un software con le Qt per Windows era necessario spendere sui 2-3000€ a postazione per la licenza ;)
ma ormai si parla di 6-7 anni fà
beh, red hat usava kde in un lontano passato....però c'è anche da dire che allora gnome era una mezza sega...
Non è strano, o almeno non lo era fino a quando per sviluppare un software con le Qt per Windows era necessario spendere sui 2-3000€ a postazione per la licenza ;)
ma ormai si parla di 6-7 anni fà
zephyr83
27-02-2010, 21:47
beh, red hat usava kde in un lontano passato....però c'è anche da dire che allora gnome era una mezza sega...
ecco appunto, prima nn c'era tanta alternativa, kde è stato il primo a nascere :sofico:
ma ormai si parla di 6-7 anni fà
Bhe ma se già conosci uno strumento nn è che lo cambi facilmente.......pensa a quelli di intel che usano ancora programmi a 16 bit e sn in cresi per passare a seven (avendo saltato a piedi pari vista) :sofico:
ecco appunto, prima nn c'era tanta alternativa, kde è stato il primo a nascere :sofico:
ma ormai si parla di 6-7 anni fà
Bhe ma se già conosci uno strumento nn è che lo cambi facilmente.......pensa a quelli di intel che usano ancora programmi a 16 bit e sn in cresi per passare a seven (avendo saltato a piedi pari vista) :sofico:
cionci
28-02-2010, 01:55
ma ormai si parla di 6-7 anni fà
La licenza LGPL, che permette a chi usa Qt di non rilasciare il sorgente, anche senza acquistare la versione commerciale, è stata adottata a febbraio 2009.
La licenza LGPL, che permette a chi usa Qt di non rilasciare il sorgente, anche senza acquistare la versione commerciale, è stata adottata a febbraio 2009.
killercode
28-02-2010, 11:22
La licenza LGPL, che permette a chi usa Qt di non rilasciare il sorgente, anche senza acquistare la versione commerciale, è stata adottata a febbraio 2009.
la lgpl si, è stata nokia ha introdurla, ma la wiki dice che già dal 2005 la licenza open source (gpl) immagino era disponibile per tutte le piattaforme
la lgpl si, è stata nokia ha introdurla, ma la wiki dice che già dal 2005 la licenza open source (gpl) immagino era disponibile per tutte le piattaforme
cionci
28-02-2010, 11:39
la lgpl si, è stata nokia ha introdurla, ma la wiki dice che già dal 2005 la licenza open source (gpl) immagino era disponibile per tutte le piattaforme
Certo, ma un'azienda non sviluppava con le Qt se doveva rilasciare il sorgente, o almeno le piccole o medie imprese. Con la LGPL non c'è più questo obbligo.
Certo, ma un'azienda non sviluppava con le Qt se doveva rilasciare il sorgente, o almeno le piccole o medie imprese. Con la LGPL non c'è più questo obbligo.
ArtX
28-02-2010, 11:47
scusate ma le gtk+ fanno anch'esse parte del LSB o solo le QT?
marco.r
28-02-2010, 15:04
E il C++ scrivendo un framework per Gnome che racchiudesse GTK+ e tutte le decine di librerie necessarie non sarebbe stata una scelta altrettanto valida ?
Non se vuoi evitare un linguaggio senza una ABI standard e che quindi non solo non esistono opportune interfacce FFI negli altri linguaggi, ma è impossibile andare tranquilli quando vuoi collegare le librerie.
Quando in Python programmavano 10 persone ;)
Lo usavamo io, Larry Page e Sergey Brin. Ora non ci resta che cercare gli altri 7 :D.
Diciamo che tentano di essere object oriented...alla fine chiamarle object oriented è solo una dicitura di comodo se non si può sfruttare l'ereditarietà e il polimorfismo.
Ci sono. Il modo per usarle fa totalmente schifo, ma ci sono.
Non se vuoi evitare un linguaggio senza una ABI standard e che quindi non solo non esistono opportune interfacce FFI negli altri linguaggi, ma è impossibile andare tranquilli quando vuoi collegare le librerie.
Quando in Python programmavano 10 persone ;)
Lo usavamo io, Larry Page e Sergey Brin. Ora non ci resta che cercare gli altri 7 :D.
Diciamo che tentano di essere object oriented...alla fine chiamarle object oriented è solo una dicitura di comodo se non si può sfruttare l'ereditarietà e il polimorfismo.
Ci sono. Il modo per usarle fa totalmente schifo, ma ci sono.
marco.r
28-02-2010, 15:07
C'è chi con i cambiamenti di versione ci deve lottare ogni 2-3 mesi (chi programma in C su Gnome o chi scrive i binding per i linguaggi di alto livello).
Inoltre un avanzamento di versione non può andare ad influire su KDE se non marginalmente, come già detto sicuramente inseriranno la retrocompatibilità (così come è stato fatto per le Qt3).
Tanto per API quanto le ABI di Gtk sono retrocompatibili per tutta la major version. Puoi prendere un programma scritto per la 2.0 e compilarlo con le 2.16. Oppure prenderlo compilato per la 2.0 e linkarlo direttamente con la 2.16.
E i binding di solito vengono generati automaticamente.
Inoltre un avanzamento di versione non può andare ad influire su KDE se non marginalmente, come già detto sicuramente inseriranno la retrocompatibilità (così come è stato fatto per le Qt3).
Tanto per API quanto le ABI di Gtk sono retrocompatibili per tutta la major version. Puoi prendere un programma scritto per la 2.0 e compilarlo con le 2.16. Oppure prenderlo compilato per la 2.0 e linkarlo direttamente con la 2.16.
E i binding di solito vengono generati automaticamente.
cionci
28-02-2010, 16:21
Tanto per API quanto le ABI di Gtk sono retrocompatibili per tutta la major version. Puoi prendere un programma scritto per la 2.0 e compilarlo con le 2.16. Oppure prenderlo compilato per la 2.0 e linkarlo direttamente con la 2.16.
E i binding di solito vengono generati automaticamente.
Non parlavo delle sole Gtk, ma anche di tutte la altre librerie del mondo Gnome.
E i binding di solito vengono generati automaticamente.
Non parlavo delle sole Gtk, ma anche di tutte la altre librerie del mondo Gnome.
marco.r
01-03-2010, 10:39
Non parlavo delle sole Gtk, ma anche di tutte la altre librerie del mondo Gnome.
Boh, per Gnome io non ho scritto molto, ma non ho mai avuto problemi a fare andare programmi scritti tempi addietro con versioni piu' recenti.
Boh, per Gnome io non ho scritto molto, ma non ho mai avuto problemi a fare andare programmi scritti tempi addietro con versioni piu' recenti.
vBulletin® v3.6.4, Copyright ©2000-2026, Jelsoft Enterprises Ltd.