Flujo de trabajo para desarrollar complementos (y saludo inicial)
Ramón Corominas
Lo primero, un saludo para toda la lista desde Asturias, España; hace
sólo unos días que me suscribí y tras unos días "fisgando" este es mi
primer mensaje por aquí.
Para quienes no me conozcan, aparte de mi nombre que ya os saldrá en el
remitente, os cuento que soy consultor de accesibilidad y que también
programo algo en Python. Precisamente por eso último estoy interesado en
empezar a "jugar" y a hacer pruebas para crear addons de NVDA.
Así que aquí vengo a preguntar a quienes ya habéis recorrido esos
primeros pasos sobre cómo lo hacéis, es decir, qué flujo de trabajo
seguís, editores, carpetas donde trabajáis, repositorios, control de
versiones, depuración, pruebas, etc.
; por el momento creo que ya tengo más o menos claro cómo va el tema en
lo que se refiere a la programación en sí, aunque sin cosas muy
avanzadas por ahora; eso sí, ya he probado a realizar algunos de los
ejemplos básicos que vienen en la guía de desarrollo de complementos,
pero esa guía es sólo de iniciación, y tampoco detalla mucho sobre el
proceso y la forma de trabajar en sí. También he mirado un poco por
encima la documentación que está colgada en la página de nvda.es
relativa a traducciones, revisiones, ejemplos y demás, pero creo que ahí
tampoco está lo que busco. También me he descargado el código fuente de
NVDA y compilado los fuentes por si hiciera falta, aunque no he logrado
obtener la documentación de los devDocs.
En resumen, me interesa conocer ´cómo lo hacéis quienes ya os habéis
pegado con los inicios: trucos, consejos, programas, personalizaciones,
linters, testing, complementos de ayuda, documentación, referencias...
En fin, cualquier información que me podáis dar será bienvenida <guiño>
Por cierto, también me he suscrito a otras listas a las que voy a
escribir a continuación, mis disculpas por el cross-posting si os toca,
a medida que vaya aprendiendo intentaré limitar el envío a allá donde
encaje mejor.
Saludín y muchas gracias,
Ramón.
Héctor J. Benítez Corredera
Buenas Ramón y bienvenido.
Voy a intentar ser breve y explicar un poco mi proceder.
Cuando me introduje en el mundillo de la programación de NVDA me sirvió muchísimo un primer contacto que me dio José Manuel.
Su media hora o 45 minutos que estuve hablando con el y preguntándole inquietudes me sirvió muchísimo más que cualquier documentación que hubiese leído hasta ese momento ya que para mi gusto la documentación actual sobre desarrollo a mi por lo menos no me sirvió para entender conceptos necesarios para empezar desde cero a crear un complemento.
Creo que es como meterse a operar sin anestesia y es una opinión personal.
Por lo tanto, mi primer contacto como digo fue José Manuel quien me dirigió por los principios básicos.
Creo que realmente el crear un complemento es fácil ya que con muy pocos conceptos podemos hacerlo luego es Python y Python.
Conforme queramos hacer cosas más complejas pues se va complicando y subiendo el nivel en cuanto a funcionalidades que podemos aprovechar del lector.
Otra cosa que me sirvió mucho es directamente ver código y más código y más y más de complementos.
Al principio no me enteraba de nada, pero conforme veía uno y otro y otro los conceptos se van quedando y llega un momento en el cual uno descubre que hay cosas que son repetitivas y empieza a preguntarse el por que y si se ha visto la documentación de desarrollo entonces empieza a entender dicha documentación.
Al mismo tiempo se va quedando uno con conceptos que más adelante nos servirán.
Una vez en mi caso cuando empecé ya a creer que entendía el mecanismo de cualquier complemento y podía decir puedo modificarlo sobre algo que quiera, puedo entender que si modifico esta función estoy afectando a tal cosa y puedo en definitiva entender el código es cuando decidí dar un paso más y empezar a ver el código directamente de NVDA.
Al principio sinceramente ni la primera, ni la segunda, ni la octava… Me entere de absolutamente nada.
Pero con el tiempo me di cuenta de que cosas que la primera, segunda y tercera vez había visto me servía en la vez 30 para entender cosas.
Poco a poco fui atreviéndome con el código de NVDA y perdiéndole el miedo por que eso era lo que me daba al principio.
Hoy en día puedo decir con la cabeza muy alta que no tengo ni puñetera idea de NVDA que veo el código y me explota la cabeza todavía, pero si e conseguido bucear en el y buscar en momentos dados funciones, clases que me pueden servir ya sea para usarlas en algún complemento o para modificar dicha función o clase para reutilizarla en lo que necesito.
Bien como persona totalmente autodidacta y sin formación académica en cuanto a programación me a servido, ver código mucho pero mucho código.
Dejar de ser un ermitaño y preguntar, perder el miedo a decir no se esto y preguntar a quien pueda creer que si lo sabe.
Esto ultimo en todas las ocasiones me e encontrado con una disponibilidad al 120% de las personas a las que e preguntado en brindarme una ayuda.
Hoy tengo una duda y primero intento por todos mis medios el solucionar o aprender y una vez ya no puedo entonces recurro a gente como José Manuel, David, Javi, Antonio, Gera, Peter dándome cuenta de que al final entre unos y otros consiguen tener lo que necesito solucionar.
E encontrado que entre todos al final uno esta versado en una cosa, el otro en otra y en definitiva el área que entre todos abarcan es enorme.
Otras veces me han preguntado a mi y gustosamente si lo e sabido e brindado ayuda y si no e intentado aprender junto a ellos el solucionar esa duda.
Al final el preguntar es beneficioso por que terminamos aprendiendo unos de otros
En mi caso el ver código y apoyarme en las personas que saben me han servido en poder ir haciendo cosas.
Bien tienes mucho ganado si ya sabes Python pero no se como te llevas con wxpython y creo que esa es otra base muy importante de NVDA.
En mi caso wxpython empecé a manejarlo a la misma vez que iba aprendiendo Python y en la actualidad sigo tanto en uno como en otro aprendiendo pero si a mi por lo menos wxpython y su potencial me sirve mucho para sacarle más partido a NVDA.
Por lo tanto, creo que es importante tener una base de wxpython.
Esto solo es mi opinión y fue mi manera de empezar a aprender, creo que llevo como 2 años y en mi caso sigo aprendiendo ya que todavía hay infinidad de cosas que no se.
Preguntar, código y disfrutar.
Por mi parte estoy por Twuitter y por aquí y en cualquier momento no dudes en preguntarme que si esta en mis posibilidades el ayudar así lo are, e aprendido con NVDA que si yo te ayudo en una duda tuya cuando tu saques ese complemento en el cual e podido ayudarte en una pequeña parte al final me beneficio yo por que del resto de tu código aprenderé.
Por lo tanto, por aquí estamos para lo que necesites y seguro que el resto de los compañeros que desarrollan para NVDA por aquí te podrán dar mucha más información y sin dudarlo ayuda para lo que necesites.
Un saludo y bienvenido nuevamente.
Ramón Corominas
Hola, Héctor, muchas gracias por responder.
Sí, a Jose Manuel le doy la lata de vez en cuando por Twitter y si
estoy aquí es sin duda por su disponibiilidad y su ayuda para
dirigirme en la dirección correcta en esos primeros pasos. Estoy
completamente de acuerdo contigo en la parte colaborativa del
aprendizaje, y desde luego en lo de leer mucho código, no en vano
el 90% del tiempo de programación nos lo pasamos en Stack Overflow
<guiño>
En el caso concreto de NVDA sí que de momento he ido viendo por
encima cómo están hechos algunos complementos, y creo que más o
menos me voy enterando, no parece complicado, aunque tengo
pendiente profundizar más en el código del propio NVDA. También
tengo que ponerme al día en wxPython y la creación de interfaces,
por ahora me da la impresión de que está hecho demasiado a bajo
nivel para mi gusto y que se podría simplificar, pero bueno,
iremos avanzando poco a poco.
En cualquier caso, mi pregunta iba más dirigida al proceso en sí a
la hora de crear un complemento, es decir, preguntas como las
siguientes:
1. ¿qué entorno de desarrollo usáis?
- Setup del NVDA (portable/instalado, versión
publicada/sourcemaster...)
- Editor/es de código/markdown, linters, automatizaciones,
otras herramientas...
2. Documentación. Más allá de leer código, no sé, echo de menos
alguna referencia de las librerías, por eso intenté generar los
devDocs, por si de ahí sacaba algo, pero me da un error de Sphynx
y no saca nada...
3. ¿Cómo organizáis los ficheros? ¿Y el código?
- Directorio/s de trabajo, es decir, si trabajáis directamente
sobre el scratchpad o sobre otro específico de cada proyecto.
- Organización del código: paquetes, módulos, clases, funciones,
etc.
- Librerías de terceros: ¿hay algún problema en usarlas? ¿qué
desventajas puede tener?
- ¿Cómo hacéis el control de versiones? (me refiero un poco a la
metodología general que seguís para los commits, ramas, issues,
PR, etc., no tanto a cosas que parecen estar más documentadas como
el versionado o las releases).
3. ¿Cómo hacéis la depuración?
- Sé que (de momento) no hay forma de depurar paso a paso y cosas
así, pero me interesa saber cómo trazáis los errores o las
variables, si usáis logging, decoradores, algún complemento que os
ayude a esto...
- ¿Usáis tests / alguna metodología de CI/CD?
En fin, de algunas de esas cosas tampoco creáis que tengo mucha
idea aunque parezca que sé de lo que hablo, pero me interesa
conocer vuestras experiencias, luego ya adaptaré lo que me contéis
a mis propias circunstancias <guiño>
Un saludín y muchas gracias de nuevo,amón.
--
Visita la web oficial de la comunidad de NVDA en español para acceder a recursos y descargas que desplegarán todo el potencial de tu lector de pantalla:
https://nvda.es
Visita la tienda de la web oficial de la comunidad para adquirir algunos productos, como materiales de formación o sintetizadores de voz, que mejorarán tu experiencia con NVDA: https://nvda.es/tienda/
Consulta las normas de esta lista siempre que quieras en la siguiente dirección:
https://nvda.es/documentacion/normas-de-convivencia-y-buen-comportamiento/normas-de-la-lista-de-correo-de-la-comunidad-de-nvda-en-espanol/
---
Has recibido este mensaje porque estás suscrito al grupo "NVDA en español" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a nvda-es+u...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/nvda-es/5ed2ab7b-87e5-28f9-70ad-453c3069ee9f%40gmail.com.
Héctor J. Benítez Corredera
Buenas, contesto lo que se y otras no por que se me escapa nomenclatura técnica 🤣.
1. 1. ¿qué entorno de desarrollo usáis?
En mi caso uso NotePad++ configurado para Python.
Le tengo algunas configuraciones como que la indexación sea por tabs por ejemplo, pero principalmente casi por defecto todo lo demás.
Junto a NotePad++ uso el complemento Notepad++; Habilitado; 2022.05.1 pero con algunas modificaciones que hizo David y otras mías como el poder listar por función y clases e ir rápidamente, poder cambiar rápidamente desde un dialogo de pestaña esto útil para cuando tenemos muchas y una pequeña modificación para dar rápidamente línea y posición del cursor y no tener que leer la línea de estado que da mucha información y la mayoría no me interesa.
Me encantaría poder usar Visual Code pero hasta hoy no e conseguido hacerme con la interface y por el momento en mi caso queda descartado pero por aquí lo usan y supongo te podrán dar más indicaciones.
Siempre que empiezo un proyecto creo copia portable sin nada excepto esa voz que nos encanta a todos. Sobre todo, si el proyecto va a llevar librerías externas ya que en un portable limpio podremos comprobar si la importación de la librería esta correcta o hace falta algún archivo por hay perdido.
Si lo hacemos en la nuestra instalada con todos los componentes puede que en alguna ocasión dicha librería externa encuentre el archivo que falta en alguno de los complementos y pueden luego venir los problemas al no encontrar ese archivo en otro NVDA que no tenga instalado dicho complemento por lo que si hay librerías externas mejor la importación y pruebas en un NVDA limpio.
Luego directamente tengo clonado el código de NVDA por lo que trabajo directamente con el buscando hasta que encuentro entre los cientos de archivos. Esto no es muy eficiente por que se pierde mucho tiempo y por ejemplo se que con VS Code esto se simplifica bastante más que si cargas el proyecto puedes tener acceso rápido a las funciones del código y poder auto rellenar más ver parámetros requeridos y todo eso, eso me encantaría, pero por lo expuesto más arriba de momento sigo perdiendo mucho tiempo buscando en el código fuente.
2. Si no recuerdo mal José Manuel me dijo de donde poder descargar documentación ya generada con todas las funciones y poder consultarlas, ahora esto mejor si lo lee que conteste el que no estoy muy seguro. Por que al final no lo llegue a usar.
3. ¿Cómo organizáis los ficheros? ¿Y el código?
Si es un modulo para aplicación o globalPlugins el cual no requiera de librerías externas si suelo usar scratchpad, una vez toma forma ya lo paso a una carpeta donde tengo la plantilla de addons y la relleno tanto el buildVars.py donde pondremos todo lo referido a nuestro complemento y el readme.md que será el que lleve la documentación.
El buildVars.py viene bien comentado pero cualquier duda pues por aquí estamos.
En cuanto a la organización en mis últimos complementos intento que el __init__.py solo tenga lo especifico de NVDA la clase globalPlugins y si tuviese clase para agregar panel a opciones también. Luego intento crear módulos para intentar ordenar mejor el código.
En cuanto a librerías externas pues hasta hoy yo e usado bastantes y bueno a veces cuesta acoplarlas a NVDA teniendo en alguna ocasión que modificar la librería, pero en si se pueden usar sin problemas. Si es verdad que hay algunas que no e conseguido portar pero quizás es por desconocimiento o hartazgo de intentarlo y al final desistir.
Pero en definitiva la mayoría no son difíciles de portar.
Eso si tendremos que jugar con la limitación de 32 bits o ya maltratar al NVDA y hacerle algunas perrerías para que pueda comunicarse con librerías de 64 bits.
Esto ultimo por ejemplo me e encontrado con la necesidad de usar torch que solo esta para 64 bits y e tenido que crear un exe para incluir la librería y luego un servidor en local que se conecte con NVDA y le pase los datos que desde el complemento se necesite en cada momento.
Sobre tema github y releases, ramas y todo eso paso palabra por que uso lo básico y es tarea pendiente en algún momento de mi vida.
Solo te comentare que, si uso git actions últimamente para automatizar la subida de las releases, ese es un mundo que tiene muchísimas posibilidades, pero creo que por aquí hay gente que te puede informar más que yo, que simplemente hice un pega y seguí instrucciones que me dio José Manuel.
En cuanto avanzamos en nuestro código y queremos ir probándolo en mi caso soy de directamente reiniciar NVDA ya sea que tengo el código en scratchpad o generando complemento y instalando y reiniciando. Me da más confianza que recargar los complementos y así me aseguro de que empieza realmente todo de cero en NVDA es lento pero seguro.
En mi caso suelo ir probando el código cada muy poco que llevo echo, prefiero ir comprobando cada función escrita o cada paso que doy y una vez que comprueba que funciona sigo al siguiente.
Esto me lleva a la depuración yo a lo bruto, prints e ir viendo que todo pasa por donde tiene que ir pasando. Conforme se va montando el código pues voy metiendo los correspondientes try donde crea que puede fallar y voy depurando por hay, por supuesto pues a mirar mucho el log de NVDA que todo vaya funcionando.
Soy una persona muy desordenada y poco metódica por lo que suelo ser muy burro y equivocándome muchas veces pero compenso con no saber como explicar que cuando se monta en mi cabeza algo que quiero es donde toma forma y luego puedo ir plasmando en código sin necesidad de apuntes o un índice de ruta para el proyecto.
Mi manera no es la ideal, pero a mi me funciona.
Por lo tanto y concluyendo que lo que no contesto es por que no tengo ni idea te diré que si tienes posibilidad por que lo entiendes y te has hecho con el que uses Visual Code y que NVDA tiene wxpython ya incluido y es una librería que nos permite ampliar la capacidad de NVDA no solo a nivel interface si no aprovechar sus cientos de funciones que tiene y que NVDA no usa por no necesitarlas pero que para un proyecto si nos puede servir por lo tanto si creo que es muy interesante meterse con dicha librería y podremos sacar mucho partido junto a NVDA.
Saludos y arriba Stack Overflow es el 95% de
mi 😂 existencia.
Ramón Corominas
antonio....@gmail.com
Hola ramón:
Bienvenido a la lista, y voy a tratar de responder a tus preguntas, aunque ya te advierto, que al igual que Héctor, yo hago las cosas a mi manera.
¿qué entorno de desarrollo usáis?
En mi caso, y al igual que Héctor, en ambas ocasiones he utilizado Notepad++. Yo por mi parte no utilizo complementos extra, porque creo que para los desarrollos tan simples que hago, no es necesario.
Estaría muy bien poder utilizar entornos más completos como el que habéis dicho de VS Code, pero al igual que dije en el párrafo anterior, creo que este tipo de entornos solo son útiles en proyectos en los que hayan muchos ficheros, módulos, o similares.
Documentación. Más allá de leer código, no sé, echo de menos alguna referencia de las librerías, por eso intenté generar los devDocs, por si de ahí sacaba algo, pero me da un error de Sphynx y no saca nada...
Yo personalmente, no utilizo documentación específica. Y en caso de necesitar consultar el funcionamiento de alguna librería de Python, suelo buscar por Google páginas que puedan explicarme el funcionamiento de dicha librería. En cuestiones de NVDA (que en mi caso han sido más bien pocas) suelo abrir una consola Python, y utilizar la función help() con el módulo o función en cuestión.
¿Cómo organizáis los ficheros? ¿Y el código?
- Directorio/s de trabajo, es decir, si trabajáis directamente sobre el scratchpad o sobre otro específico de cada proyecto.
Yo personalmente, suelo comenzar los desarrollos con el complemento en el directorio Scrachpad, y una vez lo tengo medio montado, o montado completo, lo paso a la plantilla oficial en un repositorio local con los cambios que he ido haciendo al complemento. Y en mi último desarrollo, WikiChecker, conforme tuve una primera versión funcional del complemento, lo subí al repositorio de github, para que varias personas de mi confianza, como Jose Manuel y Héctor, pudieran ir echándole un vistazo, y darme feedback. Y para que engañarnos. También por si tenía algún problema, que pudieran echarme una mano viendo el propio repositorio.
- Organización del código: paquetes, módulos, clases, funciones, etc.
En este aspecto, no puedo orientarte mucho. DLEChecker estaba desarrollado en un único archivo, el __init__.py, y WikiChecker lo inicié igual, y finalmente me atreví a rehacerlo utilizando MVC. Y menos mal que me salió bien.
- Librerías de terceros: ¿hay algún problema en usarlas? ¿qué desventajas puede tener?
Se pueden utilizar, y problemas pueden ser diversos. Yo en mi caso para DLEChecker utilicé la libería de BeautifulSoup, lo que me conllevó problemas con el submódulo html, ya que otro complemento lo utilizaba. Si no recuerdo mal, con lo que tuvimos que hacer un apaño para que se solucionase el problema.
- ¿Cómo hacéis el control de versiones? (me refiero un poco a la metodología general que seguís para los commits, ramas, issues, PR, etc., no tanto a cosas que parecen estar más documentadas como el versionado o las releases).
Yo en mi caso, creo el repositorio, y comienzo a desarrollar en la rama master. Sin embargo, cuando tengo la base del complemento hecha, voy haciendo ramas a parte, en las que voy haciendo pruebas, hasta que consigo implementar al desarrollo alguna característica concreta. Una vez conseguido esto, y comprobado que funciona correctamente, lo integro en la rama master, y como decía en el punto anterior, lo subo al repositorio en github. Isues no utilizo, y Pull Requests únicamente para integrar los cambios que otras personas, como Jose Manuel, Héctor o Sukil, me han ido proponiendo. Pero sin complicaciones. Solo aceptarlos, y nada más.
¿Cómo hacéis la depuración?
- Sé que (de momento) no hay forma de depurar paso a paso y cosas así, pero me interesa saber cómo trazáis los errores o las variables, si usáis logging, decoradores, algún complemento que os ayude a esto...
Personalmente lo hago de la forma más simple posible. Con print() y el log de NVDA, aunque tengo clarísimo que debería utilizar loggin.
¿Usáis tests / alguna metodología de CI/CD?
Desgraciadamente no. Aprendí algo en el grado superior, pero no lo suficiente para implementarlo en todos los desarrollos, y mucho de lo que aprendí se me ha olvidado ya. Y como dije en otras respuestas, mis proyectos son tan insignificantes, que no creo que merezca la pena ponerme a leer libros, o a hacer cursos para su aprendizaje. Aunque reconozco su importancia, no creas.
Siento la extensión de la respuesta. Y espero que algo de lo que he dicho, te sirva de ayuda.
Un saludo,
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/nvda-es/c053c4f2-2626-26ca-6a7b-07bf02b3e90f%40ramoncorominas.com.
Héctor J. Benítez Corredera
Buenas.
Sobre NotepPad++ configurado para Python:
Le tengo puesto algunas configuraciones para poder ejecutar directamente desde Python el código, el tema tabulador que para mi es más fácil en la indexación y luego de todos los lenguajes por defecto en su configuración le tengo puesto Python esto ultimo es fácil por que tiene un menú dedicado.
En cuanto el poder ejecutar el código desde el mismo NotePad++ es una línea que, si estas interesado te la comparto o directamente te comparto el archivo de configuración y arreglado, permite ejecutar el código y va bien más para el desarrollo fuera de NVDA que es para lo que lo uso.
Bien sobre el complemento decir que daba problemas en versiones anteriores a la 8.4 del NotePad++, a partir de la 8.4 lo solucionaron.
Decir que esta también el otro complemento de Paul que es posible usar en versiones inferiores de NotePad++ esto si no lo arreglo y que tiene funciones muy interesantes como poder moverse por funciones, clases a través de teclas preasignadas más otras utilidades también para markdown. Bien la ultima vez que lo use me daba muchos errores y a día de hoy no se como estará el complemento. Sera cuestión de echarle otro vistazo por que en serio tenia muy buena pinta.
https://nvda.es/2022/02/09/notepadplusplus-access-enhancement-mejoras-de-accesibilidad-de-notepad/
Bien en cuanto a las modificaciones del que yo uso este el enlace:
https://hxebolax.keybase.pub/Complementos/NotepadPlusPlus_2022.05.1_Gen.nvda-addon?dl=1
Las modificaciones son:
Ctrl+Shift+. Nos abre una lista con las funciones y clases.
Ctrl+Shift+, Nos informa de la línea y posición en dicha línea
NVDA+F6 Nos dará un dialogo con todas las pestañas que tenemos abiertas pudiendo elegir rápidamente la que deseemos junto a poder dar clic derecho para sacar opciones de esa pestaña o crear nuevas pestañas.
Sobre Visual Code pues esperare dicho tutorial ya que me gustaría intentar hacerme con el ya que e leído y visto que la productividad aumenta por todas las herramientas que trae.
Sobre todo, me interesa mucho el poder acceder rápidamente a cualquier función y que me brinde información junto a parámetros requeridos. Eso e podido hacer algo con wxpython y ver como escribiendo solo primeras letras ya me mostraba la lista de todas las funciones que podía elegir solo por eso creo que merece la pena.
Sobre la librería y sus cargas.
Últimamente empecé a cargar la librería incluyéndola en el path y luego una vez cargada quitarla del path para así no entorpecer junto a que ya siempre especifico que la librería que necesite sea cargada de mi complemento no dando posibilidad a buscar ni a cargar otro que pudiese estar en memoria.
Pero en ocasiones puede que esto no suceda y te encuentres con que esta pillando partes de otras librerías ya cargadas y malo si el autor encima te mete librerías recortadas con lo que su complemento necesite. Pues listo te puedes volver loco en entender por que si carga la librería luego a ti no te funciona el complemento al buscar una función de la librería ya cargada correctamente.
Hasta que te das cuenta de que es una librería modificada y que tu función no esta. Verídico y me dio muy buenos dolores de cabeza.
Desde entonces intento lo de más arriba no dejar a mi complemento la posibilidad de cargar de otro sitio que no sea el directorio que yo le de y en mi caso prefiero aumentar el peso de un complemento y meter la librería entera y no solo lo que necesite.
Sobre el buildVars.py es el archivito de la plantilla de complementos que al rellenar es donde ponemos el nombre interno del complemento, nombre visible del complemento, una descripción, es quien le dice donde buscar los archivos cuando compilemos el complemento, versión necesaria de NVDA para dicho complemento, idioma en el que esta escrito el complemento, etc.
Como te puse esta bien comentado pero quizás la primera vez si aturulla un poco, de echo recuerdo que con ello también le di por saco a José Manuel.
Sobre librerías y su importación:
Si la ultima por ejemplo que recuerdo es torpy para poder obtener información de la red TOR y poder hacer alguna cosa con un complemento que no puedo nombrar por aquí 🔇. Realmente no fue dicha librería pero si una de sus dependencias la cual no hubo manera de portar no me acuerdo si fue Cryptodome o cryptography creo que esta ultima pedía dll que luego no me funcionaban y no conseguía apuntar correctamente hacia ellas.
En librerías que tienen muchas dependencias si uso entornos virtuales principalmente para tenerlo todo en el mismo sitio y no tener que tener que bucear en los directorios de la copia instalada de Python, en librerías pequeñas pues directamente desde la copia instalada aunque alguna una vez la portas empieza a pedir y pedir archivitos sueltos de librerías estándar de Python y bueno por eso lo de la copia limpia de nvda.
Bien sobre NVDA y sus 32 bits y librerías solo de 64 bits.
Estoy con un complemento que necesita torch bonita librería que pesa 1.6 GB la cual solo esta para 64 bits.
Bien en este caso si e reducido la librería y me e quedado con lo que necesito dejándola en 230 megas.
El proceso es crear un servidor local con multiprocessing o socket al final creo que me quedare con esto ultimo pero tengo que seguir averiguando ya que la primera opción me a traído algún problema de compatibilidad en algún ordenador.
Bien es crear un ejecutable que quede en memoria y desde el cliente del complemento mande un comando que permita parámetros y el ejecutable devuelva lo requerido.
En este caso es un traductor offline el cual desde el cliente del complemento le mando la frase por ejemplo en inglés y el servidor del ejecutable me devuelve al complemento la frase traducida al idioma que tengamos elegido.
Funciona y muy rápido yo es actualmente el que uso pero todavía no lo e lanzado por que hay cosas que hacerle ha corrido por hay alguna versión para que la gente probase.
Bien en cuanto a su distribución yo en estas primeras versiones e incluido el ejecutable en el mismo complemento principalmente por un tema de trabajar en el complemento en si y no cargarme de más trabajo si distribuyera el servidor aparte ya que tendría que crear un dialog especial para decir donde esta el servidor, controlar desde ese directorio el servidor y se abre un bonito abanico de posibilidades de problemas que pueden surgir si no lo tengo bajo mi control y dejo que sea el usuario quien instale el servidor.
Pero esto ultimo tengo que estudiarlo por que si añado el servidor al complemento se queda un bonito complemento de 200 megas sin idiomas y todavía no se si meteré algún idioma por defecto añadiendo por idioma 100 megas más.
Sobre wxpython mira esta es una pagina con funciones y tiene desde poder manejar tema de coordenadas de pantalla por ejemplo para capturar (esto ultimo no se si al final Javi lo termino usando para su complemento para capturar pantalla o partes de pantalla), manejo de cursor, se pueden crear macros para automatizar interfaces, trabajar con algunos tipos de base de datos, utilidades para fecha, hora, obtención de información de ventanas y mucho pero mucho más la siguiente pagina como digo es una muestra de funciones ya definidas que puedes usar pero cuando uno empieza a bucear en esta librería simplemente aparte de poder crear interfaces pues tiene infinidad de añadidos que uno puede utilizar. NVDA usa muchos pero no todos y como comente al venir incluida en NVDA nos podemos aprovechar de ella.
https://wxpython.org/Phoenix/docs/html/wx.functions.html
Bien en cuanto a interfaces esto a gusto colores, NVDA trae su propio no se si llamarlo lenguaje sobre wxpython supuestamente para facilitar su manejo pero en mi caso al estar acostumbrado a usar wxpython fuera de NVDA uso la manera clásica y no uso las funciones que NVDA tiene para facilitar el uso.
Sobre esto hay un repositorio que por si te diera el día de mañana ponerte con interfaces te podría interesar:
https://github.com/wxGlade/wxGlade
Es una gui para crear interfaces fácilmente y poder generar el código rápidamente. No trae todos los controles que wxpython permite pero si una gran mayoría casi diría suficiente para la mayoría de casos, algo bueno es que tiene un modo de accesibilidad el cual nos detectara si usamos lector de pantalla y nos dará indicaciones para activarlo y a si poder usar la gui y poder crear nuestras plantillas y luego poder exportar el código a nuestros proyectos.
Bien siempre he dicho es una comodidad pero mejor primero aprender a hacer una interface a mano y luego una vez ya se tiene un poco de conocimiento de wxpython pues ahorrarse tiempo con esto pero es muy importante tener unos conocimientos de wxpython por que de lo contrario podremos generar interfaces pero al final siempre hay que meter mano al código y si no estamos puestos con wxpython pues de poco sirve wxglade.
Wxglade es para facilitar y ahorrarnos trabajo de escribir pero nunca sustituir el aprender wxpython.
Te lo dejo por que seguro le sacas partido a futuro y desde que entro a mi vida es un indispensable.
Saludos.
David CM
Mi flujo de trabajo ha cambiado mucho a lo largo de los años.
Actualmente utilizo vs code como editor incluso para el proyecto más
pequeño, porque considero que VS code es muy liviano. Al menos, en mi
computadora corre igual de bien que notepad++. Y es que yo pasé de
usar algo llamado Textpad (lo usaba solo porque se acordaba de la
última sangría) y así hice el controlador para IBMTTS allá por el
2008.
Luego pasé a usar eclipse (que solo lo hacía en proyectos grandes)
después le siguió notepad++ para los pequeños, y ahora vs code que lo
uso para casi todo.
Cuando decido hacer un add-on lo primero que inicio es el repo, basado
en la plantilla de complementos. Así que ya tengo una estructura
básica de directorios, y un scon que me genera el add-on empaquetado
por si quiero dárselo a alguien para que vaya haciendo pruebas.
Bien, una vez que configuro el buildVars que me hará toda la
configuración, y escribo un poco de código, lo instalo en mi propia
copia de NVDA. Con bastante frecuencia cambio mi vs code para trabajar
directamente en la carpeta de ese add-on instalado. Así no tengo que
estar instalándolo cada vez que hago cambios.
Pero al hacer eso, pierdo el entorno que ya tengo configurado, porque
yo tengo para que vs code analice y me autocomplete el código desde el
source de NVDA.
La documentación de desarrollo de NVDA no me gusta mucho, creo que no
me gusta mucho la forma en que la herramienta la genera. La siento
incómoda de leer.
Así que siempre mantengo una copia local del código fuente de NVDA, y
también le tengo una configuración para VSCode.
Entonces cuando pienso en una idea, si no sé como implementarla, me
voy al proyecto local de NVDA, y analizo los módulos que creo que me
podrían servir. Hay algunos que son muy conocidos, como por ejemplo
tones, speech, ETC.
Pero por ejemplo cuando hice el de synthRingSettingsSelector, me tocó
analizar el código fuente para ver como podía parchear el core de NVDA
en ese aspécto específico.
Lo mismo cuando hice enhanced phonetic reading, tuve que darle
seguimiento desde el momento en que un script hacía algo similar pero
lanzado por el usuario y no por un timer.
Y lo mismo podría decir de beepKeyboard, esa vez tuve que ver que
pasaba detrás del momento que se activaban o se desactivaban las
mayúsculas, porque inicialmente ese era el objetivo, no pretendía que
fuese un complemento más grande.
Luego cuando se trata de crear diálogos y así, como no es mi área
fuerte, siempre sigo ejemplos del mismo GUI de NVDA, o de otros
complementos.
Cuando hice IBMTTS, primero observé muy bien el funcionamiento de
Espeak, además de estudiar el SDK de IBMTTS. Era bastante novato en
ese entonces, así que ni siquiera tenía idea de como cargar librerías
DLL.
Por último y como mencioné al inicio, git no puede faltar. Y para
publicar los releases utilizo un github workflow, que me genera un
release cada vez que subo un tag. Ya todo eso lo tengo puesto en el
template de add-ons, entonces no me toca configurar mucho al respecto.
Además trabajo en un branch aparte cada vez que quiero hacer algo
nuevo, y lo pongo en el principal cuando está listo.
Si alguien tiene problemas, prefiero que me los reporten en los issues
de github, pero no todos tienen cuenta. Así que dejo el correo por si
acaso.
A veces me mandan PRs, esas las reviso con una extensión de VS code.
Si todo está bien, la integro en la principal. Siempre trato de
mantener el repo lo más actualizado posible, para que quien haga sus
aportes, tenga la última versión y no me genere inconvenientes. Con
frecuencia pongo instrucciones de como realizar las contribuciones.
Complementos como IBMTTS reciben varios PRs, y no es buena idea que
utilicen branchs desactualizados.
En el readme tengo un link que apunta hacia el nombre del repo, y con
el mismo, genera un link de descarga para el último release, así no
tengo que estar actualizando el link del release.
Creo que eso es la mayoría de las cosas que yo hago al desarrollar
complementos para NVDA. Gran parte ya está en los templates, entonces
no me conlleva esfuerzo. A veces se me pierde el template jeje,
entonces tomo de referencia algún add-on ya creado.
Seguro que se me queda mucho por mencionar, de cosas que no recuerde
en este momento, pero creo que eso sería en su mayoría...
No acostumbro a usar librerías externas porque mis add-ons están más
enfocados en la funcionalidad interna de NVDA, más que conectar con
servicios externos.
Saludos.
José Manuel Delicado Alcolea
Buenas.
Ramón, yo me quería ir de vacaciones. Si haces hilos tan interesantes como este, me pongo a leer y leer, me siento obligado a contestar, y así no hay quien desconecte! Bueno, allá voy con mis respuestas.
- Entorno de desarrollo: yo uso Notepad++ para todo. Lo he
configurado de tal forma que se comporte como un editor de texto
plano. No utilizo ni autocompletado, ni autoindentado, ni nada.
Los únicos motivos por los que no me quedo simplemente con el bloc
de notas son la posibilidad de buscar en varios archivos a la vez,
y el control sobre la codificación del texto. En cuanto a mi NVDA,
lo tengo instalado y me muevo entre versiones estable y beta. Doy
el paso a las snapshots alfa cuando hay que hacer pruebas muy
concretas, pero luego regreso. Me gusta usar tabuladores para
indentar.
- Documentación: efectivamente, no se puede generar. No es que te falle sólo a ti, nos sucede a todos. Hay que abrir una incidencia o escribir por la lista nvda-devel, tal y como te han sugerido en otro lugar. No obstante, te puedo dejar la última que compilé, y que subo para todo el que la quiera: https://nvda.es/wp-content/uploads/nvda_2021.3_devDocs.zip
Sin embargo, la documentación no es mi fuente principal de información. Uso una combinación de consola Python de NVDA y exploración del código fuente, ya sea en master o en el tag de la versión actual. El código fuente te permite saber cómo se llaman los módulos y, eventualmente, ver cómo están hechos por dentro. En la consola, por otro lado, puedes hacer import de un módulo y llamar a help(módulo) o help(módulo.función). La tecla f6 te permitirá moverte entre el historial y el cuadro de edición para escribir comandos. Si has importado un módulo, puedes teclear las primeras letras de su nombre, o del nombre de una de sus funciones, variables o clases internas, pulsar tabulador, y la consola te autocompletará. Si hay varias opciones, mostrará un menú de contexto para que elijas una de ellas. Algo que yo hago mucho es escribir módulo. tabulador, y así me saca toda su implementación pública. Si quieres acceder a las partes privadas, después del punto pones uno o dos guiones bajos. Verás cosas diferentes en los dos casos.
- Directorios de trabajo: me gusta hacerme un repositorio Git con la plantilla y empezar desde allí. Si hay algo que quiero probar porque pienso que ya está listo para pruebas, lo llevo al scratchpad. Allí retoco lo que haya que retocar y voy reiniciando NVDA. A veces, pulsar simplemente NVDA+control+f3 hace que pasen cosas raras.
- Organización del código: depende. Si es muy simple, todo va en un único archivo. Si tengo varias clases y puedo agruparlas claramente según su propósito, hago varios módulos.
- Librerías de terceros: Antonio ya te ha contado lo que le pasó con html, así que depende mucho de la librería que uses. Lo único que te puedo decir es que no todas las librerías estándar de Python están incluidas, que las que uses lleven preferiblemente imports relativos, y que nunca intentes establecer relaciones de dependencia entre complementos. No acaba bien porque NVDA no lo tiene previsto. Si metes una librería, no es recomendable que la compartas entre varios complementos. Esto puede aumentar el número de archivos duplicados y el tamaño general de la instalación de NVDA, pero de momento es lo que hay.
- Control de versiones: cada uno a su manera. Yo soy de firmar
commits con gpg y poner mensajes de una sola línea resumidos y tan
explicativos como sea posible. Intento que cada commit se centre
en una tarea concreta, aunque no siempre me sale. Si veo que el
desarrollo va a tener cierta complejidad, hago ramas.
- Depuración: en opciones avanzadas, tengo activado el sonido de error. Cuando se produce un error, miro el log de NVDA. A partir de ahí, voy siguiendo la traza. El truco del print también es muy útil, y también lo aplico.
- Tests y CI/CD: NVDA tiene su propio marco de pruebas, pero sólo
es válido para el propio NVDA. Es difícil automatizar los tests de
funcionamiento en un complemento. De momento, lo más cercano al
testing que hay es Flake8, un linter que analizará el código en
busca de fallos de estilo, pero también de variables / imports no
usados y otros posibles errores. Se puede integrar con las GitHub
Actions. Ahora mismo, yo tengo configurado Flake8 para que se
ejecute cada vez que hago commit o recibo una pull request, y
creación automática de releases cuando añado un tag. La experta en
el asunto de las actions es Noelia. De hecho, algunas de las que
uso se las he tomado prestadas y las he adaptado a mis
necesidades.
Un saludo.
José Manuel Delicado Alcolea
Equipo de gestión web y desarrollo
Asociación Comunidad Hispanohablante de NVDA
- Tel.: (+34) 910 05 33 25 ext.
2001
- jm.de...@nvda.es
- www.NVDA.es
- @nvda_es
***Este mensaje y sus adjuntos están dirigidos a su destinatario
y pueden contener información exclusiva o confidencial. La
utilización, copia o divulgación de los mismos por parte de
alguien diferente a dicho destinatario no está permitida sin
autorización. Si ha recibido este mensaje por error, le rogamos
que lo comunique por esta misma vía y seguidamente lo
destruya.***
Ramón Corominas
Gracias por los aportes, ya tengo para estudiar una buena temporada 😂
Miraré los complementos esos que comentas de Notepad++ y las modificaciones, seguro que aprendo mucho. Lo de ejecutar Python con Notepad++ creo que ya lo tengo resuelto, aunque de todos modos mi editor principal para cositas simples (más allá de VSCode para depurar) sigue siendo un Ultraedit del año de la pera, pero que me va genial y ya lo tengo muy trabajado.
Lo que comentas de VSCode es sólo una ínfima parte de todo lo que ofrece, más allá del autocompletar puedes renombrar las variables y funciones sin sin el peligro que supone a veces el buscar y reemplazar, colapsar y expandir bloques de código, hacer búsquedas inteligentes con filtros, depurar con paso a paso o con breakpoints, tanto estáticos como condicionales, reformatear el código entero para que aplique un estilo concreto, moverte por todo el timeline de los ficheros, no sólo los commits sino también las veces que los hayas guardado, e incluso manejar desde ahí prácticamente todo lo del control de versiones, incluso hacer pull requests o issues... En fin, es una pasada, de verdad, no sé cómo he podido vivir sin él hasta ahora. Lo dicho, a ver cuándo sacamos tiempo para escribir esa guía, que lo básico tampoco es para tanto.
Lo de las librerías de terceros, pues sí, lo mejor suele ser insertar tu ruta al principio del sys.path y restaurarlo en cuanto ya tengas importado todo lo que necesites de ella, precisamente para que no se queden por ahí esas rutas en caso de que algún proceso tuyo no haya terminado del todo. E incluso así en la medida de lo posible es mejor si puedes asegurarte de importar desde tu directorio usando la sintaxis de los puntitos
Lo que comentas de esa librería de 64 bits con servidor socket y demás se me escapa bastante, pero suena fascinante, a ver si un día llego a entender los sockets, que me interesan para otras cosas y nunca me aclaro. En cuanto a la distribución y lo de los idiomas, entiendo que siempre podrías meter en el complemento la descarga de los idiomas a posteriori, al fin y al cabo tendrás permisos para escribir en tu propia carpeta y esa ubicación la sabes desde dentro del addon. La librería no lo sé, porque eso me suena más peligroso para el usuario, aunque la verdad que también da un poco de yuyu confiar en un EXE que te traes de dios sabe dónde y que no sabes ni lo que hace por dentro... 😜
Por cierto, ahora que te leo eso del buildVars, de momento los nombres de los complementos los estoy poniendo un poco como de prueba y tal, pero entiendo que si dos personas se ponen a desarrollar dos complementos y les ponen el mismo nombre al directorio eso va a ser un pifostio interesante... ¿QQué pasaría en ese caso? ¿Le dicen al segundo que llega que le cambie el nombre o qué pasa? 😜
En fin, mucho que mirar, eso de wxPython tiene buena pinta, pero poco a poco, que todavía tengo mucho que aprender de lo más básico.
Un saludín y gracias de nuevo por toda la información,
Ramón
Héctor me dio mucho para estudiar: