Je suis d'accord ici. D'autant plus que la boîte de dialogue de validation fonctionne effectivement comme le "statut git" dans l'interface graphique.

Qu'attendez-vous de ces scénarios :

Étapes 0 :

1. Dans le formulaire principal (Parcourir), cliquez sur le bouton "Valider", la boîte de dialogue de validation s'ouvre.
2. Réduisez la boîte de dialogue de validation et revenez à la fenêtre principale.
3. Cliquez à nouveau sur le bouton "Valider".
   Q : la boîte de dialogue existante doit-elle apparaître ou une nouvelle copie de la boîte de dialogue doit-elle être créée ?

Étapes 1 :

1. Dans le formulaire principal (Parcourir), cliquez sur le bouton "Valider", la boîte de dialogue de validation s'ouvre.
2. Remettez le focus sur la fenêtre principale et fermez-la.
   Q : la boîte de dialogue de validation doit-elle également être fermée ?

Étapes 2 :

1. Dans le formulaire principal (Parcourir), cliquez sur le bouton "Valider", la boîte de dialogue de validation s'ouvre.
2. Revenez à la fenêtre principale et notez que le nouveau commit n'existe pas encore.
3. Basculez le focus sur la boîte de dialogue de validation et validez une partie des fichiers (ou une partie des lignes modifiées), une nouvelle validation a été créée, mais la boîte de dialogue de validation est toujours ouverte.
4. Retour à la fenêtre principale.
   Q : Le graphique de l'historique des commits doit-il déjà contenir le nouveau commit ?

1. Boîte de dialogue existante
2. Fermer la boîte de dialogue
3. La boîte de dialogue de validation doit se fermer après la validation et l'historique doit afficher une nouvelle validation

C'est mon avis, en tout cas.

0 : Boîte de dialogue existante

1 : Fermer la boîte de dialogue

2: le graphique doit contenir un nouveau commit, la boîte de dialogue de commit doit être fermée en fonction de l'option choisie (comme c'est le cas actuellement)

Je souhaite également soutenir cette demande. Il ne semble pas naturel que je doive fermer la boîte de dialogue de validation uniquement pour accéder à l'historique de copie d'un message de validation, par exemple.

Grandement apprécié.

Il y a aussi un autre problème. Que doit faire GitExtensions lorsque la boîte de dialogue Commit est ouverte et que l'utilisateur change de répertoire de travail ?
a) Fermer la boîte de dialogue de validation
b) Gardez la boîte de dialogue ouverte et actualisez son contenu.
c) Gardez la boîte de dialogue ouverte et travaillez avec le référentiel précédent.
d) Ne pas autoriser le changement de répertoire de travail lorsqu'il y a des boîtes de dialogue ouvertes.
e) Autre idée.

Je m'attends à "c", mais sur le bouton "Valider", cliquez à nouveau sur une nouvelle instance de dialogue doit être ouverte. Une instance de dialogue par dépôt (donc si vous modifiez le répertoire de travail, la première instance sera à nouveau utilisée au lieu d'ouvrir la troisième instance).

c) Gardez la boîte de dialogue ouverte et travaillez avec le référentiel précédent.

Et fournissez une "mise à jour des modifications locales", représentée dans l'arborescence des fichiers de modifications sur la gauche (unstaged). Cette situation est déjà possible dans l'état actuel et n'est pas affectée par la modalité du dialogue. Cependant, il doit être clair que les modifications locales ne doivent pas être effectuées à partir de GitExt.
Je pense que changer la branche ou le commit actuel (c'est-à-dire l'index) - "hard" ne serait pas acceptable; le répertoire de travail doit rester intact - a une utilisation limitée à ce stade, mais je ne vois aucune raison pour laquelle cela ne devrait pas être possible.

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

J'ai récemment rendu ViewPullRequestForm non modal. Lorsque je clique sur FormBrowse, il répond, mais reste derrière ViewPullRequestForm. Est-ce que quelqu'un connaît un paramètre pour afficher FormBrowse devant ViewPullRequestForm après l'activation de FormBrowse?

Vous pouvez supprimer le paramètre parent de l'appel Show()/ShowDialog() pour ViewPullRequestForm.

