Riscrivere Gnome su Qt?

[masand]

Originariamente inviato da cionci

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

[cionci]

Originariamente inviato da masand

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.

[masand]

Originariamente inviato da cionci

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.

[cionci]

Originariamente inviato da masand

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.

[Dcromato]

Originariamente inviato da masand

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.

[Barra]

@Cionci:
Si vede che sei uno sviluppatore

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]

Originariamente inviato da Barra

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.

[Pixel452]

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.

[giova22]

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!

[cionci]

Originariamente inviato da Pixel452

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.

[Pixel452]

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]

Originariamente inviato da Pixel452

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 ?

[Pixel452]

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.

[zephyr83]

Originariamente inviato da Barra

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

Originariamente inviato da zephyr83

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

[zephyr83]

Originariamente inviato da masand

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)

[Barra]

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

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]

Originariamente inviato da Pixel452

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

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]

Originariamente inviato da Barra

Mi quoto:

bho forse nn ci capiamo cn mono NON risolvi il problema dell'interoperabilità da windows verso linux! ovvio che il contrario funzioni

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

[Barra]

Originariamente inviato da zephyr83

bho forse nn ci capiamo cn mono NON risolvi il problema dell'interoperabilità da windows verso linux! ovvio che il contrario funzioni

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

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