9 luglio 2008

One day is fine and next is black

Disclaimer: questo post era stato scritto un po' di tempo fa e mai finito. La notizia è vecchia, ma debbo assolvere al fioretto di scrivere 5 post pratici... Beh, pratico pratico non è... Facciamo così, mi arrogo il ruolo di opinionista. Ah, mi sono anche autocensurato. Non chiedetemi di più che poi mi snaturate.

Update: leggete anche i commenti, interessante intervento di "boyska" che chiarisce alcuni punti da me diffamati con (effettivamente) un po' di clamorosismo giornalistico. Ma in fondo io odio Python (o meglio, odio Python se usato per scrivere librerie; fateci pure le applicazioni, ma le librerie scrivetele in C e fornitene binding in tutti i migliori linguaggi) e le UI non integrate.

Per cominciare bene una corputa citazione non tradotta:
Another big issue was the choice of the toolkit.. [...] We had a list of requirements and were trying to find which toolkit would answer those requirements the best...
  • GTK did not fit the requirement of being able to have a background image on a text widget (unless doing a lot of hacking and reimplementing the text widget)...
  • QT did not fit the requirement about the performance....
Which one to choose... well, we decided to go with something completely different: EFL. For those who do not know what it is, the EFL is the Enlightenement Foundation Libraries. It's a set of libraries that makes building UIs such a beauty! It only has one.. euhh.. two... humm.. a few problems :
  1. there are still no releases of the EFL.. so anyone willing to test this needs to compile the huge set of libraries from CVS
  2. the APIs might change until the libraries are released...
  3. we cannot embed an image inside a text widget.. so no smileys support...
The first two issues are easily dealt with : we don't care.. anyways, it should be released by the time amsn2 gets finished... the last one (embeded images/smileys) is resolved with another solution: use webkit (html engine) for drawing the contact list and chat window text widgets....
L'originale completo lo trovate qui. È un estratto dall'annuncio del futuro aMSN2, nel quale confluiranno gli sforzi e le esperienze degli attuali aMSN, emesene e pymsn.

Ora, sarò io che ho la mia deviata visione del mondo, non lo nego, ma qualcuno concorda sul fatto che ciò che stanno dicendo in pratica è quanto segue:
  • vogliamo una finestra di login con tanti bei inutili fronzoli grafici accattivanti e occhiolinosi (come quella mostrata nella seconda parte di questo video) e per farlo andremo a usare un toolkit grafico che nessuno si caga di striscio trova interessante e che non ha neanche una versione rilasciata o la garazia di stabilità delle API solo perché ci permette di aggiungere un certo numero di determinati fronzoni;
  • il toolkit grafico che nessuno si caga trova interessante di cui sopra comunque non ci basta per poter disegnare ben benino tutte le michiate sciocchezzuole del protocollo MSN¹, per cui andremo a usare WebKit per disegnare l'elenco dei contatti e le finestre di chat (che cmq al momento non è di certo un prodotto "stabile" per GNU/Linux, nel senso che non lo trovate pacchettizzato in modo rigoroso nelle distribuzioni);
  • ah, la nostra applicazione comunque sarà scritta in Python, eh (questo lo leggete nell'originale) che tutti sappiamo essere un linguaggio pensato apposta per essere performante;
  • ah, la nostra applicazione comunque avrà diversi frontend: gtk+, qt, cocoa, magari perfino xul, eh (anche questo nell'originale);
Giusto? È questo che stanno dicendo? Vero?

No perché, in tal caso, sarò Franco, anche se fatico a essere Mario (Luca mi riesce decentemente bene), a me pare che tale scelta progettuale sia stata partorita dalla mente iperormonata di un adolescente in piena fase di sviluppo (ossia qualcosa il cui QI e capacità di giudizio si avvicinano a quella di fagiano maschio che decide che il periodo degli amori giusto è all'apertura della stagione di caccia... momento! mi sa che è proprio così), piuttosto che da una persona che sta cercando di sviluppare una applicazione che supporti un certo protocollo di messaggistica istantanea per il quale non esiste un client ufficiale in determinate piattaforme hardware/software.

E non venitemi a dire che si tratta di una ventata di innovazione in una desolata valle di decadenza².

Soprattutto non cominciate a pensare che, quando sarà il momento, GTK3 and GNOME3 saranno qualcosa del genere. Se pensate che la "scarsa disposizione all'innovazione e al cambiamento"³ sparirà con la versione 3, che sarà la casa delle liberta (facciamo un po' come cazzo razzo ci pare - cit.) allora avete sbagliato a connettere i neuroni con i quali rielaborate il vissuto per la creazione di una visione organica dell'esistenza.

Anzi, i lavori per GTK3 sono già cominciati con il merge del branch GSEAL (che io ve lo direi cosa è, ma poi voi che ci fate? ci andate al bar a bullarvi con gli amici? dite che gli interessa il fatto che ora tutte le strutture private delle GTK+ sono state sigillate e non sono accedibili se non tramite opportuna funzione?). Se innovazione deve essere, sarà forse individuabile nella flessibilità.

E pensate sempre che se voi ignari utenti state festeggiando in attesa delle GTK3, alcuni sviluppatori forse stanno già sbattendo la testa al muro, visto che il breakage delle ABI costringerà anche progetti esterni a un omologo breakage (qualcuno ha detto GStreamer?).

Comunque, siamo felici.

[1] che tra l'altro, commento personale, sembra che aumentino esponenzialmente con passare del tempo, vedi il recente annuncio sulla visione di film/televione condivisa con chi chiacchieri... sarò sempre io, ma o cazzeggio mi intrattengo con i miei contatti o mi guardo un prodotto audiovisivo...
[2] ehi, era ovvio che era qui che volevo andare a parare, no :-)
[3] citazione di citazione

6 commenti:

Anonimo ha detto...

Mah, guarda forse python è la cosa che ancora va bene tra tutto il resto....
se proprio vogliono ultilizzare un "linguaggio" prestante unito alla facilità di programmazione potrebbero provare ad utilizzare vala ( anche se ancora in sviluppo ) con le librerie grafiche dovrebbero utilizzare GTK2 o QT4 al limite wxwidgets...

Anonimo ha detto...

Bhe se consideri che amsn è in tk il passo in avanti è notevole...
python era ovvio, va talmente di moda
Non capisco il problema sulle prestazioni di QT, che tra l'altro non dovrebbero garantire un facile porting anche verso windows ?

ExAzor ha detto...

ciao, leggo questo post con un po' di stupore... seguo da un po' il tuo blog e, anche non essendo uno "gnomer" (uso kde, ma le guerre di religione mi scivolano addosso :) ), ho sempre apprezzato le posizioni prese qui... questa pero' mi suona strana! Premetto: non partecipo allo sviluppo di aMsn2; mi sarebbe piaciuto, ma al momento sono un po' troppo impegnato, so pochissimo di socket e cose varie, e non sono un guru nemmeno di GUI (praticamente una pippa, esatto :P ). In compenso sviluppo plugins per emesene, e ultimamente anche qualche patch.
Per quanto mi riguarda, la scelta di aMsn2 e' stata buona, anche se non ottima.
Prestazioni: e' vero, python non regna sovrano qui. Ma e' anche vero che ci sono molte applicazioni che lo usano e che danno prova di ottima usabilita': io su KDE, su un computer comprato 7 anni fa, avvio emesene (mia unica applicazione gtk, che quindi secondo chiunque dovrebbe essere lenta/pesante/cattiva) e va benissimo. Consuma un po' di ram, ma questo e' a causa di un po' di memory leak di emesene che vanno ancora risolti :) Quello che piu' mi interessa e' pero' una visione "in prospettiva": python ha dimostrato moltissime volte di essere un linguaggio che permette tempi di sviluppo rapidissimi (saro' monotono, ma pensiamo ancora a emesene, che in pochi mesi e' diventato tra i client piu' popolari); non solo, python permette anche un'ottima estensibilita': un plugin manager in python e' semplice da scrivere, efficiente ed estremamente potente (so di cosa parlo, stavolta, visto che su questo sto facendo un po' di patch). Farlo in C++ e' certo ugualmente possibile, ma molto difficile senza ricorrere a librerie esterne; l'idea del multi-frontend puo' sembrare overloaded, ma non lo e': ne' dal punto di vista delle prestazioni, ne' da quello del codice. Semplicemente ogni GUI e' un oggetto che si attiene a un preciso duck-typing e tutto funziona.

Frontend: questo e' l'argomento piu' ostico, che ha lasciato perplesso anche me per parecchio tempo. La confusione nasce dal fatto che il frontend EFL e' stato chiamato "ufficiale" per il semplice fatto che lo sviluppatore e' uno dei piu' importanti di aMsn2. In realta', non avra' *niente* in piu' degli altri. La scelta di usare piu' frontend e' al contempo obbligata e senza ripercussioni: aMsn nasce con l'obiettivo di essere IL client msn open source. E per fare questo si deve adattare bene a windows (qt), gnome (gtk), mac (cocoa). L'EFL non mi pareva fondamentale, ma per quanto mi riguarda facessero tutti i frontend che vogliono, al massimo non li uso. Qualcuno obiettera' che questo spezzera' lo sviluppo su piu' fronti, rallentandolo; io dico che invece questo aumentera' gli sviluppatori: un vero kdefan non si sarebbe mai messo a lavorare su aMsn2, preferendo magari KMess. Ora gli utenti di tutti i DE/OS potranno essere interessati, e quindi sviluppare, aMsn2. La legge di Linus ha bisogno di "un numero sufficiente di occhi" per funzionare. Se guardi il codice, noterai che ogni frontend e' un po' simile a un "plugin": sta per fatti suoi, viene importato solo se richiesto, ecc. Non capisco cosa ci sia di sbagliato.
O forse era meglio aMsn scritto in Tcl/Tk, in cui il codice di protocollo si confondeva con quello della gui, con i suoi temi assurdi e i suoi moltissimi bachi?

WebKit: qui innanzitutto ho da ridire sulla questione della stabilita' e dei tempi; WebKit e' sviluppato in modo molto serio e a breve sara' sicuramente pacchettizzato in maniera piu' standard, e dunque piu' adatto alla distribuzione; probabilmente, molto prima che aMsn2 sia utilizzabile con profitto dall'utente medio (quello a cui interessa installarlo con un click; gli altri potranno sbattersi dietro webkit nel frattempo). Ma soprattutto quella di WebKit e' un'ipotesi, da relegare a 1) quando ci sara' una gui che fa qualcosa 2) dipendera' dal frontend la scelta di utilizzarla o meno
E' una cosa richiesta da molti, visto che la message view in stile Adium ha sempre fatto un po' di invidia. Da qui a dire che ci sara'... aspettiamo.

Scusa per il lunghiiiiissimo commento, ma proprio non ho resistito :)

Anonimo ha detto...

Sono rimasto "basìto" (cit. Boris - La fuoriserie italiana) leggendo il contenuto del post del forum di aMSN. Poi, la scelta del toolkit grafico è a dir poco incredibile...

Luca Ferretti ha detto...

boyska, sinceramente grazie per i chiarimenti.

ExAzor ha detto...

grazie a te per averli accettati... fa sempre piacere trovare persone disposte ad accettare opinioni cosi' diverse :)