J'ai essayé mais ça n'aide pas.

Je pense que le comportement actuel du formulaire sans mode n'est pas intuitif du point de vue de l'utilisateur car l'application se ferme lors de la fermeture de la fenêtre principale.

Je pense que nous avons plusieurs options :

• Essayez de corriger le problème dans l'implémentation actuelle
• À chaque fois, exécutez une nouvelle instance d'application
• Remplacez toutes les fenêtres non modales FormBorderStyle par FixedToolWindow/SizableToolWindow afin que les utilisateurs puissent au moins s'attendre à ce comportement

J'ai souvent trébuché là-dessus. Je fais régulièrement de petits commits et je garde donc la fenêtre de commit.

Cela continue à se produire :

1) Commettre quelque chose
2) Réduire la fenêtre
3) Continuez
4) Revenez à la fenêtre principale de Git Extensions et essayez de cliquer sur des éléments
5) Soyez frustré quand il clignote et fait un bruit d'erreur
6) Réalisez qu'il y a une petite fenêtre modale minimisée tout en bas à gauche de mon écran

Veuillez soit le rendre non modal, soit supprimer la possibilité de minimiser. Je vote pour la première option.

Vous pouvez activer et désactiver, puis fermer la boîte de dialogue de validation et l'amener
sauvegarder à tout moment.

Le jeudi 18 juillet 2013 à 11h14, Drew Noakes [email protected] a écrit :

J'ai souvent trébuché là-dessus. Je fais régulièrement de petits commits et je continue donc
la fenêtre de validation à propos.

Cela continue à se produire :

1) Commettre quelque chose
2) Réduire la fenêtre
3) Continuez
4) Revenez à la fenêtre principale de Git Extensions et essayez de cliquer sur des éléments
5) Soyez frustré quand il clignote et fait un bruit d'erreur
6) Réalisez qu'il y a une minuscule fenêtre modale minimisée tout en bas à gauche
de mon écran

Veuillez soit le rendre non modal, soit supprimer la possibilité de minimiser. je vote
pour la première option.

—
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/gitextensions/gitextensions/issues/564#issuecomment -21190625
.

_Jay Asbury_
Réparation de PC et programmes personnalisés 30 $/h 1h min
Mon blog de vélo http://vbjaybiking.blogspot.com

@vbjay , je sais, ce n'est pas seulement comme ça que j'ai l'habitude de travailler avec des fenêtres de validation :) Je passe la plupart de mon temps sous Linux avec d'autres outils qui fonctionnent comme je m'y attends. Heureux pour les auteurs de décider ce qui est le mieux. Juste mon +1 pour changer.

Une autre nuisance de la boîte de dialogue de validation modale est qu'elle fait avancer la fenêtre principale avec elle lorsqu'elle est focalisée.

Par exemple, si vous ancrez la fenêtre principale à gauche, puis ouvrez la boîte de dialogue de validation et l'ancrez à droite, puis que vous ouvrez un IDE ancré à gauche et concentrez la boîte de dialogue de validation, la fenêtre principale obscurcit l'IDE. Vous finissez par devoir jongler un peu avec les fenêtres pour l'obtenir comme vous le souhaitez.

J'ai réalisé récemment que je n'utilisais essentiellement que la fenêtre de validation et que je serais heureux de la lancer de manière autonome. J'aime vraiment la possibilité de valider des correctifs avec la souris (plutôt que de manière interactive sur la console), mais tous les autres trucs de git sont plus confortables sur la ligne de commande.

Dans cet esprit, mes réponses aux trois questions posées par @vcpp sont :

1. Réutilisez la fenêtre de validation sur la base d'un référentiel (j'aimerais avoir plusieurs fenêtres de validation ouvertes pour différents projets).
2. Laissez la fenêtre de validation ouverte
3. La validation dans la fenêtre enfant informe la fenêtre principale de la nouvelle validation, de sorte que la mise à jour se produit immédiatement

Il semble qu'il y ait un accord entre @NJAldwin , @jbialobr et moi-même (les trois répondants) sur tout sauf le deuxième point, et cela pourrait être contrôlé par une option dans cette liste déroulante existante :

Il y a des discussions intéressantes sur le site UX Stack Exchange :

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

