لقد كنت في مستوى إحباطك قبل بضع سنوات عندما بدأت في النقل عبر تطبيقات WPF لأول مرة. لذلك أنا بالتأكيد أفهم مشاعرك. كان هناك بعض التقدم منذ ذلك الحين وكما قلت ، فإن فريق WinUI يحاول بالفعل من نهايته.

من وجهة نظري ، هناك مشكلة أساسية في التصميم لا يمكننا حلها: لقد كان WinRT معاقًا تقنيًا لأنه يجب أن يتفاعل مباشرة مع C ++ و JavaScript ( هنا مثال وآخر ). إنها حقًا لا تلعب بشكل جيد مع الكثير من المفاهيم عالية المستوى مثل الأدوية الجنيسة. بالطبع هناك فائدة كبيرة واحدة لهذه البنية أيضًا: يمكن لجميع أنظمة Windows الآن مشاركة نفس WinRT API.

تم إجراء WinRT أيضًا بواسطة فريق Windows تحت إدارة Sinofsky أعتقد أنه يعني ، نعم ، أنهم عاشوا في عالمهم الخاص وليس لديهم خبرة في العمل مع النظام البيئي الحالي لمطور المستخدم النهائي. لقد انتهى بنا الأمر بواجهة برمجة تطبيقات "ذات القاسم المشترك الأقل" والتي لا يستمتع كل من المطورين الأصليين والمُدارين بالعمل معها. هذا هو في الأساس أحد الأسباب الرئيسية وراء وفاة Windows Phone - لم يتمكن المطورون من تطوير / منفذ التطبيقات بسهولة. بدون تطبيقات ، لم يكن هناك عملاء. لقد تعلمت Microsoft هذا الدرس.

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

من الواضح أن WinUI 3.0 هو خطوة في الاتجاه الصحيح لمحاولة إصلاح هذا في الواجهة الأمامية على الأقل. على الرغم من ذلك ، فإنني أفضل أن تنفذ Microsoft عملية تطوير أكثر قوة والمزيد من الاختبارات قبل إصدار عناصر تحكم جديدة ... أعلم أن التطوير يدفع الآن للتغييرات ، ثم الإصلاح لاحقًا. على الرغم من أن هذا قد يعمل مع التطبيقات ، إلا أنه ليس نمطًا جيدًا لمنصة حيث بمجرد تعيين الأشياء يصعب تغييرها لاحقًا. (لدى TreeView و NumberBox وما إلى ذلك ... العديد من المشكلات في الإصدار الأول والتي لن تخرج أبدًا ، ناهيك عن مراحل التخطيط ، منذ 15 عامًا).

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

هل تعتقد أن المستخدمين سيفعلون ما ورد أعلاه بسعادة؟ لا لن يفعلوا ذلك - في الواقع ، 79.8٪ لا يفعلون ذلك (تدعم بيانات AppCenter هذا الأمر). ترك لي مع مستخدمين لا يستخدمون تطبيقي ، أو مجرد جعل تطبيقي يبدو دون المستوى بالنسبة للتطبيقات المحلية الأخرى.

ربما لا تفكر في حقيقة أن المستخدمين يتوقفون بالفعل عن التفكير: "انتظر ، هل أريد حقًا منح هذا التطبيق حق الوصول إلى محرك الأقراص الخاص بي بالكامل؟" هذا تحذير من الضوء الأحمر للأشخاص الذين ليسوا على دراية بالتطبيق / المطور / الشركة.

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

لمعلوماتك ، إذا كنت أرغب في تجربة أحد التطبيقات وبعد التثبيت ، كان الأمر أشبه بـ "مهلا ، أعطني إذنًا للوصول إلى كل شيء ، في كل مكان" ، كنت أقوم بتشغيله أيضًا.

عندما تطلب broadSystemAccess ، فإن التطبيق الخاص بك ، افتراضيًا ، لا يمتلك هذا الوصول.

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

أيضًا ، استنادًا إلى العنوان غير المحترم وحده الذي يخرق مدونة قواعد سلوك Microsoft Open Source ، والمحتوى الذي لا يتعلق بـ WinUI ، يجب إغلاق هذه المشكلة. تضمين التغريدة

آخر شيء تضيفه. أعتقد أن ريتش لاندر قال ذلك بشكل أفضل في 15 يناير. NET Community Standup (بدءًا من 1:12:40).

verelpode أنت تركب الخط المذكور في الفيديو أعلاه ، لكنك تظل بناءًا وموضوعًا في الغالب ، لذلك أقدر مساهماتك في WinUI repo - حتى لو شعرت أنها غير مجدية في بعض الأحيان ، كما رأيت في مؤخرتك تعليقات).

عندما تطلب broadSystemAccess ، فإن التطبيق الخاص بك ، افتراضيًا ، لا يمتلك هذا الوصول.

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

هذه ليست المشكلة: على الأقل في Android / iOS ، يتم سؤالك عن هذه الأشياء بينما يحاول تطبيقك الوصول إلى محرك الأقراص الثابتة ، ولا يتم إغلاقه ، كما هو الحال في حالتنا.

لن يتم إغلاق تطبيقك إذا قدمت منتقي (منتقي) الملفات الذي يسمح للمستخدم باختيار ما يريد منح تطبيقك حق الوصول إليه.

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

أيضًا ، استنادًا إلى العنوان غير المحترم وحده الذي يخرق مدونة قواعد سلوك Microsoft Open Source ، والمحتوى الذي لا يتعلق بـ WinUI ، يجب إغلاق هذه المشكلة. تضمين التغريدة

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

أين يمكن للمجتمع التحدث مع فريق WinRT؟ هل هناك من يستمع؟

لن يتم إغلاق تطبيقك إذا قدمت منتقي (منتقي) الملفات الذي يسمح للمستخدم باختيار ما يريد منح تطبيقك حق الوصول إليه.

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

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

لقد قلت هذا من قبل ، لا يوجد مكان للكتابة عن WinRT.

كما تشير الروابط الخاصة بك ، فقد كنت بالفعل تتحدث عن WinRT في منتديات UWP للأسئلة والأجوبة ، حيث تم توجيهك للذهاب.

لذلك من خلال النشر هنا ، يبدو أنك تريد فقط جمهورًا أكبر ، بدلاً من إنجاز أي شيء فعليًا (نظرًا لأن فريق WinUI لا يعمل على WinRT).

كما تشير الروابط الخاصة بك ، فقد كنت بالفعل تتحدث عن WinRT في منتديات UWP للأسئلة والأجوبة ، حيث تم توجيهك للذهاب.

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

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

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

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

kmgallahan بالتأكيد ، يمكن إرجاع النغمة قليلاً ، لكننا جميعًا شعرنا بالإحباط من قبل. إنه لمن المحبط أكثر أن تعتقد أن المشكلات الواضحة لا تتم معالجتها. أعتقد أنه من البناء أحيانًا التنفيس عن هذه الإحباطات في منتدى حيث يمكن للأشخاص التحقق من صحتها وتقديم حلول محتملة أيضًا. نقاطه الفنية صالحة ، إنها فقط لـ WinRT و UWP قليلاً - كلاهما لا يتحكم WinUI XAML الذي يمثله هذا الريبو. لهذا السبب ، ربما يجب إغلاق هذا باعتباره خارج الموضوع.

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

بالتأكيد ، يمكن إرجاع النغمة قليلاً ، لكننا جميعًا شعرنا بالإحباط من قبل. إنه لمن المحبط أكثر أن تعتقد أن المشكلات الواضحة لا تتم معالجتها.

شكرا :)

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

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

من الواضح أنهم ليسوا في تلك المواقع المحددة ...

بالتأكيد ، يمكنني استخدام FutureAccessList وجعل المستخدمين يتذكرون المكان الذي يحتفظون فيه بصورهم / مقاطع الفيديو الخاصة بهم ، لأننا نعلم جميعًا أين نحتفظ بجميع الصور / مقاطع الفيديو ، أليس كذلك؟

بدلاً من (ما يفعله تطبيقي) معاينة المجلدات بشكل جيد وإظهار المجلدات التي توجد بها صور / مقاطع فيديو لك.

بعض الملاحظات:

شكرًا jtorjo على الوقت الذي الأسئلة والأجوبة أيضًا.

كماrobloo وkmgallahan المذكورة أكثر من هذا لا علاقة مباشرة لWinUI وكنت قد دفع مدونة قواعد السلوك قليلا 🙂

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

على سبيل المثال ، نرى حقًا كل ما يأتي من خلال مركز تقديم الملاحظات ولكن لا توجد طريقة جيدة للرد أو مواصلة المناقشة. لذلك ، طالما أنها تظل بنّاءة ومرتبطة بـ UX / تطوير تطبيق Windows ، فنحن على ما يرام بمناقشة بعض ملاحظات النظام الأساسي العامة هنا إذا كان الموضوع لا يتناسب حاليًا مع أي مكان آخر.

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

لتطوير تطبيقات سطح المكتب: يُعد WinUI 3 جزءًا كبيرًا من جهودنا لفصل النظام الأساسي لمطوري Windows لإزالة حواجز التشغيل البيني وتسهيل اعتماد WinUI و UWP بشكل تدريجي. نحن نعلم أننا بحاجة إلى تمكين تطبيقات سطح المكتب بشكل أفضل باستخدام UX الحديث دون الحاجة إلى جميع القيود الحالية. لدينا الكثير من الخبراء بما في ذلك بعض المبدعين الرئيسيين لـ WPF يعملون عليها.

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

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

WinUI Community Call (22 يناير 2020) # 1857

مرحبًا jesbis ،

شكرا للنظر في قضاياي!

كماrobloo وkmgallahan المذكورة أكثر من هذا لا علاقة مباشرة لWinUI وكنت قد دفع مدونة قواعد السلوك قليلا 🙂

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

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

موافق تماما. كملاحظة جانبية ، لقد حاولت بالفعل الإبلاغ عن broadSystemAccess على Feedback Hub ، وبعد تقديم جميع التفاصيل وقضاء حوالي 15 دقيقة عليها ، انتهى بي الأمر بطريقة ما على الأرجح بالضغط على مفتاح الاختصار الذي كان يعادل "رجوع" - وبالتالي ، لقد فقدت كل عملي (لا يوجد تراجع ، لا يتم نسخ أي نص إلى الحافظة ، لا شيء). من الواضح أنني كنت محبطًا بجنون واستسلمت للتو.

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

رائع!

لتطوير تطبيقات سطح المكتب: يُعد WinUI 3 جزءًا كبيرًا من جهودنا لفصل النظام الأساسي لمطوري Windows لإزالة حواجز التشغيل البيني وتسهيل اعتماد WinUI و UWP بشكل تدريجي. نحن نعلم أننا بحاجة إلى تمكين تطبيقات سطح المكتب بشكل أفضل باستخدام UX الحديث دون الحاجة إلى جميع القيود الحالية. لدينا الكثير من الخبراء بما في ذلك بعض المبدعين الرئيسيين لـ WPF يعملون عليها.

هذا رائع! أنا بالتأكيد أتطلع أكثر إلى ذلك. من المحتمل جدًا أن أقوم بتحديث تطبيقي بمجرد الانتهاء من ذلك ، ولكن حتى ذلك الحين ، أواجه الكثير من المشكلات.

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

WinUI Community Call (22 يناير 2020) # 1857

هل يمكنني اقتراح مواضيع WinRT التي ذكرتها هنا؟

شكرا لك مرة أخرى!

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

تضمين التغريدة
هذه اخبار عظيمه! شكراً جزيلاً لفريق WinUI لإظهار هذه المرونة ومحاولة التخفيف من مشكلات نظام ملاحظات WinRT (المتصورة) على الرغم من أنهم ليسوا مضطرين لذلك!

تضمين التغريدة

أعتقد أن ريتش لاندر قال ذلك بشكل أفضل في 15 يناير. NET Community Standup (بدءًا من 1:12:40).

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

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

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

تضمين التغريدة
إليك أصل المشكلة:

تكرار خطأ نوكيا الكارثي

كرر WinRT / UWP عن طريق الخطأ نفس الخطأ مثل Nokia و BlackBerry و Apple في مرحلة ما وشركات أخرى. قصة نوكيا: كانت نوكيا عملاقًا ناجحًا للغاية ، لكن نوكيا أدركت لاحقًا أنها تأخرت في تكنولوجيا الهواتف الذكية. لحل هذه المشكلة ، احتاجوا إلى جعل تحقيق سلسلة من الإصدارات المحسّنة لنظامهم الموجود مسبقًا أولوية قصوى. بدلاً من القيام بذلك ، حاولوا التحول إلى نظام جديد ، وقتلهم. قتلهم حرفيًا - اضطرت Nokia Mobile إلى قبول شرائها من قبل Microsoft.

لذلك تتوقع أن تتعلم Microsoft من خطأ Nokia ولن تكرر نفس المشكلة. لسوء الحظ ، كررت Microsoft نفس الخطأ مثل Nokia. شرعت Microsoft في استخدام WinRT / UWP بدلاً من إنتاج إصدارات جديدة من WPF و .NET Framework. خمن ماذا جرى؟ نفس كارثة نوكيا: لقد قتلتهم. مات Windows Mobile وتم إلغاؤه من قبل المسؤولين التنفيذيين في Microsoft. وبالتالي ، للأسف ، لم تتعلم Microsoft من خطأ نوكيا الكارثي. الآن جميع الهواتف الذكية تعمل إما بنظام Android أو Apple بدلاً من WinRT / UWP ، وبالتالي كان WinRT / UWP فشلًا كارثيًا تسبب في فقدان Microsoft مكانتها تمامًا في صناعة الهواتف الذكية بمليارات الدولارات. تسبب WinRT / UWP في خسائر تقدر بمليارات الدولارات لشركة Microsoft.

ارتكب BlackBerry نفس الخطأ الذي ارتكبت به Nokia و Microsoft. كان BlackBerry ناجحًا للغاية ، لكن BlackBerry أدرك لاحقًا أنهم قد تأخروا في تكنولوجيا الهواتف الذكية. لحل هذه المشكلة ، احتاجوا إلى جعل تحقيق سلسلة من الإصدارات المحسّنة لنظامهم الموجود مسبقًا أولوية قصوى. بدلاً من القيام بذلك ، حاولوا التبديل إلى نظام جديد. استخدم BlackBerry في الأصل نظام التشغيل BlackBerry OS ، ثم في عام 2013 تقريبًا ، تحولوا إلى نظام QNX. ماذا حدث؟ نفس WinRT و Nokia. قتلهم. في عام 2016 ، أعلنت شركة BlackBerry أنها ستتوقف عن تصميم هواتفها الخاصة.

حدث هذا أيضًا مع Apple في وقت ما في الماضي. كادت شركة آبل أن تنهار وكانت محظوظة للغاية للبقاء على قيد الحياة. بعد عدة سنوات ، حققت Apple في النهاية تعافيًا قويًا عبر الهواتف الذكية. محظوظ لأنك على قيد الحياة بعد الخطأ الكارثي.

كسر التغييرات

تدعي Microsoft أنها لا تستطيع مواصلة تطوير WPF ؛ لا يمكن استخدام WPF للهواتف الذكية / الأجهزة اللوحية بسبب التغييرات المفاجئة ، ولكن هذه حالة من الخوف الشديد من كسر التغييرات. نعم ، من الحكمة توخي الحذر الشديد فيما يتعلق بتعطيل التغييرات ، ولكن إذا تم تجاوزها ، فإنها تقتل المشاريع والشركات. الحقيقة هي أنه يمكن في الواقع إدخال تغييرات جذرية. كان بإمكان Microsoft إصدار "WPF 5" مع دعم الهواتف الذكية / الأجهزة اللوحية / شاشات اللمس ، وأعلنت أنها تتضمن تغييرات عاجلة ولكن لا يوجد مطور مضطر للترقية إليه على الفور. لا تتعطل التطبيقات الموجودة مسبقًا لأنها تستمر في العمل مع WPF 4 حتى يصبح مطور التطبيق مرتاحًا وجاهزًا للتبديل إلى WPF 5. وبالتالي لا تسبب التغييرات العاجلة فوضى أو فشلًا.

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

عكس وجهة النظر في التعليمات البرمجية المدارة

قالت Microsoft إن التعليمات البرمجية المُدارة توفر مزايا ممتازة ، وكان ذلك صحيحًا تمامًا في تجربتي باستخدام التعليمات البرمجية المُدارة وغير المُدارة. بدأت حياتي المهنية في كتابة كود غير مُدار. في وقت لاحق ، اختبرت مطالبات Microsoft وتحولت إلى التعليمات البرمجية المدارة وشهدت تحسينات ممتازة في الإنتاجية والموثوقية. في وقت لاحق ، عكست Microsoft بشكل غريب وجهة نظرها وأنتجت WinRT بأساس على رمز غير مُدار ، ونموذج كائن المكون القديم (COM) من عام 1993 ، والاستخدام المفرط لـ Win16 (المعروف أيضًا باسم Win32). أساس WinRT هو التكنولوجيا التي مضى عليها عقود من الزمن: الكود الأصلي ، COM ، و Win16 AKA Win32. لا ينبغي أن يكون مفاجئًا أن معظم مطوري التطبيقات كانوا مترددين في التبديل إلى WinRT / UWP.

Android هو الآن الرائد في السوق. يمكن لـ Microsoft التعلم من Android. عادةً ما تتم كتابة تطبيقات Android باستخدام رمز مُدار. على الرغم من أنني لا أحب Java وأفضل استخدام C # ، إلا أنني يجب أن أقول إن Java أفضل بكثير من Win16 و COM الأصلي.

لا يزال العديد من موظفي Microsoft يواصلون قول كلمة "أصلي" كما لو كان هذا أمرًا جيدًا. بدأت مسيرتي المهنية مع "مواطن" وأنا أعلم من سنوات الخبرة أن "الأم" شيء سيء. تعرف جحافل من مطوري Android أيضًا أن المحتوى الأصلي أمر سيء ، لكن الكثير من موظفي UWP يقولون إنه رائع. لاستخدام كلمات jtorjo ، كان فريق WinRT ولا يزال "بعيدًا عن الواقع". يواصل فريق WinRT التصرف كما لو أن WinRT كان ناجحًا ، على الرغم من حقيقة أنه فشل بشكل كارثي وأن Windows Mobile قد تم إلغاؤه بالفعل من قبل المديرين التنفيذيين في Microsoft.

يجب أن أكرر هذه الكلمات مرارًا وتكرارًا: لقد كان WinRT / UWP فشلًا ذريعًا. لقد اضطررت إلى الاستمرار في تكرار هذه الكلمات لأن فريق WinRT "بعيد عن الواقع" بمعنى أنهم يرفضون الاعتراف بأن WinRT / UWP كان فشلًا ذريعًا وأن Microsoft يجب ألا تستمر في تكرار نفس الأخطاء WinRT كما لو لم يحدث شيء.

على سبيل المثال ، حاليًا DataGrid مكتوب برمز مُدار حديثًا ، لكن فرق WinUI تريد إعادة كتابة DataGrid لاستخدام كود "أصلي" ويعتقدون أن هذا "ترقية" بينما في الواقع هو الرجوع إلى إصدار أقدم وانحدار إلى الممارسات التي انتهت عقودها. بشكل عام ، يعاني WinRT / UWP من الخلط بين ممارسات هندسة البرمجيات الحديثة والمتقادمة. وبالتالي فإن استخدام jtorjo للكلمات _ "بعيدًا عن الواقع" _ يمكن تفسيره على أنه غير مهذب ، لكنني أعتقد أنه وصف دقيق ، حتى لو لم يكن الخيار الأفضل للكلمات.

للحصول على مثال آخر على _ "بعيدًا عن الواقع" _ ، انظر إلى تصميم WebView2 - إنه مثل أخذ رحلة عبر الزمن إلى بداية مسيرتي المهنية ، منذ عقود ، عندما استخدمنا مفاهيم قديمة مثل HRESULT بدلاً من معالجة الاستثناءات الحديثة. إنه لأمر مدهش أن نرى إطلاق WebView2 كمشروع جديد في عام 2020 ومع ذلك لا يزال يستخدم تقنيات قديمة مثل HRESULT و LPCWSTR . تصميم WebView2 بعيد كل البعد عن ممارسات هندسة البرمجيات الحديثة.

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

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

شرعت Microsoft في استخدام WinRT / UWP بدلاً من إنتاج إصدارات جديدة من WPF و .NET Framework. ...

متفق. لقد قمت بتطوير UWP منذ عدة أشهر حتى الآن ... هناك عدد قليل من القيود ، لكنني بذلت قصارى جهدي لأكون "zen" حيال ذلك ، وأكثر أو أقل ، المضي قدمًا. ولكن كلما عملت أكثر ، أدركت أن القيود كانت في الواقع WinRT ، وليس UWP.

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

