Estoy de acuerdo aquí. Especialmente porque el cuadro de diálogo de confirmación funciona efectivamente como el "estado de git" en la interfaz gráfica de usuario.

¿Qué espera para estos escenarios:

Pasos 0:

1. En el formulario principal (Examinar), haga clic en el botón "Confirmar", se abre el cuadro de diálogo de confirmación.
2. Minimice el cuadro de diálogo de confirmación y cambie el enfoque de nuevo a la ventana principal.
3. Haga clic en el botón "Confirmar" nuevamente.
   P: ¿Debería aparecer un cuadro de diálogo existente o debería crearse una nueva copia del cuadro de diálogo?

Pasos 1:

1. En el formulario principal (Examinar), haga clic en el botón "Confirmar", se abre el cuadro de diálogo de confirmación.
2. Vuelva a poner el foco en la ventana principal y ciérrela.
   P: ¿Debería cerrarse también el cuadro de diálogo de confirmación?

Pasos 2:

1. En el formulario principal (Examinar), haga clic en el botón "Confirmar", se abre el cuadro de diálogo de confirmación.
2. Cambie el enfoque de nuevo a la ventana principal y tenga en cuenta que la nueva confirmación aún no existe.
3. Cambie el enfoque al cuadro de diálogo de confirmación y confirme parte de los archivos (o parte de las líneas modificadas), se creó una nueva confirmación, pero el diálogo de confirmación aún está abierto.
4. Volver a la ventana principal.
   P: ¿El gráfico del historial de confirmaciones ya debería contener la nueva confirmación?

1. Diálogo existente
2. Cerrar cuadro de diálogo
3. El cuadro de diálogo de confirmación debe cerrarse después de la confirmación y el historial debe mostrar una nueva confirmación

Esta es mi opinión, de todos modos.

0: Diálogo existente

1: Cerrar cuadro de diálogo

2: el gráfico debe contener una nueva confirmación, el diálogo de confirmación debe cerrarse según la opción elegida (como está ahora)

También me gustaría apoyar esta solicitud. No parece natural que tenga que cerrar el cuadro de diálogo de confirmación solo para acceder al historial para copiar un mensaje de confirmación, por ejemplo.

Altamente apreciado.

También hay otro problema. ¿Qué debe hacer GitExtensions cuando el cuadro de diálogo Confirmar está abierto y el usuario cambiará el directorio de trabajo?
a) Cerrar diálogo de confirmación
b) Mantenga el cuadro de diálogo abierto y actualice su contenido.
c) Mantener el cuadro de diálogo abierto y trabajar con el repositorio anterior.
d) No permitir cambiar el directorio de trabajo cuando hay diálogos abiertos.
e) Otra idea.

Espero "c", pero en el botón "Confirmar", haga clic en repetir y se debe abrir una nueva instancia de diálogo. Una instancia de diálogo por repositorio (por lo que si vuelve a cambiar el directorio de trabajo, la primera instancia se usará nuevamente en lugar de abrir la tercera instancia).

c) Mantener el cuadro de diálogo abierto y trabajar con el repositorio anterior.

Y proporcione una "actualización de cambios locales", representada en el árbol de archivos de cambios a la izquierda (sin preparar). Esta situación ya es posible en el estado actual y no se ve afectada por la modalidad del diálogo. Sin embargo, debe quedar claro que los cambios locales no se realizarán desde GitExt.
Creo que cambiar la rama o el compromiso actual (es decir, el índice) - "duro" no sería aceptable; el directorio de trabajo debe permanecer intacto; tiene un uso limitado en este momento, pero no veo ninguna razón por la que esto no sea posible.

Alternativamente, "Confirmar a... (sucursal|confirmar)".

Recientemente hice ViewPullRequestForm sin modelo. Cuando hago clic en FormBrowse, responde, pero permanece detrás de ViewPullRequestForm. ¿Alguien sabe alguna configuración para mostrar FormBrowse delante de ViewPullRequestForm después de activar FormBrowse?

