Gitextensions: جعل حوار الالتزام غير مشروط

تم إنشاؤها على ١٧ أغسطس ٢٠١١  ·  36تعليقات  ·  مصدر: gitextensions/gitextensions

لا يعد مربع حوار الالتزام المشروط بديهيًا ، خاصة عند تصغيره.

user experience discussion feature request

التعليق الأكثر فائدة

كثيرا ما أتعثر في هذا. أقوم بإلتزامات صغيرة منتظمة ، لذا حافظ على نافذة الالتزام.

يستمر هذا في الحدوث:

1) ارتكب شيئًا
2) تصغير النافذة
3) استمر
4) ارجع إلى نافذة Git Extensions الرئيسية وحاول النقر فوق العناصر
5) تشعر بالإحباط عندما يومض فقط ويصدر ضوضاء خطأ
6) أدرك أن هناك نافذة صغيرة مصغرة في أسفل الشاشة في أقصى يسار شاشتي

يرجى إما جعلها غير مشروطة أو إزالة القدرة على التصغير. أنا أصوت للخيار السابق.

ال 36 كومينتر

أوافق هنا. خاصة وأن مربع حوار الالتزام يعمل بشكل فعال كـ "حالة git" في واجهة المستخدم الرسومية.

ماذا تتوقع من هذه السيناريوهات:

الخطوات 0:

  1. في النموذج الرئيسي (تصفح) انقر فوق الزر "تنفيذ" ، يتم فتح مربع حوار الالتزام.
  2. تصغير مربع حوار الالتزام وعودة التركيز إلى النافذة الرئيسية.
  3. انقر فوق الزر "تنفيذ" مرة أخرى.
    س: هل يجب أن يظهر مربع حوار موجود أم يجب إنشاء نسخة جديدة من مربع الحوار؟

الخطوات 1:

  1. في النموذج الرئيسي (تصفح) انقر فوق الزر "تنفيذ" ، يتم فتح مربع حوار الالتزام.
  2. قم بتبديل التركيز مرة أخرى إلى النافذة الرئيسية وأغلقها.
    س: هل يجب إغلاق مربع حوار الالتزام أيضًا؟

الخطوات 2:

  1. في النموذج الرئيسي (تصفح) انقر فوق الزر "تنفيذ" ، يتم فتح مربع حوار الالتزام.
  2. قم بتبديل التركيز مرة أخرى إلى النافذة الرئيسية ولاحظ أن الالتزام الجديد غير موجود بعد.
  3. قم بتبديل التركيز إلى حوار الالتزام وتنفيذ جزء من الملفات (أو جزء من الأسطر التي تم تغييرها) ، تم إنشاء التزام جديد ، لكن حوار الالتزام لا يزال مفتوحًا.
  4. العودة إلى النافذة الرئيسية.
    س: هل يجب أن يحتوي الرسم البياني للتاريخ السابق على الالتزام الجديد؟
  1. مربع حوار موجود
  2. إغلاق الحوار
  3. يجب إغلاق مربع حوار الالتزام بعد الالتزام ، ويجب أن يُظهر السجل التزامًا جديدًا

هذا رأيي على أي حال.

0: مربع حوار موجود

1: إغلاق الحوار

2: يجب أن يحتوي الرسم البياني على التزام جديد ، ويجب إغلاق مربع حوار الالتزام بناءً على الخيار المختار (كما هو الحال الآن)

أود أيضًا أن أؤيد هذا الطلب. من غير الطبيعي أن أقوم بإغلاق مربع حوار الالتزام فقط للوصول إلى السجل لنسخ رسالة الالتزام على سبيل المثال.

في غاية الإمتنان.

هناك أيضا مشكلة أخرى. ما الذي يجب أن تفعله GitExtensions عندما يكون مربع حوار Commit مفتوحًا وسيغير المستخدم مسار العمل؟
أ) إغلاق حوار الالتزام
ب) حافظ على الحوار مفتوحًا وقم بتحديث محتواه.
ج) حافظ على الحوار مفتوحًا واعمل مع الريبو السابق.
د) لا تسمح بتغيير عمل دير ، عندما تكون هناك حوارات مفتوحة.
هـ) فكرة أخرى.

