Eu concordo aqui. Especialmente porque a caixa de diálogo de confirmação funciona efetivamente como o "status do git" no gui.

O que você espera para esses cenários:

Etapas 0:

1. No formulário principal (Procurar), clique no botão "Commit", a caixa de diálogo de commit é aberta.
2. Minimize a caixa de diálogo de confirmação e mude o foco de volta para a janela principal.
3. Clique no botão "Commit" novamente.
   P: a caixa de diálogo existente deve aparecer ou uma nova cópia da caixa de diálogo deve ser criada?

Etapas 1:

1. No formulário principal (Procurar), clique no botão "Commit", a caixa de diálogo de commit é aberta.
2. Mude o foco de volta para a janela principal e feche-a.
   P: a caixa de diálogo de confirmação também deve ser fechada?

Etapas 2:

1. No formulário principal (Procurar), clique no botão "Commit", a caixa de diálogo de commit é aberta.
2. Mude o foco de volta para a janela principal e observe que o novo commit ainda não existe.
3. Mude o foco para a caixa de diálogo de confirmação e confirme parte dos arquivos (ou parte das linhas alteradas), uma nova confirmação foi criada, mas a caixa de diálogo de confirmação ainda está aberta.
4. Retorne à janela principal.
   P: O gráfico do histórico de commits já deve conter o novo commit?

1. Caixa de diálogo existente
2. Fechar caixa de diálogo
3. A caixa de diálogo de confirmação deve fechar após a confirmação e o histórico deve mostrar uma nova confirmação

Esta é a minha opinião, de qualquer maneira.

0: caixa de diálogo existente

1: Fechar caixa de diálogo

2: o gráfico deve conter um novo commit, a caixa de diálogo de commit deve ser fechada dependendo da opção escolhida (como está agora)

Eu também gostaria de apoiar este pedido. Não parece natural que eu tenha que fechar a caixa de diálogo de confirmação apenas para acessar o histórico para copiar uma mensagem de confirmação, por exemplo.

Muito apreciado.

Há também outro problema. O que GitExtensions deve fazer quando a caixa de diálogo Commit é aberta e o usuário altera o diretório de trabalho?
a) Fechar caixa de diálogo de confirmação
b) Mantenha a caixa de diálogo aberta e atualize seu conteúdo.
c) Mantenha a caixa de diálogo aberta e trabalhe com o repositório anterior.
d) Não permita alterar o diretório de trabalho, quando houver diálogos abertos.
e) Outra ideia.

Eu espero “c”, mas no botão “Commit” repita clique em nova instância de diálogo deve ser aberta. Uma instância de diálogo por repositório (portanto, se você alterar o diretório de trabalho de volta, a primeira instância será usada novamente em vez de abrir a terceira instância).

c) Mantenha a caixa de diálogo aberta e trabalhe com o repositório anterior.

E forneça uma "atualização de alterações locais", representada na árvore de arquivos de alterações à esquerda (não preparada). Esta situação já é possível no estado atual e não é afetada pela modalidade do diálogo. No entanto, deve ficar claro que as alterações locais não devem ser feitas a partir do GitExt.
Eu acho que mudar o branch ou commit atual (ou seja, o índice) - "hard" não seria aceitável; o diretório de trabalho deve permanecer intocado - tem uso limitado neste momento, mas não vejo nenhuma razão para que isso não seja possível.

Alternativamente, "Commit to ... (branch|commit)".

Eu fiz recentemente ViewPullRequestForm sem janela restrita. Quando clico em FormBrowse, ele responde, mas fica atrás de ViewPullRequestForm. Alguém conhece alguma configuração para mostrar FormBrowse na frente de ViewPullRequestForm após FormBrowse ser ativado?

Você pode remover o parâmetro pai da chamada Show()/ShowDialog() para ViewPullRequestForm.

Eu tentei mas não ajuda.

Eu acho que o comportamento atual do formulário sem janela restrita não é intuitivo do ponto de vista do usuário porque o aplicativo sai ao fechar a janela principal.

Acho que temos várias opções:

• Tente corrigir o problema na implementação atual
• Cada vez que executa uma nova instância do aplicativo
• Altere todas as janelas sem janela restrita FormBorderStyle para FixedToolWindow/SizableToolWindow para que os usuários possam pelo menos esperar esse comportamento

Muitas vezes me engasgo com isso. Eu faço pequenos commits regulares e então mantenho a janela de commit.

Isso continua acontecendo:

1) Cometa algo
2) Minimizar janela
3) Continue
4) Volte para a janela principal do Git Extensions e tente clicar em coisas
5) Fique frustrado quando apenas pisca e faz um ruído de erro
6) Perceba que há uma pequena janela modal minimizada na extremidade esquerda da minha tela

Por favor, torne-o não modal ou remova a capacidade de minimizar. Eu voto na primeira opção.

Você pode preparar e desmontar e depois fechar a caixa de diálogo de confirmação e trazê-la
backup a qualquer momento.