Puede eliminar el parámetro principal de la llamada Show()/ShowDialog() para ViewPullRequestForm.

Lo intenté pero no ayuda.

Creo que el comportamiento actual del formulario no modal no es intuitivo desde el punto de vista del usuario porque la aplicación se cierra al cerrar la ventana principal.

Creo que tenemos varias opciones:

• Intente corregir el problema en la implementación actual.
• Cada vez que se ejecuta una nueva instancia de aplicación
• Cambie todas las ventanas sin modo FormBorderStyle a FixedToolWindow/SizableToolWindow para que los usuarios al menos puedan esperar este comportamiento

A menudo me tropiezo con esto. Hago pequeñas confirmaciones regulares y así mantengo la ventana de confirmación.

Esto sigue pasando:

1) cometer algo
2) Minimizar ventana
3) continuar
4) Vuelva a la ventana principal de Git Extensions e intente hacer clic en cosas
5) Frustrarse cuando solo parpadea y hace un ruido de error
6) Me doy cuenta de que hay una pequeña ventana modal minimizada en el extremo izquierdo de mi pantalla.

Hágalo no modal o elimine la capacidad de minimizar. Voto por la primera opción.

Puede preparar y quitar la preparación y luego cerrar el cuadro de diálogo de confirmación y traerlo
copia de seguridad en cualquier momento.

El jueves 18 de julio de 2013 a las 11:14 a. m., Drew Noakes [email protected] escribió:

A menudo me tropiezo con esto. Hago pequeños compromisos regulares y así sigo
la ventana de compromiso sobre.

Esto sigue pasando:

1) cometer algo
2) Minimizar ventana
3) continuar
4) Vuelva a la ventana principal de Git Extensions e intente hacer clic en cosas
5) Frustrarse cuando solo parpadea y hace un ruido de error
6) Date cuenta de que hay una pequeña ventana modal minimizada en el extremo izquierdo
de mi pantalla

Hágalo no modal o elimine la capacidad de minimizar. yo voto
por la primera opción.

—
Responda a este correo electrónico directamente o véalo en Gi tHubhttps://github.com/gitextensions/gitextensions/issues/564#issuecomment -21190625
.

_Jay Asbury_
Reparación de PC y programas personalizados $30/hr 1hr min
Mi blog de ciclismo http://vbjaybiking.blogspot.com

@vbjay , lo sé, así no es como estoy acostumbrado a trabajar con ventanas de confirmación :) Paso la mayor parte de mi tiempo en Linux con otras herramientas que funcionan de la manera que espero. Feliz de que los autores decidan qué es lo mejor. Solo mi +1 para variar.

Otra molestia del diálogo de confirmación modal es que trae la ventana principal hacia adelante cuando se enfoca.

Por ejemplo, si acopla la ventana principal a la izquierda, luego abre el cuadro de diálogo de confirmación y lo acopla a la derecha, luego abre un IDE acoplado a la izquierda y enfoca el cuadro de diálogo de confirmación, la ventana principal oculta el IDE. Terminas teniendo que hacer malabarismos con las ventanas un poco para conseguirlo como quieres.

Recientemente me di cuenta de que básicamente solo uso la ventana de confirmación, y me encantaría iniciarla de forma independiente. Realmente me gusta la capacidad de enviar parches con el mouse (en lugar de interactuar en la consola), pero todas las demás cosas de git se sienten más cómodas en la línea de comandos.

Con esto en mente, mis respuestas a las tres preguntas planteadas por @vcpp son:

1. Reutilice la ventana de confirmación en función del repositorio (me gustaría tener varias ventanas de confirmación abiertas para diferentes proyectos).
2. Deje la ventana de confirmación abierta
3. La confirmación en la ventana secundaria notifica a la ventana principal de la nueva confirmación, por lo que la actualización se produce de inmediato