Cela semble se résumer à savoir si vous utilisez la fenêtre de validation pour une courte période ou si vous la laissez ouverte. Un outil comme Git Extensions s'intègre dans les workflows variés des développeurs. Sur ce seul problème, j'ai l'impression qu'il a été conçu pour quelqu'un avec un flux de travail différent du mien. Pour l'anecdote, ce point de vue est partagé par les autres développeurs de mon équipe.

Récemment, une console a été ajoutée au contrôle de l'onglet dans le volet inférieur de la fenêtre principale. Pourquoi la fenêtre de validation n'a-t-elle pas pu être ajoutée en tant qu'onglet ici aussi ?

Cela me semble être une excellente solution.

Voici une maquette. Les titres des onglets devraient changer. Peut-être que le deuxième onglet "Valider" devient "Modifications".

Vous pouvez toujours conserver la fenêtre de validation existante pour les utilisateurs qui ont appris à aimer cela. Au moins d'un point de vue visuel, le contrôle pourrait être réutilisé (moins les options de fermeture de la boîte de dialogue lors de la validation, etc.).

Cela me semble être une excellente solution.

C'est effectivement une excellente idée ! La plupart du temps, je passe à la boîte de dialogue Parcourir uniquement pour ouvrir la boîte de dialogue Commit.

Le seul problème que je verrais avec lui est le ralentissement de l'interface utilisateur. C'est beaucoup de
fonctionnalités réunies dans un seul formulaire. Peut-être pas mettre à jour le contrôle jusqu'à ce que le
l'onglet est actif.

Le lun. 20 mars 2017 à 13:36 Janusz Białobrzewski <
[email protected]> a écrit :

Cela me semble être une excellente solution.

C'est effectivement une excellente idée ! La plupart du temps, je passe à la boîte de dialogue Parcourir
uniquement pour ouvrir la boîte de dialogue Commit.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/gitextensions/gitextensions/issues/564#issuecomment-287837834 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ADdhsWU1-9kllO-8sYbi61lIS_owCqH0ks5rnrkcgaJpZM4AdCWc
.

Charger l'interface utilisateur paresseusement semble raisonnable (mais pas familier avec le code).

Je pense que si nous voulons intégrer FormCommit au formulaire principal, nous devrions déplacer les onglets "Console", "Commit..." sur la fenêtre complète

@KindDragon qui semble logiquement cohérent car aucun de ceux-ci ne dépend du commit sélectionné dans le graphique.

Les inconvénients sont la perte d'espace vertical et l'augmentation du nombre de déplacements et de clics de la souris nécessaires pour naviguer dans l'interface utilisateur. Souvent, une interface utilisateur est plus conviviale/naturelle pour l'utilisateur, même si elle est moins logique pour le programmeur.

Si vous deviez introduire des onglets en haut, je préférerais personnellement qu'ils soient destinés aux référentiels afin de pouvoir suivre plusieurs référentiels dans une seule fenêtre. Ce n'est pas l'objet de ce problème, mais il vaut la peine d'envisager d'autres utilisations pour un contrôle d'onglet de niveau supérieur avant de le faire.

Un flux de travail qui serait plus agréable si le formulaire de validation était sous le graphique est celui de la création de validations de correction. Tout ce dont vous auriez besoin serait visible à l'écran. Je suis sûr que les deux éléments de l'interface utilisateur les plus regardés sont le graphique et la fenêtre de validation. Rendre le commit modal rend difficile l'utilisation de ces deux éléments ensemble. Les mettre dans des onglets facilite les choses, mais les avoir tous les deux visibles en même temps est (à mon avis) le nec plus ultra.

Si vous deviez introduire des onglets en haut, je préférerais personnellement qu'ils soient destinés aux référentiels afin de pouvoir suivre plusieurs référentiels dans une seule fenêtre.

Je pense aux onglets en bas.

Se déplacer entre la barre d'onglets en bas, les onglets au milieu et la barre d'outils / menu en haut nécessite beaucoup d'activité de la souris pour naviguer là où vous devez aller. Avoir une barre en haut et une barre au milieu est mieux que d'avoir trois barres, IMO. Les onglets placés sous leurs volets ne sont pas si courants dans les interfaces utilisateur.

