Hace 10-15 días Facebook hizo algunos cambios de diseño en sus páginas, personalmente no me gustaban nada, pero eran soportables. Los que me dañaban las retinas de verdad eran los cambios que hizo Twitter con la cabecera de su página y con la que consiguió una nueva definición gráfica del triste “feo-de-cojones“.
Muchos usuarios de Firefox y GoogleChrome (en cualquier plataforma) ya sabrán que tienen fácil proteger su integridad artística de los desaguisados de los diseñadores web con multitud de extensiones y herramientas que permiten “customizar” los sitios web que visitamos para verlos tal como nos gustaría: fuentes más grandes, fondos de colores no aberrantes, banners que distraen la lectura, frames con información molesta o irrelevantes y publicidades varias.

Lo que muchos de estos usuarios no sabrán es que no hace falta instalar nada para poder personalizar el contenido mostrado en las páginas que visitamos habitualmente, basta con ser usuario de Firefox ó Google Chrome y tener unos conocimientos básicos de CSS.

En ambos navegadores y cualquiera de los sistemas operativos habituales (Windows, Mac y Linux) el funcionamiento es idéntico: al iniciar el navegador se lee el contenido CSS de un archivo que es aplicado a todas la páginas cargadas a continuación. Por lo tanto para evitar alterar otras páginas diferentes a las deseadas nuestras reglas deberían lo más concretas posibles, evitando reglas CSS genéricas como body {background: red;}.

Los archivos

Los archivos que tenéis que modificar son (aproximadamente):
En Linux
Firefox
/home/tu-usuario/.mozilla/firefox/XXXXXXX.default/chrome/userContent.css
GoogleChrome
/home/tu-usuario/.config/google-chrome/Default/User StyleSheets/Custom.css

En Windows
Firefox
%USERPROFILE%\Application Data\Mozilla\Firefox\Profiles\XXXXX.default
GoogleChrome
%USERPROFILE%\AppData\Local\Google\Chrome\User Data\Default\User StyleSheets\Custom.css

En MAC ignoro la ruta, pero imagino que será muy parecida a Linux.

En dichos archivos podéis escribir reglas CSS que se aplicarán a los sitios por los que navegáis modificando el contenido mostrado.

Puesto que son archivos que se cargan al iniciarse el navegador es necesario restaurar este para aplicar los cambios que hagamos.

Ejemplos de uso