1. يحتاج UWP إلى إخفاء حقيقة أنه يستخدم WinRT و
2. يجب أن يسعى WinRT لإزالة أكبر عدد ممكن من القيود (غير الضرورية)
3. يجب أن يكون التركيز الأساسي على سطح المكتب ، ثم الأنظمة الأساسية الأخرى (Hololens و xbox وما إلى ذلك)

(ملاحظة: حقيقة أنه ، للحصول على خصائص الملف ، أحتاج إلى استدعاء وظيفة غير متزامنة ، لا يزال يجعلني أرتعش)

عكس وجهة النظر في التعليمات البرمجية المدارة

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

[تحرير لاحقًا] الآن فكر في الأمر ، فسنحتاج على الأقل إلى COM للتعامل مع DirectX. ومع ذلك ، يجب أن تكون مخفية قدر الإمكان عن مستخدمي المكتبات.

لا يزال العديد من موظفي Microsoft يواصلون قول كلمة "أصلي" كما لو كان هذا أمرًا جيدًا.

Native ، في سياق "التحويل البرمجي إلى .net الأصلي" ، أعتقد أنه أمر جيد ، ومع ذلك ، لا أحب حدوده. فشل مشروعي في التحويل البرمجي إلى .net الأصلي ، لأنه يستخدم lib آخر قمت بنقله إلى UWP ، ويستخدم بعض واجهات برمجة التطبيقات ، التي يعتقد رجال المتجر الأقوياء أنها "غير مقبولة". lib المعني هو https://github.com/naudio/NAudio - مكتبة قوية بذهول. لهذا السبب وحده ، قلت ببساطة - لن أنشر تطبيقي في متجر MS.

للحصول على مثال آخر على _ "بعيدًا عن الواقع" _ ، انظر إلى تصميم WebView2 - إنه مثل أخذ رحلة عبر الزمن إلى بداية مسيرتي المهنية

لست متأكدًا بنسبة 100٪ ، لكنك على الأرجح على حق. أعلم أن WebView يقال إنه غلاف على عنصر تحكم Win32 ، وأنا أعلم بوجود خطأ غريب ، وهو أن روابط WebView لن تعمل عندما يكون WebView أعلى عنصر تحكم آخر.

مرحبا robloo ،

آسف على الرد المتأخر

لقد كنت في مستوى إحباطك قبل بضع سنوات عندما بدأت في النقل عبر تطبيقات WPF لأول مرة. لذلك أنا بالتأكيد أفهم مشاعرك. كان هناك بعض التقدم منذ ذلك الحين وكما قلت ، فإن فريق WinUI يحاول بالفعل من نهايته.

نعم ، أوافق تمامًا. مرة أخرى في 2016-2017 ، لن أتطرق حتى إلى UWP.

من وجهة نظري ، هناك مشكلة أساسية في التصميم لا يمكننا حلها: لقد كان WinRT معاقًا تقنيًا لأنه يجب أن يتفاعل مباشرة مع C ++ و JavaScript ( هنا

هذا أمر محزن ، على أقل تقدير ... لماذا لماذا نريد إمكانية التشغيل البيني لـ JS؟

... هو مثال وآخر ). إنها حقًا لا تلعب بشكل جيد مع الكثير من المفاهيم عالية المستوى مثل الأدوية الجنيسة. بالطبع هناك فائدة كبيرة واحدة لهذه البنية أيضًا: يمكن لجميع أنظمة Windows الآن مشاركة نفس WinRT API.

هناك العديد من الأشياء التي أكرهها بشأن WinRT - ما هي الأشياء الأخرى في القائمة؟

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

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

نعم ، نحن نفعل ...

من الواضح أن WinUI 3.0 هو خطوة في الاتجاه الصحيح لمحاولة إصلاح هذا في الواجهة الأمامية على الأقل. على الرغم من ذلك ، أفضل أن تنفذ Microsoft عملية تطوير أكثر قوة والمزيد من الاختبارات قبل إصدار عناصر تحكم جديدة ... [...]

متفق عليه 100٪.

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

نعم، من الواضح أن هناك شخص رهيبة في MS التي يتم الاستماع. لنأمل أن نتمكن من قلب هذا ...

الاستعلام عن ملفات API أبعد من البطء

على ما يبدو ، وجد شخص ما حلاً لهذا. من الواضح أنه من المحزن حقًا أن هذا استغرق وقتًا طويلاً - وهذه ليست الطريقة المفضلة التي أرغب في التعامل بها مع البحث عن الملفات ، ولكنها على الأقل تعمل بالفعل.
https://github.com/microsoft/microsoft-ui-xaml/issues/1465#issuecomment -575987737

لذا ، شكرًا جزيلاً لـ @ duke7553 !

jtorjo سعيد للمساعدة!

أجد هذه المناقشة ممتعة للغاية وذات صلة وثيقة بمستقبل واجهة مستخدم Windows. هذا لأن WinUI لا يجلس في فراغ. هذا الريبو بأكمله له قيمة قليلة جدًا ما لم يكن مفيدًا في إنشاء تطبيقات تعمل على شيء آخر غير WinRT / UWP. لا يمكن أن يأتي WinUI 3.0 قريبًا بما فيه الكفاية.

لدينا رؤية وخارطة طريق لواجهة المستخدم على النوافذ ، ولكن هذا موجود في أعلى المكدس ولا توجد رؤية لما يوجد تحت تلك الطبقة السطحية:
هل WinUI يبدو جيدًا؟ نعم
هل يمكنك إنشاء تطبيقات حديثة وجيدة المظهر على Windows الآن (JAN2020)؟ لا
هل يمكنك إنشاء تطبيق جيد باستخدام UWP؟ قطعا لا!

لا يمكننا المضي قدمًا حقًا دون مخاطبة الفيل في الغرفة: ذكرت الحقيقة السابقة أن WinRT و UWP كانا إخفاقات كاملة ، ليس فقط من الناحية التجارية ولكن أيضًا من الناحية التكنولوجية. أنا شخصيا من بين الجثث. توقفت عن تطوير مشروع هوايتي عندما لم أستطع معرفة كيفية تشغيل صوت عندما فقد تطبيقي التركيز. تافه. هل يجب أن تكون الأشياء التافهة صعبة كما هي في UWP؟ هل يمكنك وصف النظام الأساسي بأنه رائع عندما تكون الأشياء التافهة صعبة بشكل مستحيل؟ WinUI هو مجرد جزء من منصة ، أليس كذلك؟

فيل آخر في الغرفة. إذا سأل أحدهم: أريد إنشاء برنامج Windows جديد ، فما أفضل طريقة للقيام بذلك؟ لا توجد إجابة مباشرة في يناير 2020! إذا حاولت وضع UWP في الإجابة - فسوف تمر بوقت سيئ. (هل هناك تعليق واحد ، أو مشاركة مدونة ، أو مقطع فيديو على YouTube حيث قال أحدهم: لقد صنعت تطبيقًا رائعًا باستخدام UWP وأعجبتني العملية؟ نعلم جميعًا أنه لا يوجد أي تعليق. لا أحد يكتب عن إنشاء تطبيق باستخدام UWP ، فهو ليس كذلك حرفيًا لا توجد على الإنترنت). WPF؟ لا توجد ضوابط حديثة - تقنية ميتة ، ليست فكرة جيدة (لا تزال أفضل من UWP ، رغم ذلك). الجواب الصادق يجب أن يكون: جرب الإلكترون ، ربما؟ تم إنشاء VSCode مع ذلك ، لذا فأنت تعلم أنه يمكنك إنشاء تطبيق جيد باستخدامه.

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

الشيء navie المذكور سابقا في الخيط؟ أتفق تماما. Visual Studio - يتكون The Juggernaut نفسه (UI) من كود مُدار - WPF. إنه رائع ورائع حتى. بينما حتى Microsoft لا يمكنها إنشاء تطبيقات جيدة باستخدام هذا الرمز الأصلي الخارق المفترض. أرى سلوكًا غير متوقع كل يوم باستخدام OneNote و Weather وحتى Start / Search / Taskbar. إنه شعور متزعزع وأحيانًا لا يعمل التركيز كما ينبغي.

هذا موضوع غني ومهم. وثيق الصلة بـ WinUI ، وللأسف لا يوجد مكان أفضل للحديث عنه. تحتاج Microsoft إلى التعامل مع هذه الموضوعات بطريقة مفتوحة.

لدينا رؤية وخارطة طريق لواجهة المستخدم على النوافذ ، ولكن هذا موجود في أعلى المكدس ولا توجد رؤية لما يوجد تحت تلك الطبقة السطحية:
هل WinUI يبدو جيدًا؟ نعم

نعم إنه كذلك!

هل يمكنك إنشاء تطبيقات حديثة وجيدة المظهر على Windows الآن (JAN2020)؟ لا

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

• على واجهة واجهة المستخدم ، ستكون هناك مشكلات ، ولكن عادةً ما ستتفهمها
• في جبهة "أي شيء آخر" ، تبدو الأمور قاتمة جدًا.
• التعامل مع الملفات على UWP هو جحيم كامل ، بسبب StorageFile / Folder API ، والتي ، في منتصفها ، أكرهها من كل قلبي

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

متفق. في الواقع ، تشغيل أصوات النظام ، والتي تشبه في WPF SystemSounds.Beep.Play() ، فهي غير متوفرة على UWP.

في الأساس ، لا توجد مكتبة صوت على UWP ، نظرًا لقيود WinRT "الرائعة" ، والتي تعني أساسًا - لا يمكنك استيراد أي وظائف من مكتبات DLL التي هي win32. إلى حد كبير ، لا يمكن نقل كل مكتبة لائقة إلى UWP. لا مكتبات ولا تطبيقات.

في "مكتبة الصوت" على UWP ، بذلت naudio قصارى جهدها للعمل على UWP. من الواضح أنها سقطت بشكل مسطح. لقد قمت بعمل شوكة ، وأزلت الكثير من #ifdefs ، وهي تعمل الآن لتلبية احتياجاتي. لن أتمكن أبدًا من نشر تطبيقي على MS Store ، ولا أريد ذلك مطلقًا.

أفضل خطوة في الاتجاه الصحيح ، في رأيي ، هي أن يكون مرض التصلب العصبي المتعدد

1. أخيرًا ركز على سطح مكتب Windows أولاً . توقف عن ملاحقة آلاف المنصات ، مثل Hololens و Xbox وما شابه ذلك. بالتأكيد ، سيكون هناك أشخاص يرغبون في التطوير لتلك المنصات ، لكن النسبة ضئيلة.
2. قم بإزالة جميع قيود واجهة برمجة التطبيقات (API) - حتى يتمكن الأشخاص بالفعل من ترجمة libs إلى UWP
3. بمجرد أن تطلب broadSystemAccess ، ما عليك سوى إعطائها وتوقف عن
4. بمجرد أن تطلب broadSystemAccess ، اسمح لـ System.IO عبر جميع محركات الأقراص الثابتة
5. اجعل من السهل التوزيع خارج متجر MS (+ إصلاح مشكلة "الشهادة الجديدة")

فيل آخر في الغرفة. إذا سأل أحدهم: أريد إنشاء برنامج Windows جديد ، فما أفضل طريقة للقيام بذلك؟ لا توجد إجابة مباشرة في يناير 2020! إذا حاولت وضع UWP في الإجابة - فسوف تمر بوقت سيئ. (هل هناك تعليق واحد ، أو مشاركة مدونة ، أو مقطع فيديو على YouTube حيث قال أحدهم: لقد صنعت تطبيقًا رائعًا باستخدام UWP وأعجبتني العملية؟ نعلم جميعًا أنه لا يوجد أي تعليق. لا أحد يكتب عن إنشاء تطبيق باستخدام UWP ، فهو ليس كذلك حرفيًا لا توجد على الإنترنت). WPF؟ لا توجد ضوابط حديثة -

نعم ، أتفق معك - العثور على موارد جيدة في UWP قريب من الصفر. الكثير من المشكلات ، ما عليك سوى معالجتها وإصلاحها بنفسك.

التكنولوجيا الميتة ، ليست فكرة جيدة (لا تزال أفضل من UWP ، رغم ذلك). الجواب الصادق يجب أن يكون: جرب الإلكترون ، ربما؟ تم إنشاء VSCode مع ذلك ، لذا فأنت تعلم أنه يمكنك إنشاء تطبيق جيد باستخدامه.

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

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

الشيء navie المذكور سابقا في الخيط؟ أتفق تماما. Visual Studio - يتكون The Juggernaut نفسه (UI) من كود مُدار - WPF. إنه رائع ورائع حتى. بينما حتى Microsoft لا تستطيع ذلك

من الواضح أنني أراهن على ** أنه لا يمكنك إنشاء Visual Studio في UWP طوال حياتي - وأنا لا أتحدث عن واجهة المستخدم ، يمكنك مطابقة واجهة المستخدم الخاصة بـ Visual Studio وتجاوزها ، ولكن الباقي. ...

هذا موضوع غني ومهم. وثيق الصلة بـ WinUI ، وللأسف لا يوجد مكان أفضل للحديث عنه. تحتاج Microsoft إلى التعامل مع هذه الموضوعات بطريقة مفتوحة.

وافق 100٪!

هل يمكنك إنشاء تطبيقات حديثة وجيدة المظهر على Windows الآن (JAN2020)؟ لا

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

• على واجهة واجهة المستخدم ، ستكون هناك مشكلات ، ولكن عادةً ما ستتفهمها
• في جبهة "أي شيء آخر" ، تبدو الأمور قاتمة جدًا.
• التعامل مع الملفات على UWP هو جحيم كامل ، بسبب StorageFile / Folder API ، والتي ، في منتصفها ، أكرهها من كل قلبي

نحن هنا مثل الكلاب المضروبة. من الصعب جدًا إنشاء تطبيق حديث جديد لسطح مكتب Windows! ألا يجب أن تكون هناك طريقة ممتازة واحدة على الأقل لتنفيذ التطبيقات؟ عندما تذهب إلى Microsoft Store على windows وتحاول تمرير فئة التطبيقات ، فلن تجد أي تطبيق لائق تم إنشاؤه باستخدام UWP. راجع للشغل لا يمكنني التحقق من ذلك بنفسي لأن ...

نعم ، السيدات والسادة التطبيق "الحديث" ، "الأصلي". نظرًا لأن Windows أصبح الآن مجانيًا عمليًا ، فلا ينبغي أن يكون المصدر الرئيسي لتحقيق الدخل هو التطبيق الأكثر صلابة على النظام ، لكنني أستطرد. لا تحتاج في الواقع إلى البحث في التطبيق لمعرفة التقنية التي تم تصنيعها بها. نظرة واحدة فقط ويمكنك معرفة ما إذا كان قد تم بناؤه باستخدام UWP. لا توجد مشاريع تجارية جادة تم بناؤها باستخدام UWP ، وما تم بناؤه بها هو ... كما تعلم ...

وهذا لأنه صعب جدًا. Window10 هي أكبر منصة بعد الإنترنت و Android !!! لكن لا أحد يصنع تطبيقات لها بالأدوات التي يُفترض أنها صنعت لهذا الغرض! مجرد التفكير في ذلك. من الأسهل إنشاء تطبيق Electron لأنظمة تشغيل 3 بدلاً من إنشاء تطبيق Electron لنظام التشغيل Windows باستخدام UWP!

هل هذا مناسب لنا ، أيها الكلاب المهزومة ، الذين يريدون فقط إنشاء تطبيقات سطح مكتب Windows للمطالبة بأدوات ممتازة؟ أقول نعم بلا اعتذار! لكن كل ما لدينا هو صمت الراديو من Microsoft. من يريد أن يسمع حكاية خرافية مفادها أن تطبيقك قد يعمل على Holo Lens أو Windows Phone أو Xbox؟ لا أحد. بعد 5 سنوات ، لم يكن هناك تطبيق تجاري يعمل على 2 من تلك المنصات الموعودة من أجل UWP. (غالبًا لأن هذه المنصات لا تخرج). مرة أخرى ، تأمل في ذلك! أفضل شيء حدث لنا هو إعادة WinUI إلى Win32 القديم.

أنا أحب سطح مكتب Windows ، لقد تعلمت البرمجة باستخدام C # على WinForms و WPF. وكان الأمر سهلاً وممتازًا بالنسبة إلى مبتدئ مثلي. اليوم أنا أفرح لعابي بالنظر إلى تلك الضوابط المثيرة في WinUI ، لكن يجب على شخص ما توضيح الصورة الكبيرة للمنصة. نحن بحاجة إلى رسالة واضحة حول القيادة التقنية العملية وليس حول تطلعات السوق لبعض التنفيذيين في مجال MS.

أهلا،
لقد تأخرت قليلاً في هذه المناقشة ولكني أردت أن أعطي رأيي المتواضع على أي حال.
فيما يتعلق بتطبيقات UWP التجارية: أحد ما يتبادر إلى ذهني هو Adobe XD. هذا هو UWP ويشعر بأنه ناضج وكامل للغاية.
تجربتي الخاصة مع UWP ، بصفتي مطورًا .Net لمدة 13 عامًا: بالطبع يمكنك إنشاء تطبيق جيد المظهر وذو أداء عالٍ معه. لكن ... إنها ليست تجربة جميلة. نحن بصدد إنشاء تطبيق طبي وقد صادفنا أيضًا العديد من الأشياء المذكورة بالفعل هنا وفي أماكن أخرى:

• ملف بطيء لا يصدق API
• بطيء جدا "وقت F5". لذا فإن الدخول في تصحيح الأخطاء لإنشاء / بدء التطبيق لتجربة شيء ما يكون أبطأ بمقدار 10 مرات على الأقل من WPF. (فكر في دقيقتين تقريبًا على Surface Book 2)
• بشكل عام ، يتم تقييدها بواسطة sandbox.
  هؤلاء هم فقط من أعلى رأسي. في النهاية ، عندما تم إصدار XamlIslands ، اخترنا استضافة UWP UI الكاملة في نافذة WPF ، مع وجود نواة .net سريعة وراء كل شيء. لا أعتقد أن الكثير من الناس استخدموا XamlIsland بهذا الحجم (استنتاجًا من مشكلات github / العلاقات العامة التي أنشأناها). ومع ذلك ، فإن لهذه التكنولوجيا أيضًا بعض القيود الخطيرة للغاية. فقط كمثال ، وقت التجميع يرتفع أكثر. فقدان القدرة على التحرير المباشر Xaml. هل تريد إنشاء مثبّت لتطبيق WPF / XamlIsland / UWP جاد؟ هذا مؤلم. إلخ...
  لتلخيص ذلك ، يمكن بالطبع إنشاء تطبيقات UWP جميلة. لكنها بطيئة وغير منتجة للغاية. ومقيدة.
  لذا ، مثل العديد من الآخرين ، ننتظر بحماس إصدار WinUI 3 ونضجه ، والقدرة على الحصول على واجهة أمامية "UWP" و. net core (أو .net 5 ؛-)) بدون حيل.

jasonwurzel هذه بعض النقاط الجيدة جدًا

• ملف API بطيء ولكن في هذه الأثناء نشر @ duke7553 حلاً في # 1465 (تعليق)
  هذا صحيح ، لكننا لم نكن نعرف عنه في ذلك الوقت. لا داعي للقول ، إنه من الجنون إلى حد ما تنفيذ هذا الحل لمجرد الحصول على إدخال / إخراج سريع للملف ...
• يعمل الوقت F5 على إبطاء الأشياء وأعتقد أنه يمكن استخدام بعض التحسينات
• لدي فضول عن القيود التي واجهتها من خلال محاولة تطوير تطبيق UWP عادي بدلاً من الذهاب إلى مسار جزر xaml؟ أنا أعمل على عدد قليل من التطبيقات في الوقت الحالي وتمكنت من حل أي قيود من خلال تضمين عمليات Win32 ، لكنني أدرك أنها ليست الطريقة المثالية دائمًا لإنشاء تطبيق.
  أعتقد أنه في النهاية كان مجموع العقبات التي واجهناها ، ولا شك أن بعضها كان يمكن حله بعمليات خارجية. ليس في ترتيب معين:
• مراقبة درج الأقراص المضغوطة / منافذ USB للوسائط المدرجة
• مراقبة بعض الدليل الذي يختاره المستخدم في أي مكان على جهاز الكمبيوتر المحلي وجعل التطبيق / Windows يتذكر حق الوصول عند التحديث
• يطالب بـ broadFileSystemAccess ، والحصول على الاستثناء ، وفتح صفحة إعدادات Windows المقابلة ، ويتحقق المستخدم من تبديل التطبيق ، ويغلق boom App دون سابق إنذار ، ولا توجد فرصة للتدخل.
• نفس المجال: السماح للمستخدم باختيار دليل دون الحاجة إلى فتح FolderPicker على غرار Windows (لا ، لا نريد تصميم تطبيق ملء الشاشة الخاص بنا بطريقة لطيفة ومبسطة ، ثم يقفز مربع حوار Windows في وجه المستخدم)
• مشكلة الدجاج والبيض: توافر / دعم حزم nuget (لا يزال العديد من الأشخاص يستخدمون WPF ، لذا فإن إيجاد حلول للمشكلات الصغيرة يكون أسرع بكثير)
• التحكم في موقع التثبيت

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

