Nokia vai mudar para Qt no Maemo

Como já era esperado a Nokia anunciou durante o GCDS que o Maemo 6 (Harmattan) vai trocar o GTK pelo Qt. Embora o Gnome Mobile continue sendo a base do sistema, a interface com usuário passa a utilizar Qt. Essa mudança era esperada devido a compra da Trolltech pela Nokia.

Mesmo sendo uma decisão esperada, ao meu ver a Nokia parece complicar ainda mais o já ruim processo de aceitação do Maemo e seus Internet Table NXXX pelo mercado. O atual Maemo 5 que ainda não foi lançado, foi basicamente reconstruído utilizando GTK/Clutter mudando totalmente a interface em relação ao seu antecessor o Maemo 4 que era basicamente GTK. Agora na próxima versão mais mudanças na interface com adoção do Qt.

O GTK ainda vai estar disponível no Maemo mantido pela comunidade, garantindo que aplicativos legados continuem funcionando mesmo que com visual diferente do sistema. Trocar de GTK para Qt não é uma simples mudança de ui toollkit mas também de linguagem já que Qt se baseia em C++ e GTK em C, ou seja, uma grande mudança para todos os desenvolvedores.

Na minha opnião, a Nokia mostra mais uma vez que as decisões em relação ao Maemo são tomados mais por diretores sem conhecimento e menos pelos técnicos ou ao menos demonstra que existe pouca sinergia entre esses dois grupos, já que não ter GSM no N810 e mudar completamente sua interface a cada versão não anima desenvolvedores para produzir aplicativos para essa plataforma e não traz novos usuários.

Tudo bem, Qt é uma excelente biblioteca, mas na minha opinião essa mudança já deveria ter sido feita no Maemo 5, evitando que novos aplicativos para o Maemo 5 tenham que portardos em seguida para o Maemo 6 quando estiver utilizando Qt.

Maemo é uma excelente plataforma e meu sonho de consumo é o futuro N900 assim que for lançado, mas espero que a Nokia tenho um pouco mais de cuidado com suas decisões em relação ao Maemo, afinal Android e Moblin estão criando excelentes plataformas.

Decorators com argumentos

Nos últimos tempos estive escrevendo uma API que utiliza decorators para registrar eventos em uma aplicação PyGTK/Glade. Nessa API basicamente eu tenho eventos registrados no glade e associados a um handler na aplicação (glade.sinal_connect('event', handler)) e eventos conectados diretamente na aplicação associados a um handler e um widget (widget.connect('event', handler)).

Então precisei de um decorator que em alguns momentos não receberia nenhum parâmetro, associando a função decorada a um sinal registrado no glade com o mesmo nome da função.

# Associa a função 'destroy' ao evento 'destroy' já registrado no glade

@handler
def destroy(self, *args):
    print args

# Mesmo funcionamento

@handler()
def destroy(self, *args):
    print args

Ou ainda, este mesmo decorator poderia receber argumentos detalhando qual o nome do evento e widget para quais a função decorada deve ser associada.

# Associa a função 'x' ao evento 'destroy' já registrado no glade

@handler('destroy')
def x(self, *args):
    print args

# Associa a função y ao evento 'on_bt_ok_clicked' no widget bt_ok

@handler('on_bt_ok_clicked', bt_ok)
def y(self, *args):
    print args

Quando nenhum argumento é informado (@decorator()) utilizo uma função aninhada para ser retornada como decorator e assim efetivamente decorar a função. O mesmo funcionamento se aplica quando os argumentos não são funções ou métodos (@decorator('x'), @decorator('x', a=1)), utilizando o módulo inspect . Esse comportamento só muda quando o decorator não recebe parâmetros, ou seja, quando este não é invocado, retornando a função ou método recebido sem nenhuma modificação.

def decorator(*args, **kargs):
    import inspect
    # @decorator() or @decorator('x') or @decorator('x', d='a')
    if not args or not inspect.isroutine(args[0]): 
        def deco(func):
            def wrapper(*f_args, **f_kargs):
                return func(*f_args, **f_kargs)
            return wrapper
        return deco
    elif inspect.isroutine(args[0]): # @decorator
        return args[0]

Exemplos de uso:

@decorator
def d(x, y, d=1):
    print x, y, d
#d = decorator(d)

@decorator()
def e(x, y, d=1):
    print x, y, d
#e = decorator()(e)

@decorator('x')
def f(x, y, d=1):
    print x, y, d
#f = decorator('x')(f)

@decorator('x', d=5)
def g(x, y, d=1):
    print x, y, d
#f = decorator('x', d=5)(g)

Abaixo o mesmo decorator utilizando classe, assim o comportamento do decorator pode ser facilmente expandido para funcionar com métodos seguindo esse texto Decorators and Descriptors, fazendo o decorator ser ainda mais flexível podendo ser utilizado com funções ou métodos ao mesmo tempo:

class decorator(object):
    def __init__(self, *args, **kargs):
        import inspect
        # @decorator() or @decorator('x') or @decorator('x', d='a')
        if not args or not inspect.isroutine(args[0]): 
            def deco(func):
                def wrapper(*f_args, **f_kargs):
                    return func(*f_args, **f_kargs)
                return wrapper
            self.func = deco
        elif inspect.isroutine(args[0]): # @decorator
            self.func = args[0]

    def __call__(self, *args, **kargs):
        return self.func(*args, **kargs)

    def __get__(self, obj, type=None):
        if obj is None:
            return self
        new_func = self.func.__get__(obj, type)
        return self.__class__(new_func)    

Exemplos de uso:

class A:
    @decorator
    def b(self, x, y):
        print x, y

a = A()
a.b(1, 2)

@decorator
def b(x, y):
    print x, y

b(2, 3)