Continuando la entrada "OpenCV - Mouse Event Handler (parte 1)", que ya publiqué hace un tiempo, os traigo la segunda parte que da cierre al manejo de eventos del ratón con OpenCV. Si en la primera parte me centraba en el manejo puro de los eventos del ratón, en esta entrada hablaré sobre la combinación de eventos de ratón con eventos de teclado.
La combinación de eventos de teclado con los eventos de ratón, son muy útiles por ejemplo cuando queremos asegurarnos que las acciones con el ratón no son fortuitas, y por ello se asegura la acción del ratón con la pulsación de alguna tecla. Un ejemplo común puede ser el pulsar la tecla "CRTL" o "SHIFT" cuando se hace click con el ratón. Otro ejemplo puede ser la de diferenciar dos acciones distintas desde un click de ratón, gracias a la pulsación combinada con distintas teclas.
El siguiente ejemplo toma como partida el ya expuesto en la entrada de la parte 1 y modifica la función "mouseEventHandler" de la siguiente forma:
void mouseEventHandler(int event, int x, int y, int flags, void* param)
{
if ( flags == (EVENT_FLAG_CTRLKEY + EVENT_FLAG_LBUTTON) )
{
cout << "Left mouse button is clicked while pressing CTRL key - position (" << x << ", " << y << ")" << endl;
}
else if ( flags == (EVENT_FLAG_SHIFTKEY + EVENT_FLAG_RBUTTON) )
{
cout << "Right mouse button is clicked while pressing SHIFT key - position (" << x << ", " << y << ")" << endl;
}
else if ( event == EVENT_MOUSEMOVE && flags == EVENT_FLAG_ALTKEY)
{
cout << "Mouse is moved over the window while pressing ALT key - position (" << x << ", " << y << ")" << endl;
}
}
Cada vez que se produzca alguno de los siguientes eventos:
EVENT_FLAG_LBUTTON
EVENT_FLAG_RBUTTON
EVENT_FLAG_MBUTTON
EVENT_FLAG_CTRLKEY
EVENT_FLAG_SHIFTKEY
EVENT_FLAG_ALTKEY
Se invocará a la función callback “mouseEventHandler“. En este caso, en la sucesión de los distintos “if” que permite identificar el tipo de evento, se incluye además una condición de teclado. En el caso de los clicks izquierdo y derecho del ratón, se puede combinar las flags de pulsación del ratón con los del teclado, aplicando una suma aritmética de los valores. En el caso del movimiento del ratón, esto no es aplicable, ya que el movimiento del teclado es de tipo "EVENT" y el de la tecla es de tipo "EVENT_FLAG". A causa de ello se realiza una operación lógica entre los resultados obtenidos en las comparaciones de cada tipo.
A continuación dejo el código completo de la arquitectura básica para el manejo de eventos con pulsaciones de teclado:
En ocasiones, por cuestiones de diseño es necesario mantener una estructura de carpetas determinada. Si además trabajas con Git te habrás dado cuenta que Git no añade un directorio vacío (ya sea una carpeta o varias anidadas) al proyecto. Siempre tiene que haber un archivo para que Git haga el tracking y añada la estructura de carpetas.
Si además dicho directorio quieres que se excluya del tracking de archivos, la cosa se pone un pelín más complicada, pero nada que no se pueda configurar con un poco de tino 😉 .
Para resolver el problema, en Git es necesario crear un archivo para que la estructura de carpetas se añada al tracking del proyecto. Por ello es necesario generar un fichero "dummy", un fichero vacío en el nivel más bajo del directorio, que sirva de baliza para que Git nos incluya la ruta completa de carpetas que nos permita llegar al archivo. Con esto ya tenemos solucionado el tema del directorio, poniendo ficheros "dummy" en los niveles más bajos del directorio.
Ahora es necesario realizar una acción que nos excluya todos los ficheros del directorio en cuestión, menos los ficheros "dummy" que nos hacen de baliza. Para ello en la raíz del proyecto, definiremos un fichero ".gitignore" que sirve para manejar exclusiones del tracking de ficheros para el proyecto. Lo ficheros o grupos de ficheros definidos en las reglas de ".gitignore" se comportan como ficheros que no existen para Git, y evita proponerlos para incluirlos en un eventual commit.
Creando un caso simple que sirva de ejemplo, excluiremos la carpeta "test" de la ruta "config/test/" de un proyecto.
La configuración del fichero ".gitignore" sería la siguiente:
config/test/*
!config/test/dummy.txt
El fichero consta de dos líneas. Una primera línea que excluye todo el directorio del tracking y una segunda línea que excluye el fichero "dummy" de la exclusión de la primera línea. Es importante el orden de las líneas y no son conmutables, ya que el fichero es interpretado de manera secuencial desde la primera línea hasta la última.
Con estas dos sencillas líneas podemos crear estructuras de ficheros, dentro del proyecto, para las cuales no queremos hacer seguimiento de cambios en sus ficheros. Esto es útil para generar estructuras donde alojar ficheros con los que probar el código del proyecto, pero los cuales no queremos añadir al proyecto porque no nos interese (por la razón que sea). También pueden ser útiles estas estructuras estáticas, en los casos en los que el usuario final, introducirá algún tipo de fichero que consuma nuestro proyecto.
Una mejor opción 🧬 [28/02/2021]
Un iteración más elegante es usar varios ficheros ".gitignore". Sobre todo en el caso de que queramos excluir un directorio y todos sus posibles subdirectorios.
⚠️ El uso de ficheros ".gitignore" de manera indiscriminada y descontrolada puede ser constraproducente si no existe una organización o una estrategia previa en su uso en el repositorio del proyecto. Git busca recursivamente y aplica todos los ficheros ".gitignore" que se encuentre dentro del repositorio.
La estrategia sería definir un fichero ".gitignore" dentro de la carpeta (y subcarpetas) que queramos que sean ignoradas, añadiendo como excepción el propio fichero para que Git nos permita añadirlo. El contenido del fichero sería el siguiente:
# Este directorio y subdirectorios son ignorados
*
# Indicamos que .gitignore es la única excepción
!.gitignore
El fichero consta de dós línea, la primera excluye absolutamente todo y la segunda añade como excepción el propio fichero para que pueda ser incluido en el árbol de versionado Git y no sea también excluido. De esta forma tenemos una forma sencilla en la que añadiendo ese fichero ".gitignore" a cualquier directorio, estaremos ignorando el contenido de dicho directo y subdirectorios.
Si has actualizado a Windows 10, probablemente hayas notado problemas en la visualización de texto en pantalla, algo que tiene que ver con el DPI (Dots Per Inch) o PPP (Puntos Por Pulgada) del sistema operativo. Aunque por lo general es un ajuste que no se suele modificar al cambiar el software, hay usuarios que reportan fuentes borrosas.
Parece ser que cambios en los DPI del sistema están provocando que algunas fuentes aparezcan borrosas en la interfaz del sistema operativo. La heterogeneidad de este problema hace que cada caso sea diferente, pero particularmente he experimentado este tipo de problemas en el navegador web, en algunas páginas en concreto, no en todas. También he detectado el mismo problema en las aplicaciones clásicas y los menús de configuración del sistema, mientras que todo funciona perfectamente en las aplicaciones Modern del sistema operativo.
Este error sólo afecta a los usuarios de Windows 10 y no a los de Windows 8 u 8.1. Es extraño ya que estos sistemas comparten una gran cantidad de código, especialmente en lo relacionado con escritorio, fuentes y librerías Modern UI. Claramente Microsoft no ha hecho del todo bien los deberes y su ambición de un único sistema operativo para todos los dispositivos no ha ayudado, creando este tipo de problemas en su nicho de mercado dominante (PC de Escritorio y Portátiles).
Sabiendo de la inexistencia del problema en sistemas Windows 8 y 8.1, hay una aplicación llamada Windows 10 DPI Fix que se encarga automáticamente de aplicar al sistema el método de escalado de fuente de Windows 8 en lugar de utilizar la de Windows 10.
Si tenemos problema con las fuentes borrosas en el sistema, podremos ver cómo con solo ejecutar la herramienta el problema se soluciona y las fuentes dejan de estar borrosas.
Yo personalmente abogo por aplicar una solución particular y focalizada si el problema de las fuentes borrosas no es muy acusado. Con ello quiero decir que si el problema está un conjunto reducido de aplicaciones, las cuales presentan fuentes borrosas, te propongo lo siguiente.
Caso práctico
Voy ha plantear un caso particular de una aplicación en la que he sufrido el problema de fuente borrosa. La aplicación en cuestión es XAMPP, la cual en su panel de control, muestra las fuente borrosas.
Para los que tenemos una leve miopía es como intentar ver algo lejano sin ponernos las gafas. Algo que resulta bastante molesto... y que perjudica su lectura.
Para solucionarlo ve al ejecutable que lanza la aplicación y dale con el botón derecho a "Propiedades". Se desplegará una ventana, donde hay que seleccionar "Compatibilidad".
Deberemos marcar la opción "Deshabilitar el ajuste de escala de la pantalla si se usa la configuración elevada de ppp". Para guardar damos en "Aplicar" y después "Aceptar". Al ejecutar de nuevo la aplicación veremos que el texto es más pequeño (lógico porque hemos deshabilitado el escalado), pero por lo menos no aparece borroso que es nuestro objetivo.
A efecto de apreciar mejor la diferencia tras aplicar la configuración, os pongo el antes (a la izquierda) y el después (a la derecha). No dudes en hacer click en la imagen para verla con más detalle.
Espero que estas propuestas para paliar el problema de los textos borrosos en Windows 10 os sirvan, y sobre todo esperemos que Microsoft haga algo al respecto.
Es una realidad, a día de hoy Internet está lleno de malware y cuando navegamos es posible que acabemos descargando y ejecutando este tipo de software.
El malware se define como software que tiene como objetivo infiltrase o dañar un sistema de información sin el consentimiento de su propietario. El término se refiere genéricamente a una variedad de software hostil, intrusivo o molesto.
A pesar de tener nuestro sistema actualizado, nuestro navegador actualizado y tener un antivirus protegiendo la última línea de batalla de los dos anteriores, habitualmente puedes llegar a tener infecciones por malware o simplemente tener un falso positivo, que se define como una detección erróneamente clasificada como malware.
Ante el primer caso, mi consejo es el siguiente: evitad la descarga de contenido procedente de enlaces que referencien a un javascript y no muestren la url final del archivo a descargar. Desconfiad de ellos, porque el script os devolverá el archivo a descargar, pero no sabréis de antemano nada sobre el archivo. Esta técnica se suele usar para proporcionar descargas de malware y variar el fichero (normalmente un archivo.zip) que pase desapercibido por el navegador y el antivirus. Esto no quiere decir que haya sistemas que usen un javascript para servir contenidos de manera legítima y benévola, pero por norma general desconfiad.
Para saber que hay un javascript tras un enlace, es tan fácil como hacer click derecho sobre el enlace y selecciona "Copiar dirección de enlace". Si lo copias en un editor de texto os aparecerá algo parecido a esto:
Una forma mucho más preventiva de bloquear estos elementos, es usar programas como NoScript, que nos permite desactivar el código javascript de las webs que visitemos. En el blog de Víctor Goñi tenéis una somera introducción al uso de NoScript.
En el segundo caso de tener un posible falso positivo, yo recomiendo usar el sentido común (que a veces es el menos común de los sentidos 😉 ). Tu antivirus o navegador pueden detectarlo como potencial malware, pero está en nuestra mano descargarlo. En el caso del antivirus podemos desconectar momentáneamente el antivirus para poder descargarlo y en el caso del navegador siempre podremos forzar la descargar o recuperar el archivo. Alguno me dirá: ¡Estás loco hermano! Pues NO. Mientras no ejecutes el archivo o lo descomprimas, estaremos a salvo.
Alguno a estas alturas estará pensando, cuál el motivo por el que a pesar de un posible falso positivo decido descargar el archivo. Una de las formas de percibir ingresos extra por las compañías que desarrollan los navegadores y los antivirus, es la de provocar falsos positivos en ciertos archivos para que funcione como medida disuasoria para su descarga. Terceras empresas suelen pagar a navegadores y antivirus para mostrar estos avisos, ya que la descarga de dichos archivos son contrarias a su negocio o le provocan directamente pérdidas económicas. Cracks, Keygens, Scene, Descifrado (Desencriptación) de Sistemas de Información, Herramientas de Ingeniería Inversa... son algunos de los muchos ejemplos en los que se puede dar falsos positivos pagados por empresas. Esto no quiere decir que dentro de estos grupos, haya software con malware, que los hay.
Especulaciones a un lado, tenemos nuestro archivo descargado. Para comprobar que no es malware, hay una prueba sencillísima, abre una nueva pestaña y vuelve a descargar el mismo ficheros sin ejecutarlo. Si el fichero se descargar con el mismo nombre (el segundo fichero tendrá el mismo nombre más "(1)"), es probable que no sea malware. No por ello bajaremos la guardia.
Una forma de clarificar la cosa es pedir una o varias opiniones más sobre el posible archivo cargado con malware. Para ello podemos acceder a Virus Total, dónde podremos pedir que varios motores de antivirus analicen el fichero y nos devuelvan el resultado.
Caso práctico
Personalmente todo esto que os cuento lo puse en práctica al ir a descargar DVDshrink, un software que permite romper el cifrado de los DVDs comerciales para generar copias de seguridad. Al descargar la última versión del programa, tanto el navegador como el antivirus saltaron.
Inmediatamente comprobé que la descarga del archivo usaba un enlace con javascript. Tras descargarlo una segunda vez, el nombre del archivo cambiaba. Con lo que acudí a Virus Total en busca de respuestas.
Virus Total genera un SHA256 que identifica unívocamente al archivo, y en este caso no había relación con el primero que subí. Además de todo ello, los resultados variaban y para colmo había alrededor de un 50% de resultados que decían que no era malicioso y el otro 50% decían que sí lo era.
*Nota: Virus Total actualiza los resultados si se vuelve a subir por otros usuarios el mismo archivo
Esto me hizo desconfiar automáticamente. En mi caso basta que 10 de los 56 motores de los antivirus, me devuelvan infección para destruir el fichero sin pensármelo demasiado, si no sé exactamente lo que estoy manejando. El que haya entre 1 y 4 resultados de infección también puede ser que se trate de una infección nueva. En este caso el software ya lo conocía anteriormente y su última versión pone que es del 2014, sería algo raro que tras ese tiempo se tratase de una infección nueva, si hubiese entre 1 y 4 resultados de infección.
Recuerda también que entre los resultados ofrecidos por los distintos motores de los antivirus, puede haber falsos positivos o reportes de infecciones hechos desde la parte heurística de cada motor, que se encarga de detectar posibles amenazas que no estén catalogadas dentro de las bases de datos de cada antivirus.
Al final cada uno tomamos la decisión de ejecutar el archivo y como todo en la vida podemos equivocarnos, a pesar de haber contrastado las fuentes de información para generar una decisión en consecuencia informada y de calidad.
