Cominciamo con un "quote"
nessun atteggiamento autoritario da parte mia, nessuna volontà di uccidere lo sviluppo. Chiudere il bug *è* stato per fermare la discussione [...] Questa richiesta di feature ha evidenti problemi di usabilità e non potrà mai essere accettata, sono stato molto chiaro nel bugzillaQuesta io la definirei una contraddizione in termini: se chiudi in bug per fermare la discussione affermando che la richiesta era inaccoglibile, ne deriva che 1) decidi tu solo per cui metti in pratica un atteggiamento autoritario e 2) blocchi quel possibile sviluppo, anche solo per motivazioni di "indagine" e "prototipizzazione". Non hai neanche dato l'opportunità a chi quel bug l'aveva aperto e aveva perso un po' di tempo lavorandoci (ok, magari divertendosi un po') sopra di spiegare le sue motivazioni.
Altro "quote"
[...]gli sviluppatori impiegherebbero tutto il loro tempo libero a parlare e a rispondere ai bugreport. Purtroppo questo non è ovviamente possibile, per cui bisogna limitare il numero dei bug su cui rivolgere le attenzioni[...]Vero, ma bugzilla è abbastanza versatile ed efficiente da permettere la definizione diversi tipi di bug (da "critical" a semplice "enhancement"), diversi livelli di importanza e diversi livelli di temporalizzazione (prossimo rilascio o in un futuro non definito), permettendo di differenziare in modo completo rispetto a un semplice bug aperto|chiuso.
Ancora "quote":
Come puoi notare il numero dei bug segnalati supera il mezzo MILIONECimi, questa è una ca##ata bella e buona, o meglio non è certo una motivazione che si regge in piedi. Mi sembra quasi di vederti su una delle poltrone di porta a porta in doppiopetto blu a snoccialare numeri senza senso.
570.000+ è il numero di bug SEGNALATI a partire da GNOME 1 (10 anni fa). Se non leggo male, il numero dei bug ATTUALMENTE APERTI è inferiore a 40.000, spalmati su tutti i progetti ospitati, non solo sui moduli dello GNOME Desktop. In un arco di tempo di 10 anni discutere due giorni o anche due settimane su una funzionalità non avrebbe di certo causato danni al buco dell'ozono. Ci sono bug aperti da anni con richieste inutili (sì, anche miei, magari) che nessuno si è mai, eufemisticamente parlando, "cagato di striscio". Uno in più non vedo che differenza avrebbe fatto (a meno che, l'essere comparso sul noto blog PollyCoke non comporta automaticamente la necessità di risoluzione immediata del bug in questione).
Comque, a parte tutto cio, lasciando per un attimo da parte ciò, lasciando da parte cioè il modo in cui Cimi ha agito e spiegato le sue posizioni, concentriamoci sulle sue posizioni: la trasparenza in «Esegui applicazione» è stata rigettata ora perché per farla dovremo attendere che ci sia il "blur", cosicché il testo sia leggibile.
Non sto sbagliando, vero? Perché questo ho letto sia sul bug che nei copiosi commenti del noto blog mondano intestato a Felipe.
Benissimo. Condivisibilissimo. Apprezzatissimo (ancor di più se qualcuno ci sta lavorando).
Ma allora, Cimi( e qui parte l'accorata supplica, che lo so che Cimi non ne ha bisogno e magari non gliene frega neanche), in tal caso, ti faccio notare che dovresti immediatamente fare il revert di questo bug (#515907) che aggiunge la trasparenza al monitor di sistema (ispirato, sponsorizzato e patchato da te) e dell'analoga (non trovo il bug su bugzilla, né nei ChangeLog) funzione nel terminale, che magari ricordo male, ma sempre da te era stata fatta o per lo meno partiva.
In caso contrario, dopo mesi a parlare di semitrasparenze, di Murrine, delle GTK+ con RGBA, dopo aver chiesto donazioni per comprare un nuovo portatile con cui continuare a lavorare per il bene di tutti e per rendere figherrimi i nostri GNOME Desktop, se bolli come totalmente inutile il lavoro che altri hanno fatto sul tuo "solco" e lasci invece lo stesso lavoro fatto da te altrove, rischi di attirare su di te la disapprovazione di tutte quelle persone intelligenti e con un minimo di conoscenza che hanno apprezzato i tuoi sforzi e il tuo lavoro. A meno che, ovvio, non ti interessano sono le schiere di adepti che ti osannano. Che potrebbe pure quella essere una scelta.
PS Cimi, ma l'hackfest????
5 commenti:
Ho chiuso il bug prima di leggere di felipe, comunque condividiamo le stesse idee.
Il mio discorso numerico lo sottoscrivo... ovvio che quel numero è relativo a gnome 1... ma se si è sicuri che un bug non verrà MAI accettato perchè tenerlo aperto?
L'ho visto sul planet e mi sono detto "siccome non è minimamente accettabile per i problemi con il testo, meglio chiudere ora per evitare che questi ragazzi sprechino altre energie per una cosa che non verrà mai accettata".
Il blur non lo vedremo mai, sulle intel funziona SOLO con le 965 e con i driver 2.6, sulle nvidia solamente dalle 6200 in poi è accettabile, sulle ati funziona solamente con i driver closed e bisogna possedere anche lì schede recenti... Inoltre in metacity non verrà mai aggiunto, nemmeno con mutter (ho parlato con ebassi). Questo bug non s'ha da fare purtroppo...
Insomma se volete la dimostrazione che aprire quel bug farà solo che perdere un sacco di tempo in due click ve lo riapro e vi dimostro che almeno questa volta ho ragione. E' una cosa che non verrà M-A-I accettata in gnome 2.x. Ficcatevelo nella zucca :)
Piuttosto la butto lì, perchè non fare una patch analoga per la luminosità? gnome-power-manager mostra ancora una vecchia finestrella opaca, e non ha certamente problemi di testo...
"Ma allora, Cimi( e qui parte l'accorata supplica, che lo so che Cimi non ne ha bisogno e magari non gliene frega neanche), in tal caso, ti faccio notare che dovresti immediatamente fare il revert di questo bug (#515907) che aggiunge la trasparenza al monitor di sistema (ispirato, sponsorizzato e patchato da te) e dell'analoga (non trovo il bug su bugzilla, né nei ChangeLog) funzione nel terminale, che magari ricordo male, ma sempre da te era stata fatta o per lo meno partiva.
In caso contrario, dopo mesi a parlare di semitrasparenze, di Murrine, delle GTK+ con RGBA, dopo aver chiesto donazioni per comprare un nuovo portatile con cui continuare a lavorare per il bene di tutti e per rendere figherrimi i nostri GNOME Desktop, se bolli come totalmente inutile il lavoro che altri hanno fatto sul tuo "solco" e lasci invece lo stesso lavoro fatto da te altrove, rischi di attirare su di te la disapprovazione di tutte quelle persone intelligenti e con un minimo di conoscenza che hanno apprezzato i tuoi sforzi e il tuo lavoro. A meno che, ovvio, non ti interessano sono le schiere di adepti che ti osannano. Che potrebbe pure quella essere una scelta."
1) Abilitare la colormap RGBA non significa applicare le trasparenze. Di fatto, se tu apri il system monitor con clearlooks, non mi sembra affatto sia trasparente. Comunque non ho più fatto patch simili perchè, dopo averne discusso pure nella ML gtk-devel, ci sono più problemi che vantaggi.
Ciò nonostante ripeto, tra dire ad una applicazione di abilitare la colormap RGBA e avere uno sfondo trasparente c'è una grandissima differenza... credo KDE4 usi la colormap RGBA di default però non mi pare konqueror o dolphin siano trasparenti!
2) La patch per le trasparenze nel terminale esiste da anni, molto prima di quando io imparai a scrivere la prima riga in C :)
Non sono MAI stato in contraddizione su queste cose, GNOME ha delle linee guida da rispettare. Abilitare le trasparenze è una cosa che so benissimo fare e che avrei potuto fare per Clearlooks, ma non l'ho fatto perchè non è possibile piazzare temi trasparenti con tutti i problemi di usabilità che ne derivano.
I miei lavori tipo murrine, che vanno in contrasto con alcune linee guida di gnome, sono infatti progetti esterni.
Ho appena riaperto il bug, chissà che succederà, vedremo queste fantomatiche trasparenze nel pannello o avevo avuto ragione? :)
"siccome non è minimamente accettabile per i problemi con il testo, meglio chiudere ora per evitare che questi ragazzi sprechino altre energie per una cosa che non verrà mai accettata"
Ahahahaha... da oggi sarai "Cimi il paladino"!
"Il blur non lo vedremo mai, sulle intel funziona SOLO con le 965 e con i driver 2.6, sulle nvidia solamente dalle 6200 in poi è accettabile, sulle ati funziona solamente con i driver closed e bisogna possedere anche lì schede recenti..."
Peccato, siamo nel 2009, e forse resteremo sempre nel 1989 di questo passo. Ah, ma no... poi ci sarà un "hackfest" per decidere come creare il futuro GNOME e a prendere le decisioni sarà un gruppo di hacker senza mai tenere conto di cosa gli utenti vogliano. Perché non mi pare sia mai stato chiesto nulla agli utenti per almeno sondare cosa realmente vogliono o come usino il computer. Il futuro "workflow" di GNOME 3.0 sarà basato sul "workflow" di un gruppo di hacker...
"E' una cosa che non verrà M-A-I accettata in gnome 2.x"
Allora perché è stata accettata la patch a gnome-system-monitor che con il compositing_manger ha le "trasparenze" (o il "blur" che dir si voglia) ed è una porcata micidiale messa assieme a Murrine? Non so se te ne sei mai accorto, ma è incomprensibile quella roba quando è attivata... Oppure non è stata accettata, ma semplicemente inclusa perché qualcuno che si sente investito di un potere che non ha lo può fare? A me pare che sia il metodo con cui è stato fatto il tutto ad essere sbagliato: chiudere perché è una trasparenza che non piace, quando magari si poteva dire "abilitate l'RGBA e ve la faccio passare". E se non fosse stata fatta passare in quel modo, beh... sarebbe stata proprio una bella merda: io ho potere sull'SVN e faccio quel cazzo che voglio. Non è così che funziona l'open source. Tra l'altro, in questo modo hai creato un precedente per includere quel tipo di patch...
"Non sono MAI stato in contraddizione su queste cose, GNOME ha delle linee guida da rispettare."
Per fortuna che le ha... peccato però che da allora non mi pare siano mai più stati fatti altri grossi studi di usabilità per aggiornare o estendere quella guida... gli unici aggiornamenti che ci sono sono "cosmetici"...
"ma non l'ho fatto perchè non è possibile piazzare temi trasparenti con tutti i problemi di usabilità che ne derivano."
Ma aggiungere un'opzione del cazzo in "Preferenze dell'aspetto" che se esiste una sorta di "compositing" può abilitare le trasparenze può sembrare brutto? Va contro l'usabilità? È un'opzione di troppo che porterà GNOME nel baratro della non usabilità? Deve essere fatto dalla Ubuntu di turno per poi scagliarsi contro additando alla blasfemia e alla non usabilità? Se un utente vuole distruggersi gli occhi con le trasparenze non lo può fare? Ah no... ora lo può fare SOLO con un'applicazione.
madonna che commento... sembra proprio che le persone non vogliano capire.
il monitor di sistema NON è trasparente, perchè continuate a dire che lo è????? Il mio non lo! Se ubuntu distribuisce pacchetti di software in sviluppo con trasparenze abilitate NON venitevela a prendere con noi sviluppatori e non sparate *vaccate* del tipo che c'entro io perchè questa volta mi girano proprio.
Abilitare il canale alpha è una cosa giusta e prima o poi dovrà essere fatto per l'intero desktop, proprio come fa KDE4, Windows Vista, Leopard, perchè permette di fare cose tipo tooltips rotondi, menu rotondi ed altri effetti grafici, senza per forza dover passare per le trasparenze.
Tu sei il classico lettore che parla a sproposito, racconti che io spingo per abilitare trasparente o cose del genere quando è l'esatto opposto. Ti sei fatto la tua storia in cui io sono il brutto cattivo che vuole avere l'esclusiva.
Ma leggi il mio blog, leggi il sito di murrine, e scoprirai che ho sempre detto che abilitare le trasparenze senza blur è la cosa più stupida che si possa fare, e mi sono SEMPRE dichiarato CONTRARIO ad esse.
E se non ti va di leggere il mio blog perchè ti sto antipatico, almeno abbi la decenza di non mettermi in bocca cose che non ho mai detto.
Posta un commento