Thunderbird en vez de Evolution

Llevo tres semanas usando Thunderbird para leer el correo en vez de Evolution. Evolution es el cliente de correo que se instala por defecto con Gnome, uno de los manejadores de ventanas de Linux. Por temporadas he usado otros programas (Claws, por ejemplo), pero siempre volvía a Evolution.

Hace cuatro años compré una PC de segunda mano por $180, sin pantalla ni teclado. Le instalé una distribución de Linux sin entorno gráfico. La conecté a Internet y la metí en un armario. Instalé algunos programas, redireccioné unos cuantos puertos del router para que apuntaran al la PC… ¡Listo! El pequeño servidor descargaba mi correo de varias cuentas, lo distribuía en varias carpetas usando procmail y marcaba el SPAM. Podía accederlo desde diversos lugares utilizando IMAP (o a través de una página web usando Squirrelmail). Y tenía como 30GB para el correo.

Conectado a la red local, usando Evolution para acceder al correo usando IMAP, no tenía problemas con la velocidad de acceso, porque el servidor de correo está en la misma red. Desde fuera, incluso desde Europa en algún viaje, las cosas funcionaban razonablemente rápido.

Los discos duros se malogran algún día

Es obvio: ese servidor no va a durar para siempre. Ha sido un buen experimento, he aprendido en el proceso. Y me sigue siendo útil. Pero si la máquina “se cae”, como mínimo tendré que dedicarle un par de horas. Y probablemente, comprar otra PC. Mientras tanto, estaré sin correo.

El servicio de hosting que tengo contratado con Dreamhost ofrece acceso al correo electrónico por IMAP y página web, y espacio más que suficiente. De modo que hace unas semanas decidí pasar todo el correo a Dreamhost.

Tomada la decisión, el primer paso fue copiar todo el correo, con carpetas y subcarpetas incluido, al servidor de Dreamhost. Para eso, usé IMAPCopy. El programa funcionó a la primera. Era algo más de 1GB. Empecé a las 8pm, y dejé corriendo el programa toda la noche. Al día siguiente tenía una copia de todo el correo en mi cuenta en Dreamhost.

Como siempre, los detalles…

Siguiente paso, configurar una nueva cuenta en Evolution, el cliente de correo, y acceder al email. Primera impresión: todo funciona… pero funciona lentísimo. Entiendo que cuando Evolution se conecta al servidor IMAP por primera vez las cosas demoren un poco (ahora el servidor no está a dos pasos de mi escritorio sino en otro país). Pero después sigue lentísimo. Las cosas llegan al punto en que no se puede trabajar.

Thunderbird

La única diferencia entre las dos configuraciones IMAP es que el servidor IMAP de Dreamhost sólo permite crear carpetas debajo del INBOX. En mi servidor, que usa Dovecot como servidor IMAP, las carpetas pueden crearse en cualquier sitio debajo de la raíz. Bien, no sé qué dice el RFC del protocolo IMAP sobre esto. Pero es la única diferencia entre las dos configuraciones.

Thunderbird

Para descartar si el problema era el cliente de correo, instalé Thunderbird. ¡Perfecto! Funciona rápido. Por ejemplo, ahora estoy en Cañete, con una conexión a Internet medio lenta, y leo el correo sin problemas. Hasta me olvido de que estoy usando un servidor IMAP…

Desconozco el motivo. Podría ponerme a investigar. Pero el Thunderbird funciona bastante bien y es rápido. Así que incluso voy a desinstalar el Evolution, para no tener el evolution-data-server y otros procesos que ya no uso corriendo en la laptop.

Probablemente me estarán gritando que la otra alternativa es pasar todo mi correo a GMail, que también me ofrece acceso IMAP (y por supuesto, por página web). También lo he considerado. De hecho he ayudado a varias personas a pasar todo su correo a GMail, y están bastante contentos. Pero por ahora prefiero tener control sobre mis datos.


Tags: , , , , , ,

Leave a Comment

Efectos gráficos en Linux: Beryl, Compitz…

Dreamhost, el alojamiento que uso para el blog, tiene un utilitario en su panel de control para convertir videos en formato .avi, .mov y .mpeg en videos flash. El video se aloja en mismo espacio que el blog, pero gracias a la conversión puede verse en un player “embebido”, al estilo YouTube.

En el blog casi no hay videos. Pero de todos modos he convertido una de las capturas de pantalla de Ubuntu+Compitz de este post a un video flash incrustado. Además de facilitar al lector ver el video, la diferencia de peso también es notable.