Em quinta-feira, 18 de julho de 2013 às 11h14, Drew Noakes [email protected] escreveu :

Muitas vezes me engasgo com isso. Eu faço pequenos commits regulares e assim mantenho
a janela de commit sobre.

Isso continua acontecendo:

1) Cometa algo
2) Minimizar janela
3) Continue
4) Volte para a janela principal do Git Extensions e tente clicar em coisas
5) Fique frustrado quando apenas pisca e faz um ruído de erro
6) Perceba que há uma pequena janela modal minimizada na extrema esquerda
da minha tela

Por favor, torne-o não modal ou remova a capacidade de minimizar. eu voto
para a primeira opção.

—
Responda a este e-mail diretamente ou visualize-o no Gi tHubhttps://github.com/gitextions/gitextions/issues/564#issuecomment -21190625
.

_Jay Asbury_
Reparo de PC e programas personalizados $ 30/hr 1hr min
Meu blog de ciclismo http://vbjaybiking.blogspot.com

@vbjay , eu sei, não é assim que estou acostumado a trabalhar com janelas de commit :) Passo a maior parte do meu tempo no Linux com outras ferramentas que funcionam da maneira que eu espero. Feliz para os autores decidirem o que é melhor. Apenas meu +1 para variar.

Outro incômodo da caixa de diálogo de confirmação modal é que ela traz a janela principal para frente quando focada.

Por exemplo, se você encaixar a janela principal à esquerda, abrir a caixa de diálogo de confirmação e acoplá-la à direita, abrir um IDE encaixado à esquerda e focar a caixa de diálogo de confirmação, a janela principal obscureceu o IDE. Você acaba tendo que fazer malabarismos com as janelas para ficar do jeito que você quer.

Percebi recentemente que basicamente só uso a janela de confirmação e ficaria feliz em iniciá-la de forma independente. Eu realmente gosto da capacidade de enviar patches com o mouse (em vez de interativamente no console), mas todas as outras coisas do git parecem mais confortáveis ​​na linha de comando.

Com isso em mente, minhas respostas para as três perguntas feitas por @vcpp são:

1. Reutilize a janela de confirmação em uma base de repositório (eu gostaria de ter várias janelas de confirmação abertas para diferentes projetos).
2. Deixe a janela de confirmação aberta
3. O commit na janela filho notifica a janela principal do novo commit, então a atualização ocorre imediatamente

Parece que há acordo entre @NJAldwin , @jbialobr e eu (os três entrevistados) em tudo, exceto no segundo ponto, e isso poderia ser controlado por uma opção neste menu suspenso existente:

Há uma discussão interessante no site UX Stack Exchange:

http://ux.stackexchange.com/questions/39778/benefits-and-drawbacks-of-modal-windows

Parece que você deve usar a janela de confirmação por um curto período ou deixá-la aberta. Uma ferramenta como o Git Extensions se encaixa nos variados fluxos de trabalho dos desenvolvedores. Só neste assunto, sinto que foi projetado para alguém com um fluxo de trabalho diferente do meu. Curiosamente, essa visão é compartilhada pelos outros desenvolvedores da minha equipe.

Recentemente, um console foi adicionado ao controle de guias no painel inferior da janela principal. Por que a janela de confirmação não pôde ser adicionada como uma guia lá também?

Isso me parece uma ótima solução.

Aqui está uma maquete. Os títulos das guias precisariam ser alterados. Talvez a segunda guia "Commit" se torne "Changes".

Você ainda pode manter a janela de confirmação existente para usuários que cresceram para gostar disso. Pelo menos de uma perspectiva visual, o controle pode ser reutilizado (menos as opções sobre fechar a caixa de diálogo no commit, etc).

Isso me parece uma ótima solução.

É mesmo uma ótima ideia! Na maioria das vezes, mudo para a caixa de diálogo Browse apenas para abrir a caixa de diálogo Commit.

O único problema que eu veria com ele é a desaceleração da interface do usuário. Isso é muito
funcionalidade rolada em um formulário. Talvez não atualize o controle até o
guia está ativa.

Em seg, 20 de março de 2017 às 13h36 Janusz Białobrzewski <
[email protected]> escreveu:

Isso me parece uma ótima solução.

É mesmo uma ótima ideia! Na maioria das vezes, mudo para a caixa de diálogo Procurar
apenas para abrir a caixa de diálogo Commit.

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/gitextions/gitextions/issues/564#issuecomment-287837834 ,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/ADdhsWU1-9kllO-8sYbi61lIS_owCqH0ks5rnrkcgaJpZM4AdCWc
.

Carregar a interface do usuário preguiçosamente parece razoável (embora não esteja familiarizado com o código).

Acho que se quisermos integrar o FormCommit ao formulário principal, devemos mover as guias "Console", "Commit..." na janela inteira

@KindDragon que parece logicamente consistente, pois nenhum deles depende do commit selecionado no gráfico.

As desvantagens são perder mais espaço vertical e aumentar a quantidade de movimentos e cliques do mouse necessários para navegar pela interface do usuário. Muitas vezes, uma interface do usuário é mais amigável/natural para o usuário, mesmo quando é menos lógica para o programador.

