SU-8W com acentos no N800
30-Jun-08
Estive me perguntando porque os acentos não funcionam corretamente no SU 8W com o N800. Decidi investigar.
Quando eu estava tentando sincronizar o teclado com o N800 pude perceber que o SU 8W é um teclado pré-configurado, e com um pouco de paciência encontrei o arquivo de configuração do mesmo: /usr/share/X11/xkb/symbols/nokia_vndr/su-8w
Após 5 minutos estudando a sintaxe, em 10 minutos é possível perceber que falta alguma coisa: Não há, pelo menos, as configurações para português, espanhol e italiano. Agora eu entendo porque a configuração de layout português não funciona.
Já que não existe uma configuração para o idioma definido, utiliza-se o us_intl, certo? Mas a primeira linha da definição do us-intl tem um comentário preocupante: “I can’t belive! It’s not intl”. Parece que a tafera não será assim tão simples.
Para propósito de teste, não criei um novo mapa de teclado para pt_BR e sim editei o us_intl. O resultado ficou aceitável, e finalmente é possível ter um teclado funcional em português. O resultado você pode entrar aqui.(Não esqueça de fazer backup antes de sobrescrever)
Nos próximos dias ponho aqui a solução definitiva.
Resltado final:
Pychord 2 saindo do forno
30-Mar-08
Certa vez um colega de trabalho de uma das empresas por onde passei comentou:
“Não basta colocar um filho no mundo, é preciso alimenta-lo, educa-lo e fazer o possível para vê-lo crescido!”
Pois bem, depois de certo tempo resolvi voltar a mexer no abandonado código do pychord e adicionar algumas funcionalidades que eu precisava.
Após duas tentativas frustradas (0.4.5 e 0.5) percebi que era necessário re-escrever a biblioteca gráfica. Assim foi feito. Adicionei o conceito de janela, conteiner de widgets, melhorei a herança entre classes, etc. A interface não mudou muita coisa, pygame é meio chato para isso.
Ainda estou usando o padrão .chr criado para a primeira versão, mas pretendo adicionar o formato XML opensong em breve.
A parte legal, e a novidade mais visível, é que criei uma heurística para decidir quais linhas são acordes e quais não são. Esta heurística pretendo ir melhorando a medida que for encontrando casos em que ela não funcione.
Para resumir: ao nível de usuário, as modificações foram:
- Heurística para reconhecer/diferenciar acordes de letra de músicas
- Mudança de tom
- Listas clicáveis e móveis
- Suporte ao Maemo OS2008
- Controle da luminosidade durante a apesentação das cifras ( o display não apaga durante a mostragem mais )
A parte nerd
A idéia era que o código da interface pudesse ser reutilizada em outros projetos, logo trabalhei para ter uma GUI mais conscistente do que a anterior. Utilizando melhor o conceito de herança foi possível simplificar a utilização da lib, deixando as coisas com menos cara de gambiarra.
Através do conceito de slots ficou bem simples implementar mais de uma action para um mesmo evento.
Screenshots
Tela de busca, não mudou muito de como era anteriormente.
Visualização da cifra
Mudaça de tom.
Como sempre, o arquivo de instalação pode ser pego aqui. Ainda não criei um repositório pois o aplicativo está em fase de testes. Mas pretendo fazer isto em breve.
[UPDATE 03/03/2008] Por problemas de codificação dentro do módulo sqlite3, os textos devem estar em formato UTF-8…
Como descrevi aqui a alguns dias atrás, o GoogleStreeMaps tem problema em posicionar geograficamente as ruas de algumas cidades do Brasil ( principalmente do interior ). Para quem o utiliza apenas para ver rotas não tem problema algum, mas para quem utiliza-o como motor para GPS a coisa muda de figura. O que acontecia era mais ou menos isto:
(A linha vermelha indica o que o carro estava fazendo, a linha verde indica o que o GoogleStreetMaps indicava fazer)
Como não quero passar aperto em Sampa semana que vem, e sei que Sorocaba e Itu estão na lista das cidades que o GoogleMaps erra, resolvi escrever um pequeno patch para o Maemo-Mapper, que adiciona a seguinte feature: “Calibrar o Mapa”.
Funciona mais ou menos assim: Ao identificar um erro de deslocamento, o usuário vai no menu Mapas e depois em “Calibrar Mapa”. Logo após clica-se em algum lugar da tela onde ele crê que realmente está.
O ideal mesmo seria parar o carro em uma esquina, identificar a rua onde está e a rua que irá cruzar, e clicar bem em cima.
O algoritmo faz duas coisas muito simples: Calcula a diferença da Latitude e Longitude do clique e da posição real indicada pelo cursor. Em mãos desta diferença, ela será sempre adiciona à Latitude e Longitude na leitura do GPS.
Desta forma conseguiremos andar sempre em cima da rota. O resultado final será algo como:
(Há! bem melhor agora!)
Bom, se o patch mostrar-se útil para mais alguém posso envia-lo à equipe do maemo-mapper… Para mim com certeza o será.
O patch pode ser encontrado aqui, e o pacote para instalar aqui.
É isso, bom fim de semana a todos!
[]’s
Danilo Cesar
[UPDATE: 15/02/2008] Quase um mês depois…
O mapeamento de Sorocaba é melhor do que eu pensava. Usei o calibrador apenas em um momento, quando entrei na cidade. Excelente trabalho do nosso co-piloto!
Depois, com o calibrador desligado, percebi que o erro era imperceptível em vários pontos, inclusive na chegada do kartódromo de Itu! Por falar em Kartódromo, o Schinchariol é uma exelente opção para os paulistas amantes da velocidade.
Notas de um viajante.
11-Jan-08
Adquiri um GPS Bluetooth Holux a alguns dias atrás para minha viagem por São Paulo com alguns amigos, e como viria para Londrina neste fim de semana com meu pai resolvi testa-lo na viagem.
Bom, o equipamento é o seguinte: GPS Holux com interface bluetooth, N800 com Maemo-Mapper com trajeto e mapas adquiridos antecipadamente através do Google-Maps.
A saída de Curitiba e boa parte do trajeto até chegar em Londrina foi excepcional! Se havia algum erro de GPS, este foi imperceptível. Eu ficava admirado em ver o ponto azul em uma curva exatamente quando o carro fazia a mesma. Tudo muito sincronizado.
Como nem tudo são flores, chegando em Londrina houve uma grande decepção, pois havia um erro de quase duas quadras ( uns duzentos metros ) em relação ao ponto mostrado no mapa e o ponto onde eu realmente estava.
De duas uma:
- O GPS está me passando uma informação errada.
- O Google Maps não mapeou direito às coordenadas de Londrina.
Pessoalmente, a primeira eu acho difícil de ser verdade, uma vez que ele estava funcionando muito bem em Curitiba em meus testes utilizando de 9 a 10 satélites ( onde estou agora, em Londrina, o GPS utiliza 8 ).
A segunda opção eu acho bem viável. Londrina não é uma cidade tão grande, e o mapeamento pode ter sido feito “às coxas”.
A questão é a segunte: Será que em minha passagem por Sorocaba e Itú terei o mesmo problema? Mesmo SP sendo o “coração do Brasil” (sem trolls aqui, por favor), ambas também são cidades de interior.
Por isto eu faço um apelo: Se você é morador de Londrina-PR, Itú-SP ou Sorocaba-SP, e possui GPS: Pegue suas coordenadas e coloque-as no GoogleMaps e verifique se a referência no mapa é realmente onde você está. Depois poste aqui os resultados.
Bom, vou aproveitar minha família agora =)
Abraços a todos e bom fim de semana!
[Update] Hoje com mais tempo vim tentar descobrir o problema, e é mais ou menos o que o Rafael falou. A verdade é que o mapeamento por satélite do GoogleMaps é uma beleza, mas o mapeamento de rua não!
Descrevendo o problema: A rua marcada em vermelho deveria estar no traçado verde. O Google Satelite posiciona-se corretamente, mas o mapa é posicionado com um erro de cerca de 167 metros.
Bom, talvez o Google não seja tão bom assim =)
[Update2] O Google compra as informações sobre mapas da MapLink. Logo o problema está lá!