أنا لا أقول إنه غير ممكن ، لكنه صعب للغاية. وأنا لا أتحدث عن تطبيق "يشبه Notepad" بسيط ، فأنا أتحدث عن تطبيق معقد للغاية يتعامل مع واجهة المستخدم / تحرير الفيديو / تحرير الصوت / تحميل / حفظ الكثير من الأشياء على القرص / (محاولة وفشل ) تشغيل الأشياء (ورجاء عدم إخباري عن واجهة برمجة تطبيقات fullTrust). أنا أتحدث عن تطبيق 50-100 ألف + سطر من التعليمات البرمجية.

هذا هو أصعب waaaay.

وحقيقة أنه يمكنك تشغيل صوت عندما يفقد التطبيق التركيز - لا أحد يقول أنه لا يمكنك ذلك ، ولكن يجب أن يكون الأمر أسهل مما هو عليه الآن.

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

أوافق ، لهذا السبب بدأت بالفعل في نقل تطبيقي إلى UWP. لكنه كان طريقًا وعرًا للغاية ، ولا يزال كذلك.

أنت تدعي أيضًا أنه لا يوجد أحد يكتب عن تطوير تطبيقات UWP ويجب أن أقول إن هذا مجرد خطأ ، rudyhuyn ، Martin Zikmund هما مثالان فقط للمطورين الذين يكتبون عن UWP ولكن هناك العديد من التطبيقات الأخرى أيضًا.

أتفق تمامًا ، لكن قارن ذلك مع الأشخاص الذين يكتبون عن wpf. إنها قطرة في الماء.

ما عليك سوى إجراء بحث بسيط في جيثب - "c # wpf" (3701 نتيجة) مقابل "c # uwp" (337 نتيجة).
أنا متأكد مما إذا كنت ستبحث عن نفس الشيء ، وقم بالتصفية حسب "عدد الالتزامات> 500" (التي تعني كيندا - المستخدم عالق في المشروع) -> ستجد صورة باهتة باهتة.

يوضح هذا إلى حد كبير أنه يمكنك إنشاء تطبيقات جيدة المظهر في عام 2020 بالإضافة إلى تطبيقات UWP الحديثة وأن العديد من بياناتك ليست دقيقة.

أتوسل إلى عدم الموافقة - لكي أكون قادرًا على تطوير تطبيق UWP المعقد وأكون سعيدًا بالقيام بذلك -> نحن بعيدون جدًا عن ذلك.

• لدي فضول عن القيود التي واجهتها من خلال محاولة تطوير تطبيق UWP عادي بدلاً من الذهاب إلى مسار جزر xaml؟ أنا أعمل على عدد قليل من التطبيقات في الوقت الحالي وتمكنت من حل أي قيود من خلال تضمين عمليات Win32 ، لكنني أدرك أنها ليست الطريقة المثالية دائمًا لإنشاء تطبيق.

من ناحيتي ، حاولت استخدام win2d باستخدام Xaml Islands مرة أخرى في سبتمبر - لم يعمل شيء واحد. لقد جربت بعض أمثلة MS ولكنها لم تنجح أيضًا. في هذه المرحلة ، أدركت أنني بحاجة حقًا إلى نقل تطبيقي إلى UWP وإلا فلن يعمل هذا أبدًا.

بالنسبة للاختبار الأحدث - https://github.com/microsoft/Win2D/issues/731

• بطيء جدا "وقت F5". لذا فإن الدخول في تصحيح الأخطاء لإنشاء / بدء التطبيق لتجربة شيء ما يكون أبطأ بمقدار 10 مرات على الأقل من WPF. (فكر في دقيقتين تقريبًا على Surface Book 2)

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

• بشكل عام ، يتم تقييدها بواسطة sandbox.

آه أجل :)

• ملف API بطيء ولكن في هذه الأثناء نشر @ duke7553 حلاً في # 1465 (تعليق)

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

إذا أجريت بحثًا على google ، فلن تجد أيًا من المنشورات التي توضح هذا الحل ، لذلك من المحتمل أن تمر بضعة أشهر قبل أن يدرك معظم المطورين ذلك.

تضمين التغريدة

لذا ، مثل العديد من الآخرين ، ننتظر بحماس إصدار WinUI 3 ونضجه ، والقدرة على الحصول على واجهة أمامية "UWP" و. net core (أو .net 5 ؛-)) بدون حيل.

أريد فقط أن أشير إلى أن MS قالت أنه بمجرد هبوط .NET 5 ، ستتمكن من استخدامه لمشاريع UWP الخاصة بك على ما يرام. لا حاجة لأية "حيل" أو موقف مثل .NET Core 3.x. إليك منشور إعلان .NET 5 مرة أخرى: https://devblogs.microsoft.com/dotnet/introducing-net-5/

نعم ، هذا ما كنت أشير إليه 👍

أعتقد أن كلمة "بالكامل" في _ "بعيدة تمامًا عن الواقع" _ كانت غير عادلة وغير دقيقة ، لكن jtorjo كان محبطًا للغاية لأسباب مفهومة. إذا كانت Microsoft بعيدة تمامًا عن الواقع ، فلن يعمل فريق WinUI على فصل WinUI عن UWP. بشكل عام ، يبدو أن فريق WinUI على اتصال أكثر من الأقسام الأخرى في UWP / WinRT. أعتقد أن الوصف الدقيق هو أن هناك درجة من عدم الاتصال موجودة في بعض الفرق في الوقت الحالي.

أهمية واجهة المستخدم الرسومية القائمة على الأعمدة

على الرغم من أن فريق WinUI هو على الأرجح الفريق الأفضل أداءً من بين جميع الفرق المتعلقة بـ UWP / WinRT ، أعتقد أنه لا تزال هناك بعض الأخطاء في إدارة مشروع WinUI. تعد واجهة المستخدم الرسومية القائمة على الأعمدة (مثل DataGrid ) ميزة أساسية أساسية يستخدمها كل عميل على أساس يومي (كما هو الحال في مستكشف Windows والعديد من الأمثلة الأخرى مثل Spotify وما إلى ذلك). منذ بداية WinRT ، مرت 8 سنوات بدون دعم رسمي لقائمة مع أعمدة واجهة المستخدم الرسومية! أجد أن هذا الوضع مروع. لهذا السبب وغيره ، أقول إن UWP لا يزال إصدارًا ألفا اليوم (لم يكتمل بعد بالميزات ، وبالتالي فهو ليس إصدارًا تجريبيًا حقيقيًا). ليس من المستغرب أن معظم مطوري التطبيقات لم يأخذوا UWP على محمل الجد ، وبالتالي تم إلغاء Windows Mobile.

نسخة رسمية من WinUI DataGrid قد تأخرت عن السداد على مدى السنوات الثماني الماضية. أصبح برنامج DataGrid متأخرًا في اللحظة التي تم فيها إصدار WinRT 1.0 لأنه لم يكن من المفترض أن تبدأ Microsoft نظامًا جديدًا (كما أوضحت في رسالتي السابقة المتعلقة بـ Nokia ، إلخ). 8 سنوات مع الأساسيات المفقودة ، وتأخر 8 سنوات ، والآن يريد فريق WinUI جعل DataGrid أكثر تأخراً عن طريق إضاعة المزيد من الوقت عن طريق الرجوع إلى الكود الأصلي. لأسباب متعددة ، من الصعب أن تأخذ UWP على محمل الجد ويصعب الوثوق بها.

تم استبدال C ++ / CX مؤخرًا بـ C ++ / WinRT

إليك مثال آخر على "الابتعاد عن الواقع":
من الواضح أن البرامج تحتاج إلى أن تتم كتابتها بطريقة عاقلة (أعني "عاقل" كمصطلحات ، وليس إهانة مثل "أنت مجنون"). "عاقل" كمصطلح يعني أنه لا يجب عليك استخدام السحر الأسود المعقد الغامض لإنجاز مهمة بسيطة ومباشرة.
تم استبدال C ++ / CX مؤخرًا بـ C ++ / WinRT. يستخدم C ++ / WinRT ما يسمى بـ _ "نمط القالب المتكرر بشكل مثير للفضول" _ لاستدعاء الوظائف عبر الإرسال الثابت. هذا تصميم رهيب حقًا لأنه ليس تصميمًا عاقلًا لأنه يتعلق باستخدام السحر الأسود الغامض والمعقد لإنجاز مهمة بسيطة ومباشرة. علاوة على ذلك ، حل CLR / C # هذه المشكلة بالفعل منذ عقود ، فلماذا لا يزال فريق WinRT يعبث ويضيع الوقت في الموضوعات القديمة والبدائية التي تم حلها بالفعل منذ عقود؟ لماذا يقوم فريق WinRT بإعادة اختراع العجلة؟

لقد تصفحت الكود المصدري الجديد لـ C ++ / WinRT وانطباعي عنها هو أنها قطعة برمجية منخفضة الجودة بشكل رهيب ، لكن فريق WinRT ينظر إليها على أنها متقدمة بشكل رائع. وبالتالي ، فإن وصف "بعيد عن الواقع" هو وصف دقيق.

نظام ملفات UWP لا يزال إصدار ألفا

ذكرjtorjo وأشخاص آخرين مشكلات أداء واجهات برمجة تطبيقات نظام ملفات

افترض Windows أن الهاتف المحمول مثل "App Dev" كان السوق المزدهر ، وكان حديثًا من حيث أنه يتمتع بالأمان وعمر البطارية في صميمه.

تم طردهم من سوق الهاتف المحمول بسبب قوى السوق. تحاول أجهزة مثل Hololens و Xbox إزالة دعم Win32 القديم - لجعل التطوير أبسط بالنسبة لها ، وقاعدة أكواد لنظام التشغيل الأقل رشاقة وأكثر كفاءة.

لم تؤت هذه الرهانات ثمارها بالكامل ، لكن المثل العليا لتقديم التطبيقات الحديثة ونموذج الأمان هي أهداف جديرة بالثناء.

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

يجب أن يكون WinUI 3.0 الأفضل في كلا العالمين ، مما يسمح بالوصول إلى معظم واجهات برمجة التطبيقات الحديثة التي تستفيد من إسقاط اللغة ومعايير الترميز الحديثة ومعرفة الأجهزة المحمولة. ولكن أيضًا السماح للتطبيقات باستخدام أوقات تشغيل Win32 و .NET الأقل أمانًا ولكن الأكثر قوة.

بالطبع ، الاعتماد على الوصول إلى Win32 ، سيؤدي إلى تقييد الأنظمة الأساسية التي سيتم تشغيلها عليها - ومن يدري إلى أين سينتقل السوق في السنوات القادمة.

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

mdtauk كتب:

تم طردهم من سوق الهاتف المحمول بسبب قوى السوق.

يود العديد من موظفي UWP / WinRT أن يصدقوا هذا التفسير كثيرًا ، من أجل أن يشعروا بشكل أفضل بما حدث. لا أصدق هذا التفسير. أعتقد أن UWP فشل بسبب:

1. سوء الإدارة ، و
2. الفشل في معالجة مشكلة مطوري التطبيقات الذين يؤجلون دائمًا إصدارات UWP من تطبيقاتهم بسبب الانطباع بأن UWP لم يكن جاهزًا ولا يزال غير جاهز لوقت الذروة ، و
3. الاستخدام المفرط لتقنيات هندسة البرمجيات القديمة غير المنتجة ، و
4. عدم كسب ثقة غالبية مطوري التطبيقات ، و
5. الأشياء التي جعلت UWP تبدو سخيفة مثل الترويج لاستخدام JavaScript بدلاً من Java ، مما يعني الفشل في التعرف على الفرق بين لغة البرمجة النصية مقابل لغة البرمجة.

للأسف ، نظرًا لأن سوء الإدارة هو السبب الرئيسي لفشل UWP ، فمن المثير للسخرية أن UWP مكتوب في رمز غير مُدار لأن كلمة "غير مُدار" تلخص سبب الفشل حقًا: سوء إدارة كل من الكود المصدري وإدارة المشروع.

jtorjo كتب:

Native ، في سياق "التحويل البرمجي إلى .net الأصلي" ، أعتقد أنه أمر جيد

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

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

ما الذي يمكن عمله الآن لحل أخطاء الماضي؟ توقف عن تكرار نفس الأخطاء التي أدت إلى فشل UWP. لا تستمر كما لو لم يحدث شيء سيء. سأستخدم DataGrid كمثال هنا: أضف ميزات جديدة إلى DataGrid بدلاً من تأخير DataGrid أكثر من ذلك. لا تجعل DataGrid متأخرًا لأكثر من 8 سنوات عن طريق القيام بإعادة كتابة / تحويل يدوية عديمة الفائدة إلى كود أصلي.

لا يهتم المستخدمون النهائيون بما إذا كانت DataGrid مكتوبة برمز مُدار أو غير مُدار ، ولا يعرفون ما تعنيه هذه المصطلحات ، وبالتالي فإن ما هو أكثر أهمية وعقلانية هو الاحتفاظ بها مع التعليمات البرمجية المُدارة كما هي وتحسين وظائف / ميزات DataGrid. إن مقدار الشفرة الأصلية المكتوبة يدويًا في UWP هي بالفعل حالة كارثية ، فلماذا تجعل الموقف أسوأ من خلال كتابة المزيد من التعليمات البرمجية الأصلية وحتى المزيد من التعليمات البرمجية القديمة استنادًا إلى Win16 / 32 و COM؟

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

نظام ملفات UWP لا يزال إصدار ألفا
ذكرjtorjo وأشخاص آخرين مشكلات أداء واجهات برمجة تطبيقات نظام ملفات

لقد ذكرت هذا من قبل وسأذكر مرة أخرى - واجهة API StorageFolder / StorageFile هي واحدة من أسوأ واجهات برمجة التطبيقات التي رأيتها. نحن في القرن الحادي والعشرين ، وأحتاج إلى أن أسأل "أرجوكم ، هل يمكنني الوصول إلى هذا؟ وإلى ذلك؟ ثم إضافتهم إلى قائمة الوصول العظيمة فيوتشرز أكسس؟"

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

لم تؤت هذه الرهانات ثمارها بالكامل ، لكن المثل العليا لتقديم التطبيقات الحديثة ونموذج الأمان هي أهداف جديرة بالثناء.

انا موافق تماما...

[....] بالطبع ، الاعتماد على الوصول إلى Win32 ، سيؤدي إلى تقييد المنصات التي سيتم تشغيلها عليها - ومن يدري إلى أين سينتقل السوق في السنوات القادمة. [...]

أتفق تمامًا ، لكن التفكير كثيرًا في المستقبل يمكن أن يكون أيضًا بمثابة ألم ...
أعني بذلك - إذا قمت بتقييد وصول Win32 من البداية ، فسيكون نقل المكتبات إلى حد كبير "محظورًا" ، لذلك لن يكون لديك حاضر ، ناهيك عن المستقبل.

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

لكني أفعل ما يجب أن يُمنح لي الاختيار ، وسأفهم المخاطر.

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

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

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

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

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

نحن نعلم الآن أيضًا أن إطار عمل تطبيق Win32 / .NET سيأتي مع WinUI 3.0 - فلا جدوى من انتقادهم لكونهم WinRT فقط في الماضي. 😁

تضمين التغريدة

نحن في القرن الحادي والعشرين ، وأحتاج إلى أن أسأل "أرجوكم ، هل يمكنني الوصول إلى هذا؟ وإلى ذلك؟ ثم إضافتهم إلى قائمة الوصول العظيمة فيوتشرز أكسس؟"

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

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

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

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

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

https://opensource.microsoft.com/codeofconduct/

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

لذلك نبدأ بعيب كبير مقارنة بتطبيقات WPF. هذا شيء - الشيء الآخر هو

1. أنا أطلب ذلك بالفعل عند التثبيت.
2. حتى إذا كان المستخدمون قد لا ينتبهون ، فقد يُظهر Windows مرة أخرى للمستخدم "يريد هذا التطبيق الوصول إلى ملفاتك" ويمكن للمستخدم أن يقول نعم / لا. سأكون بخير تماما مع ذلك. ومع ذلك ، هذا بعيد كل البعد عما يحدث.

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

أعتقد أن السبب المنطقي هو أنه لا ينبغي أن يحظر مؤشر ترابط واجهة المستخدم لأن أسوأ شيء يمكن أن يحدث من نقطة UX هو أن التطبيق لم يعد يستجيب بعد الآن لأن المطور ينسى

يجب جلب حجم الملف مسبقًا (مثل تاريخ آخر وصول / تاريخ آخر كتابة) - إنه مهم جدًا ، بحيث يجب جلبه مسبقًا عند إجراء استعلام عن ملفات.

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

أريد تمامًا حل هذه المشكلات ، لا شيء غير ذلك.

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

لم تكن هذه المناقشة لتحدث هنا ، لو كان لدينا بالفعل مكان لطرح هذه الأسئلة ، ولكي تستمع WinRT للتعليقات في مكان آخر.

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

أوافق على أنه سلبي قليلاً ، مرة أخرى ، لم يكن هذا ليحدث ، لو كان هناك مكان آخر لتقديم ملاحظات حول مشكلات WinRT.

نحن نعلم الآن أيضًا أن إطار عمل تطبيق Win32 / .NET سيأتي مع WinUI 3.0 - فلا جدوى من انتقادهم لكونهم WinRT فقط في الماضي. 😁

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

لذلك نبدأ بعيب كبير مقارنة بتطبيقات WPF. هذا شيء - الشيء الآخر هو

فقط للتوضيح ، ترك خيار منع التطبيقات من الوصول إلى كل الملفات هو عيب في رأيك؟
نحن كمطورين يجب أن نطور البرنامج للمستخدمين وليس ضدهم. وترك للمستخدم أي خيار بشأن البيانات التي يراها تطبيقك هو عيب أمني للمستخدمين ، في رأيي.

1. أنا أطلب ذلك بالفعل عند التثبيت.

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

كما قلت في تعليقك الأولي:

هل تعتقد أن المستخدمين سيفعلون ما ورد أعلاه بسعادة؟ لا لن يفعلوا ذلك - في الواقع ، 79.8٪ لا يفعلون ذلك (تدعم بيانات AppCenter هذا الأمر).

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

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

يحرر:

يجب جلب حجم الملف مسبقًا (مثل تاريخ آخر وصول / تاريخ آخر كتابة) - إنه مهم جدًا ، بحيث يجب جلبه مسبقًا عند إجراء استعلام عن ملفات.

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

لم تكن هذه المناقشة لتحدث هنا ، لو كان لدينا بالفعل مكان لطرح هذه الأسئلة ، ولكي تستمع WinRT للتعليقات في مكان آخر.

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

@ فيليكس ديف

هنا إعلان آخر NET 5 مرة أخرى

شكرا لربطك بذلك. لقد وجدت هذا الجزء مثيرًا للاهتمام بشكل خاص ، وأعتقد أن هذا خبر إيجابي:

"ستتوفر إمكانية التشغيل التفاعلي لـ Java على كافة الأنظمة الأساسية.