أتوقع "c" ، ولكن على الزر "تنفيذ" ، كرر النقر فوق يجب فتح مثيل مربع حوار جديد. مثيل حوار واحد لكل ريبو (لذلك إذا قمت بتغيير dir العامل مرة أخرى ، فسيتم استخدام المثيل الأول مرة أخرى بدلاً من فتح مثيل ثالث).

ج) حافظ على الحوار مفتوحًا واعمل مع الريبو السابق.

وتقدم "تحديث التغييرات المحلية" ، ممثلة في ملف شجرة التغييرات على اليسار (غير مرحلي). هذا الوضع ممكن بالفعل في الوضع الحالي ولا يتأثر بطريقة الحوار. ومع ذلك ، يجب أن يكون واضحًا أن التغييرات المحلية لن يتم إجراؤها من GitExt.
أعتقد أن تغيير الفرع أو الالتزام الحالي (أي الفهرس) - "صعب" لن يكون مقبولاً ؛ يجب أن يظل دليل العمل كما هو - له استخدام محدود في هذه المرحلة ولكني لا أرى أي سبب لعدم إمكانية ذلك.

بدلاً من ذلك ، "الالتزام بـ ... (الفرع | الالتزام)".

لقد قمت مؤخرًا بعمل ViewPullRequestForm غير مشروط. عندما أنقر على FormBrowse فإنه يستجيب ، لكنه يظل خلف ViewPullRequestForm. هل يعرف أي شخص أي إعداد لإظهار FormBrowse أمام ViewPullRequestForm بعد تنشيط FormBrowse؟

يمكنك إزالة المعلمة الأصل من استدعاء Show () / ShowDialog () لـ ViewPullRequestForm.

حاولت لكن ذلك لم يساعد.

أعتقد أن سلوك النموذج الحالي غير المشروط ليس بديهيًا من وجهة نظر المستخدم لأن التطبيق يخرج عند إغلاق النافذة الرئيسية.

أعتقد أن لدينا عدة خيارات:

  • حاول تصحيح المشكلة في التنفيذ الحالي
  • في كل مرة قم بتشغيل مثيل التطبيق الجديد
  • قم بتغيير كافة الإطارات غير الملائمة FormBorderStyle إلى FixedToolWindow / SizableToolWindow بحيث يمكن للمستخدمين توقع هذا السلوك على الأقل

كثيرا ما أتعثر في هذا. أقوم بإلتزامات صغيرة منتظمة ، لذا حافظ على نافذة الالتزام.

يستمر هذا في الحدوث:

1) ارتكب شيئًا
2) تصغير النافذة
3) استمر
4) ارجع إلى نافذة Git Extensions الرئيسية وحاول النقر فوق العناصر
5) تشعر بالإحباط عندما يومض فقط ويصدر ضوضاء خطأ
6) أدرك أن هناك نافذة صغيرة مصغرة في أسفل الشاشة في أقصى يسار شاشتي

يرجى إما جعلها غير مشروطة أو إزالة القدرة على التصغير. أنا أصوت للخيار السابق.

يمكنك تنظيم وإلغاء المرحلة ثم إغلاق مربع حوار الالتزام وإحضاره
النسخ الاحتياطي في أي وقت.

يوم الخميس ، 18 يوليو 2013 الساعة 11:14 صباحًا ، Drew Noakes [email protected]

كثيرا ما أتعثر في هذا. أقوم بإلتزامات صغيرة منتظمة وهكذا استمر
نافذة الالتزام حول.

يستمر هذا في الحدوث:

1) ارتكب شيئًا
2) تصغير النافذة
3) استمر
4) ارجع إلى نافذة Git Extensions الرئيسية وحاول النقر فوق العناصر
5) تشعر بالإحباط عندما يومض فقط ويصدر ضوضاء خطأ
6) أدرك أن هناك نافذة نموذجية صغيرة جدًا أسفل في أقصى اليسار
من شاشتي

يرجى إما جعلها غير مشروطة أو إزالة القدرة على التصغير. انا اصوت
للخيار السابق.

-
قم بالرد على هذه الرسالة الإلكترونية مباشرة أو اعرضها على Gi tHubhttps: //github.com/gitextensions/gitextensions/issues/564#issuecomment -21190625
.

_جاي اسبري _
إصلاح أجهزة الكمبيوتر والبرامج المخصصة 30 دولارًا / ساعة 1 ساعة دقيقة
مدونة ركوب الدراجات الخاصة بي http://vbjaybiking.blogspot.com

vbjay ، أعلم أن هذه ليست الطريقة التي اعتدت على العمل مع نوافذ الالتزام فقط :) أقضي معظم وقتي في Linux باستخدام أدوات أخرى تعمل بالطريقة التي أتوقعها. يسعد المؤلفون أن يقرروا ما هو الأفضل. فقط +1 للتغيير.

مصدر إزعاج آخر لمربع حوار الالتزام المشروط هو أنه يجلب النافذة الرئيسية إلى الأمام عند التركيز.

على سبيل المثال ، إذا قمت بإرساء النافذة الرئيسية على اليسار ، ثم فتحت مربع حوار الالتزام وقم بإرسائه على اليمين ، ثم تفتح IDE مثبتًا على اليسار وتركز على مربع حوار الالتزام ، فإن النافذة الرئيسية تحجب IDE. ينتهي بك الأمر إلى التوفيق بين النوافذ قليلاً للحصول عليها بالطريقة التي تريدها.

لقد أدركت مؤخرًا أنني أستخدم نافذة الالتزام بشكل أساسي فقط ، وسيسعدني إطلاقها بشكل مستقل. أحب حقًا القدرة على تثبيت التصحيحات بالماوس (بدلاً من التفاعل على وحدة التحكم) ، لكن جميع عناصر git الأخرى تشعر براحة أكبر في سطر الأوامر.

مع وضع ذلك في الاعتبار ، فإن إجاباتي على الأسئلة الثلاثة التي طرحها vcpp هي:

  1. أعد استخدام نافذة الالتزام على أساس المستودع (أرغب في فتح العديد من نوافذ الالتزام لمشاريع مختلفة).
  2. اترك نافذة الالتزام مفتوحة
  3. يؤدي الالتزام في النافذة الفرعية إلى إخطار النافذة الرئيسية بالتزام جديد ، لذلك يحدث التحديث على الفور

يبدو أن هناك اتفاقًا بين NJAldwin و jbialobr وأنا (المستجيبين الثلاثة) على كل شيء باستثناء النقطة الثانية ، ويمكن التحكم في ذلك من خلال خيار في هذه القائمة المنسدلة الحالية:

image

هناك بعض المناقشات الشيقة على موقع UX Stack Exchange:

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

يبدو أن الأمر يتعلق بما إذا كنت تستخدم نافذة الالتزام لفترة قصيرة ، أو ما إذا كنت ستتركها مفتوحة. تتناسب أداة مثل Git Extensions مع مطوري مهام سير العمل المتنوعين. في هذه المشكلة وحدها ، أشعر أنها مصممة لشخص لديه سير عمل مختلف عن سير العمل الخاص بي. وفقًا للروايات المتناقلة ، يتم مشاركة هذا العرض من قبل المطورين الآخرين في فريقي.

في الآونة الأخيرة ، تمت إضافة وحدة تحكم إلى عنصر التحكم في علامة التبويب في الجزء السفلي من النافذة الرئيسية. لماذا لا يمكن إضافة نافذة الالتزام كعلامة تبويب هناك أيضًا؟

هذا يبدو وكأنه حل رائع بالنسبة لي.

هنا نموذج بالحجم الطبيعي. عناوين التبويب تحتاج إلى تغيير. ربما تصبح علامة التبويب "الالتزام" الثانية "التغييرات".

image

لا يزال بإمكانك الاحتفاظ بنافذة الالتزام الحالية للمستخدمين الذين أصبحوا معجبين بذلك. على الأقل من منظور مرئي ، يمكن إعادة استخدام عنصر التحكم (باستثناء الخيارات المتعلقة بإغلاق مربع الحوار عند الالتزام ، إلخ).

هذا يبدو وكأنه حل رائع بالنسبة لي.

إنها بالفعل فكرة رائعة! في معظم الأوقات ، أقوم بالتبديل إلى مربع الحوار "استعراض" فقط لفتح مربع حوار "الالتزام".

