kde4 uso eficiente del plasma (uso no evidente)

Hola,

Hasta hace muy poco utilicé openSUSE con KDE 3 y una de las cosas que extrañé cuando definitivamente me moví a KDE 4 en openSUSE 11.2, es que en KDE 3 uno puede invocar el menú inicio (K menú) poniendo el cursor en la esquina inferior izquierda de la pantalla sin hacer clic. Una tontería, pero buscando una característica similar en KDE 4 me encontré con una muchísimo más poderosa.. el tablero de mandos del plasma.

Y es que combinando 3 cosas:

1. El tablero de mandos del plasma.
2. Los elementos gráficos.
3. Los bordes de escritorio y los efectos de KWin.

Se puede tener una especie de mesa de trabajo (escritorio) con el menú K desplegado, una calculadora, un calendario, el selector de color, etc. Que está a sólo mover el ratón a una de las esquinas de la pantalla. Aquí unas imágenes de lo que estoy tratando de explicar:

Pasos a seguir:

1. Asignar el tablero de mandos a una de las esquinas del escritorio (prefiero esquina inferior izquierda):
   
   
   
   
2. Separar el tablero de mandos del escritorio. Ésto lo hago porque en el escritorio me gusta tener un fondo algo que haga juego con las ventanas y no herramientas de trabajo que haga que se parezca a mi escritorio real (un desastre).
   
   
   
   
3. Invocar el tablero de mandos y agregar los elementos gráficos que más usemos. Yo en lo particular recomiendo el menú K (Lanzador de aplicaciones) ponerlo del mismo tamaño que el menú real (se puede presionar la tecla Ctrl mientras cambiamos su tamaño para mayor control; una calculadora; un conversor de unidades; un calendario y algunos iconos de los programas más usados. No recomiendo colocar alguno que nos mantenga más de unos segundos en el tablero (como un terminal).

Adicionalmente:

Asigno la Rejilla del escritorio y Presentar las ventanas a las otras esquinas del escritorio:

Conclusión

Por ensayo y error conseguí el increíble poder que tiene el plasma y de por qué se le da tanta fuerza dentro de KDE y openSUSE. Lamentablemente como me sucedió a mi, su uso eficiente no es tan evidente como se quisiera. Yo le recomiendo a la gente de KDE y openSUSE que saquen una configuración de plasma por omisión, para sacarle el mayor provecho sin tener que configurar.

Queremos escuchar tus experiencias, publica tus comentarios de como te fue con los tips o si ¿Tienes otros mejores? ¿Qué piensas del Plasma?

Hasta la próxima...

Validando xml con xsd usando msv

Hola,

Parte del proceso de utilizar xml para el intercambio de datos, por ejemplo importación y exportación de datos hacia y desde nuestro sistema respectivamente, es tener clara una definición del archivo xml que se va a utilizar. Para ello generamos un archivo xsd (XML Schema) con la definición de nuestro xml.

Ahora bien antes de intentar cargar una data en formato xml en nuestro sistema, es aconsejable primero verificar que el archivo está bien formado y luego si cumple con nuestra definición. Bueno hoy les enseñaré como hacerlo en Java.

Primero necesitamos una biblioteca llamada msv (Multi Schema Validator) se puede descargar desde aquí: https://msv.dev.java.net/ . Este paquete funciona de dos maneras:

1. Como un programa de línea de comandos para validar xmls con un xsd que se especifique.
2. Como una biblioteca que permite validar xmls con xsds directamente desde nuestro código en Java.

Para probar como funciona, vamos a descargar el zip del msv y expandirlo en cualquier directorio (tiene su propia carpeta) ahora para probarlo ejecutamos la siguiente línea de comandos:

java -jar msv.jar mi.xsd mi.xml

Si todo sale bien y el documento es válido debería soltar:

start parsing a grammar.
validating mi.xml
the document is valid.

Ahora bien para usarlo desde nuestro código Java lo primero que hay que hacer es incluir todos los jar de la carpeta msv en nuestro classpath (isorelax.jar, relaxngDatatype.jar, xmlParserAPIs.jar, msv.jar, xercesImpl.jar, xsdlib.jar). Luego el siguiente código nos permite validar nuestro xml:

/* Paso 1 creamos el fabricador de verificadores */
VerifierFactory factory = new com.sun.msv.verifier.jarv.TheFactoryImpl();

/* Paso 2 compilamos el esquema (nuestro archivo xsd) */
Schema schema = factory.compileSchema(new File("mi.xsd"));

/* Paso 3 creamos el verificador */
Verifier verifier = schema.newVerifier();

/* Paso 4 validamos */
if(verifier.verify(new File("mi.xml"))) {
// el documentos es válido
} else {
// el documento es inválido
}


Con ésto estamos listos. Algo muy importante si la verificación la estamos haciendo en una PC que no tiene conexión al Internet, vamos a tener que agregar el componente resolver de Apache XML Commons al classpath. Se puede descargar aquí: http://xml.apache.org.


Hasta la próxima...

Nota: Si esta información te es de utilidad o piensas que se puede mejorar, por favor deja un comentario con tus observaciones.

Utilizar wine para probar aplicaciones Java en ambiente Windows desde Linux

Actualizado: Revisado para wine 1.4 y Java 1.6.0u32, 4 de junio de 2012

Al leer este título, lo primero que viene a la mente es: ¿Para qué correr aplicaciones Java sobre wine si Java existe para Linux? Además las aplicaciones Java son multiplataforma. Ajá, paremos ahí y revisemos la última palabra de la frase: multiplataforma.

Muchas veces queremos verificar que tal corre nuestra aplicación en otra plataforma, para precisamente verificar que es multiplataforma. Hay varias cosas que pueden dejar de funcionar (o funcionar diferente) cuando se corre en otra plataforma:

• Nombres de archivo: Los separadores de nombres de archivo es lo más cambiante entre plataformas.


• Llamadas a comandos externos: Hay unos cuántos problemas que se solucionan fácilmente en Linux invocando comandos ¿Y en Windows?. Un ejemplo a éste respecto es el método listRoots() de la clase File. Si se quiere saber los volúmenes montados, en Windows funciona perfecto, pero en Linux únicamente retorna "/", entonces una de las maneras de resolverlo es invocando al comando df (entre otros) parsear su salida y obtener las unidades montadas.


• Codificación de caracteres: Nuestras letras acentuadas comúnmente se ven mal en otras plataformas si no tenemos el debido cuidado.


• Applets: Probar nuestros applets en navegadores que no corren en nuestra plataforma de desarrollo. Por ejemplo, Internet Explorer sobre Linux. No sólo estaríamos probando nuestra aplicación en otra plataforma sino además en otro navegador.

Para los casos antes mencionados y algunos otros, nos gustaría verificar que tal corre nuestra aplicación en otra plataforma. Específicamente si estamos desarrollando en Linux, poder correr la aplicación en Windows. Si tenemos dual boot, perfecto, reiniciamos la PC en Windows y listo. El problema es todo lo que tenemos que esperar para hacer una prueba. Para ésto podríamos usar wine.

Para utilizar java sobre wine, simplemente se instala la versión Windows de la máquina virtual de Java usando wine así:

wine jre-6u32-windows-i586.exe

Una vez instalado, simplemente corremos nuestro programa en "Windows" así:

wine java -jar ~/jdk/demo/jfc/SwingSet2/SwingSet2.jar

Fíjense que la única diferencia es colocar wine adelante. Si tienen problemas gráficos prueben deshabilitar Direct3D:

wine java -Dsun.java2d.d3d=false -jar ~/jdk/demo/jfc/SwingSet2/SwingSet2.jar


Les en va a impresionar lo bien que corre.


Por supuesto siempre tenemos la opción CrossOver para hacer lo mismo en unos pocos clics. Presiona aquí para instalar Java Windows en Linux: https://www.codeweavers.com/compatibility/browse/name/?app_id=3883

Applets

Uno de los usos más frecuentes para wine es correr Internet Explorer en Linux y así probar como se ven nuestros sitios web. Bueno si somos desarrolladores de Applets, podríamos usar Internet Explorer sobre wine para poder verlos sin tener que salir de Linux. Basta con tener instalado Internet Explorer antes de instalar java. ¿Y que tal un applet en Firefox sobre windows?

Aquí les presento las instrucciones para hacer correr applets en java 1.4 Internet Explorer 6.0 Windows 98, escojo esta configuración porque todo corre casi perfecto.

1. Instalar Internet Explorer 6.0 en wine simulando Windows 98, en este paso no me extenderé ya que hay sin número de artículos que lo explican. Usen winetricks para ello. Si tienen Crossover (versión comercial de wine) es cuestión de unos clics.
2. Instalar Java 1.4 para Windows 98 en wine. Aquí les dejo el enlace: https://java.sun.com/products/archive/j2se/1.4.2_19/index.html
3. Hasta aquí los applets deberían correr perfectamente. Pues no, así como la versión 6 de java tiene problemas con Direct3D en wine, java 1.4 los tiene con DirectDraw, cosa que no es tan sencilla desactivar para los applets. Lo que hay que hacer es ejecutar a mano el panel de control de java en wine, desactivando el directdraw para poderlo mostrar y ahí desactivar el directdaw para los applets. Aqui el comando:
   cd ~/.wine/drive_c/Program\ Files/Java/j2re1.4.2_19/lib/

wine java.exe -Dsun.java2d.noddraw=true -Xbootclasspath/a:plugin.jar sun.plugin.panel.ControlPanel
   Cuando se esté ejecutando el panel de control, se debe ir a la pestaña Avanzado y escribir -Dsun.java2d.noddraw=true en al campo Parámetros del entorno de ejecución y presionar Aplicar.

Con los pasos anteriores ya los applets deberían correr en Internet Explorer en Linux. Para versiones posteriores es posible que se necesite la misma técnica para deshabilitar el Direct3D en java. Cuando tenga una buena prueba actualizaré este post.

Hasta la próxima...

Nota: Si esta información te es de utilidad o piensas que se puede mejorar, por favor deja un comentario con tus observaciones.