هناك أيضًا القليل من مناقشة Java في التعليقات في نهاية صفحة الويب هذه ، حيث يؤكد Rich Lander على التشغيل المتداخل ثنائي الاتجاه. أفسر هذا على أنه علامة إيجابية على عودة مايكروسوفت إلى التواصل مع الواقع. لست من محبي Java (أفضل C #) ، ولكن مع ذلك أقر بأن قابلية التشغيل البيني لـ Java مفيدة للغاية ويجب أن تكون محور التركيز في UWP / WinRT منذ البداية. إذا كان UWP / WinRT قد أعطى أولوية قصوى لـ Java و C # (رمز مُدار) بدلاً من الكود الأصلي القديم غير المرغوب فيه (C ++ / CX ، Win16 / 32 ، COM) ، وإذا لم يخلط UWP بين الغرض من JavaScript مقابل Java ، إذن ، كان UWP قد اجتذب العديد من مطوري التطبيقات ، وربما يكون Windows Mobile على قيد الحياة اليوم.

سواء أعجبك ذلك أم لا ، من الضروري الاستيقاظ والاعتراف بواقع الموقف: رائد السوق هو Android مع تركيزه على تطوير تطبيقات Java. Java و C # تعنيان كود مُدار. ارتكبت Microsoft خطأ مكلفًا للغاية عندما عكست وجهة نظرها بشأن التعليمات البرمجية المُدارة.

على الرغم من أنني لا أحب Java حقًا ، إلا أنه من الواضح بالنسبة لي أن تقنيات Java في Android أفضل بكثير من الطريقة القديمة التي تعمل بها Microsoft على تطوير WebView2 باستخدام تقنيات برمجة Win16 القديمة مثل مؤشرات 16 بت مقابل 32 بت ، و HRESULT بدلاً من معالجة الاستثناءات الحديثة ، إلخ. يستخدم WebView2 LPCWSTR L ويعني W "الأحرف العريضة" التي تعني Unicode (UTF-16) بدلاً من أحرف ASCII / ANSI ذات 8 بت. بالمقارنة ، يعد استخدام Android لـ Java أكثر احترافًا وحداثة وإلهامًا للثقة مما تفعله بعض أقسام Microsoft.

لذا في ملاحظة إيجابية ، من الجيد حقًا أن نسمع أن Microsoft ستدعم Java (على الرغم من أنني شخصياً أفضل C # على Java). سيزيد مطورو تطبيقات Android من اهتمامهم بنظام التشغيل Windows بمجرد إصدار توافق Java جيد وموثوق به.

نحن نعلم الآن أيضًا أن إطار عمل تطبيق Win32 / .NET سيأتي مع WinUI 3.0 - فلا جدوى من انتقادهم لكونهم WinRT فقط في الماضي. 😁

1. المستقبل مشرق ، أنا أحب ما أراه يتم تطويره في WinUI.
2. كان الماضي قاتمًا للغاية ، بالنسبة لمنصة بها 900 مليون جهاز ، يصعب الدفاع عن الانتشار الضعيف لـ UWP. تحرير: الماضي هو المكان الوحيد الذي يمكننا التعلم منه ، لذلك من المهم مناقشته.
3. أعتقد أن الحاضر هو النقطة الرئيسية في هذا الموضوع ولا يتم تناوله. إذا أراد شخص ما أن يبدأ اليوم تطبيقًا غير عادي سيستغرق تطويره من 1 إلى 1.5 سنة ، فما هي النصيحة الصادقة التي يمكن تقديمها؟ ستكون إجابتي هي: جرب WinUI ، وقم بعمل libs في dotnet Core ، وانتظر حتى يظهر WinUI3.0 لتبدأ حقًا في إنشاء تطبيقك. لا تهتم بـ UWP لأنك سترغب في التخلص منه من تطبيقك على أي حال ، فربما لا تريد منصات مختلفة لأن 900 مليون واحد كبير جدًا. الأسئلة حول الحاضر ليست تافهة ، يجب اتخاذ قرارات العمل اليوم.

ما لا يقال ، ولكن ما يحدث بالفعل هو أن UWP وواجهة المستخدم الحديثة لا يتم تمديدهما إلى win32 ، ولكن UWP في الواقع يتم إعادة بنائه خارج المكدس . لماذا قد يرغب أي شخص في التعامل مع UWP في حين أنه يمكنه استخدام قوة dotnet standard 2 و dotnet core 3 وجميع libs المتوفرة مع ذلك؟

حول وضع الحماية والأفكار الجيدة الأخرى التي تم تقديمها في UWP: كانت أفكارًا جيدة ، ولكن كان من الممكن تنفيذها بشكل أفضل. آمل أن يعودوا وسيكون هناك إمكانية لـ OPT-IN في وضع الحماية أو OPT-IN في إدارة الحالة المشابهة لـ UWP. كمطورين ، نريد خدمة المستخدمين ولكن في UWP تم تهديدنا كمشكلة يجب على النظام الأساسي احتوائها.

ما هي النصيحة الصادقة التي يمكن تقديمها؟ انتظر؟

AndrewPawlowski إذا كنت قد قررت أن UWP و sandbox لا يعملان من أجلك ، أعتقد أن كتابة تطبيق WPF المعبأ في MSIX يعد خيارًا جيدًا حتى يصل WinUI 3. يمكنك بالفعل استدعاء واجهات برمجة التطبيقات الحصرية لنظام التشغيل Windows 10 ، وتزويد المستخدم بتجربة تثبيت / إلغاء تثبيت حديثة واختيار ما تريده وما لا يعجبك (أي يمكنك البدء في استخدام واجهات برمجة تطبيقات Windows 10 Shell). تعد بعض واجهات برمجة تطبيقات WinRT متعة حقًا في العمل بها مقارنة بطرق win32 السابقة وبعض السيناريوهات التي أعتقد أنها تتم بشكل أفضل على DesktopBridge بدلاً من UWP الخالص. مثال على ذلك: تسجيل تطبيق لبدء التشغيل التلقائي عند تسجيل الدخول ، راجع هذا المنشور لمقارنة سلوك UWP مقابل DesktopBridge. في حالة DesktopBridge ، لا تزال ، في النهاية ، تترك للمستخدم تحت السيطرة ، ولكن لن يُطلب من المستخدم باستمرار مرتين (أولاً ، التبديل في التطبيق ، ثم مطالبة النظام بطلب التأكيد) عند تمكين البدء عند السجل- في التطبيق.

لسوء الحظ ، تظهر أجزاء كثيرة من واجهات برمجة تطبيقات WPF فعليًا عمرها الآن عند مقارنتها بواجهات برمجة تطبيقات UWP UI ، لذا سيكون عليك فقط التعايش مع ذلك لبضعة أشهر أخرى (على الأقل). ستعمل مجموعات أدوات WPF العديدة المتاحة على التخفيف من هذه الحقيقة ، ولكن إذا كنت تريد حقًا مظهرًا وشعورًا أصليًا لتطبيق سطح مكتب Windows (وتجربة تطوير XAML حديثة!) ، فلن تتمكن حقًا من الهروب من واجهات برمجة تطبيقات UWP (و في وقت لاحق WinUI 3 APIs). هذا يعني أنه حتى إذا كان بإمكانك إعادة استخدام بعض كود WPF UI لـ WinUI لاحقًا ، فإن تحديث واجهة المستخدم سيظل عنصر عمل كبير على ما أعتقد.

هذه هي حالة تطوير تطبيقات Windows الأصلية التي أراها حاليًا إذا كنت لا تستطيع الانتظار حتى يتم شحن WinUI 3 و UWP ليس خيارًا لك.

تضمين التغريدة

1. المستقبل مشرق ، أنا أحب ما أراه يتم تطويره في WinUI.

كونكور

1. كان الماضي قاتمًا للغاية ، بالنسبة لمنصة بها 900 مليون جهاز ، يصعب الدفاع عن الانتشار الضعيف لـ UWP. تحرير: الماضي هو المكان الوحيد الذي يمكننا التعلم منه ، لذلك من المهم مناقشته.
2. أعتقد أن الحاضر هو النقطة الرئيسية في هذا الموضوع ولا يتم تناوله. إذا أراد شخص ما أن يبدأ اليوم تطبيقًا غير عادي سيستغرق تطويره من 1 إلى 1.5 سنة ، فما هي النصيحة الصادقة التي يمكن تقديمها؟ ستكون إجابتي هي: جرب WinUI ، وقم بعمل libs في dotnet Core ، وانتظر حتى يظهر WinUI3.0 لتبدأ حقًا في إنشاء تطبيقك. لا تهتم بـ UWP لأن

كان تفكيري الأولي هو نفسه ، لكنني لم أنتظر ....

حول وضع الحماية والأفكار الجيدة الأخرى التي تم تقديمها في UWP: كانت أفكارًا جيدة ، ولكن كان من الممكن تنفيذها بشكل أفضل.

متفق عليه 100٪

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

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

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

أنا شخصياً لا أحب مركز التعليقات - فهو غير محدد للغاية ، من بين أمور أخرى.

jtorjochingucoding مركز ردود الفعل لWinRT واجهات برمجة التطبيقات يمكن استبدال / يقترن مع مايكروسوفت Q & A قريبا، وتحقق من هذا الالتزام: https://github.com/MicrosoftDocs/winrt-api/commit/efcc4e041122e8a816a12c0581199c2f36ba36fc

نظرًا لأن Chigusa قد تم ذكره هناك: chigy هل سيكون نظام Microsoft Q&A الأساسي هو النظام الأساسي المفضل للتعليقات لغير WinUI WinRT APIs؟ إذا لم يكن الأمر كذلك ، فكيف سيكون مرتبطًا بمركز التعليقات (مثل أخطاء الملفات / الأسئلة في الأسئلة والأجوبة ، وطلبات واجهة برمجة التطبيقات في مركز التعليقات ، ...)؟

نأمل ألا ينتهي بنا الأمر بثلاث منصات مختلفة للتعليقات

نظرًا لأن هذه مناقشة حول UWP ، يمكنني الترويج لطلب ميزة: السماح بأفعال قائمة السياق مع تكامل مستكشف الملفات دون وجود اقتران بنوع الملف https://aka.ms/AA71n2t راجع للشغل. https://aka.ms/AA6rmrk (ولكن في الفئة الخطأ - ربما يمكن لشخص ما إصلاح هذا؟)

مصدر جيد لطلبات الميزات هو:
https://web.archive.org/web/20161221051552/https : //wpdev.uservoice.com/forums/110705-universal-windows-platform/category/171141-missing-apis
من المؤسف أن لقطة هذا الصوت المستخدم قديمة جدًا (2016). أستطيع أن أتذكر أنه كان هناك أشياء مثل:

• قم بمحاذاة سلوك طلب broadFileSystemAccess كما لو كان سيتصرف عند طلب الكاميرا والموقع وبدء التطبيق عند بدء التشغيل ...
• تلقاءي. الطباعة (مدعوم حاليًا فقط لنقاط البيع على إنترنت الأشياء بقدر ما أتذكر)
• جعل الطباعة أكثر شكليًا

تضمين التغريدة

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

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

وإلا فقد ترغب في إلقاء نظرة على:
https://docs.microsoft.com/en-us/windows/uwp/files/quickstart-managing-folders-in-the-music-pictures-and-videos-libraries

ولكن لكي أكون صادقًا ، لا أعرف بالضبط ما الذي سيساعدك في هذه الحالة broadFileSystemAccess. لا يمكنك التأكد من مكان الملفات بالضبط (على عكس المستخدم). لكن ربما لا أفهم تمامًا فكرة تطبيقك بشكل صحيح.

@ فيليكس ديف
شكرًا على المعلومات ، لم أكن أعرف أن ملاحظات WinRT قد تتحرك.

نأمل ألا ينتهي بنا الأمر بثلاث منصات مختلفة للتعليقات

هههه نعم آمل ألا!

jtorjo - هل فكرت في إلغاء نقل تطبيقك من WPF إلى UWP؟ يمكنك إلغاؤه والانتظار حتى يتم إصدار WinUI 3 ، وبعد ذلك لن تضطر إلى استخدام واجهة برمجة تطبيقات نظام ملفات UWP ، و broadFileSystemAccess ، وما إلى ذلك. في هذه الأثناء ، أثناء انتظار WinUI 3 ، يمكنك الاستمرار في تقديم إصدارات جديدة من تطبيقك إلى المستخدمين لديك من خلال الاستمرار في تطوير إصدار WPF من تطبيقك.

خلال السنوات الثماني التي مرت منذ بداية WinRT ، لم نعطِ مستخدمينا مطلقًا أي تطبيق WinRT أو UWP. بدلاً من ذلك ، قدمنا ​​لهم العديد من التحديثات التي تستمر في استخدام إصدار WPF من برنامجنا. ليس لدى مستخدمينا أي شكوى بشأن هذا الأمر لأنهم لا يهتمون بالتفاصيل التقنية مثل WPF و WinUI و UWP ، بل إنهم يهتمون بمدى جودة عمل التطبيق والوظائف التي يمتلكها. ليس لدى مستخدمينا أي شكاوى حول واجهة المستخدم الرسومية القديمة لأن تطبيقات WPF الخاصة بنا تتضمن مجموعة من تحديثات واجهة المستخدم الرسومية.

AndrewPawlowski قال "تجربة مع WinUI". نعم ، جرب. لقد قمت بكتابة مجموعة من التعليمات البرمجية لـ UWP و WinUI على مر السنين ، لكنها كلها كود تجريبي أو ألفا أو تجريبي. لم أصل أبدًا إلى نقطة شعرت فيها بالراحة الكافية لإصدار أي تطبيقات UWP للمستخدمين.

يعد انفصال WinUI 3 عن UWP مساعدة كبيرة ، لكنني لا أعتقد أنه حل كامل. لا يعالج WinUI 3 الإنتاجية المنخفضة / البطء في تطوير WinUI: تم تطوير WPF بشكل أسرع بكثير من WinUI ، على الرغم من أن WPF كان أكثر صعوبة من WinUI.

يقول فريق WinUI إن السرعة ستزداد عندما يكون WinUI 3 مفتوح المصدر ، وربما يحدث ذلك ، لكنني شخصياً لن أكتب أي مساهمات في C ++ / CX أو C ++ / WinRT أو Win16 / 32 أو COM لـ WinUI 3. I بدأت مسيرتي المهنية مع Win16 / Win32 منذ عقود ، وكان Win32 كابوسًا ، وليس لدي أي نية للعودة إلى تقنيات البرمجة القديمة والمشكلة. على مر السنين ، حافظت على تحديث مهاراتي في هندسة البرمجيات وتحولت إلى C # و .NET Framework ، وكان ذلك بمثابة تحسين وفائدة كبيرة ، ولن أعود إلى كابوس Win16 / 32 القديم. أيام وكميات كبيرة من التعليمات البرمجية الأصلية المكتوبة يدويًا.

@ كتب

ما هي النصيحة الصادقة التي يمكن تقديمها؟ انتظر؟

هذا سؤال صعب الإجابة عليه. من ناحية ، نعم ، انتظر WinUI 3 ، ولكن من ناحية أخرى ، لا يعد WinUI 3 حلاً كاملاً للمشكلة الكبيرة التي بدأها WinRT منذ 8 سنوات. WinUI 3 هو حل جزئي مفيد.

فيديو رائع من Ignite: https://youtu.be/Ul5JcdIJv5s

أعتقد أن الكثير من المناقشة هنا تتساءل عن الغرض من WinRT. لا يزال المطورون والمستخدمون يتساءلون عن الدور الذي سيلعبه بمجرد أن يسمح WinUI 3 و .NET 5.0 بالتفاعل السهل بين التقنيات المختلفة. ناهيك عن القدرة النهائية على الاختيار بين نماذج التطبيقات ذات وضع الحماية مقابل نماذج التطبيقات الكلاسيكية.

أفترض أن كتابة واجهات برمجة تطبيقات WinRT جديدة أسهل بالنسبة لشركة Microsoft داخليًا ، وهو ما يفسر سبب ذكرهم مرات عديدة قبل أن يتم تنفيذ معظم ابتكارات طبقة API داخل WinRT. هذا يعني أنه بالنسبة لتطبيقات Windows الجديدة والحديثة ، من المنطقي استخدام WinRT لأنه سيحتوي على أحدث وأكبر تكامل مع التجارب الجديدة التي ستأتي مع عوامل الشكل الجديدة. الغرض من WinRT هو أن يكون مجموعة محددة من واجهات برمجة التطبيقات العالمية التي تضيء في تطبيق .NET على Windows.

مع ذلك ، أعتقد أننا نتفق جميعًا على أنه سيجعل التطبيقات العامة أكثر قيمة إذا كانت حزمة UWP Desktop Extension Pack تتمتع بقدرات تكامل أفضل مع Windows Shell الحالي.

من يدري ، قد يكون لدى Microsoft خطط لاستبدال Windows Explorer Shell في النهاية بـ Composable Shell (CShell) الموجود في Windows 10x ، وما إلى ذلك. اكتشف الخبراء على Twitter أيضًا UDK (مجموعة تطوير غير مُرسلة) موجودة في Windows والتي قد تسمح بـ تكامل أفضل مع هذه القشرة الجديدة في المستقبل.

تضمين التغريدة

ربما لا تريد منصات مختلفة لأن 900 مليون واحد كبير جدًا.

بينما أرى ما تقصده ، عليك أن تدرك أن UWP و .NET لم تعدا أشياء حصرية بشكل متبادل ، لذلك إذا كان من المنطقي تشغيل تطبيقك باستخدام ميزات Universal ، فيجب على المرء الاستثمار في فهم أجزاء من WinRT.

أنا أستطرد. بصفتك أحد الذين قاموا ببناء منافس لـ Windows File Explorer مع نموذج تطبيق خالص UWP ، لا يمكن أن يأتي WinUI 3 بالسرعة الكافية. في المستقبل القريب ، لن تضطر إلى الاختيار بين استخدام ميزات Universal و "900 مليون مستخدم" 😀

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

تضمين التغريدة

jtorjo - هل فكرت في إلغاء نقل تطبيقك من WPF إلى UWP؟ يمكنك إلغاؤه والانتظار حتى يتم إصدار WinUI 3 ، وبعد ذلك لن تضطر إلى استخدام واجهة برمجة تطبيقات نظام ملفات UWP ، و broadFileSystemAccess ، وما إلى ذلك. في هذه الأثناء ، أثناء انتظار WinUI 3 ، يمكنك الاستمرار في تقديم إصدارات جديدة من تطبيقك إلى المستخدمين لديك من خلال الاستمرار في تطوير إصدار WPF من تطبيقك.

لقد فكرت طويلا وبجد في هذا - هذا ما أردت أن أفعله. لكن لا يمكنني فعل ذلك ، لأنني أحتاج حقًا إلى win2d (أو أكثر من ذلك ، غلاف جيد على Direct2D). بدا ShapDX (غلاف آخر على Direct2D) أكثر تعقيدًا ، لذلك اخترت استخدام win2d (وهو UWP). لذلك ، قم بنقل كل شيء إلى UWP.

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

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

وبعد ذلك ، كلما قمت (المستخدم) بنسخ الصور / مقاطع الفيديو بطريقة ما إلى مجلد جديد ، ستحتاج إلى تذكر إخبار تطبيقي بتضمين ذلك أيضًا ...

كي لا نقول إن FutureAccessList "الرائع" - لا يحدد حقًا -> إذا أضفت مجلدًا ، فهل سيكون تطبيقي متاحًا لجميع مجلداته الفرعية؟

أيضًا ، إذا أضفت شيئًا ما إلى FutureAccessList ، فهل أحتاج إلى استعادته من هناك أم يمكنني الحصول عليه باستخدام GetFolderFromPathAsync / GetFileFromPathAsync (إنه السابق ، أفضل القفز من الهاوية)؟

وهل تعلم أنه إذا استخدمت FutureAccessList.AddOrReplace واستخدمت مسار الملف كرمز ، فستحصل على استثناء؟ كم هو مدروس ... (ليس في أي مكان في الوصف)

سيكون WinUI 3 و .NET Core خيارًا في المستقبل - أفترض أن هذه المجموعة ، بدون وضع الحماية الخاص بـ UWP ستعمل بنفس طريقة WPF ، ولكن مع عناصر تحكم XAML الأحدث ، والطبقة المرئية ، ووصول WinRT API البسيط.

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

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

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

وبعد ذلك ، كلما قمت (المستخدم) بنسخ الصور / مقاطع الفيديو بطريقة ما إلى مجلد جديد ، ستحتاج إلى تذكر إخبار تطبيقي بتضمين ذلك أيضًا ...

أعتقد أنه إذا كان لديك حق الوصول إلى الدليل الأصلي ، فيمكنك أيضًا الوصول إلى مجلدات الأطفال المستقبلية (لست متأكدًا بنسبة 100٪).

وهل تعلم أنه إذا استخدمت FutureAccessList.AddOrReplace واستخدمت مسار الملف كرمز ، فستحصل على استثناء؟ كم هو مدروس ... (ليس في أي مكان في الوصف)

هذا غريب ، هذا شيء يجب توثيقه بالتأكيد!

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

لكن ربما لا أعرف حالات عمل كافية لمثل هذا. إذا كان هناك المزيد ، فأنا أحب أن أسمعهم!

لكن ربما لا أعرف حالات عمل كافية لمثل هذا. إذا كان هناك المزيد ، فأنا أحب أن أسمعهم!

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

  • إذا قام المستخدم بسحب الملف إلى تطبيق uwp الخاص بك ، فلن يكون لديك حق الوصول للكتابة إلى هذا الملف!
    https://stackoverflow.com/questions/48001601/c-sharp-uwp-drag-and-drop-file-folder-permission؟rq=1

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

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

إذا قام المستخدم بسحب الملف إلى تطبيق uwp الخاص بك ، فلن يكون لديك حق الوصول للكتابة إلى هذا الملف!
https://stackoverflow.com/questions/48001601/c-sharp-uwp-drag-and-drop-file-folder-permission؟rq=1

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

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

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

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

أنا شخصياً لست معجبًا حقًا بالتطبيقات التي تطلب "broadFileSystemAccess" نظرًا لأن الكثير منها لا يحتاج إليها.

لا يهم. إن نموذج حماية نظام الملفات الخاص بـ WinRT's sandbox هو أبعد ما يكون عن الواقع. إنه شيء استمده شخص ما من شعار "الجوال أولاً" الرائع ، والذي لا ينطبق ببساطة على سطح المكتب.

في الواقع ، تتمثل الطريقة الأكثر ذكاءً في وضع الحماية للملفات / المجلدات في السماح للمستخدم بتحديد الملفات / المجلدات التي يريد حمايتها - يجب أن تكون هناك طريقة سهلة جدًا للقيام بذلك (مثل ، ربما في File Explorer ، باستخدام أمر النقر بزر الماوس الأيمن) .

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

اسمحوا لي أن أكون صريحًا هنا - أي تطبيق غير تافه لا يعيش في فراغ.

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

نعم هذا احتمال. ولكن متى ستفحص المجلد؟ وما هي المجلدات التي يمكن للمستخدم توسيعها في تطبيقك بالضبط؟

لا يهم.

ما الذي تحاول قوله بالضبط هنا؟

في الواقع ، تتمثل الطريقة الأكثر ذكاءً في وضع الحماية للملفات / المجلدات في السماح للمستخدم بتحديد الملفات / المجلدات التي يريد حمايتها - يجب أن تكون هناك طريقة سهلة جدًا للقيام بذلك (مثل ، ربما في File Explorer ، باستخدام أمر النقر بزر الماوس الأيمن) . سيعرف المستخدمون بوضوح ما هي المستندات / الملفات المعيارية ، وسيحميونها.

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

وهناك أيضًا تشبيه في العالم الحقيقي - فقط فكر في ملفات seifs.

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

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

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

اسمحوا لي أن أكون صريحًا هنا - أي تطبيق غير تافه لا يعيش في فراغ. سيحتاج إلى الحصول على البيانات من مكان ما (المدخلات) وإخراجها في مكان ما. غالبًا ما تكون المدخلات والمخرجات عبارة عن ملفات - تحتاج إلى التعامل مع التطبيقات الأخرى وما إلى ذلك. و WinRT يجعل من المستحيل بالنسبة لي تصميم واجهة مستخدم لطيفة لمنحها للمستخدمين.

إن القول بأنه مستحيل يعد امتدادًا هنا نظرًا لوجود الكثير من تطبيقات UWP الرائعة (على الرغم من عدم وجود العديد منها للأسف).

نعم هذا احتمال. ولكن متى ستفحص المجلد؟ وما هي المجلدات التي يمكن للمستخدم توسيعها في تطبيقك بالضبط؟

هل أنت على دراية بمفهوم مستكشف Windows؟ تقوم بتوسيع مجلد أو محرك أقراص - وهذا هو الوقت الذي أبدأ فيه المسح

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

هذه ليست مشكلة ، إذا كان التطبيق سيحتفظ بملفاته في مجلد "يمكن لهذا التطبيق فقط الوصول إليه".

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

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

أنا لا أوافق تمامًا - الهدف الكامل من "السرية" يجب أن يجعلك تريد قفل هذا الملف.

إن القول بأنه مستحيل يعد امتدادًا هنا نظرًا لوجود الكثير من تطبيقات UWP الرائعة (على الرغم من عدم وجود العديد منها للأسف).

أنت تناقض نفسك هنا. لكن دعنا نتعمق في اتساع نطاق تطبيقات UWP الرائعة:

لاحظ "كثرة" الإعجابات ، والتي يجب أن تخبرك بعدد الأشخاص الذين يستخدمونها. أردت أن أعطي تباينًا مع متجر آبل ، لكن لا يمكنني ذلك لأنني لا أملك تفاحة. لكن دعنا نرى Android - يحتوي Facebook على 70+ مليون تقييم (مقارنة بـ 1353 على Windows). يحتوي Instagram على 93+ مليون تعليق (مقارنة بـ 1578 هنا). وأنا على يقين من أن كلا من Fb و Instagram هما في الواقع تطبيقات إلكترونية وليست UWP.

هل أنت على دراية بمفهوم مستكشف Windows؟ تقوم بتوسيع مجلد أو محرك أقراص - وهذا هو الوقت الذي أبدأ فيه المسح

إذن أنت تبني شيئًا مشابهًا لـ Windows Explorer يقوم بمعاينة ملفات الفيديو في المجلدات؟

هذه ليست مشكلة ، إذا كان التطبيق سيحتفظ بملفاته في مجلد "يمكن لهذا التطبيق فقط الوصول إليه".

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

أنا لا أوافق تمامًا - الهدف الكامل من "السرية" يجب أن يجعلك تريد قفل هذا الملف.

إذن ما الذي لن أختاره بالضبط باعتباره سريًا؟ لا أريد أن يرى كل تطبيق صور عطلاتي ، ولكن يجب أن يتمكن Photoshop من رؤيتها. هل هي سرية أم لا؟ أم أن هذه "العلامة" السرية هي قائمة بالبرامج وبعض الملفات ليست سرية لبعض التطبيقات؟

أنت تناقض نفسك هنا.

نعم ، كانت صياغتي هراء هناك. اسف بشأن ذلك. أردت الإشارة إلى أنه توجد بالتأكيد تطبيقات رائعة غير "تافهة" تعمل بشكل جيد.

لاحظ "كثرة" الإعجابات ، والتي يجب أن تخبرك بعدد الأشخاص الذين يستخدمونها. أردت أن أعطي تباينًا مع متجر آبل ، لكن لا يمكنني ذلك لأنني لا أملك تفاحة. لكن دعنا نرى Android - يحتوي Facebook على 70+ مليون تقييم (مقارنة بـ 1353 على Windows). يحتوي Instagram على 93+ مليون تعليق (مقارنة بـ 1578 هنا). وأنا على يقين من أن كلا من Fb و Instagram هما في الواقع تطبيقات إلكترونية وليست UWP.

هذه ليست مشكلة مع UWP ولكن مع حقيقة أن:

1. عادة لا يميل الناس إلى كتابة التعليقات
2. يعد متجر iTunes Store / Google Play Store أقدم بكثير من متجر Microsoft
3. لم يتم استقبال متجر Microsoft بشكل جيد بين المستخدمين ولم يبدأ بشكل جيد
4. تفضل معظم الشركات تطوير مواقع الويب بدلاً من تطبيقات النظام الأساسي المحدودة

وأنا على يقين من أن كلا من Fb و Instagram هما في الواقع تطبيقات إلكترونية وليست UWP.

من الصعب معرفة ما إذا كانت إلكترونية أم لا لأن موقع الويب والتطبيق يبدوان مختلفين اختلافًا كبيرًا. استنادًا إلى حقيقة أن مربعات الحوار تبدو تمامًا مثل تلك الافتراضية ، فقد تكون تطبيقات UWP.

إذن أنت تبني شيئًا مشابهًا لـ Windows Explorer يقوم بمعاينة ملفات الفيديو في المجلدات؟

هذا جزء من معالج من تطبيقي.

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

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

إذن ما الذي لن أختاره بالضبط باعتباره سريًا؟ لا أريد أن يرى كل تطبيق صور عطلاتي ، ولكن يجب أن يتمكن Photoshop من رؤيتها. هل هي سرية أم لا؟ أم أن هذه "العلامة" السرية هي قائمة بالبرامج وبعض الملفات ليست سرية لبعض التطبيقات؟

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

نعم ، كانت صياغتي هراء هناك. اسف بشأن ذلك. أردت الإشارة إلى أنه توجد بالتأكيد تطبيقات رائعة غير "تافهة" تعمل بشكل جيد.

أنا لا أقول لا يوجد. أنا أقول أنه من الصعب للغاية صنع واحدة ، مقارنة بـ WPF.
أنا أقول إنني أضيع أيامًا في التعامل مع قضايا لا ينبغي ببساطة أن توجد.

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

هناك مشكلة أخرى تتمثل في شعار "دعنا نحصل على معلومات غير متزامنة" - وهو الأمر الذي أكرهه بشدة. أنا أتعامل مع العرض الذي يجب أن يكون فوريًا ، لكن تحميل الصور النقطية غير متزامن. لذلك كان عليّ بناء آلية تخزين مؤقت معقدة حقًا من أجل ذلك فقط.

ويتيح عدم الدخول في أوقات التجميع. وفي بعض الأحيان عند البناء ، أحصل على "... تم إنشاء dll في وضع الإصدار" (والذي لا يمكن أن يكون في الأساس ، لأنني أقوم ببناء تصحيح الأخطاء). الحل هو ببساطة تنظيف كل الحلول وإعادة البناء (الذي يستغرق 1+ دقيقة).

ونعم ، تعطل. تتعطل VS كل 10-20 جولة ، يتفوق علي لماذا.

وهذه هي القضايا التي خطرت على بالي الآن. هناك المزيد لا حصر له.

هذه ليست مشكلة مع UWP ولكن مع حقيقة أن:

1. عادة لا يميل الناس إلى كتابة التعليقات
2. يعد متجر iTunes Store / Google Play Store أقدم بكثير من متجر Microsoft
3. لم يتم استقبال متجر Microsoft بشكل جيد بين المستخدمين ولم يبدأ بشكل جيد
4. تفضل معظم الشركات تطوير مواقع الويب بدلاً من تطبيقات النظام الأساسي المحدودة

حسنًا ، أتمنى لو كان لدي مقارنة متجر Apple - أنا متأكد تمامًا من أن أفضل تطبيقاتهم بها ملايين المراجعات. الفكرة هي أن متجر MS لم يتم اكتشافه أبدًا - لأن الناس يتخلون ببساطة عن UWP / WinRT. لو لم أكن بحاجة إلى win2d ، لكنت استسلمت 20 مرة على الأقل.

فقط فكر في ذلك - أحتاج أن أطلب من Windows الانتقال إلى وضع ملء الشاشة ، كتطبيق UWP. هذا أبعد من الجنون. ولجعل الأمر أكثر غباءً ، فلن يتم تطبيق ذلك إلا في الجولة التالية .

كنت أنظر إلى واجهة برمجة التطبيقات "Grab a screenshot of the screen" - لقد تخلت عنها ببساطة ، إنها عديمة الفائدة. أردت أساسًا الحصول على طريقة رائعة لبدء التطبيق ، استنادًا إلى الشاشة الحالية (نوعًا ما ، انتقل إلى تطبيقي) -> هذا غير ممكن ، لأنه يتطلب تفاعل المستخدم (أي يجب أن يقول المستخدم - نعم ، أريد السماح بالتقاط لقطة شاشة ، مما يفسد كل شيء)

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

القائمة تطول - أعتقد أنه يمكنني كتابة كتاب. بالتأكيد ، UWP / WinRT رائعان من الناحية النظرية. ولكن عندما تبدأ في الاستخدام بعد ذلك ، حسنًا ..

من الصعب معرفة ما إذا كانت إلكترونية أم لا لأن موقع الويب والتطبيق يبدوان مختلفين اختلافًا كبيرًا. استنادًا إلى حقيقة أن مربعات الحوار تبدو تمامًا مثل تلك الافتراضية ، فقد تكون تطبيقات UWP.

حسنًا ، وجهة نظري هي - يتخلى الناس عن تطبيقات UWP - تفوق الفوائد العديد من المشكلات التي تأتي معها.

تضمين التغريدة
(فقط للتأكد من أنك على علم بذلك.)

اسمحوا لي ألا أبدأ بالحافظة - التي تعمل فقط عندما يكون تطبيقك في المقدمة.

لقد وصلت إلى نفس المشكلة (أو ما شابهها) أثناء تطوير أحد تطبيقات UWP الخاصة بي حيث كان علي وضع البيانات في الحافظة وفي النهاية قمت بحلها عبر عملية الثقة الكاملة win32 المصاحبة (والتي تستدعي فقط Win32's SetClipboardData ). إذا كان مفهوم وجود عملية ثقة كاملة win32 مصاحبة لتطبيق UWP الخاص بك هو خبر جديد بالنسبة لك ، فستحصل على مقدمة جيدة هنا (عمل المؤلف سابقًا على UWP في Microsoft).

@ فيليكس ديف

لقد وصلت إلى نفس المشكلة (أو ما شابهها) أثناء تطوير أحد تطبيقات UWP الخاصة بي حيث كان علي وضع البيانات في الحافظة وفي النهاية قمت بحلها عبر عملية الثقة الكاملة win32 المصاحبة (والتي تستدعي فقط Win32's SetClipboardData ). إذا كان مفهوم وجود عملية ثقة كاملة win32 مصاحبة لتطبيق UWP الخاص بك هو خبر جديد بالنسبة لك ، فستحصل على مقدمة جيدة هنا (عمل المؤلف سابقًا على UWP في Microsoft).

شكرا للمؤشر! لقد علمت بعملية الثقة الكاملة لـ win32. ربما قرأت هذه المقالات عدة مرات :) لقد فكرت بالفعل في الحصول على تطبيق مصاحب لعملية الثقة الكاملة win32 عدة مرات. اخترت عدم القيام بذلك ، بسبب التعقيد الإضافي - أنا أعاني بالفعل من أجل إنشاء مجموعات الإعداد التي تعمل بالفعل بدون متجر MS. لم أرغب في إدخال هذا في المعادلة أيضًا.

إذن أنت تبني شيئًا مشابهًا لـ Windows Explorer يقوم بمعاينة ملفات الفيديو في المجلدات؟

هذا جزء من معالج من تطبيقي.

يبدو هذا النوع مثل مستكشف الملفات بخطوات إضافية (⊙ˍ⊙)

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

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

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

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

هناك مشكلة أخرى تتمثل في شعار "دعنا نحصل على معلومات غير متزامنة" - وهو الأمر الذي أكرهه بشدة. أنا أتعامل مع العرض الذي يجب أن يكون فوريًا ، لكن تحميل الصور النقطية غير متزامن. لذلك كان عليّ بناء آلية تخزين مؤقت معقدة حقًا من أجل ذلك فقط.

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

ج #
// سيتم حظر الخيط حتى ينتهي MyAsyncMethod
var myResult = MyAsyncMethod (). نتيجة ؛

// سينتهي هذا أيضًا عندما تنتهي الطريقة من التنفيذ.
// لاحظ أن ConfigureAwait قد تؤدي إلى استدعاء الطريقة في سياق مختلف
var myResult2 = MyAsyncMethod (). ConfigureAwait (خطأ) ،
" For ConfigureAwait" يمكنك إلقاء نظرة على المقالة التالية: https://devblogs.microsoft.com/dotnet/configureawait-faq/

ويتيح عدم الدخول في أوقات التجميع. وفي بعض الأحيان عند البناء ، أحصل على "... تم إنشاء dll في وضع الإصدار" (والذي لا يمكن أن يكون في الأساس ، لأنني أقوم ببناء تصحيح الأخطاء). الحل هو ببساطة تنظيف كل الحلول وإعادة البناء (الذي يستغرق 1+ دقيقة).

إن "... dll" المدمج في وضع الإصدار غريب. ربما تحقق مما إذا كانت ملفات المشروع غير متماسكة؟ فيما يتعلق بوقت الترجمة ، نعم هذا مزعج بعض الشيء ، على الرغم من أن دقيقة واحدة لا تزال على ما يرام ، يستغرق WinUI حوالي 5-10 دقائق

ونعم ، تعطل. تتعطل VS كل 10-20 جولة ، يتفوق علي لماذا.

نعم ، هذا أمر مزعج للغاية ، على الرغم من أنني لا أعتقد أن هذا يعتمد حقًا على UWP ولكن فقط Visual Studio بشكل عام (لا تزال عملية 32 بت لسبب ما!).

حسنًا ، أتمنى لو كان لدي مقارنة متجر Apple - أنا متأكد تمامًا من أن أفضل تطبيقاتهم بها ملايين المراجعات. الفكرة هي أن متجر MS لم يتم اكتشافه أبدًا - لأن الناس يتخلون ببساطة عن UWP / WinRT. لو لم أكن بحاجة إلى win2d ، لكنت استسلمت 20 مرة على الأقل.

يبدو أنه يمكنك استخدام Win2D مع WPF: https://github.com/Microsoft/Win2D/issues/660

فقط فكر في ذلك - أحتاج أن أطلب من Windows الانتقال إلى وضع ملء الشاشة ، كتطبيق UWP. هذا أبعد من الجنون. ولجعل الأمر أكثر غباءً ، فلن يتم تطبيق ذلك إلا في الجولة التالية.

يبدو أنه من الممكن الحصول على تطبيق UWP في وضع ملء الشاشة ، حتى عند بدء التشغيل: https://stackoverflow.com/questions/31758775/windows-10-universal-app-run-in-fullscreen-mode-by-default
(على الرغم من أنني لم أحاول إرسال تطبيق بذلك)

كنت أنظر إلى واجهة برمجة التطبيقات "Grab a screenshot of the screen" - لقد تخلت عنها ببساطة ، إنها عديمة الفائدة. أردت أساسًا الحصول على طريقة رائعة لبدء التطبيق ، استنادًا إلى الشاشة الحالية (نوعًا ما ، انتقل إلى تطبيقي) -> هذا غير ممكن ، لأنه يتطلب تفاعل المستخدم (أي يجب أن يقول المستخدم - نعم ، أريد السماح بالتقاط لقطة شاشة ، مما يفسد كل شيء)

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

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

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

https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.datatransfer.clipboard

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

حسنًا ، وجهة نظري هي - يتخلى الناس عن تطبيقات UWP - تفوق الفوائد العديد من المشكلات التي تأتي معها.

ربما ، ولكن أيضًا من خلال حقيقة أنه من الأسهل كتابة موقع ويب وتعبئته داخل Electron وشحنه إلى Mac و Linux و Windows بدلاً من كتابة تطبيقات منفصلة لجميع الأنظمة الأساسية.

يبدو هذا النوع مثل مستكشف الملفات بخطوات إضافية (⊙ˍ⊙)

ليست كذلك. بعيد عنه.

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

أنا لا أقول إن الحل هو الحل الصحيح. من الواضح أنني أفضل ألا أكون في وضع الحماية على الإطلاق ، فأنا أقول فقط أن التنفيذ الحالي سيء للغاية.

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

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

إن وجود كل شيء غير متزامن يجبرني على استدعاء الانتظار ووضع علامة على الوظائف غير متزامنة.

[...] مقابل ConfigureAwait يمكنك إلقاء نظرة على المقالة التالية: https://devblogs.microsoft.com/dotnet/configureawait-faq/

شكرا انا اعرف عن هذا هناك مشكلة أخرى واجهتني وهي تحميل صورة نقطية (غير متزامن) تمامًا كما اقترحت. بين الحين والآخر ، كنت أواجه أوقات انتظار مجنونة ، مثل 5-6 ثوانٍ لتحميل صورة نقطية.
انتهى بي الأمر بعمل الحلول.

إن "... dll" المدمج في وضع الإصدار غريب. ربما تحقق مما إذا كانت ملفات المشروع غير متماسكة؟ فيما يتعلق بوقت الترجمة ، نعم هذا مزعج بعض الشيء ، على الرغم من أن دقيقة واحدة لا تزال على ما يرام ، يستغرق WinUI حوالي 5-10 دقائق

نعم ، لا أريد حتى التفكير في ذلك :) لست متأكدًا مما تقصده بشأن عدم ترابط ملفات المشروع.

ونعم ، تعطل. تتعطل VS كل 10-20 جولة ، يتفوق علي لماذا.

نعم ، هذا أمر مزعج للغاية ، على الرغم من أنني لا أعتقد أن هذا يعتمد حقًا على UWP ولكن فقط Visual Studio بشكل عام (لا تزال عملية 32 بت لسبب ما!).

أعتقد أنه متعلق بـ UWP. لم يحدث هذا لي أبدًا عند التعامل مع WPF - كان لدي 28 مشروعًا ، ولم ينهار أبدًا. في UWP لدي 15 مشروعًا (قمت بنقلها من WPF) ، وتعطل. وإذا نظرت في Event Viewer ، فهناك شيء ما يتعلق بانهيار sandbox - لا أتذكره بالضبط.

يبدو أنه يمكنك استخدام Win2D مع WPF: microsoft / Win2D # 660

كانت تلك محاولتي الأولى. إنه حظر كامل. واجهت الكثير من القضايا ، لدرجة أنني استسلمت في النهاية. الكود الذي يتعامل مع win2d معقد للغاية ، لذلك اعتقدت أنه سيستغرق وقتًا أطول لكتابته أعلى WPF بدلاً من استخدام UWP مباشرةً.

بقدر ما أكره إعداد UWP كما هو ، كنت على صواب. لم أكن لأتمكن من جعلها تعمل بشكل صحيح. وأفترض أنك على دراية بـ https://github.com/microsoft/Win2D/issues/731

فقط فكر في ذلك - أحتاج أن أطلب من Windows الانتقال إلى وضع ملء الشاشة ، كتطبيق UWP. هذا أبعد من الجنون. ولجعل الأمر أكثر غباءً ، فلن يتم تطبيق ذلك إلا في الجولة التالية.

يبدو أنه من الممكن الحصول على تطبيق UWP في وضع ملء الشاشة ، حتى عند بدء التشغيل: https://stackoverflow.com/questions/31758775/windows-10-universal-app-run-in-fullscreen-mode-by-default

أنا آسف ، لقد قصدت "الوصول إلى الحد الأقصى" - آسف لذلك.

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

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

https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.datatransfer.clipboard

ولكن لماذا تحتاج إلى الوصول إلى الحافظة عندما لا يستخدم المستخدم تطبيقك؟ [...]

الشيء المضحك هو هذا - أردت نسخ شيء ما إلى الحافظة عند بدء التشغيل. ومع ذلك ، كان هذا في مُنشئ MainPage ، لذا على ما يبدو ، لم أكن في المقدمة بعد. عملت خادعًا في Debug ، وتحطمت في Release - وبهذا ، أعني بالضبط عند بدء التشغيل ، لا تسجيل ولا شيء.

حسنًا ، وجهة نظري هي - يتخلى الناس عن تطبيقات UWP - تفوق الفوائد العديد من المشكلات التي تأتي معها.

ربما ، ولكن أيضًا من خلال حقيقة أنه من الأسهل كتابة موقع ويب وتعبئته داخل Electron وشحنه إلى Mac و Linux و Windows بدلاً من كتابة تطبيقات منفصلة لجميع الأنظمة الأساسية.

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

تضمين التغريدة

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

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

لا يعد استخدام Win32 خارج وضع الحماية لـ UWP دائمًا لأن المطور يريد تحقيق شيء ما دون معرفة المستخدم به. لذلك ، في حين أن وضع الحماية بشكل عام يوفر قيمة لنا نحن المستخدمين ، فلا يزال يتعين عليك التعامل معه كمطور في أي حال ، حتى لو لم تكن مطورًا ضارًا لا يمانع في التجسس على المستخدم أو ليس لديه نية في طلب ذلك موافقة المستخدم قبل تغيير شيء ما في نظامه.

حقيقة أنه يمكنك استخدام عملية الثقة الكاملة Win32 وجنبا إلى جنب مع التطبيق يشير إلى أن MS يدرك هذه المعضلة ولا تعطينا المشروعات الإنمائية الأدوات اللازمة لاستخدام UWP ويكون لا يزال قادرا على التمتع بحرية Win32 وإلى حد جيد.

ليست كذلك. بعيد عنه.

هل يمكن للمرء تنزيل التطبيق الآن؟ إذا كان الأمر كذلك ، أين يمكنني أن أجده؟ 😅

من الواضح أنني أفضل ألا أكون في وضع الحماية على الإطلاق ، فأنا أقول فقط أن التنفيذ الحالي سيء للغاية.

أعتقد ، إذا كنت لا تحب وضع الحماية ، فربما يكون التبديل إلى بديل WPF هو الخيار الأفضل ، بدلاً من مجرد محاولة تطوير تطبيقاتك في UWP ، وهو ما أوضحته ، تعتقد أنه "مستحيل" أو "صعب للغاية" تطوير تطبيقات لـ. لا أعتقد أن بدائل WPF سيئة للغاية مقارنة بنظام Win2D ، فهذا من شأنه أن يبرر خوضك جميع معاناتك. لكن هذه فقط وجهة نظري حول ذلك.

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

لست متأكدًا مما تقصده بشأن عدم ترابط ملفات المشروع.

ربما تكون ملفات المشروع الخاصة بالتصحيح خاطئة ويتم إنشاء بعض ملفات dll في الإصدار ، على الرغم من أنني أشك في أن هذا سيحدث إذا كنت تسمح لبرنامج Visual Studio بمعالجة ذلك.

أعتقد أنه متعلق بـ UWP. لم يحدث هذا لي أبدًا عند التعامل مع WPF - كان لدي 28 مشروعًا ، ولم ينهار أبدًا. في UWP لدي 15 مشروعًا (قمت بنقلها من WPF) ، وتعطل. وإذا نظرت في Event Viewer ، فهناك شيء ما يتعلق بانهيار sandbox - لا أتذكره بالضبط.

تعتمد موثوقية Visual Studio بشكل كبير على حجم المشروع بالنسبة لي. تعمل UWP / NetCore / NetFramework الصغيرة / المتوسطة دائمًا بشكل جيد. تؤدي المشاريع الكبيرة إلى عدم استجابة Visual Studio أو تعليقه أو تعطله في الوقت المناسب. لكن هذه مجرد تجربتي.

أنا آسف ، لقد قصدت "الوصول إلى الحد الأقصى" - آسف لذلك.

في هذه الحالة ، نعم ، سيتم تطبيق التغيير فقط عند بدء التشغيل التالي ، نظرًا لأنك قمت بتعيين القيمة له بعد بدء تطبيقك. لا أعرف ماذا تقصد بعبارة "يجب أن أسأل Windows". هل تشير إلى حقيقة أنه يجب عليك ضبطه في الكود؟

هناك أيضًا طريقة لتعيين الحجم المفضل ، والذي يجب أن يؤدي إلى أن يشغل التطبيق كل المساحة الموجودة على الشاشة التي يعمل عليها (على غرار المكبر) على الرغم من أنها ليست جيدة تمامًا مثل التكبير الحقيقي:
https://stackoverflow.com/questions/35247320/how-to-maximize-a-uwp-window-not-fullscreen؟rq=1

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

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

بقدر ما أكره إعداد UWP كما هو ، كنت على صواب. لم أكن لأتمكن من جعلها تعمل بشكل صحيح. وأفترض أنك على دراية بـ Microsoft / Win2D # 731

لم أكن على علم بذلك ، اعتقدت أنه نظرًا لكون المشكلة التي ذكرتها منذ عام 2018 ، سيتم حلها بشكل جيد الآن.

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

حسنًا ، هذا غريب جدًا. يجب أن يكون السلوك متسقًا.

الشيء المضحك هو هذا - أردت نسخ شيء ما إلى الحافظة عند بدء التشغيل.

يذكرون أيضًا حالة الاستخدام هذه في الوثائق ، وعليك انتظار CoreWindow.Activate to copy. لماذا بالضبط تنسخ شيئًا ما إلى الحافظة ، عندما بدأ المستخدم للتو تطبيقك؟ شيء مشابه لما يريد @ Felix-Dev تحقيقه / تحقيقه؟

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

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

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

فيما يتعلق بالنقطة الأخيرة ، نعم ، حقيقة أنه يمكنك استخدام عمليات Win32 هي إشارة إلى أن هناك حالات يحدك فيها UWP.
ربما كان هذا هو الحل الأسهل / الأسرع في متناول اليد ، أو ربما يكون في الواقع حسب التصميم.

ليست كذلك. بعيد عنه.

هل يمكن للمرء تنزيل التطبيق الآن؟ إذا كان الأمر كذلك ، أين يمكنني أن أجده؟ 😅

هنا -> https://phot-awe.com

أعتقد ، إذا كنت لا تحب وضع الحماية ، فربما يكون التبديل إلى بديل WPF هو الخيار الأفضل ، بدلاً من مجرد محاولة تطوير تطبيقاتك في UWP ، وهو ما أوضحته ، تعتقد أنه "مستحيل" أو "صعب للغاية" تطوير تطبيقات لـ. لا أعتقد أن بدائل WPF سيئة للغاية مقارنة بنظام Win2D ، فهذا من شأنه أن يبرر خوضك جميع معاناتك. لكن هذه فقط وجهة نظري حول ذلك.

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

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

كان بإمكاني أن أقسم أنك قادم من خلفية ويب :)

ربما تكون ملفات المشروع الخاصة بالتصحيح خاطئة ويتم إنشاء بعض ملفات dll في الإصدار ، على الرغم من أنني أشك في أن هذا سيحدث إذا كنت تسمح لبرنامج Visual Studio بمعالجة ذلك.

ليس هذا هو الحال ، لكنني قمت بالتحقق مرة أخرى - ليس هذا هو الحال.

تعتمد موثوقية Visual Studio بشكل كبير على حجم المشروع بالنسبة لي. تعمل UWP / NetCore / NetFramework الصغيرة / المتوسطة دائمًا بشكل جيد. تؤدي المشاريع الكبيرة إلى عدم استجابة Visual Studio أو تعليقه أو تعطله في الوقت المناسب. لكن هذه مجرد تجربتي.

نعم ، لقد تعاملت مع ذلك في الماضي. لا يبدو أن هذا هو الحال مع أحدث إصدارات VS (2017-2019). على أي حال ، قصة قصيرة طويلة ، حدث هذا للتو على UWP بالنسبة لي. قد يتعلق الأمر بحقيقة أنني أستخدم win2d ، ولدي شعور بأنه وحش معقد تمامًا.

في هذه الحالة ، نعم ، سيتم تطبيق التغيير فقط عند بدء التشغيل التالي ، نظرًا لأنك قمت بتعيين القيمة له بعد بدء تطبيقك. لا أعرف ماذا تقصد بعبارة "يجب أن أسأل Windows". هل تشير إلى حقيقة أنه يجب عليك ضبطه في الكود؟

في WPF ، أقوم ببساطة بتعيين حجم النافذة على المكان الذي أريده. هنا ، هناك واجهة برمجة تطبيقات تحتاج إلى الاتصال بها -> ApplicationView.PreferredLaunchViewSize - والتي ، كما يقول المستندات "تعمل ، باستثناء الحالات التي يدير فيها النظام حجم النافذة مباشرة." - ونعم ، إنه يعمل فقط لبدء التطبيق التالي.

هناك أيضًا طريقة لتعيين الحجم المفضل ، والذي يجب أن يؤدي إلى أن يشغل التطبيق كل المساحة الموجودة على الشاشة التي يعمل عليها (على غرار المكبر) على الرغم من أنها ليست جيدة تمامًا مثل التكبير الحقيقي:
https://stackoverflow.com/questions/35247320/how-to-maximize-a-uwp-window-not-fullscreen؟rq=1

أنا أستخدم رمزًا آخر يعمل بشكل صحيح بالفعل

var view = DisplayInformation.GetForCurrentView();
var resolution = new Size(view.ScreenWidthInRawPixels, view.ScreenHeightInRawPixels);
var scale = view.ResolutionScale == ResolutionScale.Invalid ? 1 : view.RawPixelsPerViewPixel;
var bounds = new Size(resolution.Width / scale, resolution.Height / scale);

ApplicationView.PreferredLaunchViewSize = new Size(bounds.Width, bounds.Height);
ApplicationView.PreferredLaunchWindowingMode = ApplicationViewWindowingMode.PreferredLaunchViewSize;

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

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

لم أكن على علم بذلك ، اعتقدت أنه نظرًا لكون المشكلة التي ذكرتها منذ عام 2018 ، سيتم حلها بشكل جيد الآن.

لم يحدث ذلك - على الأقل في المرة الأخيرة التي راجعت فيها.

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

حسنًا ، هذا غريب جدًا. يجب أن يكون السلوك متسقًا.

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

يذكرون أيضًا حالة الاستخدام هذه في الوثائق ، وعليك انتظار CoreWindow.Activate to copy. لماذا بالضبط تنسخ شيئًا ما إلى الحافظة ، عندما بدأ المستخدم للتو تطبيقك؟ شيء مشابه لما يريد @ Felix-Dev تحقيقه / تحقيقه؟

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

هنا -> https://phot-awe.com

شكرا!

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

لم أكن أعلم أن WPF يعاني من تراجع كبير في الأداء مقارنةً بـ UWP.

ليس هذا هو الحال ، لكنني قمت بالتحقق مرة أخرى - ليس هذا هو الحال.

هذا غريب. كنت أتوقع أن يكون هناك شيء خاطئ. لماذا يتحدث VS عن Release dll عند تشغيل التصحيح.

في WPF ، أقوم ببساطة بتعيين حجم النافذة على المكان الذي أريده. هنا ، هناك واجهة برمجة تطبيقات تحتاج إلى الاتصال بها - ApplicationView.PreferredLaunchViewSize - والتي ، كما يقول المستندات "تعمل ، باستثناء الحالات التي يدير فيها النظام حجم النافذة مباشرة."

ولكن أليس الرمز الذي تستخدمه أيضًا واجهة برمجة تطبيقات لتعيين حجم النافذة؟

• ونعم ، إنه يعمل فقط لبدء التطبيق التالي.

ليس من المستغرب عندما يطلق عليه "PreferredLaunchViewSize" 😅
مجرد مزعج قليلاً أنه لا توجد طريقة لضبط هذا بعد الإطلاق.

نعم ، لقد تعاملت مع ذلك في الماضي. لا يبدو أن هذا هو الحال مع أحدث إصدارات VS (2017-2019). على أي حال ، قصة قصيرة طويلة ، حدث هذا للتو على UWP بالنسبة لي.

سعيد لسماع أنه ليس سيئًا كما كان مع الإصدارات السابقة من VS.

قد يتعلق الأمر بحقيقة أنني أستخدم win2d ، ولدي شعور بأنه وحش معقد تمامًا.

لا أعتمد على المصمم كثيرًا لأنه بدأ بالفشل في عمليات ربط القوالب. هل جربت Blend for Visual Studio؟ هل هذا أكثر موثوقية فيما يتعلق بالمصمم؟

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

نعم يمكنني تخيل ذلك. الشيء الذي قد يكون جيدًا هو دليل الانتقال من WPF إلى UWP. إذا كان هذا موجودًا ، فمن المؤكد أن ذلك سيوفر الكثير من الوقت على مطوري UWP الجدد و WPF السابق. ولن تكون هذه هي المرة الأولى التي يوجد فيها دليل انتقالي. يوجد بالفعل دليل Java to C # ، والذي يساعد كثيرًا لمطوري Java.

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

حسنا أرى ذلك. إذا لم يفكر المرء في فتح المجلد ، فإن نسخ مسار المجلد إلى الحافظة يعد حلاً. لأغراض الاختبار ، هذا ذكي تمامًا.

لم أكن أعلم أن WPF يعاني من تراجع كبير في الأداء مقارنةً بـ UWP.

لم يتم تحسين WPF لـ DirectX - عندما يتم تشغيل تظليل البكسل والأقنعة ، ينتهي الأمر بالبطء الشديد. أدى النقل إلى UWP / win2d إلى جعل التطبيق أسرع 3-4 مرات. هذا ملحوظ بجنون.

هذا غريب. كنت أتوقع أن يكون هناك شيء خاطئ. لماذا يتحدث VS عن Release dll عند تشغيل التصحيح.

نعم ، وجهة نظري بالضبط.

ولكن أليس الرمز الذي تستخدمه أيضًا واجهة برمجة تطبيقات لتعيين حجم النافذة؟

ما أعنيه ، أنت تستخدم الحجم المفضل ... الحجم ، لكنك لست مضمونًا أنه سيحدث. كما هو الحال عند استخدام WPF ، فأنت مضمون عند تعيين المركز / الحجم ، فسيحدث ذلك بالفعل.

ليس من المستغرب عندما يطلق عليه "PreferredLaunchViewSize" 😅
مجرد مزعج قليلاً أنه لا توجد طريقة لضبط هذا بعد الإطلاق.

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

لا أعتمد على المصمم كثيرًا لأنه بدأ بالفشل في عمليات ربط القوالب. هل جربت Blend for Visual Studio؟ هل هذا أكثر موثوقية فيما يتعلق بالمصمم؟

كان يجب أن أكون أكثر تحديدًا - لا يتعطل VS عند تحرير xaml - إنه يتعطل عند تشغيل التطبيق ؛ في الأساس ، أفترض أن ذلك يحدث بالضبط عند النشر ، نظرًا لأنك ترى فقط علامة "x" الكبيرة على تطبيق (uwp) لمدة 10 ثوانٍ تقريبًا ، وعند هذه النقطة أعلم أنه توقف. عند هذه النقطة يمكنني الانتظار 45-60 ثانية أخرى وأرى أن VS سيتعطل ، أو أغلق فقط VS من Task Manager.

نعم يمكنني تخيل ذلك. الشيء الذي قد يكون جيدًا هو دليل الانتقال من WPF إلى UWP.

نعم ، سيكون ذلك مفيدًا جدًا.

حسنا أرى ذلك. إذا لم يفكر المرء في فتح المجلد ، فإن نسخ مسار المجلد إلى الحافظة يعد حلاً. لأغراض الاختبار ، هذا ذكي تمامًا.

شكرًا ؛) حسنًا ، كان من الممكن أن يكون ذكيًا ، لو نجح بالفعل :)

