TODO

===============
=== BACKLOG ===
===============
== Funcionalidades a implementar


** Gráfico 

** Fazer com que enter no fileChoose abra a pasta, e não a selecione 
(selecionar só com o botão)

** Paralelizar processamento
Eu fiz, mas o tempo de execução ficou o mesmo! oO
Então pra deixar o log mais simples, voltei pra versão não paralela
Versão paralela salva no commit:
21e6fbcc6847670fa373a8e2aa63e9a2e515175f

** Talvez uma estrutura de mapa, em vez de lista,
para os conceitos na tarjeta fosse mais eficiente

** Melhorar o layout para que o label de status 
não altere as posições dos botões da tela

** Criar teste unitário para FinalSheetGenerator

** Letras devem aparecer na planilha do 5o conceito

******************************************
******************************************

============
=== BUGS ===
============
== Problemas para corrigir

** Verificar se abertura de caminhos absolutos em FileLoader funciona no Windows.

** Não se basear na posição da tarjeta para recuperá-la e fazer as contas

** Notas vermelhas não estão ficando vermelhas

** Se a falta anual for maior que 25% deixar em vermelho
Estou tendo problemas com a API: em vez de vermelho, texto fica tachado!
Talvez seja melhor mexer no modelo

** No sistema atual, toda tarjeta deve ter MAX_ALUNOS linhas
Mesmo que objeto tarjeta só tenha 4 notas úteis, a lista notas terá MAX_ALUNO objetos Conceito
Seria legal flexibilizar isso
Uma coisa ruim que isso gerou foi um acoplamento entre ValoresProf e OdsParser
(método fillTarjetas é muito feio, não deveria existir).
Proposta: quando acabar alunos, a linha do número do aluno deve ficar branca.
Com isso dá pra também melhorar os testes readSheetWithBlankLines e readSheetWithLetters em OdsParser

** Atualmente o programa consome cerca de 1GB de RAM para processar 48 tarjetas.
Investigar como diminuir o consumo de memória.
Suspeita: talvez os recursos (arquivos ods) não estejam sendo fechados.

Há uma grande quantidade de threads pra executar CellReader em SaferCellRetriever.
Cheguei a ver 10 threads.
Essas threads devem de ser as responsáveis pelo auto consumo de memória.
No dump os objetos suspeitos são justamente threads.
CellReader aponta pra uma Table, que deve ser o objeto pesado (carrega todo o ods).
Na análise de consumo de memória, o principal vilão é
org.odftoolkit.simple.table.Row (deve pertencer ao Table)
Talvez haja uma relação a qantidade de OdfReadCellException e o número de threads (mas não é ==).
Será que deveriam haver mesmo todas essas threads?
O código não está todo sequencial?
Como fazer essas threads morrerem?
Problema é que thread deve ficar travada em table.getCellByPosition(cellPos) quando dá pau na API do odf,
nessa situação é que soltamos OdfReadCellException.

** Nas planilhas geradas, apenas a primeira tarjeta está com a "turma" impressa corretamente.
Nas outras tarjetas, fica a string "TURMA".