Categoría: Oregano

Este fin de semana estuve avanzando en reescribir el viejo y querido código de flipping en Oregano, tarea para nada trivial, donde he logrado grandes avances como se muestra en la imagen de ejemplo.

El principal problema son las etiquetas, que no deben rotar, sino que lo que rota es su posición. Ahora, una vez rotada la posición, hay que actualizar el anclaje del texto para que se vea bien.

Cómo es esto?, cuando uno pone un texto en una posición (x,y) por defecto esa posición indica el borde inferior izquierdo de la caja que contiene al texto. Al hacer un espejado horizontal, debemos cambiar el anclado para que la posición represente el borde inferior derecho de modo que el texto salga para el otro lado y no se superponga con el componente. Lo mismo aplica para el espejado vertical.

Los diferentes anclajes de un texto

Pero tenemos otro problema :-), la rotación también afecta el anclado, por lo que el resultado debe calcularse en base a los dos parámetros simultáneamente, cosa que no es trivial, pero que espero terminar en unos días.

Todo esto por ahora mejora el rotado y espejado de un componente individual. Por algún motivo no funciona bien cuando se aplica a una selección, pero es un problema que veré de solucionar más adelante.

Si todo sale bien, el fin de semana tendríamos cerrado un bug de más de una año de edad 🙂

Hace solo un ratito terminé de armar los tarballs de la nueva versión y ya están en línea la página del proyecto. La mayoría de los cambios no son visibles, pero he aquí un pequeño resumen :

• Ploteo de Funciones : además plotear las tensiones en los nodos del circuito, como ya había dicho antes, ahora se pueden hacer operaciones sobre 2 nodos, como por ejemplo sacar la diferencia o la división (este último importante para graficar la transferencia entre dos nodos).
• FileManager : a partir de esta versión va a ser posible agregar otros formatos de archivo para grabar o cargar esquemáticos de una manera fácil y transparente. Claro que primero alguien tendría que escribir los módulos para ello :-). Si alguien tiene información sobre algún formato útil para empezar a agregar, avise.
• Reporte de errores : haciendo el punto anterior noté que si por ejemplo queríamos abrir un archivo que no sea de Oregano, el usuario nunca era notificado, por lo que agregué todo lo necesario y ahora nos aparecen unos lindos cartelitos de error 🙂
• Por úlrimo varios bugs y mejoras sobre el engine de ploteo, no es perfecto, pero funciona mejor.

Por favor a todos los interesados bajen y prueben esta versión! (que tengo que cursas Análisis de Circuitos y hacer mi TP :-D).

Ya en el post pasado había comentado el nuevo feature de poder agregar funciones. Lo primero que surgió como necesidad fue modificar la forma en como se muestran las cosas en la lista de la izquierda de la ventana de ploteo, para poder separar aquellas que eran nodos, de las funciones. Todo esto para tener más comodidad a la hora de querer seleccionar las cosas.

El primer intento fue bastante desastroso visualmente, aunque funcionaba. Lo que realmente quería mostrar era lo siguiente :

Lo cual no fue nada fácil encontrar como realizar. La solución llegó en #gnome-hackers de FreeNode, donde federico me dio el hack necesario para hacerlo, quedando finalmente así :

No le presten mucha atención a los colores, pues es otro hack a medio hacer y que todavía no me convence :-), pero la idea es también mostrar de que color se está dibujando cada curva para poder identificarlas fácilmente.

No es exactamente la idea original, pero está cerca. Más adelante veré si es posible mejorar la disposición de las celdas para que queden como a mi me gusta 🙂

La principal ventaja de este nuevo método es que para elegir que curvas dibujar no se depende de una «selección en la lista» lo cual hace mucho menos traumática la tarea, ya que antes accidentalmente era muy fácil romper la selección y tener que comenzar desde 0.

Update
Finalmente he logrado hacer exactamente lo que quería 🙂 … hoy descubrí gtk_tree_view_column_pack_start, el resto fue cuestión de minutos.

Hoy en los entremedios de estudio (esta semana estoy en el horno con la facultad) estuve trabajando en dar soporte a cairo 0.5. No fue difícil, en la mayoría de los casos con reemplazar nombres de funciones alcanzó.