تضمين التغريدة

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

اسمح لي أن أقدم لك سببًا آخر لأكره عدم التزامن - لقد حدث هذا لي الآن (في الأساس ، إنه تقرير خطأ من مستخدم). في البداية ، لم أستطع معرفة ذلك طوال حياتي.

قصة طويلة قصيرة - عند النقر على زر ، أفتح منتقي الملفات. وهو ، كما خمنت ، غير متزامن.

لذلك ، قام المستخدم بالنقر فوقه مرتين (مع توقف حوالي 100 مللي ثانية بين النقرات). بالتأكيد ، فتح هذا 2 منتقي الملفات.

الآن ، من الواضح أنني أستطيع إصلاح هذا ، لكن هذا لن يحدث أبدًا ، لو كانت الوظيفة الأولية متزامنة (وبالطبع ، لن يحدث هذا أبدًا في WPF).

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

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

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

لا أستطيع أن أفعل ذلك. هل تعتقد أن المستخدم سيوافق على "التغييرات لن تحدث إلا بعد إعادة التشغيل"؟

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

لذلك ، قام المستخدم بالنقر فوقه مرتين (مع توقف حوالي 100 مللي ثانية بين النقرات). بالتأكيد ، فتح هذا 2 منتقي الملفات.

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

قصة طويلة قصيرة - عند النقر على زر ، أفتح منتقي الملفات. وهو ، كما خمنت ، غير متزامن.

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

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

