Il 08/07/2015 19:08, enrico franchi ha scritto:
2015-07-08 15:54 GMT+01:00 germano carella <germano.care...@gmail.com
<mailto:germano.care...@gmail.com>>:
Allora, ho tolto il resto, perché rispondo a questo: non è che non
voglio lavorare con gli sviluppatori per rendere qualcosa
accessibile, è che per farlo ci vuole anche la volontà di studiare
un aspetto che, ti assicuro, non è per niente semplice.
Si, chiaro. Ed e' il motivo per cui puoi dare una grossa mano proprio
perche' tu ti interessi del problema e loro no.
Mettere le mani su un software completamente inaccessibile
significa, a conti fatti, rallentarne lo sviluppo.
Si.
Mi hanno assicurato che lo faranno, ma non sanno quando. Ciò vuol
dire che potrebbe anche passare un anno.
O 5.
Mi occupo di accessibilità da 13 anni, un po' per lavoro, un po'
perché io sono non vedente e quando scrivo una cosa, se non la
faccio accessibile almeno per me, non ha molto senso che io la scriva.
L'accessibilità di un'applicativo va progettata dall'inizio, se lo
sviluppatore decide di non usare oggetti standard.
Chiaro. E suppongo che se usa oggetti non standard sia comunque
possibile, sapendolo fare, renderli comunque accessibili.
Assolutamente, specialmente in QT, perché QT ha già delle classi
predisposti ad interfacciarsi con QWidget. La cosa è piu' difficile,
perché di ogni QWidget va scritta l'interfaccia che si occupa di
comunicare con le AT: l'oggetto dev'essere presentato all'AT, va create
l'interazione con la tastiera e gestiti gli eventi che comunicano all'AT
i nuovi valori, o il nuovo testo.
Tanti sviluppatori mi ascoltano, ma tanti, ti garantisco, mi
rispondono che se il progetto è open-source, posso tranquillamente
metterci io le mani per renderlo accessibile.
E non vedo perche' stupirti di questo. E' *esattamente* come funziona
l'open source. Esattamente come se a me interessa una feature che non
c'e' o me la scrivo o aspetto che me la scrivano. Esattamente come se
ho un baco che mi da fastidio o me lo fixo o aspetto che lo facciano
per me. E se lo fanno gli altri, lo fanno gli altri quando hanno tempo
e voglia.
No no, niente stupore. Semmai credo che la difficoltà sia mia, leggere
il codice che ha scritto qualcun altro è estremamente lungo e lento, se
non hai qualcosa che ti velocizza il lavoro.
Faccio un esempio: in visual studio puoi collassare la struttura di un
file c#, vedendo solo le classi principali. Se ne vuoi leggere una, apri
la struttura ad albero e vai alla definizione dei metodi.
Con un editor testuale e python, dove non c'è il fine blocco ma solo le
indentazioni, la prima difficoltà che ho è il colpo d'occhio; devo
leggere tutto in maniera sequenziale, stando attento a contare i livelli
di indentazione.
A volte riesco a trovare quello che mi serve, altre volte, lo ammetto,
mi viene molto difficile...
Ora, io mi rendo conto che per te "accessibilita'" non e' esattamente
una feature come un'altra, e' il fondamento minimo senza cui non si va
avanti. Pero' il modo in cui funziona l'open source e' esattamente che
se hai bisogno di qualcosa hai il *potere* di farlo. E in un certo
senso e' anche il modo piu' rapido per ottenere qualcosa.
Lo so, lo so, hai ragione. Per questo sono sempre alla ricerca di editor
o roba simile open, perché se magari trovo qualcosa che piu' o meno è
accessibile si può lavorare su quella...
Avevo trovato degli editor scritti con scintilla, ma mi sono accorto che
il problema sta nel controllo base. Praticamente, dopo che sei arrivato
a leggere la cinquantesima riga di codice, lo screen reader impazzisce:
ti legge non la linea che sta sul cursore, ma quella che gli sta
sopra... e ancora non ho capito il perché! è un comportamento che sfugge
alla mia comprensione.
Vabbè, la taglio qui perché è poco interessante.
E invece e' *molto* interessante. Perche' secondo me il punto e' che
stai sbagliando approccio (e te ne pentirai).
Ok, parliamone allora...
Concludendo questa tiritera infinita, senza dubbio ci sono cose
che non so, sfido a trovarne uno che le sappia tutte;
probabilmente mi sono occupato troppo di accessibilità e ho
tralasciato qualcosa, ma preferisco colmare qualche lacuna studiando,
No aspetta... e' chiaro che nessuno sa tutto. Ed e' esattamente per
questo che ti dico che se sei bravo a farne una e' un peccato che tu
non benefici delle skill degli altri sulle cose su cui loro sono forti
e che loro beneficino delle tue su quelle su cui tu sei forti.
piuttosto che mettere le mani su un progetto di cui l'autore,
mentre io cerco di capire come l'ha scritto, ne ha probabilmente
fatte altre 5 o 6 release.
E quindi? Ci sono i branch, no big deal. Tutto lo sviluppo software
funziona cosi'. Una volta che hai fatto il merge del tuo codice con un
set di regression che asseriscono quello che hai fatto, le future
versioni *rimarranno* accessibili.
Tornando a noi... ora supponiamo che $editor sia il miglior editor
immaginabile, sviluppato da centinaia di persone. E' un editor
flessibile, che supporta quasi tutto la fuori e che se non supporta
qualcosa puo' essere esteso facilmente. E', in altre parole, l'editor
che vorresti usare... solo che non e' accessibile. Quindi non puoi
usarlo. Ora, invece di provare a renderlo accessibile, ne scrivi uno
da 0.
Questo sara' sviluppato da una persona. Tu. Non avra' le features
dell'altro (perche' per quanto tu sia bravo, non puoi essere veloce
come un'intera community di persone). E dovrai re-iniziare a
implementare cose di base che gli altri hanno gia'. Non solo, proprio
perche' nessuno sa tutto, ci saranno cose che altri si aspettano che
un editor faccia cui tu non hai nemmeno pensato. In altre parole
"condanni" te stesso (e la community di non vedenti) ad uno strumento
peggiore. Perche' parlo di "community di non vedenti"? Beh, perche' se
a te mancano un centinaio di features dell'editor sopra-menzionato e
quello che offri in piu' e' l'accessibilita', di fatto creerai una
community di persone che fra virtualenv e accessibilita' scelgono
l'accessibilita' (virtualenv qui e' un esempio). E guarda caso, credo
che questa community sia fatta di persone che non *possono*
sacrificare l'accessibilita'.
In generale, l'idea di "mi riscrivo tutto da 0" (lasciando stare il
discorso accessibilita': e' un pattern comune che si applica ad ogni
tipo di software e di feature) e' molto allettante per l'ego, e' anche
in apparenza piu' facile (perche' di fatto si finiscono per non
trattare i problemi difficili che non interessano e trattere solo
quelli che interessano). Ed e' un pattern che porta solo a
frammentazione e a problemi di ogni tipo.
Poi e' interamente possibile (tornando a parlare del tuo problema
specifico) che uno specifico editor sia davvero troppo complesso da
rendere accessibile. Pero' fra quelli con una certa trazione e
community potrebbe essercene uno che invece e' fattibile. Certo, sara'
doloroso e complicato. Pero' alla fine avrai qualcosa di migliore, tu,
i tuoi utenti e in generale la comunita' dei non vedenti.
e su questo siamo assolutamente d'accordo.
Non pretendevo infatti di scrivere un editor come emacs, o come eclipse,
solo un piccolo notepad un po' piu' avanzato, tutto qui... In effetti il
mio scopo molte volte è didattico, non mi stanco mai di imparare cose
nuove, in realtà vorrei saperle tutte, ma forse così perdo tempo e non
faccio cose utili, non so...
Senza dubbio occorrerebbe trovarne uno la cui interfaccia non sia troppo
ostica e ci si possa mettere le mani, non dico facilmente, ma in maniera
un po' piu' soft, per questo ne testo tanti... Non hai idea di che
cos'ho in questo computer, sono pieno di editor di ogni tipo e sorta...
ieri sera ne ho preso un altro, liclipse, che ha installato il PyDev.
Questo sembrerebbe promettere bene con l'accessibilità, almeno riesco a
scrivere e leggere del testo e, se l'orecchio non mi inganna, anche a
usare l'autocompletamento... non mi sembra male, ma prima di cantare
vittoria lo devo testare bene.
Cosi', per curiosita', cosa fai di preciso quando l'utente da il
comando di salvataggio? Non mi interessa cosa fa lo screen reader, non
mi interessa al momento la UI: intendo, come implementi il salvataggio
in termini di pseudo-codice?
Utilizzando dei buffer di memoria e scrivendo il contenuto dei buffer
nei file?
Tipo: ad ogni file aperto associo un buffer; non appena scrivo qualcosa
in quel buffer un flag mi dirà che il testo è stato modificato. Quando
do il comando di salvataggio controllo tutti i buffer attivi e scrivo il
contenuto nei file associati solo se il testo è stato modificato.
Potrebbe andare o qualcosa mi sfugge?
Comunque ieri mi sono studiato le unit test e oggi mi appresto a fare
qualche esempio, perché devo imparare come funzionano... la mia vita è
tutto uno studio!
Ciao!
--
.
..: -enrico-
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