Se você fosse introduzir guias no topo, eu pessoalmente preferiria que fossem para repositórios para que eu pudesse rastrear vários repositórios em uma janela. Esse não é o foco deste problema, mas vale a pena considerar usos alternativos para um controle de guia de nível superior antes de fazê-lo.

Um fluxo de trabalho que seria melhor se o formulário de commit estivesse abaixo do gráfico é o de criar commits de correção. Tudo o que você precisa estaria visível na tela. Tenho certeza de que os dois elementos de interface do usuário mais vistos são o gráfico e a janela de confirmação. Tornar o modal de confirmação dificulta o uso desses dois juntos. Colocá-los em guias facilita, mas tê-los visíveis ao mesmo tempo é (na minha opinião) o máximo.

Se você fosse introduzir guias no topo, eu pessoalmente preferiria que fossem para repositórios para que eu pudesse rastrear vários repositórios em uma janela.

Estou pensando em guias na parte inferior.

Mover-se entre a barra de guias na parte inferior, as guias no meio e a barra de ferramentas/menu na parte superior exige muita atividade do mouse para navegar para onde você precisa ir. Ter uma barra no topo e uma barra no meio é melhor do que ter três barras, IMO. As guias colocadas abaixo de seus painéis não são tão comuns em interfaces de usuário.

Talvez uma coluna de guias (Graph, Commit, Console) no lado esquerdo da janela, alinhada ao topo. Isso manteria tudo junto.

Considere usar uma estrutura de encaixe para que os usuários possam configurar o layout de acordo com eles. Acho que não é possível agradar a todos com um único layout. Mais uma vez, gosto de ver o gráfico enquanto me comprometo.

Na verdade não gosto da proposta... Para mim significaria redimensionar constantemente os painéis (os divisores).

Talvez um UX melhor possa ser alcançado com janelas encaixadas como no VS (consulte https://github.com/gitextions/gitextions/issues/3679).
Mas (sempre tem que haver um) não funcionará para usuários que não são do Windows ....

Talvez uma solução de encaixe "pobre homem" onde o usuário pudesse selecionar um layout de um conjunto predefinido de layouts encaixados ou desencaixados seria possível? Encontrar uma estrutura que dê suporte ao encaixe para todos pode ser difícil?

Eu adicionei alguns problemas relacionados:

4033

4031

Sugestões em #4031 que devem estar relacionadas ao "commit sem modelo" semelhante ao mockup de @drewnoakes
Concordo até certo ponto com @RussKie e acredito que o commit básico deve ser sem janela restrita, mas o commit "completo" pode ser feito no pop-up

• A guia de confirmação está oculta no momento. Deve ter informações semelhantes à guia de confirmação para HEAD, exceto que não há hash de confirmação e essa mensagem de confirmação é "WIP atual" (o que foi adicionado preliminarmente).

• Melhoria: texto de confirmação editável. Mesmo que só seja possível enviar a partir da caixa de diálogo pop-up, isso simplificará a escrita da mensagem de confirmação.

• Aprimoramento: botões de confirmação semelhantes ao pop-up de confirmação

• Aba Diff, menu de contexto de visualização de arquivo para preparar/desmontar e redefinir arquivos

  • O clique duplo em um arquivo deve funcionar como em Procurar (Histórico de arquivos) ou preparar/desfazer o estágio como em Confirmar?

• Aprimoramento: guia separada para que o Commit/Diff possa ser visto simultaneamente

  • Suficiente para mover a janela de confirmação?

O que você acha de uma ideia de ter a caixa de diálogo de confirmação "encaixável" na parte inferior do gráfico de confirmação (como a maquete @drewnoakes ) e o atalho de teclado encaixar/desencaixar poderia ser o mesmo (ou configurável) que abrir a caixa de diálogo em primeiro lugar.
Digamos que você abra a caixa de diálogo completa com ctrl + espaço, mas queira menor, ctrl + espaço novamente e está encaixado. E o inverso se o último estado de diálogo estiver encaixado.

@drewnoakes você tem um protótipo funcional? Eu adoraria começar a usar isso HOJE :D

Comecei a implementar usando a aba CommitInfo no início do ano, mas basicamente duplicou todo o código no FormCommit para que a solução não fosse divertida do ponto de vista da manutenção e eu a abandonei.

Alguma ideia de deixar esta caixa de diálogo como um modal, mas com a opção de encaixar/desencaixar?

Nunca usei. É licenciado pelo MIT. https://github.com/dockpanelsuite/dockpanelsuite

Fechando isso em favor de #5535.

Na minha opinião pessoal, teria sido melhor implementar isso, de qualquer forma, existe uma solução alternativa, pelo menos no Windows, que é abrir a pasta no explorador de arquivos, clique com o botão direito e selecione "GitExt Commit...", isso abrirá a caixa de diálogo de confirmação independentemente de qualquer outra janela do Git Extensions aberta.