اسمحوا لي أن أبدأ بقول هذا باحترام: لن نتفق أبدًا على أي شيء .

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

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

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

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

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

لا أستطيع أن أفعل ذلك. هل تعتقد أن المستخدم سيوافق على "التغييرات لن تحدث إلا بعد إعادة التشغيل"؟

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

ولدي تجربة بدء تشغيل سيئة ، لأنني أعرض نافذة تبدو جيدة فقط بحجم معين - ويقول Windows فقط "أوه ، لكنني سأعرض التطبيق كما أريد".

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

هل تفعل هذا بصدق؟ أرني كيف قطع رمز حيث فعلت ذلك بوعي.

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

كيف يتعامل WPF مع هذا؟ يتعامل معها بشكل صحيح. لا يتم حظر واجهة المستخدم ، ولكن التطبيق يحظر عند هذه المكالمة - لذلك لن يحدث ما سبق في WPF

اسمحوا لي أن أبدأ بقول هذا باحترام: لن نتفق أبدًا على أي شيء.

إذا كان هذا هو رأيك في هذه المناقشة ، فأنا آسف لذلك.

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

أعتقد أن الوصف الأكثر دقة سيكون: أنا قادم من خلفية حيث لا يستطيع المطورون الوصول إلى أي شيء وأنت قادم من خلفية حيث يمكن للمطورين الوصول إلى كل موارد نظام التشغيل.

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

نعم ، تعمل المعالجات بأحجام أصغر ولكن معظم المعالجات (بما في ذلك Visual Studio 2019 Startup "Wizard") تغلق نفسها ثم تبدأ البرنامج الحقيقي. إنهم لا "يتحولون" إلى التطبيق الفعلي.

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

ولدي تجربة بدء تشغيل سيئة ، لأنني أعرض نافذة تبدو جيدة فقط بحجم معين - ويقول Windows فقط "أوه ، لكنني سأعرض التطبيق كما أريد".

تجعل الأمر يبدو كما لو أن Windows يتجاهل التعليمات البرمجية الخاصة بك طوال الوقت ، في حين أنه من الواضح متى سيتجاهل ذلك (مأخوذ من وثائق "PreferredLaunchViewSize"):

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

لذلك فهو يعمل فقط على سطح المكتب في وضع غير الكمبيوتر اللوحي. ولكن هل من المنطقي أن تطلب الأجهزة الأخرى أحجامًا فعلية؟ هل تتوقع أن يعمل تطبيقك على X-Box أو Holo Lens ، وهل قمت بالتحسين لمثل هذه الأجهزة؟ إذا لم يكن الأمر كذلك ، فلا ينبغي أن يزعجك هذا القيد كثيرًا.

هل تفعل هذا بصدق؟ أرني كيف قطع رمز حيث فعلت ذلك بوعي.

لا أنا لست كذلك ، كنت أحاول فقط أن أشير إلى حقيقة أنك تلوم "غير المتزامن" على شيء لا علاقة له بذلك. إذا نقر المستخدمون على زر مرتين ، فسيتم تشغيل الحدث الذي تم النقر عليه مرتين.

كيف يتعامل WPF مع هذا؟ يتعامل معها بشكل صحيح. لا يتم حظر واجهة المستخدم ، ولكن التطبيق يحظر عند هذه المكالمة - لذلك لن يحدث ما سبق في WPF

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

مرحبًا ، أنا قائد مطوري Windows SDK والبنية التحتية لـ Windows Runtime في فريق نظام التشغيل Windows.

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

