Resumo do problema
O framework de geoprocessamento é uma das maiores forças do ArcGIS Pro, e desenvolvedores terceiros são corretamente direcionados a ele: uma ferramenta construída como script tool ou Python toolbox obtém histórico de geoprocessamento, configurações de ambiente, relatório de progresso e mensagens, modo batch, composabilidade com ModelBuilder, e arcpy scripting — um ecossistema que nenhum diálogo personalizado poderia reconstruir.
Mas esse ecossistema vem com exatamente uma interface de usuário: o painel de geoprocessamento auto-gerado. Não há nenhuma forma suportada para uma ferramenta de terceiros apresentar qualquer outra UI enquanto permanece uma ferramenta real de geoprocessamento. Para ferramentas simples, o painel gerado é suficiente. Para fluxos de trabalho interativos e ricos em feedback, ele é severamente limitante, e os desenvolvedores enfrentam um dilema desnecessário:
- Permanecer como ferramenta GP e aceitar os limites do painel gerado (sem widgets personalizados, sem pré-visualizações ao vivo, controle limitado de layout e uma longa lista de peculiaridades no comportamento da validação), ou
- Construir um dockpane/janela personalizada com a UI exatamente certa — e perder completamente o histórico de geoprocessamento, ambientes, ModelBuilder, batch e scripting.
Os próprios fluxos interativos principais da Esri demonstram o problema: o Suitability Modeler, o image Classification Wizard e Georeferencing são todos painéis personalizados, não diálogos gerados de geoprocessamento. Quando a interação rica importa, a Esri contorna o painel GP. Desenvolvedores terceiros não têm forma suportada para fazer o mesmo sem abandonar o framework de geoprocessamento.
Melhoria solicitada
Desacoplar a UI da ferramenta da própria ferramenta. Dois níveis, cada um deles seria um grande avanço:
Nível 1 — diálogos personalizados para ferramentas (o pedido completo). Permitir que um add-in registre um diálogo/painel WPF como a UI do Pro para uma ferramenta específica de geoprocessamento (script tool, .pyt, ou .atbx). A ferramenta permanece uma ferramenta GP de primeira classe em todos os outros aspectos:
- O diálogo personalizado coleta e valida parâmetros, depois entrega um array padrão de parâmetros para o pipeline normal de execução GP — assim a execução é registrada no histórico de geoprocessamento, respeita configurações de ambiente, reporta progresso/mensagens e carimba metadados exatamente como hoje.
- Contextos que não podem hospedar o diálogo personalizado — ModelBuilder, modo batch, execuções agendadas, publicação em servidor,
arcpy — automaticamente retornam ao painel auto-gerado e aos objetos de parâmetro existentes. Nada quebra. - Se nenhum diálogo personalizado for registrado, o comportamento é exatamente o atual (totalmente compatível com versões anteriores).
Nível 2 — controles personalizados para parâmetros (um pedido menor mas ainda transformador). Permitir que um desenvolvedor registre um controle WPF personalizado para um parâmetro individual (ou um tipo de dado personalizado), hospedado dentro do painel gerado. Mesmo isso eliminaria a maior parte da dor: uma tabela de valores poderia se tornar uma grade real com feedback ao vivo; um parâmetro remap poderia mostrar um histograma do raster de entrada; um limiar poderia mostrar quais células ele seleciona.
Por que isso importa
Python toolboxes personalizadas são uma via de extensibilidade de primeira classe para ArcGIS Pro, e organizações e terceiros constroem suítes sérias e comerciais baseadas nelas. A qualidade do que o usuário vê é limitada não pelo esforço do desenvolvedor mas pelo painel gerado. Desenvolvedores que se preocupam com a experiência do usuário são pressionados a abandonar o framework de geoprocessamento — perdendo proveniência, reprodutibilidade e scriptabilidade, as próprias coisas que tornam as ferramentas Pro confiáveis. Um ponto suportado de extensibilidade da UI acabaria com essa troca, elevaria o padrão de qualidade de todo o ecossistema terceiro e não custaria nada em compatibilidade retroativa.