المشكلة الوحيدة التي قد أراها معها هي تباطؤ واجهة المستخدم. هذا كثير من
وظيفة توالت في شكل واحد. ربما لا يتم تحديث عنصر التحكم حتى ملف
علامة التبويب نشطة.

يوم الإثنين 20 آذار (مارس) 2017 الساعة 1:36 مساءً يانوش بياوبريفسكي <
[email protected]> كتب:

هذا يبدو وكأنه حل رائع بالنسبة لي.

إنها بالفعل فكرة رائعة! في معظم الأحيان أقوم بالتبديل إلى مربع الحوار "استعراض"
فقط لفتح مربع الحوار "الالتزام".

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/gitextensions/gitextensions/issues/564#issuecomment-287837834 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ADdhsWU1-9kllO-8sYbi61lIS_owCqH0ks5rnrkcgaJpZM4AdCWc
.

يبدو أن تحميل واجهة المستخدم بتكاسل معقول (غير مألوف مع الكود).

أعتقد أنه إذا أردنا دمج FormCommit في النموذج الرئيسي ، فعلينا نقل علامات التبويب "Console" و "Commit ..." في النافذة الكاملة

KindDragon الذي يبدو متسقًا منطقيًا حيث لا يعتمد أي منهما على الالتزام المحدد في الرسم البياني.

الجوانب السلبية تفقد المزيد من المساحة الرأسية ، وتزيد من مقدار حركة الماوس والنقر المطلوب للتنقل حول واجهة المستخدم. غالبًا ما تكون واجهة المستخدم أكثر ودية / طبيعية للمستخدم حتى عندما تكون أقل منطقية بالنسبة للمبرمج.

إذا كنت ستقدم علامات تبويب في الجزء العلوي ، فأنا شخصياً أفضل ما إذا كانت مخصصة للمستودعات حتى أتمكن من تتبع مستودعات متعددة في نافذة واحدة. هذا ليس محور هذه المشكلة ، ولكن يجدر التفكير في استخدامات بديلة لعنصر تحكم علامة تبويب من المستوى الأعلى قبل القيام بذلك.

أحد سير العمل الذي سيكون أجمل إذا كان نموذج الالتزام أسفل الرسم البياني هو إنشاء التزامات الإصلاح. سيكون كل ما تحتاجه مرئيًا على الشاشة. أنا متأكد من أن أكثر عنصرين من عناصر واجهة المستخدم يتم النظر إليهما هما الرسم البياني ونافذة الالتزام. يجعل الالتزام المشروط من الصعب استخدام هذين معًا. يجعل وضعها في علامات تبويب الأمر أسهل ، لكن جعلهما مرئيين في نفس الوقت (في رأيي) هو الأفضل.

إذا كنت ستقدم علامات تبويب في الجزء العلوي ، فأنا شخصياً أفضل ما إذا كانت مخصصة للمستودعات حتى أتمكن من تتبع مستودعات متعددة في نافذة واحدة.

أفكر في علامات التبويب في الأسفل.

يعد التنقل بين شريط علامات التبويب في الأسفل وعلامات التبويب في المنتصف وشريط الأدوات / القائمة في الأعلى نشاطًا كبيرًا بالماوس للتنقل حيث تريد الذهاب. وجود شريط واحد في الأعلى وشريط واحد في المنتصف أفضل من وجود ثلاثة أشرطة ، IMO. علامات التبويب الموضوعة أسفل أجزائها ليست شائعة جدًا في واجهات المستخدم.

ربما يكون هناك عمود من علامات التبويب (رسم بياني ، التزام ، وحدة تحكم) على الجانب الأيسر من النافذة ، محاذاة إلى الأعلى. هذا من شأنه أن يبقي كل شيء قريبًا من بعضه البعض.

ضع في اعتبارك استخدام إطار عمل لرسو السفن حتى يتمكن المستخدمون من تكوين التخطيط ليناسبهم. لا أعتقد أنه من الممكن إرضاء الجميع بتصميم واحد. مرة أخرى ، أحب رؤية الرسم البياني أثناء الالتزام.

في الواقع لا يعجبني الاقتراح ... بالنسبة لي ، قد يعني ذلك تغيير حجم الألواح باستمرار (المقسمات).