ربما لا يكون هذا هو أفضل مكان لقضايا winrt العامة. يمكنك إما إثارة المشكلات في منتديات مطوري Microsoft ، أو لمشكلات Windows Runtime على وجه التحديد ، يمكنك فتح مشكلة في https://github.com/microsoft/xlang. يقوم فريقنا بمراجعة المشكلات الواردة هناك بشكل منتظم. ستصل المشكلات المقدمة في github إلى فريقي بشكل أسرع ، لكن تتبعها أقل. إذا كانت تعليقاتك تتطلب تغييرات في نظام التشغيل ، فإن الحفاظ على نظام التشغيل متزامنًا مع مشكلة github المقدمة هو عملية يدوية. من ناحية أخرى ، تتبع ملاحظات المنتدى العمل عبر الفرق والمؤسسة ، ومن غير المرجح أن تنفصل عن العمل الفعلي المنجز بناءً على التعليقات.

شكرا مرة أخرى على المناقشة الحية. سوف أنشر مرة أخرى على هذه المسألة قريبا.

بن كون
مايكروسوفت

مرحبا بن،

مرحبًا ، أنا قائد مطوري Windows SDK والبنية التحتية لـ Windows Runtime في فريق نظام التشغيل Windows.

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

رائع - نتطلع إلى ردك (ردودك)!

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

ربما لا يكون هذا هو أفضل مكان لقضايا winrt العامة. يمكنك إما إثارة المشكلات في منتديات مطوري Microsoft ، أو لمشكلات Windows Runtime على وجه التحديد ، يمكنك فتح مشكلة في https://github.com/microsoft/xlang.

متفق عليه أنه ليس أفضل مكان ، المشكلة هي أن الناس لا يعرفون مكان النشر.

إذا قلت أنه يجب علينا النشر على https://github.com/microsoft/xlang ، فسأقوم بالتأكيد بالنشر هناك من الآن فصاعدًا.

أفضل،
يوحنا

أولاً ، اسمحوا لي أن أتحدث عن بعض الأشياء التي لن أتطرق إليها.

• هناك الكثير من المناقشات الرائعة حول وضع النوافذ ، وموضع النافذة ، وما إلى ذلك بالقرب من أسفل سلسلة المحادثات. ربما لا يزال هذا بعيدًا عن الموضوع قليلاً بالنسبة لـ WinUI ، ولكنه أقرب إلى المنزل. أود السماح لأفراد WinUI بتحليل الملاحظات حول موضع النافذة وملء الشاشة وما إلى ذلك والمساعدة في إعادة التوجيه. StephenLPeters ، هل يمكنك المساعدة في هذا؟

• لن أتطرق إلى تعليقات VS. هناك منتدى صحي لمناقشة جودة VS والأداء. على الرغم من أنني لاحظت المناقشة التي مفادها أن قصة تطوير تطبيقات Windows من Visual Studio أصبحت أكثر تعقيدًا وتشويشًا بعض الشيء.

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

ثانيًا ، verelpode : هذا جعلني أضحك. هل تمانع إذا تمسكت بهذا؟
"أعتقد أنه لا يمكنك التعامل مع الحقيقة المباشرة ، لذلك سأتعامل معك بقفازات قطنية سميكة ورقيقة ، وأحزمك في غلاف فقاعات"

حسنًا ، الآن إلى الموضوعات الحقيقية.

WinRT مقابل UWP مقابل .NET - بعض المعلومات الأساسية

Windows Runtime عبارة عن شيئين مدمجين في أحدهما ، ومعبأان في الآخر ، وقد أسيء فهمهما حقًا.

نظام نوع Windows Runtime هو حقًا ، بمعنى ما ، COM V2. إنها الخطوة الروحية التالية في التقدم من بدء المقاطعات ، إلى استدعاء Win32 ، إلى استدعاء واجهات برمجة تطبيقات COM. يعد نظام الكتابة من بعض النواحي أقل تعبيرًا قليلاً في COM ، ولكن في معظم النواحي مجموعة شاملة كبيرة. تم تصميمه في الأصل لمعالجة مشكلة واحدة بالضبط: كيف نجعل الأمر أسهل للمطورين الذين يستخدمون .NET أو لغات أخرى لاستدعاء WinRT APIs دون الحاجة إلى انتظار VS لصنع أغلفة لطيفة في إطار عمل .NET.

ثم هناك مكتبة API. قمنا ببعض الأشياء الرائعة هنا ، وبعض الأشياء السخيفة. ربما نكون قد انجرفنا قليلاً مع بعض الأشياء غير المتزامنة. إذا قمت بالبرمجة باستخدام C ++ / WinRT ، فيمكنك تخفيف ذلك بشكل كبير. إذا لم تكن في مؤشر ترابط واجهة المستخدم ، فما عليك سوى الحصول على النتيجة وسيتم حظرها وإكمالها بشكل متزامن. قد يجعل NET هذا الأمر أسهل الآن ، لكنني أكتب كود NET أقل هذه الأيام ، وأنا أقل ثقة بشأن الحالة الحالية للأشياء. قمنا ببعض الأشياء الأخرى التي لم تعمل كما هو مخطط لها أيضًا. لن أسردهم جميعًا. لقد أجرينا بعض التحسينات على الرغم من ذلك.

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

تم التطرق أيضًا إلى قابلية نقل الكود بين تطبيقات UWP وتطبيقات سطح المكتب في هذا الموضوع. نظرًا لأن نموذج UWP تباعد كثيرًا ، فهناك عدد من نقاط الألم. نحن نتعامل معها بأسرع ما يمكن عمليًا. يستغرق البعض وقتًا ، أو يتطلب "فترات راحة كبيرة". على سبيل المثال ، نستخدم أسماء مختلفة لـ CRT DLLs. لقد قمنا بتجميع حزمة التخفيف ، حزمة إعادة توجيه VC ، ولكن الإصلاح الحقيقي سيكون في النهاية إزالة التمييز في إصدار مستقبلي من CRT ، والذي يتطلب بطبيعته إعادة تسمية الملفات وتغيير كسر رئيسي. نحن لا نفعل هذا عن قصد بشكل متكرر لأنه يؤدي إلى التخريب.

تعمل WinRT نفسها بشكل متزايد على نقل الأدوات مفتوحة المصدر ، وعلى الرغم من أنها ليست معروفة جيدًا ، فإن معظم WinRT متاح لتطبيقات سطح المكتب. كان XAML هو الفجوة الكبيرة. كانت جزر XAML خطوة في الاتجاه الصحيح ، لكنني متحمس جدًا بشأن WinUI.

تعليقات على واجهات برمجة تطبيقات محددة

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

تعد واجهات برمجة تطبيقات نظام الملفات للتطبيقات الحديثة بطيئة بشكل مؤلم وغير متوقع

https://docs.microsoft.com/answers/questions/608/please-either-allow-systemio-all-over-hdd-or-drast.html
لقد سمعنا هذه التعليقات ، سواء من العملاء أو من فرقنا الخاصة ببناء التطبيقات. أتمنى لو كان لدي المزيد الذي يمكنني مشاركته في هذا الوقت. الآن كل ما يمكنني قوله ، للأسف ، هو "نعلم".

واجهة برمجة تطبيقات BroadSystemAccess / القدرة ليست عملية كما تم تنفيذها.

https://docs.microsoft.com/answers/questions/6483/is-uwp-the-right-development-tool-for-my-project.html
الرجاء إرسال عنصر محور التعليقات وإرسال الرابط إلي. سأقوم شخصيًا بالترويج لها وتسليمها إلى المالك المناسب. معدل التراجع بنسبة 80٪ ليس جيدًا. أنا أفهم النقطة المتعلقة بكونها علامة حمراء للمستخدمين أيضًا. إذا كانت واجهات برمجة التطبيقات للملف سريعة بما فيه الكفاية ، فيبدو أن قائمة الوصول المستقبلية ستخفف على الأقل بعض الألم ، ولكنها قد لا تكون "رائعة" مثل ما لديك الآن. ولكن بعد ذلك ، فأنت بين المطرقة والسندان. لكي تكون ساحرًا بالطريقة التي تقوم بها الآن ، تحتاج إلى أن يسمح لك المستخدم برؤية كل شيء. جدول بيانات كلمة المرور ، ومجلد البريد ، وذاكرة التخزين المؤقت للمتصفح ، وما إلى ذلك ، قد تكون جديرًا بالثقة ، ولكن يجب أن يجعل تطبيقك المستخدمين يتوقفون مؤقتًا ويفكرون في مدى ثقتهم بك قبل تسليم عالمهم.

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

فيما يتعلق بما إذا كانت قائمة الوصول المستقبلية يمكنها الوصول إلى المجلدات الفرعية ، فقد تقدمت وأنشأت مشكلة في التوثيق للصفحة. https://github.com/MicrosoftDocs/windows-uwp/issues/2322. تجدر الإشارة إلى أنه نظرًا لأن صفحات المستندات موجودة على github ، يمكنك تقديم مشكلات في المستندات أو اقتراح تغييرات على المحتويات أيضًا.

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

إنشاء تطبيقات للتحميل الجانبي خارج متجر MS

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

لقد لاحظت أيضًا مشكلة معينة تتعلق بالحاجة إلى التوجيه عبر الخادم لتصحيح الأخطاء. أنه يجب عليك تقديم قضية مقابل مشروع جيثب الحالي.

إصدار الشهادة الجديدة والتوزيع الخاص

هذا أقرب قليلاً من المنزل (يتعامل فريقي الأكبر أيضًا مع جوانب تثبيت التطبيق. ما زلت أقدر مشكلة مركز التعليقات حول هذا الأمر التي يمكنني العمل من خلالها.

يؤثر نظام نوع WinRT على القدرة على تقديم واجهات برمجة تطبيقات ومكتبات رائعة

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

يجب أن يطالب مركز التعليقات عند التخلي لمنع الحذف العرضي للمحتوى

نعم ، سأقوم بإجراء +1 لذلك. يرجى تقديمه. توجد فئة في مركز الملاحظات ضمن تطبيقات لـ… محور الملاحظات. هذا ميتا جدا.

لا تزال واجهات برمجة التطبيقات غير المتزامنة خارج نطاق السيطرة ، وتبدو محرجة بالنسبة للأشياء التي لا ينبغي أن تكون غير متزامنة

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

لا توجد واجهات برمجة تطبيقات صوتية جيدة على WinRT

أنا لست خبيرًا في الصوت. لا تتردد في تقديم ملف في مركز الملاحظات ، لكنني سأقوم أيضًا بالاتصال بشريان الحياة هنا والقيام ببعض الأسئلة.

آلام الحافظة

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

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

تغليف

آمل أن يكون هذا مفيدًا. سأتعقب الموضوع وأتابع المشكلات المذكورة أعلاه كما هو مذكور إذا قمت بتقديمها.

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

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

شكرًا مرة أخرى على المناقشة الرائعة وجميع التعليقات التفصيلية حول العديد من الموضوعات.

بن كون
مايكروسوفت

لن يتم إغلاق تطبيقك إذا قدمت منتقي (منتقي) الملفات الذي يسمح للمستخدم باختيار ما يريد منح تطبيقك حق الوصول إليه.

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

BenJKuhn شكرا للإجابة التفصيلية. مقدر جدا جدا!

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

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

WinRT مقابل UWP مقابل .NET - بعض المعلومات الأساسية

ثم هناك مكتبة API. قمنا ببعض الأشياء الرائعة هنا ، وبعض الأشياء السخيفة. ربما نكون قد انجرفنا قليلاً مع بعض الأشياء غير المتزامنة.

تستطيع قول ذلك مجددا :)

تم التطرق أيضًا إلى قابلية نقل الكود بين تطبيقات UWP وتطبيقات سطح المكتب في هذا الموضوع [...] ولكن الإصلاح الحقيقي سيكون في النهاية إزالة التمييز في إصدار مستقبلي من CRT ، والذي يتطلب بطبيعته إعادة تسمية الملفات وتغيير كبير .

أي ETA؟ صافي 5؟

تعد واجهات برمجة تطبيقات نظام الملفات للتطبيقات الحديثة بطيئة بشكل مؤلم وغير متوقع

https://docs.microsoft.com/answers/questions/608/please-either-allow-systemio-all-over-hdd-or-drast.html
لقد سمعنا هذه التعليقات ، سواء من العملاء أو من فرقنا الخاصة ببناء التطبيقات. أتمنى لو كان لدي المزيد الذي يمكنني مشاركته في هذا الوقت. الآن كل ما يمكنني قوله ، للأسف ، هو "نعلم".

حتى الآن ، لدي حل بديل - بعيدًا عن المثالية ، لكنني الآن على ما يرام - https://github.com/microsoft/microsoft-ui-xaml/issues/1465#issuecomment -575987737

واجهة برمجة تطبيقات BroadSystemAccess / القدرة ليست عملية كما تم تنفيذها.

https://docs.microsoft.com/answers/questions/6483/is-uwp-the-right-development-tool-for-my-project.html
الرجاء إرسال عنصر محور التعليقات وإرسال الرابط إلي. سأقوم شخصيًا بالترويج لها وتسليمها إلى المالك المناسب. معدل التراجع بنسبة 80٪ ليس جيدًا. أفهم

سأفعل ، آمل أن أصل إليه خلال عطلة نهاية الأسبوع.

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

نعم ، إذا كانت واجهة API الخاصة بملف التخزين / المجلد بنفس سرعة System.IO (أو على الأقل قابلة للمقارنة) ، فسيؤدي ذلك إلى التخفيف من حدتها. ليس بسبب قلة المحاولة - لقد فعلت كل ما هو موضح في المستندات.

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

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

بعد قولي هذا ، إليكم أفكاري للتحسين:

• قد يكون "تحديد مجلد" أكثر فائدة - يمكنني تحديد الملفات التي أهتم بها ، ويمكن أن يبرز للمستخدم المجلدات التي تحتوي عليه
• الحافظة - إذا وضع المستخدم بعض الملفات / المجلدات في الحافظة ، ثم عاد إلى تطبيقي ، يجب أن يكون لدي حق الوصول تلقائيًا إلى تلك الملفات (ربما يمكنك إضافة إمكانية "ClipboardFilesAndFolders")
• سحب الملفات / المجلدات وإفلاتها - يجب أن يمنحني ذلك تلقائيًا إمكانية الوصول إلى هذه الملفات (لماذا يسقطها المستخدم في تطبيقي بخلاف ذلك؟)

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

حسنًا ، شكرًا - خلال عطلة نهاية الأسبوع.

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

حسنًا ، سأفعل - الشيء المتعلق بسحب الملفات إلى التطبيقات. لم أجربها بالفعل بعد:

1. هل يعمل مع كل من الملفات والمجلدات؟
2. هل يمكنني الوصول إلى .Path؟
3. هل هي مستمرة (أفترض لا)؟
4. هل أحتاج إلى التمسك بملف / مجلد التخزين ، أو إعادة إنشائه لاحقًا من المسار. (بافتراض أن الإجابة على 2. هي نعم)؟

إنشاء تطبيقات للتحميل الجانبي خارج متجر MS

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

نعم، سيكون ذلك رائعا!

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

لكن بالنسبة لي ، يجب أن يكون هذا جزءًا من عملية "النشر" في Visual Studio. يجب عليك إنشاء برنامج تثبيت. يجب أيضًا إنشاء ملف readme.txt ، والذي يجب أن يشرح فيه ما أحتاج إلى تحميله على الخادم الخاص بي ، ويخبرني أيضًا أنه لا يمكنني استخدام .appinstaller محليًا ، يجب تنزيله من الخادم (عند الاختبار )

لقد لاحظت أيضًا مشكلة معينة تتعلق بالحاجة إلى التوجيه عبر الخادم لتصحيح الأخطاء. أنه يجب عليك تقديم قضية مقابل مشروع جيثب الحالي.

لا أتذكر ما كانت هذه المشكلة :)

يجب أن يطالب مركز التعليقات عند التخلي لمنع الحذف العرضي للمحتوى

نعم ، سأقوم بإجراء +1 لذلك. يرجى تقديمه. توجد فئة في مركز الملاحظات ضمن تطبيقات لـ… محور الملاحظات. هذا ميتا جدا.

حق :)

لا تزال واجهات برمجة التطبيقات غير المتزامنة خارج نطاق السيطرة ، وتبدو محرجة بالنسبة للأشياء التي لا ينبغي أن تكون غير متزامنة

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

هيهي ، هذه قائمة طويلة ؛)

1. يبدأ بالخصائص الأساسية في StorageFolder / File ؛ StorageFile.GetFileFromPathAsync (+ مشابه للمجلد).
2. تحميل الصور المصغرة (StorageFile.GetThumbnail Async
3. تحميل الصور النقطية. هذا مؤلم بشكل خاص ، لأنه تم نقله إلى libs أخرى (مثل win2d) ، وقد وصلت إلى عتبات مجنونة - مثل تحميل صورة نقطية بسيطة (والتي يجب أن تستغرق أقل من 20 مللي ثانية) ، لتستمر 5 ثوانٍ أو نحو ذلك. من الواضح أن هناك بعض الإغلاق وراء الكواليس ، لكن لا أحد يعرف ماذا / لماذا / متى. ونعم ، جهاز الكمبيوتر المحمول الخاص بي هو صاروخ.

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

ما سبق هو أهم آلامي ، من أعلى رأسي. من الآن فصاعدًا ، سأُنشئ مستندًا وأضيف إليه :)

لا توجد واجهات برمجة تطبيقات صوتية جيدة على WinRT

أنا لست خبيرًا في الصوت. لا تتردد في تقديم ملف في مركز الملاحظات ، لكنني سأقوم أيضًا بالاتصال بشريان الحياة هنا والقيام ببعض الأسئلة.