Peut-être une colonne d'onglets (Graph, Commit, Console) sur le côté gauche de la fenêtre, alignés vers le haut. Cela garderait tout rapproché.

Envisagez d'utiliser un cadre d'ancrage afin que les utilisateurs puissent configurer la mise en page qui leur convient. Je ne pense pas qu'il soit possible de plaire à tout le monde avec une seule mise en page. Encore une fois, j'aime voir le graphique pendant que je m'engage.

En fait, je n'aime pas la proposition... Pour moi, cela signifierait constamment redimensionner les panneaux (les séparateurs).

Peut-être qu'une meilleure UX pourrait être obtenue avec des fenêtres ancrées comme dans le VS (voir https://github.com/gitextensions/gitextensions/issues/3679).
Mais (il doit toujours y en avoir un), cela ne fonctionnera pas pour les utilisateurs non Windows ....

Peut-être qu'une solution d'ancrage "pauvres" où l'utilisateur pourrait sélectionner une mise en page à partir d'un ensemble prédéfini de mises en page ancrées ou non ancrées serait possible ? Trouver un cadre qui prendra en charge l'amarrage pour tout le monde peut être difficile ?

J'ai ajouté quelques problèmes connexes :

4033

4031

Suggestions dans # 4031 qui devraient être liées au "commit sans mode" similaire à la maquette de @drewnoakes
Je suis dans une certaine mesure d'accord avec @RussKie et je pense que la validation de base devrait être sans mode, mais la validation "complète" pourrait être effectuée dans la fenêtre contextuelle

• L'onglet Commit est actuellement masqué. Devrait avoir des informations similaires à celles de l'onglet de validation pour HEAD, sauf qu'il n'y a pas de hachage de validation et que le message de validation est "actuel WIP" (ce qui a été ajouté de manière préliminaire).

• Amélioration : texte de validation modifiable. Même s'il n'est possible de valider qu'à partir d'une boîte de dialogue contextuelle, cela simplifiera l'écriture du message de validation.

• Amélioration : Boutons de validation similaires à la fenêtre contextuelle Commit

• Onglet Diff, menu contextuel de la vue des fichiers pour mettre en scène/désorganiser et réinitialiser les fichiers

  • Le double-clic sur un fichier doit-il fonctionner comme dans Parcourir (Historique des fichiers) ou préparer/détacher comme dans Valider ?

• Amélioration : onglet séparé pour que Commit/Diff puisse être vu simultanément

  • Suffisant de déplacer la fenêtre de validation ?

Que pensez-vous d'une idée d'avoir une boîte de dialogue de validation "ancrable" au bas du graphique de validation (comme la maquette @drewnoakes ) et le raccourci clavier dock/unock pourrait être le même (ou configurable) que l'ouverture de la boîte de dialogue en premier lieu.
Supposons donc que vous ouvriez la boîte de dialogue complète avec ctrl + espace mais que vous la vouliez plus petite, ctrl + espace à nouveau et qu'elle soit ancrée. Et l'inverse si le dernier état du dialogue était ancré.

@drewnoakes avez-vous un prototype fonctionnel ? J'aimerais commencer à l'utiliser AUJOURD'HUI :D

J'ai commencé à implémenter en utilisant l'onglet CommitInfo au début de l'année, mais il a essentiellement dupliqué tout le code dans FormCommit afin que la solution ne soit pas amusante du point de vue de la maintenance et je l'ai abandonnée.

Avez-vous des idées pour quitter cette boîte de dialogue en tant que modal mais avec une option pour l'ancrer/la détacher ?

Je ne l'ai jamais utilisé. Il est sous licence MIT. https://github.com/dockpanelsuite/dockpanelsuite

Clôturant ceci en faveur de # 5535.

À mon avis, il aurait été préférable d'implémenter cela, de toute façon, il existe une solution de contournement, au moins sous Windows, qui consiste à ouvrir le dossier dans l'explorateur de fichiers, faites un clic droit et sélectionnez "GitExt Commit...", cela ouvrira la boîte de dialogue de validation indépendamment de toute autre fenêtre d'extensions Git ouverte.