ربما يمكن تحقيق تجربة مستخدم أفضل من خلال النوافذ الراسية كما هو الحال في VS (راجع https://github.com/gitextensions/gitextensions/issues/3679).
لكن (يجب أن يكون هناك دائمًا واحد) لن يعمل مع المستخدمين الذين لا يستخدمون Windows ....

ربما يكون حل الإرساء "المسكين" حيث يمكن للمستخدم تحديد تخطيط من مجموعة محددة مسبقًا من التخطيطات المرسومة أو غير الراسية ممكنًا؟ قد يكون من الصعب العثور على إطار عمل يدعم الإرساء للجميع؟

لقد أضفت بعض القضايا ذات الصلة:

4033

4031

الاقتراحات في # 4031 التي يجب أن تتعلق بـ "الالتزام غير المشروط" على غرار نموذج بالحجم الطبيعي بواسطةdrewnoakes
أوافق إلى حد ما مع RussKie وأعتقد أن الالتزام الأساسي يجب أن يكون بلا شروط ، ولكن يمكن تنفيذ الالتزام "الكامل" في النافذة المنبثقة

  • علامة التبويب "الالتزام" مخفية حاليًا. يجب أن تحتوي على معلومات مماثلة مثل علامة تبويب الالتزام لـ HEAD ، باستثناء عدم وجود تجزئة الالتزام وأن رسالة الالتزام هي "قيد العمل قيد التنفيذ" (ما تمت إضافته بشكل أولي).

  • التحسين: نص الالتزام القابل للتعديل. حتى إذا كان من الممكن الالتزام من مربع حوار منبثق فقط ، فسيؤدي ذلك إلى تبسيط كتابة رسالة الالتزام.

  • التحسين: تنفيذ الأزرار المشابهة للنافذة المنبثقة Commit

  • علامة التبويب Diff ، قائمة سياق عرض الملف لعرض / إلغاء وضع الملفات وإعادة تعيينها

    • هل يجب النقر نقرًا مزدوجًا فوق ملف يعمل كما هو الحال في استعراض (محفوظات الملفات) أو المرحلة / unstage كما هو الحال في الالتزام؟
  • التحسين: علامة تبويب منفصلة بحيث يمكن رؤية الالتزام / الفرق في وقت واحد

    • هل يكفي تحريك نافذة التنفيذ؟

ما رأيك في فكرة جعل مربع حوار الالتزام "قابل للإرساء" في الجزء السفلي من الرسم البياني للالتزام (مثل drewnoakes mockup ) ويمكن أن يكون اختصار لوحة المفاتيح dock / undock هو نفسه (أو قابل للتهيئة) عند فتح مربع الحوار في المقام الأول.
لنفترض أنك قمت بفتح مربع الحوار الكامل باستخدام ctrl + space ولكنك تريده أصغر ، ثم ctrl + space مرة أخرى وتم إرساؤه. والعكس إذا تم إرساء حالة الحوار الأخير.

drewnoakes هل لديك نموذج أولي يعمل؟ أود أن أبدأ في استخدام هذا اليوم: د

لقد بدأت في التنفيذ باستخدام علامة التبويب CommitInfo في بداية العام ، ولكنها في الأساس قامت بتكرار جميع التعليمات البرمجية في FormCommit بحيث لا يكون هذا الحل ممتعًا من منظور الصيانة وقد أسقطته.

هل لديك أي أفكار حول ترك مربع الحوار هذا باعتباره نموذجًا ولكن مع وجود خيار لإرساءه / إلغاء إرسائه؟

لم تستخدمه من قبل. إنه مرخص من معهد ماساتشوستس للتكنولوجيا. https://github.com/dockpanelsuite/dockpanelsuite

إغلاق هذا لصالح # 5535.

في رأيي الشخصي ، كان من الأفضل تنفيذ هذا ، على أي حال ، هناك حل بديل ، على الأقل في Windows ، وهو فتح مجلد في مستكشف الملفات ، انقر بزر الماوس الأيمن وحدد "GitExt Commit ..." ، وهذا سيفتح مربع حوار الالتزام بشكل مستقل عن أي نافذة ملحقات Git أخرى يتم فتحها.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات