[Python] piccolo editor con autocompletamento del codice

Gio 9 Lug 2015 07:19:50 CEST


Il 08/07/2015 19:08, enrico franchi ha scritto:
>
> 2015-07-08 15:54 GMT+01:00 germano carella <germano.carella a gmail.com 
> <mailto:germano.carella a 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 a lists.python.it
> http://lists.python.it/mailman/listinfo/python

-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20150709/d2f3e2d6/attachment.html>