Revisão Menu de Classificação (Dev)
Closed this issue · 14 comments
-
Ao tentar carregar um conjunto de regras pelo botão importar externo ele não encontra o arquivo (o filtro está .setups, deveria ser .setup)
-
Ao clicar no botão de "+" ele está dando uma série de warnings "None é um valor inválido para o atributo densamente_edificada". Isso ocorre com diversos atributos, não consegui entender o motivo.
-
Ao reclassificar não aparece os combo box para mapa de valores.
-
Ao clicar em editar a configuração atual do arquivo os checkbox de editável e ignorar não funcionam. Percebi que se trocar de botão e retornar para ele os checkbox passam a funcionar.
-
Na extração de feições, se mudar o valor do formulário ao adquirir a feição é duplicada.
-
Para campos booleanos o formulário aparece como entrada de texto também.
Melhorias de uso:
- Para todos os usuários que passei eles pensaram que ao clicar na ordem dos botões iria mostrar as configurações daquele botão, permitindo edita-las. Porém não é esse o comportamento.
- Com a interface atual é ruim ordenar os botões pois não consegue visualizar em que aba cada botão está.
Integração com o SAP:
Seria interessante ter um processing que tenha o input de multiplos arquivos de configuração de botões, e ele carrega esse menu configurado com tais arquivos.
Também era interessante um input booleano para definir se o menu pode ter as configurações editáveis ou não.
- Ao tentar carregar um conjunto de regras pelo botão importar externo ele não encontra o arquivo (o filtro está .setups, > deveria ser .setup)
Era pra ser ".setups" mesmo. Aqui ele salva o conjunto de perfis de botão que estão carregados na ferramenta, além de salvar o estado de interface (aba, botão selecionado, modo de funcionamento, etc).
O ".setup" é somente a configuração de um único conjunto de botões, de modo que este só é importado/exportado na janela de configuração de perfis de botões.
- Ao clicar no botão de "+" ele está dando uma série de warnings "None é um valor inválido para o atributo > densamente_edificada". Isso ocorre com diversos atributos, não consegui entender o motivo.
Vou tentar dar uma olhada. Faz um tempinho que não mexo nessa ferramenta, mas me lembro de ter algo como ter um alerta no caso de se carregar um conjunto de botões em que os atributos, quando configurados, não estão respeitando o conjunto de regras da camada carregada atualmente no canvas.
- Ao reclassificar não aparece os combo box para mapa de valores.
Achei que tinha resolvido isso. Vou dar uma olhada / colocar para revisão.
- Ao clicar em editar a configuração atual do arquivo os checkbox de editável e ignorar não funcionam. Percebi que se trocar de botão e retornar para ele os checkbox passam a funcionar.
Lembro de ter encontrado este problema e ter resolvido anteriormente. Vou colocar para revisão também.
- Na extração de feições, se mudar o valor do formulário ao adquirir a feição é duplicada.
Estranho que isso também testamos à época. Também vai para a revisão.
- Para campos booleanos o formulário aparece como entrada de texto também.
Ok.
Melhorias de uso:
- Para todos os usuários que passei eles pensaram que ao clicar na ordem dos botões iria mostrar as configurações daquele botão, permitindo edita-las. Porém não é esse o comportamento.
Não lembro o motivo de não ser mediante um único clique, mas se der duplo clique no número da linha do botão, ele é carregado para edição.
- Com a interface atual é ruim ordenar os botões pois não consegue visualizar em que aba cada botão está.
De fato não há como se visualizar os grupos. Teria que aumentar a complexidade da interface, talvez reutilizado o widget de tabs usado na interface principal da ferramenta pudéssemos resolver isto. Porém, ainda haveria o problema de ordenamento quando os botões estão fora das guias de grupo (imagine que o usuário fez uma busca em que todos os botões aparecem, por exemplo).
Como algo que minimiza isto, a ordem dos botões é independente de grupo, de modo que a ordem é sempre a mesma, independente de onde sejam apresentados.
Integração com o SAP:
Seria interessante ter um processing que tenha o input de multiplos arquivos de configuração de botões, e ele carrega esse menu configurado com tais arquivos.
Também era interessante um input booleano para definir se o menu pode ter as configurações editáveis ou não.
Pode ser.
A princípio, tinha o issue de gerenciamento de estado (#216 ), que introduz o componente stateManager, cuja função é centralizar o gerenciamento de estado das ferramentas do DSGTools.
Esse componente serviria de "entrypoint" para chamadas externas e ele é capaz de alterar o estado das ferramentas do DSGTools. Sendo assim, pode oferecer a modificação de estado por chamada de API direta.
O algoritmo do processing poderia ser um processo que seja um wrapper para este componente.
Outro problema quando tenta editar o menu com camadas raster no projeto.
Parece só ocorrer depois de carregar a camada raster depois de configurar o menu.
Traceback (most recent call last): File "C:/Users/diniz/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\DsgTools\gui\ProductionTools\Toolboxes\CustomFeatureToolBox\customFeatureTool.py", line 502, in editCurrentSetup dlg = ButtonSetupWidget() File "C:/Users/diniz/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\DsgTools\gui\CustomWidgets\BasicInterfaceWidgets\buttonSetupWidget.py", line 58, in __init__ self.setupUi(self) File "", line 136, in setupUi File "C:/Users/diniz/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\DsgTools\gui\CustomWidgets\BasicInterfaceWidgets\buttonPropWidget.py", line 75, in __init__ self.updateFieldTable() File "C:/Users/diniz/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\DsgTools\gui\CustomWidgets\BasicInterfaceWidgets\buttonPropWidget.py", line 524, in updateFieldTable fields = layer.fields() AttributeError: 'QgsRasterLayer' object has no attribute 'fields'
Era pra ser ".setups" mesmo. Aqui ele salva o conjunto de perfis de botão que estão carregados na ferramenta, além de salvar o estado de interface (aba, botão selecionado, modo de funcionamento, etc).
O ".setup" é somente a configuração de um único conjunto de botões, de modo que este só é importado/exportado na janela de configuração de perfis de botões.
Não parece ter uma utilidade em salvar aba, botão selecionado e modo de funcionamento, mas agora entendi a ideia.
Dando o feedback é bem contra intuitivo para o usuário.
Não lembro o motivo de não ser mediante um único clique, mas se der duplo clique no número da linha do botão, ele é carregado para edição.
O usuário nunca ia achar isso. Ele nunca daria duplo clique, e se desse ia ser no botão em si, não ali no início.
Clique único ali no número da linha também não resolve.
Pode ser.
A princípio, tinha o issue de gerenciamento de estado (#216 ), que introduz o componente
stateManager, cuja função é centralizar o gerenciamento de estado das ferramentas do DSGTools.Esse componente serviria de "entrypoint" para chamadas externas e ele é capaz de alterar o estado das ferramentas do DSGTools. Sendo assim, pode oferecer a modificação de estado por chamada de API direta.
O algoritmo do processing poderia ser um processo que seja um wrapper para este componente.
Qualquer solução está ótima, não precisa ser um processing.
Só precisa que o Ferramentas de Produção seja capaz de passar o conteúdo de várias configurações de menu, e bloquear a capacidade do usuário alterar as configurações do menu.
@dinizime, juntando as observações em itens "acionáveis" para ficar mais fácil de acompanhar o que deve ser feito e o progresso da resolução do issue, enxergo isto:
- editar configurações de botões, após adicionar camadas raster no canvas, gera erros;
- extensão do arquivo de estado / conjunto de configurações de botões está contraintuitivo e mal documentado (era para constar na documentação da ferramenta - manual);
- reclassificação de feições não oferece mapeamento de atributos pelos domínios;
- campos do tipo
boolnão possuem o seu widget associado (QCheckBox) - ao editar uma configuração de botões as opções de campo editável / ignorado ficam desabilitadas (trocar o botão retorna ao normal);
- feições duplicadas ao se alterar o atributo de uma feição adquirida usando a ferramenta de classificação;
- na interface de configuração de botões, os widgets ficam "cortados", tendo-se que aumentar a altura das células para que apareçam completamente;
- ao se iniciar uma nova configuração de botões, várias mensagens relativas ao atributo de uma das camadas são levantadas (~"value None is not valid");
- reclassificar feições gera erros quando está sob o modo "todas as camadas" e há uma camada raster carregada;
- (sugestão) adicionar controle de exposição de botões de edição de perfis de botões via API;
- (sugestão) pesquisa por botões dinâmica (e.g. à medida que se digita, já se filtra os botões);
- (sugestão) alterar a forma de interação entre o botão selecionado na tabela de ordenamento e o painel de edição de suas configurações; e
- (sugestão) exibir os grupos dos botões no ordenamento de alguma forma.
O principal problema é a duplicação de feição (a gente parou o uso da ferramenta devido a isso)
Ah, sim. Adicionei lá. Falta testar com Windows, mas em Linux e Unix MacOS não consegui reproduzir.
extensão do arquivo de estado / conjunto de configurações de botões está contraintuitivo e mal documentado (era para constar na documentação da ferramenta - manual);
Minha opinião poderia remover a funcionalidade.
Ferramenta de uso geral assim acredito que necessitar uma documentação para entender o que está acontecendo já é um fator negativo.
Não consigo ver uma utilidade para salvar o .setups, em vez de simplesmente importar um .setup.
@dinizime, considerando o que tínhamos conversado, marquei a parte de duplicação como resolvida.
Hoje terminei a solução pra importação de múltiplos setups. Como não vejo como funcionalidade vital, resolvi só remover a opção. Caso exista algum issue solicitando a (re)introdução da importação/exportação em lote via interface, coloco novamente. A chamada via API foi mantida e será mais prática com a introdução do stateManager.
Adicionei a funcionalidade de controlar a exibição de botões de edição dos setups por API (a ferramenta agora tem um método chamado hideToolEditButton), cuja assinatura é:
def hideToolEditButton(self, hide: bool) -> None:
"""
This method allows all button setups edition calls from buttons on the
GUI to be hidden from (or displayed to) the user. This allows the tool
state to be handled exclusively by API calls from external services,
such as SAP.
:param hide: (bool) whether buttons should be hidden from the GUI.
"""O único ponto sem solução é a sugestão de expor o grupo dos botões, que não consegui desenhar uma solução trivial que envolvesse um mínimo de modificações de interface. Como era sugestão, acho que, por enquanto, resolveria este issue.
As soluções estão no dev_#559. Fico no aguardo para finalização do issue.
Quanto a expor o grupo de botões pode botar no nome entre parenteses, para pelo menos ter algum indicativo. O que poderia ser feito para complementar é ter um combobox com as categorias, e ao selecionar uma categoria filtrar os botões.
Além disso tem os erros que mencionei contigo. Era interessante um teste de produção aí no 2ºCGEO, que aí facilita o feedback de melhorias dessa ferramenta.
@dinizime, submeti um commit por agora que introduz o nome dos grupos na frente do botão na tabela de ordenamento (dentro da interface de configuração dos perfis de botão, somente).
Acho que seja o caso de, futuramente, revisitar esta implementação e repensar como apresentar o ordenamento.
Testado, está ok.
@dinizime, a duplicação ocorre quando o QGIS não está em inglês por conta de uma comparação com o texto do comando de alteração de atributo.
Essa não é a melhor forma de comparar (principalmente por conta da internacionalização e da possibilidade de alterações simples no texto), mas não achei, por enquanto, outra forma de identificar os comandos que alteram os atributos. Assim, a solução dada, embora não seja a mais adequada, é comparar com as possíveis traduções também (o que significa que, para traduções não inclusas no código, o problema persistirá).
Para o nosso contexto de trabalho, creio que resolve. Em uma solução mais definitiva, é interessante removermos a comparação com textos de interface.
@jpesperidiao alterei a comparação com o texto do comando de alteração de atributo para ignorar a capitalização do texto do comando, uma vez que em pt-br o texto retornado é todo em minúsculas ("atributos modificados") e estava sendo verificado com a primeira maiúscula ("Atributos modificados").
@pedro-mar beleza, valeu. Essa era uma das coisas que eu temia que acontecessem. O texto foi copiado direto do arquivo de tradução da pasta do QGIS, então tem diferença de capitalização das palavras de acordo com a versão do QGIS. Agora é ficar atento e identificar possíveis variações.
Vou encerrar novamente o issue. Acredito que com a modificação que você fez, não haverá problemas entre as versões que variarem apenas a capitalização.