Para cambiar la horrorosa cabecera blanca de Twitter por una negra .global-nav-inner {background-color:#333 !important;}
#global-actions li a {color:#fff !important;}
.dropdown-menu a {color:#333 !important;}


Eliminar la tercera columna de Facebook en la que se muestra habitualmente publicidad, encuestas y chorradas varias (mira la primera imagen).#globalContainer {width:720px !important; padding:0px !important;}
#rightCol,#navFindFriends {display:none !important;}
.5r69 {width:100% !important;}

Este año le estaba haciendo poco ó ningún caso a las cajas nido de la terraza y a sus webcams, entre otras cosas porque en años anteriores la crianza de los gorriones que las habitan suele ser un rotunda fracaso.
Pero no un fracaso extraordinario, sino un fracaso común y corriente.Y es que los gorriones normalmente ponen 5-6 huevos, nacen todos y van muriendo hasta quedar 1 ó 2 el día que toca salir del nido. De esos 1 ó 2, excepcionalmente, uno sobrevive al primer año. Si prestáis un poco de atención en estas fechas veréis que raramente a un hembra la siguen más de 1 ó 2 volantones, 3 con mucha suerte.

Eso, más o menos es lo normal (al menos es lo que yo llevo observando), lo anormal es que llegue el día en que van a echar a volar y haya en el nidal cinco polluelos (como ocurre actualmente en uno de los nidales de casa) y en un más que sorprendentemente buen estado de salud.

Así es que para celebrar el inminente acontecimiento he conectado la cámara al streaming de Youtube como os indico a continuación y de paso estreno la herramienta de Eventos en directo que apenas he tenido tiempo de probar.

Eventos en vivo

Desde hace un año (aprox. en España) Youtube ofrece la posibilidad de crear lo que ellos llaman Eventos en directo, es decir conectar y ver ( o insertar en tu página ) grabaciones que se están produciendo en ese instante, en tiempo real (o casi). Muy usado para eventos deportivos y conciertos pero también para la retransmisión de webcam y creación de vídeotutoriales (conectas la webcam y le explicas a alguien el método para hacer tal ó cual).

Existen ya varios servicios de este estilo que se han popularizado mucho en internet ( Ustream.tv o Justin.tv ) muy usados actualmente para la emisión en directo de manifestaciones o escraches e imposibilitando de esta manera el secuestro policial del material grabado ya que este se difunde públicamente en el mismo momento que se genera, vaya lo que viene siendo un canales de información en vivo y en directo de cualquiera acontecimiento público.

He probado los tres sitios comentados para la emisión de eventos en directo y creo que me voy a quedar con el de Youtube por varios motivos: Es el más popular, conocido y que llega a más gente. Dispone de soporte para gran número de navegadores y plataformas. Permite un control más personalizado de la publicidad que el canal inserta (normalmente) al inicio de la retransmisión.

Creación de eventos

Los tres sitios que he probado hasta ahora (Justin.tv, Ustream.tv y Youtube) son gratuitos. Todos insertan publicidad (normalmente al principio). Los dos primeros ofrecen la posibilidad de retirar la publicidad mediante pago del servicio. En Youtube en cambio podéis desactivar la inserción de publicidad en vuestros vídeos de forma gratuita (aunque creo que la cuenta tiene que reunir algunas condiciones previas para poder hacerlo).
Todos generan archivos de vídeo de lo emitido desde el canal que van quedando almacenados en el servidor. Todos disponen de aplicaciones/métodos para embeber los eventos en tu página web. Todos disponen de métodos de recepción del flujo de vídeo desde un terminal Linux y todos disponen de su propia aplicación web (normalmente desarrollada en Flash Macromedia) que nos permite hacer lo mismo consumiendo muchos más recursos de nuestro ordenador y obligándonos a mantener abierta la ventana del navegador mientras dure la retransmisión.

Para crear un evento en vivo en Youtube, dirígete a la página de Eventos en vivo y logéate si no lo estás. La cuenta de Youtube desde la cual quieras retransmitir debe estar confirmada (normalmente mediante SMS a tu móvil) antes de poder crear el evento, si la ya tienes confirmada llegarás a una página como esta:

Pulsa crear evento para entrar en la página de configuración. Marca la casilla de abajo “Acepto los términos…” y (IMPORTANTE) la casilla de abajo a la derecha ” TIPO > Personalizar (más opciones de codificación) “.
Observa la hora de inicio del evento. Youtube permite el inicio de eventos en fracciones de 30 min. (9:00, 9:30, 10:00, … ). El inicio de tu evento debería ser posterior al momento en que empieces a enviar datos, es decir: cuando el evento empiece tu ya deberías llevar 3-4 minutos enviando flujo de vídeo. De esta manera se genera una caché que evita que la retransmisión sufra demasiados “parones”.
Pulsa Crear Evento.

Entrareis en la página de configuración avanzada del evento donde debéis especificar la calidad de la “ingestión” (creo que “inyección” habría resultado menos digestivo). Para una retransmisión casera standar os aconsejo usar la Ingestión básica > 300kbs – 700Kbps (240px).
Si queréis o necesitáis eventos con muy buena calidad podéis aumentarla gradualmente hasta los HD1080, claro, siempre y cuando vuestra conexión de subida lo permita.

En el desplegable Selecciona tu codificador selecciona Otros codificadores para que la página os muestre las URLs de ingestión. No compartas esta URL.
Copia el contenido de URL del servidor principal y añádele detrás Nombre de la emisión para componer una URL aprox. como
rtmp://a.rtmp.youtube.com/live2/cuaderno-de-cam-XXXX-xxxx-XXXX-xx
Esa es la dirección donde tienes que inyectar el flujo de vídeo con ffmpeg

Después de guardar los cambios puedes cambiar arriba a “Sala de control en directo” desde donde la página te informa de si se está recibiendo o no el flujo de vídeo en condiciones ó los errores que hubiera (útil para depuración).

Configuración de FFMPEG

Una vez tenemos el espacio de emisión reservado en Youtube procedemos a rellenarlo con el video de nuestra webcam. Para ello con ffmpeg y usando la URL ofrecida por Youtube ( rtmp://xxxxx ) procedemos a codificar la imagen original al formato FLV, vídeo codec libx264 y audio codec MP3. La orden que estoy usando para emitir la señal del nidal de gorriones es:ffmpeg -loglevel fatal -f alsa -i default -ac 2 -f video4linux2 -i /dev/video7 -vcodec libx264 -f flv -r 15 -q 3 -b:v 320k -s 320x240 -acodec libmp3lame -ar 44100 -ab 128k -threads 0 -bufsize 64k -force_key_frames 0:00:01 "rtmp://a.rtmp.youtube.com/live2/cuaderno-de-cam-xxxx_xxxx_xxxx_xxxx"

En las primeras pruebas deberías quitar la opción -loglevel fatal para depurar y buscar posibles errores. Youtube es bastante pelmazo con la calidad del audio y aunque el sonido del nidal no es ninguna maravilla emite errores si le reduzco la calidad por debajo de 128k, 64k o similar.
Todos estos sistemas de streaming de vídeo también suelen dar muchos problemas si tratáis de emitir un vídeo SIN audio. Si por cualquier motivo no queréis insertar sonido os aconsejaría no anularlo sino emitir una pista vacía, por ejemplo cambiando –i default de ALSA por -i /dev/zero, de lo contrario vais a tener problemas casi seguro.

Una vez empecéis a enviar el flujo de vídeo la página de control de la emisión en Youtube os debería mostrar un mensaje del estado de emisión OPTIMO ó en su defecto información relevante sobre el origen del fallo. Si todo va como debería, desde dicha página podéis dar al PLAY para empezar la retransmisión (siempre y cuando la hora de inicio se haya cumplido) y para compartir la URL del evento.

Respetando los parámetros de configuración deberíais poder hacer la emisión con cualquier otro programa que permita retransmitir vídeo a un servidor RTMP, he preferido FFMPEG porque es mucho más liviano y lo conozco algo mejor pero igualmente VLC podría seros más cómodo.

NotaEn el tiempo en que escribía el apunte parte de los polluelos del nidal han echado a volar. Ahora solo quedan 2. Pero como se puede rebobinar y ver las grabaciones de hace 4 horas podéis que no miento y había 5 polluelos. ;)

A estas alturas ya habrán oido hablar de Telegram, la alternativa libre y gratuita a Whatsapp. Visual y funcionalmente es idéntico a Whatsapp, literalmente es un clon, pero es gratuito y disfruta de las enormes ventajas del desarrollo Open source, una de las cuales es la posibilidad de que a su alrededor crezcan otros proyectos que amplían, complementan y enriquecen el original. Telegram dispone de una API de gestión y control de que se alimentan virguerías como Tg-master: un Telegram para terminal/consola.

A partir de aquí las posibilidades de usar este “Whatsapp libre” desde el ordenador y poder chatear desde un terminal con el teléfono de alguien, y viceversa. Pueden dar un juego inmenso. Podéis enviar mensajes, realizar chats y enviar/recibir archivos de vídeo/foto, mensajes privados, etc. A fecha de hoy (Marzo/2014) tg-master está en fase beta, pero ya me gustaría que programas en fase de producción tuvieran su estabilidad. Funciona perfectamente y es muy sencillo.

Podéis usar Tg-master con vuestra actual número de teléfono compartiendo la cuenta de Android con el ordenador. Al ingresar en Tg-master con el mismo número os llegará un chivatazo al móvil informando que “otro dispositivo se ha conectado a vuestra cuenta” pero sin más repercusiones. Pero claro, las posibilidades más creativas se presentan asignando una segunda cuenta de Telegram a vuestro PC. Aprovechando que tenía un número de teléfono en desuso de tarjeta prepago de mi anterior zapatófono lo he aprovechado para registrar en Telegram una segunda cuenta que es gestionada desde el PC con Tg-master y de esta manera disponer de un canal de chat entre PC y Móvil. Algo muy parecido a lo que ya hiciera con MCABBER (Jabber) (¿alguien se acuerda de aquellas charlas con la máquina?)

Para instalar Tg-master necesitáis descargar y descomprimirwget https://github.com/vysheng/tg/archive/master.zip -O tg-master.zip
unzip tg-master.zip && cd tg-master
Compilad (si es necesario tendréis que resolver dependencias)./configure --prefix=/usr
make
Ahora copiad el binario a /usr/bin y lo hacéis ejecutable para tenerlo disponible desde cualquier sitio.
cp ./telegram /usr/bin/telegram; chmod +x /usr/bin/telegram

Instalación

Una vez compilado e instalado en /usr/bin lo podéis ejecutar por primera vez para registraros en el servicio. En primer lugar Tg-master os pedirá el número de teléfono que queréis registrar en el servicio de Telegram. Introducid vuestro segundo número (con el +34 delante) y al instante os enviarán al móvil (tenedlo encendido cerca) un código de 5 dígitos que habréis de ingresar en Tg-master. Una vez validado ya estaréis listos para chatear con vuestro teléfono (claro os tenéis que agregar mutuamente en contactos).

Tg-master dispone de autocompletado con TAB (como la consola Linux) por lo que los comandos aunque no los conozcáis se escriben rápidamente.

Aunque Tg-master está en fase de desarrollo admite ya un tosco método de ejecución vía stdin recibiendo ordenes directas desde terminal. Para enviar un mensaje un contacto cualquiera en Telegram sin necesidad de entrar en el programa ejecutadecho "msg user#12345678 Mi mensaje al contacto | /usr/bin/telegram -k /home/tu-usuario/.telegram/tg.pub > /dev/null & sleep 1; killall telegram
(la carpeta /home/tu-usuario/.telegram/ se crea la primera vez que ejecutáis Telegram y registráis un teléfono y contiene el archivo tg.pub con la clave pública que debéis adjuntar con cada orden)
Como veis el método es bastante tosco porque requiere matar el proceso a lo bestia dándole un segundo para que envíe el mensaje. (el número de usuario destino lo obtenéis en Telegram haciendo contact_list). Este método es probable que cambien en breve con forme avance el desarrollo del programa.

Si necesitáis hacer videoconferencia con algo más de calidad de imagen de la que suelen ofrecer las webcams comerciales standard una opción a tener en cuenta es usar nuestra cámara de fotografía ó videocámara.
Casi todas las cámaras digitales modernas, incluso las de gama baja, disponen de una conector salida VGA con la que podemos enviar la imagen a cualquier dispositivo grabador/reproductor como el televisor ó nuestro PC si este dispone de capturadora de vídeo ( si no tenéis tarjeta capturadora en Ebay podéis conseguir modelos PCI muy básicos y perfectamente válidos por 10-15 euros).

Para ver la imagen de cámara (GNU/Linux, openSuse 11.4) simplemente conecta el cable de la cámara a la tarjeta capturadora y en un terminal escribesmplayer tv:// -tv device=/dev/video1:driver=v4l2:width=320:height=240

Aplicar filtros y convertir V4l2 a V4l

Si en algún momento te pierdes hecha un vistazo a este apunte anterior: V4lo2loopback para Linux.
Una vez tengo la cámara conectada al PC cargo el módulo v4l2loopback_dcsudo modprobe v4l2loopack_dc
Creo una tubería
mkfifo /home/trebol-a/tuberia_logo.pipe
Convierto mi logo en formato PNG de 200×80 pixels de marca de agua a RGBA y lo vuelco en la tubería según las especificaciones del filtro de Mplayer.
convert logo.png logo.rgba
(echo "RGBA32 200 80 10 10 0 1"; cat "/home/trebol-a/logo.rgba" ) > /home/trebol-a/tuberia_logo.pipe &
Ahora cogemos la imagen de cámara con Mplayer, la volcamos a otra tubería creada específicamente desde donde yuv4mpeg_to_v4l2 tomará la imagen enviándola al dispositivo /dev/video0 creado por el módulo v4l2loopback_dc.
mkfifo /home/trebol-a/tuberia_mplayer.pipe
yuv4_mpeg_to_v4l2 < /home/trebol-a/tuberia_mplayer.pipe & mplayer tv:// -tv device=/dev/video1:width=320:height=240 -vf bmovl=0:0:/home/trebol-a/tuberia_logo.pipe -vo yuv4mpeg:file=/home/trebol-a/tuberia_mplayer.pipe
Ahora en la consola se quedaría Mplayer codificando en tiempo real la imagen de la videocámara y enviandola al dispositivo /dev/video0 desde donde Skype puede cogerla como si fuese un dispositivo nuevo.

El filtro bmovl de mplayer lee en tiempo real la tubería tuberia_logo.pipe y sobre imprime la imagen rgba sobre el vídeo. Podéis ajustarlo en tiempo real simplemente haciendo en consola(echo "RGBA32 200 80 45 33 0 1"; cat "/home/trebol-a/logo.rgba" ) > /home/trebol-a/tuberia_logo.pipe &
Donde:
200 = ancho de imagen
80 = alto imagen
45 = posición X de la imagen
33 = posicion Y de la imagen
0 = transparencia del canal alfa
1 = borrar/mantener imagen logo anterior

Obviamente la orden -vf de Mplayer podéis ampliarla con más filtros con los que mejorar la imagen de la videocámara además de añadir la marca de agua.
En mi caso estoy usando:-vf eq2=0.9:1.1:0:1.4:1.0:1.0:1.2,yadif=1,unsharp=l3x3:2,expand=0:-60,bmovl=0:0:/home/trebol-a/.logo.pipe
Donde:
Ajustes de nivel y color: eq2=0.9:1.1:0:1.4:1.0:1.0:1.2
Elimina el entrelazado de videocámara: yadif=1
Enfoca imagen: unsharp=l3x3:2
Panorámica en imagen cuadrada: expand=0:-60
Marca de agua: bmovl=0:0:/home/trebol-a/.logo.pipe

Para GNU/Linux. La idea es sencilla: un script BASH que mediante el uso de ADB (Android Debug Bridge) mantenga una o varias carpetas sincronizadas entre nuestro Android y el ordenador de tal manera que siempre dispongamos de una copia en nuestro disco duro y esta se realice de manera automática (sin más intervención manual que conectar el teléfono al USB para cargarlo) y rápida.
En el siguiente vídeo se ve como funciona y como la sincronización es bastante rápida.

Idealmente esto lo empecé para mantener a mano en el ordenador las fotografías y vídeos que grabo con mi móvil (un Android – HTC Wildfire S) pero en realidad nada impide que esto puede ser usado para sincronizar otros contenidos ó simplemente como un modo cómodo de traspasar archivos al teléfono habitualmente para usarlo como pendrive.

La alternativa más evidente a este uso de ADB para sincronizar dos carpetas sería el montaje del teléfono como unidad de disco duro externo y a continuación usar alguna aplicación como sync para la sincronización, pero hay un par de ventajas a favor de ADB abismales: en el tiempo que tarda el teléfono en desmontar y montar en el PC la nueva unidad como un disco duro de nuestro ordenador he acabado yo de transferir alrededor de 200 Mg de archivos. La velocidad de transferencia es idéntica pero la conexión en inmediata (un par de segundos. Actualmente mantengo sincronizados 15 carpetas que contienen 250 archivos. Desde que conecto el teléfono al USB y aparece el diálogo informando de “No es necesaria la sincronización” pasan aprox. 6 seg).
Además de la velocidad, al no estar la tarjeta del teléfono montada como un disco duro/pendrive se gana en seguridad frente a archivos corruptos o desmontajes inapropiados. Si tienes que irte de improviso simplemente desconectas el teléfono y te lo llevas.

El único engorro es instalar ADB que viene con el kit de desarrollo de Android distribuido por Google. Si no las tienes ya instaladas simplemente sigue los pasos que se indican en la sección “Descargar Android SDK“

Preparar el móvil

La única preparación o instalación en el teléfono móvil es dejar activa por defecto la depuración USB de tal manera que siempre que se conecte esté accesible de forma inmediata para la aplicación ADB. Para activar la depuración usb, en tu teléfono busca y activa: Ajustes->Aplicaciones->Desarrollo->Depuración USB

Preparar el PC

En tu ordenador la única tarea extraordinaria (si no has hecho todavía) es asegurar que el ejecutable de ADB está accesible para todo el sistema. En mi caso ADB está instalado en /usr/bin.

Identificar tu Android

A continuación necesitamos algunos datos con los que reconocer cuando nuestro teléfono ha sido conectado al USB del ordenador.
Conecta el móvil vía USB, abre una konsola/terminal y escribes dmesg. Verás algunas líneas de información detectando la conexión de un nuevo dispositivo USB. Busca la línea que indica idVendor y idProduct. Copia y guarda esa información en un archivo de texto para usarla a continuación.

Reglas para UDEV

UDEV es el servicio encargado en la mayoría de los Linux modernos de registrar y administrar la conexión de dispositivos al ordenador. Mediante un serie de reglas indicamos a UDEV que es lo que tiene que hacer cuando detecte que se ha conectado/desconectado tal o cual dispositivo.
Las reglas UDEV estan normalmente (en openSuse 11.3) en el directorio /etc/udev/rules.d. En dicho directorio veréis una lista de archivos de texto que configuran el comportamiento de UDEV. Para no alterar archivos de sistema ya existentes lo ideal es crear nuestro propio archivo (como root) conteniendo nuestras reglas personalizadas y a continuación situarla al final de la lista de archivos existentes simplemente asignándole un nombre único tal como “99-mis reglas.rules” que lo situa al final de la lista.

(todas las operaciones siguientes se realizan como administrador, sudo) Si ya tienes tu archivo de reglas personales edítalo, de lo contrario crea uno con la siguiente línea:
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTRS{idVendor}=="XXXXX-ID-VENDOR", ATTRS{idProduct}=="XXXXX-ID-PRODUCT", ACTION=="add", RUN+="/bin/su mi-usuario -c '/home/mi-usuario/bin/sincro-movil'"
Reemplaza XXXX-ID-PRODUCT y XXXX-ID-VENDOR por los valores de tu dispositivo obtenidos en el paso anterior y mi-usuario por tu nombre de usuario.

En un terminal recarga las reglas conudevadm control --reload-rules

Probando la detección

Bien, vamos a comprobar que todo funciona como debe y que UDEV detecta y ejecuta el script correctamente, creamos un script que más tarde completaremos y lo guardamos con el nombre usado en el punto anterior (/home/mi-usuario/bin/sincro-movil) con el siguiente contenido:#!/bin/bash
echo "Hola móvil" > /home/mi-usuario/Desktop/movil.conectadoHaz ejecutable el script (chmod +x /home/mi-usuario/bin/sincro-movil).
Una vez hecho esto conecta tu teléfono al puerto USB, en un par de segundos debería aparecer en tu escritorio una archivo de texto llamado “móvil.conectado“. Si no es así comprueba las rutas de archivos, nombres de archivos, etc…
Una vez que tienes tu script creado, funcionando y ejecutado correctamente desde UDEV pasamos a llenarlo de contenido.

Script de sincronización

El script que utilizo para la sincronización podéis copiarlo/descargarlos desde aquí sincroMovil (txt).
Guardad el contenido como (p.ejem) sincroMovil en vuestra carpeta ~/bin (o donde le indicasteis en el paso anterior a UDEV) y hacedlo ejecutable (chmod +x ~/sincroMovil). Editadlo y corregid las líneas que requieren personalizarse, las carpetas que quereis sincronizar, etc…

En este vídeo podéis ver el script en funcionamiento. Tomar una foto de la pantalla, conectar el teléfono y tener la imagen en el escritorio en unos segundos.

Sincronización: Básicamente el script lo que hace es generar un par de listas de archivos para cada una de los directorios a sincronizar. Ambos archivos se guardan en local (por rendimiento) y bajo los nombres (personalizables) de sincro.list y sincro.list.remota. Cuando el script se ejecuta (porque UDEV ha detectado la conexión o bien lo lanzamos manualmente) se recrean de nuevo ambas lista y se comparan mediante DIFF. Este archivo de diferencias define si es necesario el copiado de archivos y la dirección del mismo (del teléfono al PC ó viceversa) o simplemente se emite un diálogo avisando de que no es necesaria la sincronización.

Borrado local: Antes de hacer esto el script comprueba si falta algún archivo en local desde la última sincronización (es decir, se ha borrado manualmente) y caso de detectar que falta algún archivo lo borra también en el teléfono. Pero no a la inversa. Es decir, si borramos un archivo en local se borrará en el teléfono en la siguiente sincronización, pero si lo borramos en el teléfono únicamente el fichero se volverá a copiar a este en cuanto lo enchufemos al PC.
He hecho esto así porque parece más cómodo eliminar imágenes y vídeos desde el escritorio que desde el teléfono. Tiene el inconveniente de que no podremos eliminar un archivo desde el teléfono si este se encuentra en una carpeta sincronizada ya que a cada conexión se volverá a copiar desde el PC. Esto en realidad no es un bug sino una feature. :D

Si queréis anular esta función de borrado basta con comentar la línea 156 del script.

Mejoras

La principal mejora a introducir sería el refresco de la caché del teléfono. Actualmente el teléfono no se entera de los cambios ocurridos en su sistema de archivos (al menos en las galerías de fotos que mantengo sincronizadas). Si borramos un archivo en local y sincronizamos las carpetas, el teléfono sigue mostrando la miniatura de una imagen que ya no existe y emite un error al tratar de abrirla.
Si enviamos algún archivo al teléfono no aparece en la lista hasta que la caché se refresca.

Debe haber alguna manera de forzar el refresco de la caché pero he sido incapaz de encontrarla. Se agradece cualquier información.

# zypper in xvkbd

$ xbindkeys --defaults > $HOME/.xbindkeysrc 

$ xbindkeys -k

$ xmodmap -e "remove mod4 = Super_L"

#!/bin/bash
xvkbd -xsendevent -text "\Cc"
qdbus org.kde.klipper /klipper org.kde.klipper.klipper.getClipboardHistoryItem 0 >> ~/Dropbox/Historial.txt

$ chmod +x ~/bin/super_copiar.sh 

#!/bin/bash
/usr/bin/xmodmap -e "remove mod4 = Super_L"
/usr/bin/xbindkeys

Acabo de sacar la primera versión de raecas, un plasmoide para consultar la RAE. Es muy sencillo su uso; escribes el término a consultar y le das al intro.
Está basado en qRAE.