Parece que hay acuerdo entre @NJAldwin , @jbialobr y yo (los tres encuestados) en todo menos en el segundo punto, y eso podría controlarse con una opción en este menú desplegable existente:

Hay una discusión interesante en el sitio de UX Stack Exchange:

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

Parece que se reduce a si usa la ventana de confirmación durante un período breve o si la deja abierta. Una herramienta como Git Extensions encaja en los variados flujos de trabajo de los desarrolladores. Solo en este tema, siento que fue diseñado para alguien con un flujo de trabajo diferente al mío. Como anécdota, esta opinión la comparten los demás desarrolladores de mi equipo.

Recientemente, se agregó una consola al control de pestañas en el panel inferior de la ventana principal. ¿Por qué no se puede agregar la ventana de confirmación como una pestaña allí también?

Esto me parece una gran solución.

Aquí hay una maqueta. Los títulos de las pestañas tendrían que cambiar. Tal vez la segunda pestaña "Confirmar" se convierta en "Cambios".

Todavía puede mantener la ventana de compromiso existente para los usuarios a los que les gusta eso. Al menos desde una perspectiva visual, el control podría reutilizarse (menos las opciones sobre cerrar el diálogo al confirmar, etc.).

Esto me parece una gran solución.

¡Es realmente una gran idea! La mayoría de las veces cambio al cuadro de diálogo Examinar solo para abrir el cuadro de diálogo Confirmar.

El único problema que vería con él es la desaceleración de la interfaz de usuario. eso es mucho
funcionalidad en un solo formulario. Tal vez no actualice el control hasta el
La pestaña está activa.

El lunes 20 de marzo de 2017 a las 13:36 Janusz Białobrzewski <
[email protected]> escribió:

Esto me parece una gran solución.

¡Es realmente una gran idea! La mayoría de las veces cambio al cuadro de diálogo Examinar
solo para abrir el cuadro de diálogo Confirmar.

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/gitextensions/gitextensions/issues/564#issuecomment-287837834 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/ADdhsWU1-9kllO-8sYbi61lIS_owCqH0ks5rnrkcgaJpZM4AdCWc
.

Cargar la interfaz de usuario de forma perezosa parece razonable (aunque no estoy familiarizado con el código).

Creo que si queremos integrar FormCommit al formulario principal, entonces deberíamos mover las pestañas "Consola", "Commit..." en la ventana completa

@KindDragon que parece lógicamente consistente ya que ninguno de ellos depende de la confirmación seleccionada en el gráfico.

Las desventajas son perder más espacio vertical y aumentar la cantidad de movimientos y clics del mouse necesarios para navegar por la interfaz de usuario. A menudo, una interfaz de usuario es más amigable/natural para el usuario, incluso cuando es menos lógica para el programador.

Si fuera a introducir pestañas en la parte superior, personalmente preferiría que fueran para repositorios para poder rastrear múltiples repositorios en una ventana. Ese no es el enfoque de este problema, pero vale la pena considerar usos alternativos para un control de pestañas de nivel superior antes de hacerlo.

Un flujo de trabajo que sería mejor si el formulario de confirmación estuviera debajo del gráfico es el de crear confirmaciones de reparación. Todo lo que necesita sería visible en la pantalla. Estoy seguro de que los dos elementos de la interfaz de usuario más vistos son el gráfico y la ventana de confirmación. Hacer commit modal hace que sea difícil usar estos dos juntos. Ponerlos en pestañas lo hace más fácil, pero tener ambos visibles al mismo tiempo es (en mi opinión) lo último.

Si fuera a introducir pestañas en la parte superior, personalmente preferiría que fueran para repositorios para poder rastrear múltiples repositorios en una ventana.

Estoy pensando en pestañas en la parte inferior.

