Cosa farne del colorscheme

[lucas992x]

Descrizione

Il modulo colorscheme è decisamente scomodo da usare al momento. Ecco la sintassi per richiamarlo: {{#invoke: css | horizGrad | #{{#invoke: colorscheme | kanto | dark}} | #{{#invoke: colorscheme | kanto | light}} }} Da notare che in vari casi i colori usati nel colorscheme non corrispondono agli omonimi del modulo colore, quindi non basta sostituirlo con {{#invoke: css | horizGrad | type = kanto }}. Per esempio il colore kanto è rosso, e quindi crea un gradiente da rosso chiaro a rosso, mentre il colorscheme omonimo crea un gradiente da rosa a verde (v. screen).

Ecco le possibili soluzioni:

• Se vogliamo tenere il modulo colorscheme, modificare il modulo css in modo da poter usare una scrittura del tipo {{#invoke: css | horizGrad | colorscheme = kanto }}.
• Cancellare il modulo colorscheme e trasferire questi colori nell'attuale modulo colore (magari con un prefisso apposito come _colorscheme__), nei valori light e normale rispettivamente, in modo che la sintassi del tipo {{#invoke: css | horizGrad | type = colorscheme_kanto }} funzioni. Il valore dark lo si può tranquillamente mettere uguale a normale, visto che di questi colori interesserebbero solo le prime due sfumature.
• Cancellare il modulo colorscheme, e in tutte le pagine che usano il colorscheme, sostituire il parametro colorscheme con i due colori voluti.
• Cancellare il modulo colorscheme, e in tutti i template e in generale gli elementi che usano il parametro colorscheme, inserire uno switch immenso che per ogni possibile valore richiami i due colori voluti. E ogni volta che si vuole aggiungere una nuova combinazione, aggiornare questo switch in tutti i template e le pagine che lo richiamano (a meno che non si trovi una soluzione migliore obv).

[davla]

Perché hai anche proposto le soluzioni ovviamente orrende?

[lucas992x]

Io non ho proposto nulla, ho solo riportato le proposte altrui XD

[flavio-a]

Un po' di considerazioni:

• sono completamente contrario alla soluzione dello switch. Secondo me il colorscheme non va tolto perché è scomodo da usare (cioè, anche, ma non solo), è perché concettualmente mi sembra una cagata enorme avere due mappe nomi -> colori (i due moduli) semplicemente perché a quelli di Bulba pesava il culo scrivere |color1=red|color2=green e hanno pensato bene di inventarsi questa shortcut |colorschemerda=kanto che non funziona con la mappa "classica" (il modulo colore).
• la soluzione della sostituzione è quella che avevo pensato inizialmente io, ovviamente da fare con infinita calma (mettendo dei parametri opzionali nella versione aggiornata del template così se uno aggiorna la pagina corregge anche quello). I template colore sono rimasti usatissimi per parecchi anni dopo la loro "abolizione", quindi non credo sarebbe stato un problema. Capisco però che questa soluzione risulti scomoda.
• le prime due soluzioni sono quelle che conciliano la fattibilità e il mondo delle (mie) idee, quindi sono più orientato a quelle.

Come già detto, nel mio mondo ideale il modulo colorscheme non dovrebbe esistere, quindi a me la prima soluzione non convince molto. Di contro la seconda mi sembra un po' spostare il problema sul solo modulo colore, nascondendo sotto il tappeto l'esistenza del colorscheme. Ma questa in realtà è solo una para mia, quindi direi che la mia preferenza è per questa soluzione.

PS: ricordo che abbiamo già dovuto annullare una modifica molto bella al modulo colore perché ci serve efficienza negli elenchi non modulizzati (che resteranno non modulizzati ancora per un po', mentre noi vogliamo una soluzione attiva subito), quindi vorremmo una soluzione a basso costo (computazionale) sul modulo colore.

PPS: questa modifica annullata ha fatto divergere il modulo colore sul Wiki e su GitHub, quindi prima di modificare bisogna pareggiarli (sì lo so, dovevo annullare anche su GitHub quando ho annullato sul Wiki ma mi sono dimenticato).

[davla]

In realtà quelli di bulba non hanno fatto il male: se una coppia di colori la usi molto spesso, da' loro un nome. Se scrivi più volte lo stesso pezzo di codice, fa' una funzione.

Sul perché abbiano queste coppie di colori usate così, ho i miei dubbi e le mie riserve. Ma d'altronde, di estetica non ci capisco niente.

Io sarei più favorevole alla prima soluzione. Teniamo il colorscheme isolato, impedendogli di inquinare il resto.

[flavio-a]

Mi può andare bene la prima soluzione, però non voglio che ci siano degli hex nel colorscheme. Ricicliamo quelli del modulo colore: per esempio kanto del colorscheme diventa un alias per rosso e verde del modulo colore.

[lucas992x]

Il fatto è che non sono gli stessi colori. Ma a parte questo (basta trovare colori abbastanza simili), dovremmo aggiornare in contemporanea il modulo css, il modulo colorscheme e tutti i template che usano quest'ultimo. Fattibile ovviamente, ma non così immediato.

[davla]

Il Modulo CSS si può aggiornare per primo. Il colorscheme non credo debba essere aggiornato, ma in tal caso si dovrebbe fare senza cambiare l'interfaccia esterna. L'aggiornamento delle chiamate si fa sul lungo termine tranquillamente.

@flavio-a Non capisco quale sia il problema degli hex nel colorscheme.

[flavio-a]

Mi urtano l'esistenza

perché concettualmente mi sembra una cagata enorme avere due mappe nomi -> colori

Tu mi dirai che sono stupido, e probabilmente hai ragione, ma non voglio due posti in cui andare a cercare gli hex. Uno dovrebbe trovarseli tutti in un posto solo. Comunque boh, alla fine mi va bene tutto. Per te è davvero un problema se il colorscheme importa dal modulo colore? Anche perché in molti casi i colori sono già uguali o comunque si usano colori simili a quelli corrispondenti nel modulo colore.

Quindi direi che possiamo fare una lista di TODO:

• [x] aggiornare il modulo CSS
• [ ] (opzionale) aggiornare il modulo colorscheme per importare dal modulo colore
• aggiornare i template che usano il colorscheme: non è davvero parte di quest'issue, si fa quando capita...

[davla]

Se due hex sono uguali potrebbe essere semplicemente per caso, non perché sono meant di essere uguali. Quello che vorresti fare tu è una cosa del genere, che converrai non avere alcun senso:

buckets = [(1, 2), (3, 4)]
buckets_count = len(buckets)
bucket_lengths = [buckets_count, buckets_count]

Ignora le ridondanze e guarda al concetto.

[flavio-a]

Non ho capito come il tuo esempio si correli al nostro caso, comunque i colori non sono uguali per caso ma perché sono meant to be, ne sono abbastanza sicuro (ma controllerò).

[flavio-a]

Continuo a non capire in che modo il tuo esempio si correli al nostro caso. Puoi spiegarmelo meglio @davla? Comunque ho controllato e tutti i colorscheme nuovi sono copie esatte degli hex del modulo colore. Quelli più vecchi sono effettivamente diversi. Resto della mia idea di togliere gli hex dal colorscheme, però se volete tenerli posso sopravvivere lo stesso.

Per il resto si tiene l'interfaccia, si aggiunge la funzione al CSS e via.

[davla]

Non sto seguendo più la questione, perché non comprendo i problemi da schizzoide OCD di @flavio-a. Smazzatela da solo, mi va bene qualsiasi cosa tu faccia.

[flavio-a]

Non so se avrò davvero voglia di aggiornare il colorscheme per usare il modulo colore o meno, ma in ogni caso il colorscheme resta vivo (eventualmente solo come interfaccia per raggruppare chiamate al modulo colore) quindi questa issue si può chiudere (i refactor interni non si discutono).