La verdad que al ver mi video me ha parecido bastante malo… Está tomado con una cámara de video, no es una captura directa de pantalla. Así que en desagravio a Compitz, XGL, Beryl y todos los demás módulos de efectos que se pueden instalar en Linux, abajo muestro un video bien grabado que encontré en YouTube.

Por cierto que la versión 7.04 de Ubuntu instala Beryl por defecto, y se puede activar fácilmente, sin editar ningún archivo de configuración directamente.


Comments (6)

Iterating over items of selection fields in django templates using newforms

A year ago I wrote a custom CheckboxSelectMultiple control for django. My application needed to display a series of checkboxes on the webpage, but the default django control did not allow iteration over each checkbox when the control was rendered in the template (as it was possible with the RadioSelect control). This finer control was necessary because I needed to insert extra HTML between each checkbox.

As of version 0.95, django has been under heavy changes, and my custom control no longer works. In particular, the old forms module is being discarded in favor of the newforms module that will become the default forms module sometime in the future. A good explanation can be found in the on-site django documentation, under newforms-migration plan.

The good news is that newforms allows access to individual items of the form fields, multiple-select fields included. The newforms documentation is still work in progress, so it took me a while to figure out how to do it… by inspecting the source code and regression tests. It seems pretty obvious now, should have asked in the django-users list.

The example code has been tested with django svn release 4812 (2007-3-23).

2007-03-27: By mistake I published an incorrect version of views.py. Code has been corrected so that now add_post saves the tag field as expected. (Post has a many-to-many relationship with Tag, so form.save() is not enough to save the form data.)

2007-04-12: The code for views.py has been corrected again. The code posted 2007-03-27 works, but as I discovered later, there is no need to create another object (p = Post(**cleandata)) to handle the many-to-many field data. form.save() takes care of everything, as expected.

2007-04-24: You may be interested in this post.

template

</p>

<ul>
{% for choice in form.base_fields.tag.choices %}
<li> ({{ choice.0 }}, {{ choice.1 }}) </li>
{% endfor %}
</ul>

<p>

models.py

</p>

<h1>-<em>- coding: utf-8 -</em>-</h1>

<h1>models.py</h1>

<p>from django.db import models</p>

<p>class Tag(models.Model):
    tag = models.CharField(maxlength=20)</p>

<pre><code>def __str__(self):
    return self.tag
</code></pre>

<p>class Post(models.Model):
    # other fields here:
    # text = models.CharField(maxlength=255)
    # title = models.CharField(maxlength=50)
    # etc.
    tag = models.ManyToManyField(Tag)</p>

<p>

views.py

</p>

<h1>-<em>- coding: utf-8 -</em>-</h1>

<h1>views.py</h1>

<p>from django.template import Context, loader
from django.http import HttpResponse, HttpResponseRedirect</p>

<p>from django import newforms as forms
from django.newforms.widgets import *</p>

<p>from project.models import *</p>

<p>def add_post(request):
    postForm = forms.models.form_for_model(Post)
    if request.method == 'POST':
       form = postForm(request.POST)
        if form.is_valid():
            form.save()
            return HttpResponseRedirect("/")
    else:
         form = postForm()
         t = loader.get_template('add_post.html')
         c = Context({
               'form': form,
               })</p>

<pre><code>     return HttpResponse(t.render(c))
</code></pre>

<p>

views.py

This is an old version of views.py. The code works, but as I discovered later, there is no need to create another object (p = Post(**cleandata)) to handle the many-to-many field data. form.save() takes care of everything, as expected.

</p>

<h1>-<em>- coding: utf-8 -</em>-</h1>

<h1>views.py</h1>

<p>from django.template import Context, loader
from django.http import HttpResponse, HttpResponseRedirect</p>

<p>from django import newforms as forms
from django.newforms.widgets import *</p>

<p>from project.models import *</p>

<p>def add_post(request):
    postForm = forms.models.form_for_model(Post)
    if request.method == 'POST':
        form = postForm(request.POST)
        if form.is_valid():
           cleandata = form.clean_data
           # use the form tag ids to select the Tag instances
           # related to this Post entry
           tag = Tag.objects.in_bulk(cleandata['tag'])
           # need to delete the tag ids from clean data,
           # otherwise p = Post(** cleandata) will complain that
           # tag is not a parameter of Post( )
           del cleandata['tag']</p>

<pre><code>       # create an instance of Post from the form data
       p = Post(**cleandata)
       p.save()   # need to save so p gets an id.
       p.tag = tag
       p.save()

       return HttpResponseRedirect(&amp;amp;quot;/&amp;amp;quot;)
   else:
   form = postForm()

   t = loader.get_template('add_post.html')
   c = Context({
          'form': form,
    })

    return HttpResponse(t.render(c))
</code></pre>

<p>


Leave a Comment