Lo más complejo fue sin duda el manejo de superficies. Ahora cuando se crea un contexto cairo se le debe pasar la superficie sobre la cual dibujar (cambio muy lógico por cierto). Como usamos el backend Xlib, necesitamos 3 datos : Drawable, Display y Visual, cosas nada triviales de obtener un widget Gtk. En la documentación de Gdk está todo, pero costó encontrarlo. El resultado resumido a continuación :

  GdkDrawable* real_drawable;
  Display* dpy;
  Drawable drawable;
  gint x_off, y_off;
  gint width, height;
  gdk_window_get_internal_paint_info (window, &real_drawable, &x_off, &y_off);
  dpy = gdk_x11_drawable_get_xdisplay (real_drawable);
  drawable = gdk_x11_drawable_get_xid (real_drawable);
  gdk_drawable_get_size (real_drawable, &width, &height);
  target = cairo_xlib_surface_create (dpy, drawable,
      gdk_x11_visual_get_xvisual (gdk_drawable_get_visual (real_drawable)),
      width,
      height);
  cr = cairo_create (target);

Lindo, no?. El parche para probar está disponible acá (para aplicarlo : darcs apply oregano-cairo-0.5.patch). No lo voy a incluir en el repositorio hasta que Cairo 0.5 se empiece a ver estable en las distros. Por ahora solo lo he visto en Ubuntu Breezy (que es donde hice el trabajo).

Si alguien puede probarlo, se lo agradeceré. Aclaro que saque el exportar a PNG, aunque sería trivial rehacerlo.

Hace unos momentos he liberado Oregano 0.40.4, una versión que pretende arreglar un problema de ploteo con Cairo 0.4.

También se ha includio un arreglo faltante para dar soporte completo a IA64 que se había escapado en las últimas pruebas.

Otro cambio es que se han sacado los parámetros de DEPRECATED por default, para que compile ocn Gnome > 2.8, hasta que, eventualmente, se porte a Gnome 2.10 (2.12 es un lindo número :-).

En los últimos días he estado trabajando en los cambios grandes que vamos a realizar en Oregano para no perder el ritmo. El primer cambio, que va a estar disponible en el CVS pronto, es el cambio de las hojas por páginas en la edición del esquemático. La diferencia fundamental del cambio es que ahora el espacio de una hora es fijo y no puede cambiarse, de manera que si se necesita más lugar del que una página nos puede ofrecer, debemos agregar otra página y utilizar conectores de páginas para conectar 2 circuitos que están en distintas páginas. El resultado será algo como :

Quedan bastantes cosas todavía por terminar, sobre todo porque el último día me pase buscando un bug que resulto ser un typo en una de las clases :-/, y me costo encontrar el problema. Otra cosa por revisar (que lo hice a «ojimetro»), es en las relaciones mm <-> pixels y definir una escala para luego usarla en la impresión.

Hoy estuve peleándome a la tarde con Oregano para resolver un problema reportado por Marc Lorber, quién envió un parche para que se agreguen los .include de los modelos complejos, dentro de la netlist (como ser el ejemplo del Vacuum tube triode 12ax7a).

El parche funciona bien y fue aplicado (previa corrección de otro bug arrastrado desde el comienzo) y funciona de 10 con el ngSpice. Sin embargo, nuestro fiel intento de dar soporte a GNU Cap sigue fallando (y como siga así lo voy a mandar a pasear :-)). Para empezar, en el ejemplo de tubo de vacío, el primer problema es que la nomenclatura de pines no soporta letras , por lo que : .SUBCKT 12AX7A A G K debe ser traducido como .SUBCKT 12AX7A 1 2 3 y dentro del subckt todas las referencias a las letras AGK también deben ser modificadas.

Otro problema es que el nombre del modelo (12AX7A) no puede empezar con un número, pues lo toma como AX7A por lo que nunca lo encuentra por más que se haga el include 😦

Por último, al parecer GNU Cap no soporta los B* del modelo, lo cual ya es irritante para utilizar modelos.

Bien, si alguien sabe de modelos, netlist y se tiene ganas de leer la documentación del GNU Cap y darnos una mano, les invito a escribirme o dejar un comentario :-), ya que se necesita reescribir todos los modelos actuales para que anden con GNU Cap y luego modificar el código para que use uno u otro según el backend.