brauliobo / gebr Goto Github PK

A GêBR atualmente trabalha com as categorias do SU e a coloca por padrão na
lista de categorias pré-definidas na DéBR.
A proposta da GêBR não é só trabalhar com o SU, assim que as categorias do
SU só deveriam aparecer se menus do SU estiverem instalado.
Além disso, o usuário pode trabalhar com suas categorias. Essas deveriam se
tornar como as categorias pré-definidas, para ser usada para novos menus.

Para resolver esses dois problemas, a DéBR deveria também trabalhar com
índice de menus (como o $HOME/.gebr/menus.idx). Na verdade, uma lista de
categorias usadas nos menus da pasta do usuário na guardada na configuração
da DéBR ($HOME/.gebr/debr.conf) já seria suficiente.

Ao adicionar/remover uma nova categoria para um menu essa lista é
atualizada, e assim ela se torna disponível para os outros.

A função geoxml_parameters_get_number não retorna o valor correto quando há
parâmetros do tipo grupo.

Ao preencher os parâmetros de um programa na GêBR deveria haver alguma
indicação de que um grupo que esta fechado possui um parâmetro que
obrigatoriamente deve ser preenchido. Por exemplo, escrevendo o titulo do
grupo em negrito. Da forma como está um parâmetro obrigatório dentro de um
grupo é facilmente ignorado.

Apesar da GêBRD já ter suporte à internacionalização e já ter suas
mensagens traduzidas para o Português, as mensagens continuam sendo
impressas em Inglês.

A GêBR usa arquivos no formato XML para salvar suas informações. A medida
que a complexidade do projeto aumenta, mais informações são mantidas nesses
arquivos.
Para trabalhar com XML, usa-se a Gdome que por sua vez usa a libxml2. Esta
ultima tem suporte suporte a arquivos XMLs compactados.
Portanto, a questão é descobrir como salvar e abrir arquivos compactados,
ou usando a libxml2 ou a própria zlib.

Referências:
Gdome: gdome2.cs.unibo.it
libxml2: www.xmlsoft.org
zlib: www.zlib.net/zlib_how.html

A função gtk_tree_model_path_to_iter na libgebr é redundante, pois já
existe uma no gtk: gtk_tree_model_get_iter ;)

Na aba "Menu" da DéBR os menus são listados sem nenhuma ordem aparente.
Esse arranjo não contribui para a rápida localização dos menus.

Uma sugestão para organizar os menus nessa lista é reproduzir a hierarquia
de categorias usada na aba "Edição de Fluxo" da GêBR. Essa organização
facilitaria a localização de menus e aumentaria a simetria entre as 
interfaces.

Imagino que essa funcionalidade possa ter alguma (remota) relação com a
descrita no issue 14.

A seleção múltipla é útil para operações como deleção, validação (na 
DéBR),
entre outros. No entanto, a maioria das operações deve trabalhar com
seleção única, como propriedades de um fluxo.

A tarefa envolve implementar com seleção múltipla. Até agora, só a aba
Menus na DéBR tem esse suporte.

1. Selecione um determinado menu e clique na prévisualização de seus
parâmetros.
2. Sem fechar a janela de prévisualização, selecione outro menu.
3. Abra a prévisualização de parâmetros deste segundo menu.

Bug 1: ambos os menus passam a ter seus programas duplicados.
Bug 2: se clico no botão de atualizar a prévisualização do menu 1 (o que
foi aberto primeiro), os parâmetros exibidos passam a ser os do menu 2,
porém o título permanece os do menu 1.

Em alguns nomes de menu, parâmetros, categorias, etc aparecem caracteres
especiais, do ponto de vista do html. Um exemplo é a expressão "don't" que
contem uma aspa.

Embora eu não tenha encontrado nenhum outro exemplo é possível que outros
caracteres com significado especial sejam incluídos. 

Outra possibilidade bizarra é que alguem digite um comando html, por
exemplo "</spam>" dentro de um campo na DéBR.

Talves a DéBR ao gerar o código HTML devesse eliminar esses caracteres ou
comandos HTML.

A janela de leitura de parâmetros da GêBR é uma vbox. As widgets para a
leitura de cada um dos parâmetros são organizadas nas linhas nessa vbox. A
altura de cada uma dessas linhas é determinada pelo tipo de widget
(checkbox, entry, combobox, etc) correspondente ao tipo de parâmetro. Seria
interessante que todas as linhas tivessem a mesma altura (quando possível),
o que tornaria a interface esteticamente melhor.

A GêBR carece de ajuda ao usuário. 

Para as interfaces GêBR/DêBR a ajuda escrita no formato DOCBOOK será
convertida para HTML para ser exibida em um navegador. O navegador é o
definido nas configurações da GêBR/DêBR.

O trabalho envolve criar a estrutura para os arquivos do autoconf/automake
para converter os arquivos docbook para html e instalá-los na pasta
/usr/share/doc/{gebr,debr}.

No menu ajuda entra um item "Contents" que abre o navegador com a ajuda
instalada.

Tanto na GêBR quando na DêBR o usuário pode indicar apenas um diretório
onde armazena seus arquivos de menu.

Para a GêBR esse arranjo é adequado pois o usuário provavelmente só vai
incluir poucos menus a mão. Porém para o usuário DéBR a seleção de mais 
que
um diretório é necessária. Por exemplo, no arranjo atual dos mensu (SVN
r26) existem dois diretórios distintos onde os menus são arquivados 
trunk/su/menus
trunc/shtools/menus

No futuro o número de diretórios deve ser ainda maior. Como esses arquivos
estão sendo gerenciados pelo svn mexer na árvore de diretórios pode levar a
inconsistências.

A GêBR tem um pé no mundo WEB. Quero dizer, ela depende de documentos HTML
para armazenar a ajuda de fluxos e programas, projetos e linhas, além de
futuramente a ajuda da GêBR em si.

Atualmente, a GêBR usa um browser configurado pelo usuário para exibir
todos esse hyper textos. Obviamente, essa é mais uma depêndencia externa e
que constrasta com a GêBR. O ideal seria que a própria GêBR os exibisse.

Uma boa alternativa seria usar o WebKit através da libwebkit (GTK+ e
WebKit). É uma biblioteca muito completa e feita para ser usada por
aplicativos.

O trabalho inicialmente envolveria fazer um simples visualizador de HTML
numa janela de diálogo usando a libwebkit. Na GêBR, o código de ajuda está
em help.c, onde se recebe o mesmo como uma string. Está, obviamente, seria
passada para a libwekit renderizar. 

1. Seleciona uma linha com fluxos na GêBR
2. Clique no botão excluir
3. Na dialog de confirmação, arrependa-se e clique em Cancel

Implacável, a GêBR ignora sua súplica e deleta a linha mesmo assim.

Até a 0.9.12 a GêBR utilizava uma pasta, escolhida pelo usuário, para
instalar os arquivos de projetos, linhas e fluxos. A partir da 0.9.13 esta
pasta não é mais definida pelo usuário, mas sempre definida como
.gebr/gebrdata. Entretanto, quando a GêBR é iniciada pela primeira vez
ainda é exibida a dialog de preferências que solicita ao usuário a escolha
desta pasta de dados. Apenas na segunda execução da GêBR esta pasta é
migrada para o novo esquema.

Para novos usuários, a pasta de dados nem mesmo deveria ser solicitada.

A bash tem suporte a cores no terminal. Seria interessante que fluxos que
geram saídas em cores na bash pudessem ser exibidos assim na janela de jobs
da GêBR.

A widget utilizada para exibir a saída de um job é a GtkTextView
(http://library.gnome.org/devel/gtk/stable/GtkTextView.html). Esta widget
tem suporte a cores e fontes através do Pango
(http://library.gnome.org/devel/pango/stable/).

A intenção é que a saída de um job, antes de ser exibida, seja analisada
para verificar se há ou não caracteres de controle da bash que alterem
cores e fazer a conversão apropriada para a sintaxe do Pango de maneira que
a exibição dentro da GêBR mimetize a que o usuário receberia no terminal.

À imagem do que faz a GêBR, o daemon deveria preservar todos os seus dados
em disco, de maneira a poder ser reinicializado e retomar o controle dos
jobs em execução e o histórico dos jobs já executados.

Isto possibilita que o daemon seja reinicializado quando há uma atualização
da versão instalada (seja do próprio daemon, seja da lib) sem prejuízo aos
jobs monitorados pelo usuário da GêBR.

Parâmetros do tipo arquivo poderiam opcionalmente ter filtros, ou seja,
padrões que qualificariam os tipos de arquivos aceitos. Por exemplo, um
programa que espere um arquivo binário, poderiam ter o filtro "*.bin" que
seria então utilizado para filtrar os arquivos exibidos na widget de
navegação pelo sistema de arquivos.

Antes do daemon executar um job, ele poderia realizar alguns teste para
salvaguardar o usuário, como por exemplo, a existência e a acessibilidade
de arquivos de entrada e saída, permissões de escrita em diretórios, e se
consegue de fato encontrar todos os binários. Caso detecte um problema,
então o usuário seria informado do erro ao invés de receber como saída a
mensagem de erro da shell.

Na GêBR, na dialog de edição de propriedades de projetos, linhas ou fluxos,
sempre há dois botões, um para visualização e outro para edição do help. O
mesmo layout deveria ser replicado na DéBR. Atualmente, na dialog de edição
das propriedades de menus e linhas da DéBR há apenas um botão para edição
do help. A visualização só pode ser feita fora desta dialog, com o botão de
informações, presente nos "detalhes" do menu ou programa.

A possibilidade de criar grupos de parâmetros dentro de outros grupos pode
é necessária para representar corretamente a estrutura de opções de alguns
menus.

Um exemplo é o menu suhape.mnu. Nesse menu o usuário deve obrigatoriamente
atribuir valores a um conjunto de parâmetros escolhido entre três possíveis
conjuntos diferentes. 

Esse arranjo seria naturalmente descrito por um grupo exclusivo que contem
três grupos dentro dele.

Sequência para reproduzir o erro:
1- Abrir normalmente a DéBR
2- Clicar em um menu qualquer
3- Digitar o nome de outro menu para que a interface o busque na lista
4- Quando o novo menu for encontrado teclar enter
5- O quadro de dialogo para a edição do menu é aberto para editar o menu
previamente selecionado e não o que foi localizado pela busca.

O parâmetros do tipo inteiro e real podem opicionalmente ter como atributos
valores mínimos e máximos, que seriam conferidos pela interface quando o
usuário os preenchesse.

Há parâmetros comuns a muitos programas e seria interessante por copia-los
de um programa para outro (de um mesmo menu ou entre menus distintos). Num
nível acima, até mesmo programas poderiam ser copiados entre menus.

Poderia haver uma estrutura com dois campos (tipo e xml). O primeiro guarda
o tipo do bloco que foi copiado para o "clipboard" (parâmetro ou programa),
enquanto que o segundo armazena o bloco em si.

Uma vez implementado para a DéBR, a implementação para a GêBR sai fácil.

Motivação: parâmetro key de vários programas do SU. Esse parâmetro é
implementado como um enum com 84 opções! Ter que redigita-lo repetidas
vezes é impensável.

Na DéBR, ao remover um menu que foi alterado mas não foi salvo, aparece um
quadro de dialogo confirmando a remoção. Mas esse quadro de dialogo se
refere ao menu como "Fluxo" e não como "Menu". O mesmo erro ocorre ao pedir
que um "Menu" seja revertido.

Além disso, se o menu ainda não recebeu um titulo no momento da remoção o
quadro de dialogo exibe:

  Fluxo '' tem modificações não salvas. Quer salva-las?

Seria melhor que exibisse:

  Menu 'Sem Titulo' tem modificações não salvas. Quer salva-las?

Exportei uma linha com vários fluxos e a reimportei.

Em primeiro lugar, o documento mais alto na hierarquia deveria ter seu
título trocado para "<titulo> (imported)" para destaca-lo na interface.

Em segundo lugar, parece estar havendo algum problema nos fluxos e linhas
importados. Me parece que o nome do arquivo da linha foi alterado, mas esta
alteração não foi salva no arquivo do projeto. O mesmo ocorre com os
arquivos de fluxo, cujos nomes novos não foram alterados no arquivo da
linha que os contém. Por algum motivo, a ação de importar uma linha dentro
do mesmo projeto que a continha originalmente também acabou por corromper a
linha original.

Para facilitar a manutenção de grandes quantidades de menus, poderia haver
a opção de ordenar a lista de menus em edição na DéBR pelas datas de
criação ou alteração. Assim seria possível controlar quais menus foram
recentemente alterados e quais não, sem precisar para tanto clicar em cada
um individualmente.

Ao criar um parâmetro tipo lista na DéBR, se o separador dos itens da lista
for um espaço em branco o usuário não ve nada dentro do campo do separador.
Isso pode levar a introdução de erros ao portar programas.

Uma solução simples para essa situação é considerar o espaço em branco 
como
valor default. Se o usuário não colocar nada no campo o programa assume que
o separador é um espaço.

Outro detalhe. O campo deveria ser etiquetado como "Separador de itens", ou
apenas "Separador", e não "Separador de listas", pois o separador aparece
entre itens e não entre listas.

A vizualização dos detalhes de um fluxo na GêBR não está sendo atualizada
após a edição das suas propriedades.

Na GêBR, as janelas de propriedades de um projeto/linha/fluxo/programa
sempre constam os botões OK/Cancel. Já na DéBR, devido a fatores históricos
herdados da antiga GêBRME, os dados quando alterados na interface já são
automaticamente alterados no fluxo.

Uma possível solução, como já usado na GêBR, é duplicar o elemento a ser
editado no XML (usando geoxml_sequence_append_clone) e fazer as alterações
nesse "clone". Caso o usuário clique em OK, esse elemento substitui o
anterior. Caso contrário, ele é removido.

Quando um usuário esta editando, ou verificando, os parâmetros de um
programa na DéBR, ele é forçado a entrar no quadro de dialogo de edição do
parâmetro para ver informações básicas.

Seria muito mais produtivo se informações simples como: se o parâmetro é
obrigatório, o tipo de um grupo, etc. Fossem incluídos na lista de
parâmetros, como já foi feito no caso de parâmetros tipo lista.

Ao criar um parâmetro na DéBR é necessário selecionar um tipo de uma lista. 

A widget lista poderia ser substituida por um conjunto de botões. 
Cada um desses botões selecionaria automaticamente um tipo de parametro e
fecharia o quadro de dialogo. 

Haveria apenas um botão extra para cancelar a operação.

1. Crie um menu novo, contendo apenas um programa.
2. Preencha as propriedades do programa.
3. Salve e feche a DéBR.
4. Ao reabri-la verá que as informações do programa não foram salvas.

Descobri isto ao criar um menu para o comando set da bash (sem qualquer
parâmetro).

Estava trabalhando na release 939.

Ao colocar o endereço [email protected] como e-mail do autor de
um menu a função validar marca esse endereço como possível erro. Removendo
o hífen esse erro desaparece. 

Versão da DéBR: 0.9.13

Ao criar um novo menu, ao entrar pela primeira vez na aba Programa, aparece
um programa pré-inserido com o nome "Novo Programa" e sem nenhuma descrição.

Assumindo que grande parte dos menus serão representações fiéis de algum
programa, seria útil usar o nome do menu e sua descrição como sugestões
iniciais para o nome e descrição do programa.

Ao criar um parâmetro flag na DéBR as opções seguem ao padrão geral de
criação de parâmetros. Mas essas opções não são adequadas para os
parâmetros flag, por exemplo:

1- O campo Valor padrão é hermético. Ao entrar em contato a primeira vez
com esse quadro de dialogo é difícil decifrar o que esse campo significa.
Uma maneira de tornar esse campo mais claro seria colocar a palavra "ativo"
logo a direita do check button.

2- Como uma flag pode ser obrigatória? O que isso significa? Ela deve estar
sempre ativa?

3- O que siginifica uma lista de flags?

Para algumas coisas na GêBR e DêBR, como o log de um job no primeiro ou o
relatório de validação no segundo, ter suporte a impressão seria 
interessante.
Isso poderia ser feito usando a biblioteca de impressão do GTK+ (ver
http://library.gnome.org/devel/gtk/stable/Printing.html).
O trabalho envolve descobrir como imprimir usando essa biblioteca do GTK, a
partir, por exemplo, de um GtkTextView
(http://library.gnome.org/devel/gtk/stable/GtkTextView.html), e implementar
na interface.

Os nomes de arquivos de entrada/saída/erro e de parâmetros do tipo arquivo
estão armazenados em UTF-8. Quando a linha de comando é gerada,
aparentemente está correta (dado que a exibição na interface espera strings
em UTF-8) mas, de fato, a shell não está entendendo o enconde corretamente.
Veja o exemplo de saída de um fluxo que deveria criar um arquivo no
diretório "Área de Teste".

----
Linha de comando:
suplane npl="3" >"/home/juca/Área de Teste/lixo.su"

Saída:
bash: /home/juca/\303\201rea de Teste/lixo.su: Arquivo ou diretório inexistente

Data de término: Seg 11 Mai 2009 17:00:43 BRT
----

A glib tem as funções as g_filename_to_utf8 e g_filename_from_utf8 que se
encarrega de converter as strings para o enconde do sistema de arquivos.

Outra complicação é que a string executada e a exibida na interface são a
mesma. Talvez isto já não seja mais possível, dado que o enconde nas duas
situações pode ser diferente.

What steps will reproduce the problem?
1.Ao atualizar a Gebr da versão 0.9.12 para 0.9.13 pelo Synaptic, quando
vai atualizar a biblioteca libgebr0, aparece a seguinte mensagem:
libgebr0:
 Depende: libwebkit-1.0-1 (>=0~svn31841) but it is not installable

2. Baixei todos libwebkit disponíveis, mas continua dando o mesmo erro.
Esta biblioteca libwebkit-1.0-1 especificamente não encontrei.

What version of the product are you using? On what operating system?
Estou com a versão 0.9.12, e usando o Ubuntu.

Please provide any additional information below.

Obrigado

Na versão atual da GêBR (0.9.13) um usuário pode acessar o help de um menu
diretamente da aba "Edição de Fluxo". Porem só tem acesso ao help dos
programas associados a esse menu quando o inclui em um fluxo.

Seria interessante que dentro do help do menu houvessem links para o help
de cada um dos programas contidos no menu.

Como a GẽBR tem a opção de linha de comando de instalar um menu no
diretório privado do usuário, é interessante que a DéBR apresente um botão
para instalar um menu em edição, evocando esta funcionalidade.

Por padrão, a GêBR não sobrescreve um menu que já esteja presente no
diretório do usuário. Caso este comportamento seja desejado, deve-se
utilizar a opção --menu-overwrite. Comportamento semelhante deveria ocorrer
na DéBR.

O código para a criação do template para a criação de help's não consegue
extrair informação dos parâmetros pertencentes a um grupo.

No quadro de dialogo "Editar programa" da DéBR o campo onde o arquivo
executável deve ser inserido esta etiquetado como "Binário". O termo
"Executável" seria mais descritivo, evitando confusão com arquivos de dados
binários, e mais preciso, um arquivo executável não é necessariamente 
binário.

Essa sugestão é fruto de algumas confusões que surgiram entre os alunos do
curso realizado no Observatório Nacional.

Caso um arquivo de menu na pasta do usuário tenha o mesmo nome de arquivo
de menu na pasta do sistema, apesar de na GêBR ambos serem exibidos, de
fato apenas um deles é acessado.

Para a resolução deste conflito, a proposta é que os menus do sistema sejam
instalados em <pasta de menus do sistema>/<pacote> e que a referência ao
nome do arquivo de menu no xml preserve o subdiretório <pacote>. Por
exemplo, os menus do SU estarão instalados em
/usr/share/gebr/menus/seismicunix e para o menu suacor, em seu xml o
elemento filename armazenará seismicunix/suacor.mnu.

A GêBR interpretará então menus com filename contendo um diretório como
menus do sistema, enquanto que menus cujo filename não contem um diretório
são menus do usuário.

What steps will reproduce the problem?
1. Remover o diretório .gebr
2. Ao entrar ne DéBR deixar o campo editor de textos vazio
3. Tentar editar o help de um menu

A DéBR simplesmente termina a execução sem nenhum aviso. Ela deveria emitir
uma mensagem de erro e retornar ao quadro de dialogo.

Nas janelas de about da GêBR e DéBR, implementadas na libgebr, é exibido um
link para a página do projeto. Este link deveria ser "clicável". Para isso
é necessário definir a ação a ser tomada (abertura do browser). Porém o
browser é definido pelas preferências do usuário da GêBR e DéBR.

A DéBR tem um validador sintático para menus. Seria interessante se o
usuário, após validar um fluxo, pudesse solicitar que os erros detectados
fossem automaticamente corrigidos, quando possível. Alguns erros possíveis
de serem corrigidos são:
- Frases de descrição e rótulos iniciando sempre em maiúsculas,
- Eliminação de espaços no final de strings,
- Eliminação de pontuação no final de frases e rótulos.

Criei um menu que apenas executa o comando set da bash. Rodei um fluxo com
apenas este menu, na ilhagrande e tudo certo. Quando fui executar este
fluxo numa máquina com ubuntu 8.10, obtive um segfault.

Vale restacar que na máquina com ubuntu a saída do set relativamente grande
(5164 linhas), enquanto que na máquina debian são apenas 61 linhas.

O backtrace do erro é:
#0  0x00007fad60cc26b0 in strlen () from /lib/libc.so.6
#1  0x00007fad60c8b44e in vfprintf () from /lib/libc.so.6
#2  0x00007fad60d3f330 in __vasprintf_chk () from /lib/libc.so.6
#3  0x00007fad61ff2dab in g_vasprintf () from /usr/lib/libglib-2.0.so.0
#4  0x00007fad61fdf5f0 in g_strdup_vprintf () from /usr/lib/libglib-2.0.so.0
#5  0x000000000040d2cb in gebr_message (type=LOG_DEBUG, in_statusbar=1, 
    in_log_file=1, message=0x0) at gebr.c:432
#6  0x00007fad6196cabb in comm_server_log_message (comm_server=0x1c85460, 
    type=LOG_DEBUG, message=<value optimized out>) at server.c:274
#7  0x00007fad6196d793 in comm_server_read (
    stream_socket=<value optimized out>, comm_server=0x1c85460) at server.c:560
#8  0x00007fad6245a25d in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#9  0x00007fad6246ff5d in ?? () from /usr/lib/libgobject-2.0.so.0
#10 0x00007fad62471608 in g_signal_emit_valist ()
   from /usr/lib/libgobject-2.0.so.0
#11 0x00007fad62471b33 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#12 0x00007fad6196a282 in __g_socket_read (source=<value optimized out>, 
    condition=<value optimized out>, socket=0x1c58640) at gsocket.c:143
#13 0x00007fad61fbdd3b in g_main_context_dispatch ()
   from /usr/lib/libglib-2.0.so.0
#14 0x00007fad61fc150d in ?? () from /usr/lib/libglib-2.0.so.0
#15 0x00007fad61fc1a3d in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#16 0x00007fad643647a7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#17 0x000000000040af75 in main (argc=1, argv=0x7fff6ca3c168, 
    env=<value optimized out>) at main.c:80

Depois deste erro, para conseguir reabrir a gebr é necessário matar a gebrd.

Em anexo está a saída esperada do set na máquina ubuntu.

Na aba Parâmetro da DéBR (versão 0.9.13) ao entrar na opção de criar um
novo parâmetro se o botão cancel for clicado o programa se comporta como se
o botão de Ok tivesse sido clicado, criando um novo parâmetro. É possível
que esse comportamento se repita em outros quadros de dialogo.

Creio que isso esta relacionado com o problema descrito no issue 19.