لست متأكدًا مما إذا كان / كيف سيتم حل هذا في أي وقت. أسهل شيء هو التراخي في المتطلبات أو شيء من هذا القبيل ، بحيث يمكن نقل naudio (https://github.com/naudio/NAudio) بشكل صحيح إلى UWP. لكي نكون واضحين ، يمكن تجميعها إلى UWP خارج الصندوق ، لكنها عديمة الفائدة لأن معظم الأشياء المفيدة # ifdef-ed out.

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

لقد أنجزت منفذًا من naudio ، حيث قمت بإزالة جميع #ifdefs إلى حد كبير - إنه يعمل ، لكن تطبيقي لن يصل إلى متجر MS - وأنا على ما يرام مع ذلك.

آلام الحافظة

[...] ومع ذلك ، يبدو أن الإخطار الذي يتم التفاعل معه يجب أن يُسمح له بالوصول إلى الحافظة. سيتطلب هذا معالجة خاصة نظرًا لكيفية حساب Windows والمقدمة ، على ما أعتقد ، ولكن لا يبدو أكثر من المعقول. يرجى تقديم ملف ضمن تعليقات API وسأقوم بترقية هذه المشكلة في قاعدة بيانات الأخطاء أيضًا.

يبدو جيدا ، سوف تفعل.

شكرا!

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

بالطبع ، سأستمر في حفظه إذا كانت إضافته إلى مركز الملاحظات سيكون غير مريح بالنسبة لك!

@ فيليكس - ديف سأبذل قصارى جهدي! حسنا ابقي ملصقك!

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

حسنًا ، سأفعل - الشيء المتعلق بسحب الملفات إلى التطبيقات.

كان من المفترض أن تكون هذه في الواقع ملاحظة حول الفتح من قائمة سياق shell. اسف لخلط الامور.

BenJKuhn في ضوء Github repo باعتباره مكانًا أفضل بكثير لإجراء مناقشات لمقترحات WinRT محددة من مكان "مركز الملاحظات" (استنادًا إلى مشاعر المطور التي تم التعبير عنها عدة مرات في هذا الريبو على مدار الـ 12 شهرًا الماضية): هل سيكون من الجيد النشر فقط ملخص سريع للمقترح على مركز الملاحظات مع ارتباط إلى الاقتراح الأكثر عمقًا الموجود في الريبو هذا (في الوقت الحالي ، حيث لا توجد منصة Fedback الخاصة بنموذج تطبيق UWP والتي تتمتع بثقة مجتمع المطورين الذي أعرفه)؟ لقد رأيت أن المقترحات يتم تنقيحها بشكل أكبر مع مدخلات المجتمع الأخرى هنا بحيث يكون للفريق المحدد في Microsoft ارتباط مباشر بمقترح التطوير.

@ Felix-Dev للحصول على مقترحات محددة ، أعتقد بصراحة أنه من الأفضل البدء في إرسالها إلى مركز تقديم الملاحظات الذي يحمل علامة "النظام الأساسي للمطورين> تعليقات واجهة برمجة التطبيقات."

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

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

أعتقد أن BenJKuhn سيتفق معي.

لقد لاحظت للتو أن استجابتي

@ duke7553 لدينا موقف هنا حيث يجب على المجتمع استخدام نظامين أساسيين مختلفين

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

• النقص (المتصور) في المشاركة من قبل فرق تطوير Windows (لقد ألقيت نظرةً فقط على تعليقات API المقدمة مؤخرًا أيضًا ، وظهرت الكثير من المشكلات هناك مع 0 تعليقات وعدم وجود رد رسمي حتى الآن ، خاصةً فيما يتعلق بالمشكلات التي تبلغ شهرين و اكبر سنا).
• مشاركة المجتمع في قضايا / مقترحات محددة منخفضة جدًا (الأصوات المؤيدة والتعليقات).
• واجهة المستخدم / UX الشاملة لمركز تقديم الملاحظات مما يجعل من الصعب جدًا التعامل مع ردود الفعل السلبية مع الفريق والمجتمع. في هذا الصدد ، ذكر بعض الأشخاص في فريق WinUI أنهم يتفقون أيضًا مع المجتمع هنا .
• أخيرًا ، من الأسهل جدًا على Github الآن إضافة ملفات الوسائط الداعمة مثل الصور أو ملفات GIF إلى اقتراح للمساعدة في تصور ذلك. سأترك هذه الصورة هنا مأخوذة مباشرة من مركز الملاحظات عند تقديم مشكلة:
  

لم أستخدم مركز تقديم الملاحظات من قبل لتقديم مشكلات خاصة بمنصة تطوير النظام والنظر إليها في الوقت الحالي ، ورؤية كيفية تلقي المجتمع للمشكلات (ما يقرب من عدم مشاركة المجتمع!) وفرق تطوير Windows وهيكلها العام ، يجب أن أقول يتفوق مستودع WinUI الفردي هذا على مركز الملاحظات في كل جانب (سهولة إنشاء الاقتراح / مشاركة المجتمع / توفر مطوري MS / ...).

إنه ليس قريبًا ، بصراحة.

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

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

تضمين التغريدة
تحتاج الفرق في MS إلى تكثيف منصة تعليقات UWP الخاصة بهم بجدية وإلى أن أرى هذه التحسينات ، سأستخدم هذا الريبو دائمًا هنا أيضًا طالما سمح به فريق WinUI. يتمتع مركز التعليقات حاليًا بمكانة متدنية في أعين العديد من مطوري Windows ولن يؤدي المنشور بين عشية وضحاها إلى تغيير هذا الموقف فجأة. إنها بداية ولكن هناك حاجة إلى المزيد لعكس الانطباعات السلبية التي سيحصل عليها العديد من المطورين بشكل أساسي عند التحدث عن مركز الملاحظات (أو غيرها من منصات تعليقات المطورين الخاصة بـ MS مثل UserVoice لـ UWP التي تم إيقافها سابقًا). نظرًا للتجارب المخيبة للآمال العديدة التي حصل عليها العديد من مطوري UWP / Windows عند التعامل مع Feedback Hub أو منصات التعليقات السابقة الأخرى ، فأنا - في هذا الشأن - أؤمن بشدة أن فرق التطوير والتعليقات في Windows بحاجة إلى التقدم أولاً وقبل كل شيء بدلاً من مناشدة المطورين العودة (بدون الكثير - إن وجدت - تحسينات مرئية لإظهارها). أدرك أن هذه وجهة نظر قاسية تمامًا ، ولكن إذا نظرت بالفعل إلى العديد من ردود المطورين الواردة في هذا الريبو والعديد من منصات التعليقات الأخرى على مر السنين ، فسترى بسهولة أن هناك إحباطًا حقيقيًا في مجتمع التطوير.

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

سأنهي هذا المنشور بلقطة شاشة مأخوذة من النظام الأساسي للمطورين في مركز الملاحظات -> قسم تعليقات واجهة برمجة التطبيقات:

ملاحظة: سأستخدم هذا المنشور لتقديم خالص شكري لفريق WinUI مرة أخرى لأنهم وافقوا على فتح مستودعهم لاستضافة المشكلات التي لا تتعلق بـ WinUI على الإطلاق ولكن بدلاً من ذلك تهدف إلى معالجة المشكلات الأساسية التي يراها المطورون في UWP . شكرا لك فريق WinUI!

تضمين التغريدة

إليك مشكلات مركز الملاحظات التي قمت بإنشائها

واجهة برمجة تطبيقات BroadSystemAccess / القدرة ليست عملية كما تم تنفيذها. https://aka.ms/AA804aq

يجب ألا تقوم واجهة برمجة تطبيقات BroadSystemAccess بإعادة تشغيل التطبيق عندما يسمح المستخدم بالوصول إلى النظام على نطاق واسع https://aka.ms/AA7zpe3

يجب أن تعمل الحافظة في جميع الأوقات. https://aka.ms/AA804ce

الوصول إلى نظام الملفات: توفير طريقة سهلة الاستخدام لطلب إذن للوصول إلى مواقع ملفات محددة https://aka.ms/AA804cp (لـ @ Felix-Dev)

لا توجد واجهات برمجة تطبيقات صوتية جيدة على WinRT https://aka.ms/AA804d0

لا تزال واجهات برمجة التطبيقات غير المتزامنة خارج نطاق السيطرة ، وتبدو محرجة بالنسبة للأشياء التي لا ينبغي أن تكون غير متزامنة https://aka.ms/AA804d3

أشياء أخرى قمت بإنشائها

مزيد من التفاصيل - يجب السماح بمزيد من الأحرف https://aka.ms/AA7zws5

اختر فئة - اجعل هذا أسهل https://aka.ms/AA804cd

أشياء لست متأكدًا منها

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

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

مركز الملاحظات

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

BenJKuhn هنا رابط مركز الملاحظات لمشكلة إشعار التوست المحدد التي لها حق الوصول إلى الحافظة عندما يتفاعل معها المستخدم: https://aka.ms/AA7zx69

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

إنني أقدر الجهد الذي بذلته للإبلاغ عن هذه المشكلات ، وسأواصل تعقبها بينما تقوم الفرق بمراجعتها. آمل أن يستمر كل منكما في التواصل معنا بشأن المشكلات التي تواجهها ، وسأبذل قصارى جهدي لدعمك في تحسين تجربة مطور التطبيق على Windows.

شكرا،

بن كون

jtorjo هل يمكن أن نشارك في WACK تقرير للمنفذ UWP من NAudio يا بني؟

ستساعدنا هذه البيانات في تقييم القيود التي سنحتاج إلى تخفيفها حتى يتمكن NAudio من اجتيازها من خلال اعتماد المتجر.

mikebattista لقد أرفقت

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

FindFirstFileExFromApp - هذا يجب (وهو موجود بالفعل) - بالتأكيد لا يجب وضع علامة عليه.

يمكنك تجاهل EnumChildWindows / EnumWindows - يمكنني #ifdef خارجها.

ValidationResult.zip

شكرا! سنقوم بتقييم حالات فشل API المدعومة. لقد تواصلت مع فريق الصوت للحصول على مدخلاتهم حول إمكانية تخفيف أي قيود هنا.

mikebattista رائع ، شكرا! نتطلع إلى هذا :)

jtorjo بخصوص سيناريو السحب والإفلات:

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

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

"FindFirstFileExFromApp - هذا يجب (وهو موجود بالفعل) - بالتأكيد لا يجب وضع علامة عليه."
أوافق تمامًا على أن جميع * FromApp APIs مصممة ومخصصة للاستخدام في تطبيقات حاوية التطبيق. لذلك إذا كانت الأدوات تقوم بالإبلاغ عن أي منها ، فهذا خطأ نحتاج إلى معالجته.

@ smaillet-ms شكرا على الرد هنا. هل يتم العمل على تحسين سرعة واجهات برمجة تطبيقات Windows.Storage؟ لقد كنا ننتظر إجابة لفترة طويلة جدًا. سأكون على استعداد للتوقيع على اتفاقية عدم الإفشاء لاستخدام واجهات برمجة التطبيقات المحسّنة في سيناريو تطبيقي.

أستخدم حاليًا تطبيق FromApp لـ FindFirstFile ، لكن من المستحيل الحصول على صور مصغرة للعناصر باستخدام FromApp API.

يتناقض هذا المستوى من السرية حول العمل الذي يتم إجراؤه لتحسين وقت تشغيل Windows مع ما تمت مشاركته سابقًا بواسطة مهندسي Microsoft في الموضوع.

رابط التعليقات التي تم تجاهلها ذات الصلة: https://aka.ms/AA6dgqz

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

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

هناك العديد من الطرق للقيام بالأشياء والعديد منها خاطئ تمامًا لتطبيق معين. لسوء الحظ ، لا يوجد أي نوع من "إجابة صحيحة واحدة صحيحة" لأنها تعتمد حقًا على التطبيق وما سيفعله بالمعلومات التي يحصل عليها من نظام الملفات. ستقدم * FromApp APIs حاليًا أفضل أداء مقارنة بنظيراتها من Win32 القياسية. على الرغم من أنه كما هو موضح هنا ، فإنه لا يحتوي على جميع بيانات الصدفة الإضافية مثل الصور المصغرة وما إلى ذلك. (والتي تكون في الواقع مكلفة إذا لم تكن متوفرة في ذاكرة التخزين المؤقت). لذلك إذا احتاج تطبيقك إلى العثور على الملفات ذات الأهمية بناءً على الاسم / المسار أو الامتداد ، فيمكنه القيام بذلك باستخدام * FromApp APIs ، ثم قم بإنشاء ملف تخزين بناءً على الاسم لاسترداد المزيد من التفاصيل. على الرغم من وجود حمل مكرر في ذلك ، حيث يتم إجراء فحوصات الوصول مرتين في هذه الحالة. إذا كنت تحاول العثور على ملف واحد فقط ، فغالبًا ما لا يمثل ذلك مشكلة ولكن التكرار على نطاق أكبر يمكن أن يكلفك. إذا كنت تستخدم WinRT Apis للتخزين مع Windows.Storage.Search.IndexerOption .OnlyUseIndexerAndOptimizeForIndexedProperties ، يمكنك الحصول على تعداد سريع حقًا ، والذي يعود إلى عنصر تخزين محقق بالكامل أسفل الطلب ، والذي يحتوي على نتيجة مثالية ولكنه أقل من إنشاء عنصر من مسار حيث يحتاج ذلك إلى تضمين فحوصات وصول إضافية. الجانب السلبي هو أنه لا يعمل إذا قام المستخدم بتعطيل مفهرس الموقع المعني.

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

كما قلت ، الكثير من المقايضات. من الواضح أن لدينا عملًا يتعين علينا القيام به لمعرفة كيفية توثيق عملية تقييم ما سيكون الأنسب لتطبيق معين. نواصل أيضًا تقييم الأماكن التي يمكننا فيها تحقيق أكبر التحسينات العامة دون كسر التطبيقات الحالية.

WinRT عبارة عن سطح كبير ولا يمتلكه فريق واحد في MS ، يقوم كل فريق بتقييم أولوياته لكل إصدار وقد ينشر أو لا ينشر خططه مسبقًا. أنا شخصياً أحب أن أرى الأشياء تصل إلى حيث لدينا Zero Overhead فيما يتعلق بواجهات Win32 API داخل أو خارج حاوية التطبيق. من الواضح أننا لسنا في هذه المرحلة الآن ولا يمكنني تقديم أي وعود سنحققها ، وأولويات العمل والخطط في مشروع كبير مثل Windows مع أكبر عدد ممكن من المستخدمين النهائيين لدينا هي عملية معقدة تنطوي على صعوبة / صعبة اختيارات على جميع المستويات. (ناهيك عن التحديات التقنية المختلفة التي يمكن أن تعترض طريق ...)

@ smaillet-ms

jtorjo بخصوص سيناريو السحب والإفلات:

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

يبدو جيدا. سيتم تنفيذ هذا في تطبيقي في مرحلة ما.

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

ليس لدي أي شيء ضد هذا ، ولكن هذا يبدو تعقيدًا إضافيًا لتطبيقي. هل سمعت عن أي شخص يستخدم هذا بالفعل؟

في الوقت الحالي ، أحتاج إلى اكتشاف ألف طريقة للتعامل مع جميع أنواع المشكلات عندما يتعلق الأمر بـ StorageFolder / File ، وهذه مجرد واحدة إضافية. إنه ببساطة يضع العبء ، مرة أخرى ، على عاتق أنا المطور.

"FindFirstFileExFromApp - هذا يجب (وهو موجود بالفعل) - بالتأكيد لا يجب وضع علامة عليه."
أوافق تمامًا على أن جميع * FromApp APIs مصممة ومخصصة للاستخدام في تطبيقات حاوية التطبيق. لذلك إذا كانت الأدوات تقوم بالإبلاغ عن أي منها ، فهذا خطأ نحتاج إلى معالجته.

متفق.

@ smaillet-ms

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

يؤسفني أن أقول ، لكن هذا لا يبدو مطمئنًا للغاية.

في أيام WPF ، كنت أستخدم System.IO ببساطة ، وأقوم بأي استفسارات عن الملفات / المجلدات التي أريدها ، بطريقة سهلة للغاية ، ولا تقلق بشأن السرعة على الإطلاق. أود أن أعرف فقط - إنه يعمل. 4000 ملف ، 10000 ملف - إنه يعمل ببساطة.

هناك العديد من الطرق للقيام بالأشياء والعديد منها خاطئ تمامًا لتطبيق معين.

هذا يشير إلى حد كبير - لا ينبغي أن توجد واجهات برمجة التطبيقات في المقام الأول.

لسوء الحظ ، لا يوجد أي نوع من "إجابة صحيحة واحدة صحيحة" لأنها تعتمد حقًا على التطبيق وما سيفعله بالمعلومات التي يحصل عليها من نظام الملفات. ستقدم * FromApp APIs حاليًا أفضل أداء مقارنة بنظيراتها من Win32 القياسية.

هذا صحيح بالتأكيد. على الرغم من أنني قمت بالفعل بلف * FromApp API في فئة سهلة الاستخدام (لسيناريو خاص بي) ، هذا ما يجب أن يفعله MS أيضًا - اعرض هذا في واجهة برمجة تطبيقات لطيفة وسهلة الاستخدام - غلاف C # بسيط من شأنه من المحتمل جدًا أن تغطي 98٪ من حالات الاستخدام.

كنت سأفعل ذلك بنفسي ، لكن ليس لدي الوقت. يمكنني مشاركة صفي البسيط بسعادة ويمكن لأي شخص أن يأخذها من هناك.

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

متفق عليه - أفعل ذلك بالفعل بشكل منفصل (أطلب صورًا مصغرة على سلسلة رسائل مختلفة) - استعلام API لهذا الغرض من شأنه أن يفعل المعجزات. في الأساس ، سأطلب الصور المصغرة بكميات كبيرة. ويمكنني الحصول على IAsyncEnumerable.

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

لذلك إذا احتاج تطبيقك إلى العثور على الملفات ذات الأهمية بناءً على الاسم / المسار أو الامتداد ، فيمكنه القيام بذلك باستخدام * FromApp APIs ، ثم قم بإنشاء ملف تخزين بناءً على الاسم لاسترداد المزيد من التفاصيل. على الرغم من وجود حمل مكرر في ذلك ، حيث يتم إجراء فحوصات الوصول مرتين في هذه الحالة.

على الجانب الإيجابي ، يوجد الكثير من المعلومات بالفعل في * FromApp API - وقت الإنشاء وآخر وقت وصول وآخر وقت للكتابة وحجم الملف.

إذا كنت تحاول العثور على ملف واحد فقط ، فغالبًا ما لا يمثل ذلك مشكلة ولكن التكرار على نطاق أكبر يمكن أن يكلفك. إذا كنت تستخدم WinRT Apis للتخزين مع Windows.Storage.Search.IndexerOption .OnlyUseIndexerAndOptimizeForIndexedProperties ، يمكنك الحصول على تعداد سريع حقًا ، والذي يعود إلى عنصر تخزين محقق بالكامل أسفل الطلب ، والذي يحتوي على نتيجة مثالية ولكنه أقل من إنشاء عنصر من مسار حيث يحتاج ذلك إلى تضمين فحوصات وصول إضافية. الجانب السلبي هو أنه لا يعمل إذا قام المستخدم بتعطيل مفهرس الموقع المعني.

هذا له العديد من العيوب - أولاً وقبل كل شيء ، في اختباراتي ، كان أسرع من الملفات غير المفهرسة ، لكن ليس بهذه السرعة. أعتقد أنه كان أسرع 3x-5x ، لكن هذا لا يزال حوالي 10x-50x أبطأ من * FromApp. هذا بطيء بجنون. علاوة على ذلك ، لا يمكنني حقًا إخبار المستخدمين بالتحقق من "جميع الملفات التي سيتم فهرستها السياق بالإضافة إلى خصائص الملف" ، إنه ببساطة خياره. وربما يترك الكثير من المستخدمين ذلك دون رادع.

في الواقع ، يجب أن يكتشف Windows تلقائيًا الملفات المستخدمة ويفهرس تلك المجلدات - من المحتمل جدًا أن يكون مهمًا جدًا لملفات الوسائط (الفيديو / الصورة / الموسيقى) والمستندات.

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

بصراحة ، لم أكن أدرك حتى أن هذا موجود - أنا أنظر إليه أثناء حديثنا.
ومع ذلك ، إذا فهمت هذا بشكل صحيح ، فهذا مجرد القليل من السكر النحوي ، حيث سيعاني من نفس مشكلات الأداء مثل IStorageQuery.

وقضايا الأداء تلك ضخمة. إنها ضخمة جدًا ، بحيث يتم استرداد الملف الأول لما يقرب من 1000 ملف بعد 9-10 ثوانٍ. بمعنى آخر ، بمجرد أن تبدأ في تعداد النتيجة ، سيتم حظرها لمدة 9-10 ثوانٍ قبل القيام بأي شيء. أفترض أن الأمر نفسه سيستخدم FileInformationFactory ، فقط أن واجهة المستخدم ستكون مستجيبة خلال ذلك الوقت.

WinRT عبارة عن سطح كبير ولا يمتلكه فريق واحد في MS ، يقوم كل فريق بتقييم أولوياته لكل إصدار وقد ينشر أو لا ينشر خططه مسبقًا. أنا شخصياً أحب أن أرى الأشياء تصل إلى حيث لدينا Zero Overhead فيما يتعلق بواجهات Win32 API داخل أو خارج حاوية التطبيق.

حسنًا ، الكثير منا أيضًا ؛) أفهم أن WinRT هو جزء كبير من Windows ، وأن الأجزاء المختلفة مبعثرة عبر فرق مختلفة.

ليس من المريح لنا ألا نرى علانية رؤية MS لـ WinRT. أن لا يكون لديك جدول زمني لما / متى / إذا حدث.

بالنسبة لي ، فإن سرعة التعامل مع الملفات / المجلدات هي ببساطة أمر بالغ الأهمية. كيف يمكن لشخص أن يثق في WinRT / UWP ، عندما يستغرق القيام بشيء بسيط مثل تعداد الملفات في مجلد وقتًا طويلاً؟ ومعرفة كيفية تحسين ذلك يعود إلى "هل سأكون محظوظًا بما يكفي لتشغيل بحث Google الخاص بي في * FromApp API"؟

لا أريد أن أكون جاحدًا - أنا حقًا أقدر لك الوقت الذي قضيته في تحديد كل هذا لنا. شكرا لك!

BenJKuhn قام شخص ما (https://docs.microsoft.com/answers/questions/6112/updating-existing-app-with-new-certificate-uwp.html؟childToView=25297#comment-25297) بتقديم بطاقة أخرى حول إصدار "شهادة جديدة" هنا -> https://aka.ms/AA8bw9v

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

لماذا تسمح بالتحميل الجانبي خارج متجر MS ، لكنك تجعله شبه مستحيل فعلاً؟

في الواقع ، هذا ليس صحيحًا. لا يمكنك تحميل التطبيق الخاص بك إلى متجر MS واستخدام مثبت التطبيقات كطريقة بديلة لتثبيت التطبيق. تم حظر تطبيقي بسبب ذلك أثناء الشهادة.
سياسات متجر MS:
https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies؟redirectedfrom=MSDN#101 - وظيفة مميزة - تمثيل دقيق للقيمة

10.1.5
يجوز لتطبيقك الترويج للبرامج أو توزيعها فقط من خلال متجر Microsoft.

بعد أن اضطررت إلى إزالة ملف مثبت التطبيقات من خادمي ، يمكن للمستخدمين استخدام متجر MS مرة أخرى لتثبيت تطبيقي. أنا أفهم - القواعد هي قواعد ، حتى أنني لا أستطيع الحصول على سبب لها. لكن هذا أمر مخيب للآمال حقًا ، عندما أعرف الكثير من التطبيقات ، والتي يتم توزيعها من خلال المتجر ومثبت التطبيقات (Unigram) أو chocolatey (محطة MS الجديدة).

لماذا تسمح بالتحميل الجانبي خارج متجر MS ، لكنك تجعله شبه مستحيل فعلاً؟

في الواقع ، هذا ليس صحيحًا. لا يمكنك تحميل التطبيق الخاص بك إلى متجر MS واستخدام مثبت التطبيقات كطريقة بديلة لتثبيت التطبيق. تم حظر تطبيقي بسبب ذلك أثناء الشهادة.
سياسات متجر MS:
https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies؟redirectedfrom=MSDN#101 - وظيفة مميزة - تمثيل دقيق للقيمة

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