Moverse entre la barra de pestañas en la parte inferior, las pestañas en el medio y la barra de herramientas/menú en la parte superior es mucha actividad del mouse para navegar a donde necesita ir. Tener una barra en la parte superior y una barra en el medio es mejor que tener tres barras, en mi opinión. Las pestañas colocadas debajo de sus paneles no son tan comunes en las interfaces de usuario.

Tal vez una columna de pestañas (Graph, Commit, Console) en el lado izquierdo de la ventana, alineada con la parte superior. Eso mantendría todo junto.

Considere usar un marco de acoplamiento para que los usuarios puedan configurar el diseño a su gusto. No creo que sea posible complacer a todos con un solo diseño. Nuevamente, me gusta ver el gráfico mientras me comprometo.

En realidad no me gusta la propuesta... Para mí significaría cambiar constantemente el tamaño de los paneles (los divisores).

Quizás se podría lograr una mejor UX con ventanas acopladas como en VS (consulte https://github.com/gitextensions/gitextensions/issues/3679).
Pero (siempre tiene que haber uno) no funcionará para usuarios que no sean de Windows...

¿Tal vez sería posible una solución de acoplamiento "pobres" en la que el usuario pudiera seleccionar un diseño de un conjunto predefinido de diseños acoplados o desacoplados? ¿Puede ser difícil encontrar un marco que admita el acoplamiento para todos?

Agregué algunos problemas relacionados:

4033

4031

Sugerencias en el n.º 4031 que deberían estar relacionadas con el "compromiso sin modelo" similar a la maqueta de @drewnoakes
Estoy de acuerdo hasta cierto punto con @RussKie y creo que la confirmación básica no debe tener modelo, pero la confirmación "completa" se puede realizar en la ventana emergente.

• La pestaña Confirmar está actualmente oculta. Debería tener información similar a la pestaña de confirmación para HEAD, excepto que no hay hash de confirmación y ese mensaje de confirmación es "WIP actual" (lo que se ha agregado preliminarmente).

• Mejora: texto de confirmación editable. Incluso si solo es posible confirmar desde el cuadro de diálogo emergente, simplificará la escritura del mensaje de confirmación.

• Mejora: Botones de confirmación similares a la ventana emergente Confirmar

• Pestaña Diff, menú contextual de vista de archivo para preparar/quitar y restablecer archivos

  • ¿Debería funcionar hacer doble clic en un archivo como en Examinar (Historial de archivos) o preparar/quitar preparación como en Confirmar?

• Mejora: Pestaña separada para que Commit/Diff se pueda ver simultáneamente

  • ¿Suficiente con mover la ventana de confirmación?

¿Qué piensa de la idea de tener un diálogo de confirmación "acoplable" en la parte inferior del gráfico de confirmación (como la maqueta de @drewnoakes ) y el atajo de teclado acoplar/desacoplar podría ser el mismo (o configurable) que abrir el diálogo en primer lugar?
Supongamos que abre el cuadro de diálogo completo con ctrl+espacio pero lo quiere más pequeño, ctrl+espacio de nuevo y está acoplado. Y al revés si el último estado de diálogo estaba acoplado.

@drewnoakes , ¿tienes un prototipo funcional? Me encantaría empezar a usar esto HOY :D

Empecé a implementar usando la pestaña CommitInfo a principios de año, pero básicamente duplicó todo el código en FormCommit para que la solución no fuera divertida desde la perspectiva del mantenimiento y la descarté.

¿Alguna idea sobre dejar este cuadro de diálogo como modal pero con una opción para acoplarlo/desacoplarlo?

Nunca lo usé. Tiene licencia del MIT. https://github.com/dockpanelsuite/dockpanelsuite

Cerrando esto a favor de #5535.

En mi opinión personal, hubiera sido mejor implementar esto, de todos modos, hay una solución, al menos en Windows, que es abrir la carpeta en el explorador de archivos, hacer clic derecho y seleccionar "GitExt Commit...", esto se abrirá el cuadro de diálogo de confirmación de forma independiente a cualquier otra ventana de Git Extensions abierta.