Usando Linux c’è da imbattersi in programmi scritti con librerie diverse da quelle usate dal DE (ovviamente parlo principalmente di gtk+ e Qt), e queste applicazioni sempre fanno esteticamente a pugni con l’ambiente circostante, nonostante si usino applicazioni esterne che permettono di arrangiarsi per quel che si può (uso qtcurve e gtk-kde4 per le applicazioni gtk) ma il risultato comunque salta all’occhio, e se su kde le cose vanno un pò meglio, su gnome un programma in qt è allucinante. Quale strada intraprendere quindi? Una soluzione, diciamo la più fattibile sarebbe quella di staccare il core dalla gui: prendiamo ad esempio Gimp, è scritto in C, e l’interfaccia in gtk+ (sempre C) perchè non continuare a scrivere il core in C e l’interfaccia in un linguaggio che si possa adattare a tutti desktop come il Python? Staccare questi due componenti non significa solo maggior pulizia del codice, ma vantaggi per entrambi gli sviluppi: una parte degli sviluppatori continua a sviluppare il core senza preoccuparsi della gui, quindi lo sviluppo può essere più veloce e può comprendere più features; una piccola parte di persone si occupa di fornire l’interfaccia al core, usando python che si integra perfettamente col c e la sua flessibilità permette di creare gui diverse utilizzando librerie diverse ma lo stesso linguaggio, e guardando oltre a gnome e kde si può fornire un’interfaccia anche a E17, a Windows e a Mac, usando la stessa base. Purtroppo serve una guida all’interno dei progetti che, più che saper programmare, deve saper gestire gli sviluppatori in base alle loro capacità e nel panorama Open difficilmente si sono viste persone capaci di ciò.
Usando Linux c'è da imbattersi in programmi scritti con librerie diverse da quelle usate dal DE (ovviamente parlo principalmente di gtk+ e Qt), e queste applicazioni sempre fanno esteticamente a pugni con l'ambiente circostante, nonostante si usino applicazioni esterne che permettono di arrangiarsi per quel che si può (uso qtcurve e gtk-kde4 per le applicazioni gtk) ma il risultato comunque salta all'occhio, e se su kde le cose vanno un pò meglio, su gnome un programma in qt è allucinante. Quale strada intraprendere quindi? Una soluzione, diciamo la più fattibile sarebbe quella di staccare il core dalla gui: prendiamo ad esempio Gimp, è scritto in C, e l'interfaccia in gtk+ (sempre C) perchè non continuare a scrivere il core in C e l'interfaccia in un linguaggio che si possa adattare a tutti desktop come il Python? Staccare questi due componenti non significa solo maggior pulizia del codice, ma vantaggi per entrambi gli sviluppi: una parte degli sviluppatori continua a sviluppare il core senza preoccuparsi della gui, quindi lo sviluppo può essere più veloce e può comprendere più features; una piccola parte di persone si occupa di fornire l'interfaccia al core, usando python che si integra perfettamente col c e la sua flessibilità permette di creare gui diverse utilizzando librerie diverse ma lo stesso linguaggio, e guardando oltre a gnome e kde si può fornire un'interfaccia anche a E17, a Windows e a Mac, usando la stessa base. Purtroppo serve una guida all'interno dei progetti che, più che saper programmare, deve saper gestire gli sviluppatori in base alle loro capacità e nel panorama Open difficilmente si sono viste persone capaci di ciò.
io tutti questi problemi non li vedo…
piccolo esempio: ho realizzato questo programma (in python per l’appunto) ma con le librerie qt4 (usando pyqt4)… il risultato è questo http://i50.tinypic.com/21cbjvd.png e non mi pare che sia brutto
(Se non fosse capito uso gnome)
hai ragione, il risultato è ottimo, non sembra neanche scritto con le qt, ho scritto una cavolata
evidentemente sotto gnome la situazione è molto cambiata (da tempo lo uso solo per provare applicazioni gtk), su kde invece non è cambiato niente dalla 4.2, però volevo far notare anche i vantaggi sul lato codice e sul lato organizzativo, che possono portare a programmi migliori.
in effetti a questo punto l’integrazione sembra piuttosto buona, l’unica cosa scomoda è installarsi tutte le librerie grafiche magari per 1-2 programmi, ma è inevitabile come cosa… Separare l’interfaccia dalla parte effettivamente “attiva” del programma non sempre è facile, ed avere una serie di persone che si occupino di creare l’interfaccia con ogni libreria magari è troppo dispersivo e come hai detto tu la cosa deve essere controllata e coordinata ottimamente (parlo per intuito e sentito dire, ho solo 15 anni e non ho mai partecipato a progetti con più persone :p)