Eclipse SDK - [سجل التغييرات]

ما الجديد [Changelog] ؟

المنصة و Equinox:

تحسينات على وصف السمات في تفضيلات الألوان والخطوط:

• تعرض صفحة تفضيلات الألوان والخطوط الآن أوصافًا لفئات السمات الرئيسية، بالإضافة إلى عناصر الشجرة الفرعية. سابقًا، كانت العناصر الفرعية فقط في الشجرة تعرض نصًا وصفيًا. مع هذا التحديث، أصبحت الفئات الرئيسية، مثل Java وBasic وDebug وText Compare، تتضمن أوصافًا أيضًا، مما يساعد المستخدمين على فهم محتوى كل فئة بشكل أفضل، ويسهل عليهم العثور على الإعدادات ذات الصلة.

تحديثات عامة:

أيقونة عرض وحدة التحكم الديناميكية:

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

إعدادات التكبير الافتراضية لبرنامج تشغيل Equinox (خاص بنظام Windows فقط):

• يُستخدم التكبير المُخصّص للشاشة كإعداد افتراضي في منتجات RCP على نظام Windows منذ إصدار Eclipse 4.36. ولكي يعمل هذا بشكل صحيح، يتطلب ذلك تفعيل خاصية DPI “PerMonitorV2″، والتي يتم ضبطها تلقائيًا بواسطة SWT لواجهة المستخدم. كان ملف تشغيل Equinox التنفيذي لا يزال يحتوي على بيان يُحدد خاصية DPI “System” للعملية.
• حتى الآن، كان هذا يؤدي إلى عدم تكبير شاشة البداية بشكل صحيح، وإلى نتائج غير صحيحة عند تسليم شاشة البداية إلى SWT و Platform Workbench. مع هذا الإصدار، يعود برنامج تشغيل Equinox إلى استخدام خاصية DPI “PerMonitorV2” افتراضيًا، ويستخدم نفس إعدادات التكبير التلقائي الافتراضية لـ SWT. للحصول على معلومات حول إعدادات SWT الافتراضية، والتي تم تحديثها وتوحيدها أيضًا مع هذا الإصدار، يُرجى الاطلاع على الأخبار ذات الصلة.
• يمكن تعطيل تغيير حجم الشاشة حسب الشاشة باستخدام الخيار ‎-Dswt.autoScale.updateOnRuntime=false، مما سيؤدي أيضًا إلى استخدام مُشغّل Equinox لإعدادات تغيير الحجم التلقائي الافتراضية لشاشة البداية. ستظل العملية تستخدم خاصية “PerMonitorV2” المُعتمدة على دقة الشاشة، ولكن سيتم استبدالها تلقائيًا بواسطة SWT لكي يعود مؤشر ترابط واجهة المستخدم للشاشة إلى “System”.

أدوات تطوير جافا:

محرر جافا:

طي العناصر مع عرض عناصر جافا المُحددة:

• يمكن الآن استخدام خاصية الطي في محرر جافا عند تفعيل خيار “عرض عنصر جافا المُحدد فقط” في قائمة “نافذة” > “تفضيلات” > “جافا” > “محرر”. في الإصدارات السابقة، كان هذا الخيار يُعطّل طي التعليمات البرمجية تلقائيًا.

عرض Javadoc من خلال تمرير المؤشر فوق التعليق التوضيحي/الإصلاح السريع:

• يتضمن تمرير المؤشر فوق التعليق التوضيحي/الإصلاح السريع الآن اقتراحًا لـ Javadoc يفتح نافذة معلومات Javadoc لعنصر جافا المُشار إليه في التعليق التوضيحي. يمكنك الآن عرض توثيق واجهة برمجة التطبيقات (API) للعنصر مباشرةً من خلال تمرير مؤشر الماوس فوق التعليق التوضيحي دون الحاجة إلى الانتقال إلى ملف المصدر الخاص به. سابقًا، كان تمرير مؤشر الماوس فوق التعليق التوضيحي له الأولوية، مما كان يحجب نافذة Javadoc المنبثقة المعتادة للعنصر الموجود أسفل التعليق. لقراءة Javadoc، كان عليك فتح ملف Java المصدر الأصلي أو الانتقال إليه. يزيل هذا التغيير هذه المشكلة.
• سلوك Javadoc عند تمرير مؤشر الماوس فوق التعليق التوضيحي
• عند عرض تعليق توضيحي/إصلاح سريع، وكان التعليق يشير إلى عنصر Java يحتوي على Javadoc، يظهر خيار “عرض Javadoc” في قائمة الاقتراحات.
• يؤدي تفعيل هذا الخيار إلى فتح عنصر تحكم معلومات Javadoc القياسي (نفس نافذة Javadoc المنبثقة المستندة إلى المتصفح والمستخدمة في أماكن أخرى).
• تحل نافذة Javadoc المنبثقة محل تمرير مؤشر الماوس فوق التعليق التوضيحي لعرض طبيعي وسياقي.
• تُغلق نافذة Javadoc المنبثقة تلقائيًا عند النقر خارجها، مما يمنع ظهور النوافذ المنبثقة القديمة.

ميزة جديدة لتحويل الأصناف إلى سجلات – المساعدة السريعة / إعادة البناء:

• تمت إضافة ميزة جديدة لإعادة البناء، انقر بزر الماوس الأيمن -> إعادة البناء -> تحويل الصنف إلى سجل…، والتي ستحوّل الصنف المناسب إلى سجل.
• يجب أن يحتوي الصنف على حقل واحد أو أكثر من حقول النسخ الخاصة، يتم تهيئتها جميعًا في مُنشئ واحد عن طريق إسناد بسيط، ولا يحتوي على أي أعضاء ثابتة.
• يجب أن يحتوي الصنف على دالة جلب واحدة على الأكثر لكل حقل نسخ، تُعيد قيمة الحقل فقط.
• يمكن للصنف أن يرث من الصنف Object فقط، ولا يمكنه تطبيق أي واجهة.
• يمكن للصنف إعادة تعريف الدوال equals() و hashCode() و toString() من الصنف Object، وسيتم نسخ هذه الدوال إلى السجل، ولكن لا يمكن أن يحتوي على أي دوال أخرى باستثناء المُنشئ ودوال الجلب المذكورة.
• قد تُشير عملية إعادة البناء إلى أن التحويل غير ممكن، أو تُصدر تحذيرًا قبل التحويل. على سبيل المثال، إذا كان هناك حقل لا يحتوي على دالة جلب، فسيتم إصدار تحذير بأن الحقل سيُتاح عبر دالة وصول، ويمكن للمستخدم اختيار المتابعة أو عدمها.
• قد تُشير عملية إعادة البناء إلى أن التحويل غير ممكن، أو تُصدر تحذيرًا قبل التحويل. على سبيل المثال، إذا كان هناك حقل لا يحتوي على دالة جلب، فسيتم إصدار تحذير بأن الحقل سيُتاح عبر دالة وصول، ويمكن للمستخدم اختيار المتابعة أو عدمها.
• عند إنشاء السجل، سيتم تغيير جميع مراجع دوال الوصول السابقة لاستدعاء دوال الوصول المناسبة للسجل.
• كما تمت إضافة ميزة مساعدة سريعة (CTRL-1 -> تحويل إلى سجل) لتحويل هذا النوع من الفئات. تختلف هذه الميزة عن إعادة هيكلة الكود في أن أي تحذيرات ستؤدي إلى عدم عرض المساعدة.

مساعدة سريعة جديدة لتعطيل/تمكين الاختبار:

• تمت إضافة ميزة مساعدة سريعة جديدة لتعطيل أو تمكين اختبار JUnit في المحرر. لتعطيل اختبار نشط، استخدم الأمر التالي:
• لتعطيل اختبار JUnit، حدده داخل الاختبار، ثم اضغط Ctrl+1 ثم اختر “تعطيل الاختبار” مع @Disabled. لتفعيل اختبار معطل، حدده داخل الاختبار، ثم اضغط Ctrl+1 ثم اختر “تفعيل الاختبار” (أزل @Disabled).

منسق جافا:

دعم تنسيق تعليقات جافا لصيغة Markdown:

• عند تفعيل تنسيق Javadoc لصيغة Markdown، يتعرف المنسق الآن على صيغة Markdown المنظمة داخل تعليقات /// وينسقها بشكل مناسب بدلاً من التعامل معها كنص عادي. تشمل العناصر المدعومة العناوين، والقوائم المرتبة وغير المرتبة (مع التداخل الصحيح)، وكتل التعليمات البرمجية المحاطة بعلامات، والجداول، وعلامات Markdown.
• تتم محاذاة القوائم المتداخلة بشكل متسق، وتحافظ عناصر القوائم المغلفة على المسافة البادئة الصحيحة، ويتم التعرف على كتل التعليمات البرمجية المحاطة بعلامات (بنمطي “` و ~~~) وتنسيق مقتطفات التعليمات البرمجية المضمنة فيها مع الحفاظ على بنيتها. يقوم المُنسِّق أيضًا بالتحقق من صحة أنماط القوائم أو الترقيم غير الصحيحة ومعالجتها بسلاسة دون التأثير على المحتوى المحيط.

المُصحِّح:

تحسين تمييز تعابير لامدا المتسلسلة المضمنة:

• استنادًا إلى دعم نقاط التوقف لتعابير لامدا المضمنة المُضافة في Eclipse 4.38، يُبرز مُصحِّح Java الآن تعبير لامدا المضمن المحدد عند تعليقه.
• في السابق، كان تحديد إطار مكدس لامدا أو التركيز عليه في تعبير متسلسل يُبرز السطر بأكمله، مما يُصعِّب تحديد تعبير لامدا بدقة.
• الآن، يتم تمييز تعبير لامدا المُعلَّق فقط، مما يُسهِّل تتبُّع التنفيذ في التعبيرات المتسلسلة المعقدة.

سحب وإفلات المتغيرات والتعابير في واجهة التصحيح:

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

منصة وواجهة برمجة تطبيقات Equinox:

تغييرات المنصة:

مُبدِّل المنظور يدعم الآن علامة IPresentationEngine.NO_MOVE:

• يدعم مُبدِّل المنظور الآن علامة IPresentationEngine.NO_MOVE. يمنع هذا التحسين إعادة ترتيب عناصر المنظور بالسحب والإفلات إذا كانت هذه العلامة مُطبَّقة على عنصر تحكم أداة مُبدِّل المنظور. يمكن للمطورين قفل أو إلغاء قفل ميزة إعادة الترتيب هذه برمجيًا عن طريق إضافة أو إزالة علامة IPresentationEngine.NO_MOVE من عنصر التحكم.

تغييرات SWT:

دعم إخراج PDF أصلي:

• يوفر SWT الآن إمكانات إنشاء ملفات PDF أصلية من خلال فئة PDFDocument جديدة، مما يُمكِّن من تصدير محتوى الأدوات مباشرةً إلى ملفات PDF دون الحاجة إلى مكتبات خارجية.
• دعم إخراج PDF أصلي: يمكن للتطبيقات الآن تصدير محتوى عناصر واجهة المستخدم الرسومية SWT إلى ملفات PDF باستخدام واجهة برمجة التطبيقات القياسية Control.print(GC) مع عمليات الرسم المألوفة في GC، أو إنشاء مستندات PDF مخصصة بالكامل برمجيًا.

دعم النظام الأساسي:

• Microsoft Print to PDF
• يُغني هذا التحسين عن الحاجة إلى مكتبات PDF خارجية، ويوفر حلاً أصليًا متكاملاً مع النظام الأساسي لإنشاء ملفات PDF في تطبيقات SWT. راجع Snippet388 للاطلاع على مثال عملي كامل.

مُزوّد ​​بيانات الصورة بحجم مُحدد:

• تتوفر الآن واجهة ImageDataAtSizeProvider كواجهة برمجة تطبيقات عامة. تُمكّن هذه الواجهة مستخدمي SWT من توفير بيانات الصورة بعرض وارتفاع مُخصصين، بدلاً من الاعتماد فقط على التكبير/التصغير. ولتحقيق ذلك، يجب تنفيذ دالة getImageData(int width, int height) الخاصة بالمُزوّد.
• يُعدّ مُزوّد ​​بيانات الصورة بحجم مُحدد مفيدًا بشكل خاص في الحالات التي تتطلب تحكمًا دقيقًا في أبعاد الصورة، مما يسمح للمستخدمين بإنشاء بيانات الصورة بعرض وارتفاع مُحددين.
• يُمكن استخدام ImageDataAtSizeProvider في الحالات التي تتطلب تحكمًا دقيقًا في أبعاد الصورة، مما يسمح للمستخدمين بإنشاء بيانات الصورة بعرض وارتفاع مُحددين. إذا كان سيتم استخدام هذا الموفر أيضًا لاسترجاع بيانات الصور لمستويات تكبير/تصغير محددة، فيمكن تجاوز دالة `ImageDataAtSizeProvider.getDefaultSize()` من نوع `Point` لتحديد حجم بيانات الصورة عند التكبير بنسبة 100%. في هذه الحالة، يتم تفويض استدعاءات `getImageData(int zoom)` إلى `getImageData(int width, int height)` مع تطبيق مستوى التكبير/التصغير المحدد على الحجم الافتراضي.
• يمكن رسم الصور من هذا الموفر بحجم محدد باستخدام `GC.drawImage(Image, int, int, int, int)`. راجع أيضًا الأخبار المتعلقة بإضافة هذه الدالة.

دالة جديدة: `Shell.getZoom()`:

• تمت إضافة واجهة برمجة تطبيقات جديدة، `Shell.getZoom()`، لاسترجاع مستوى التكبير/التصغير الأصلي للواجهة. القيمة المُعادة هي مستوى التكبير/التصغير للواجهة كما اعتمده نظام التشغيل، وليست قيمة تكبير/تصغير مُعدّلة وفقًا لإمكانيات التحجيم التلقائي في SWT. عند استخدام ميزة تغيير حجم الشاشة الخاصة بنظام ويندوز، تتوافق القيمة مع مستوى تكبير/تصغير الشاشة التي يُعرض عليها التطبيق. أما في الأنظمة الأخرى، أو عند تعطيل ميزة تغيير حجم الشاشة الخاصة بنظام ويندوز، فتتوافق القيمة مع عامل تكبير/تصغير التطبيق العام وفقًا للدالة DPIUtil#getNativeDeviceZoom().

توضيح آلية عمل الدالة Device.getDPI():

• تُعدّ الدالة Device.getDPI() إحدى دوال واجهة برمجة التطبيقات (API) القديمة في SWT. وقد طُرحت في وقت لم يكن فيه تكبير/تصغير الشاشة – الذي كان عادةً ما يقتصر على شاشات HiDPI – أمرًا مهمًا. ونتيجةً لذلك، أنشأت هذه الدالة ضمنيًا آليةً تُتيح للشاشة عرض قيمة DPI عامة واحدة، مستقلة عن الشاشة.
• عدد الشاشات المتصلة.
• عندما تم تعديل SWT لدعم شاشات HiDPI بشكل أفضل قبل حوالي عقد من الزمن، تم الاحتفاظ بهذا الشرط الضمني مع توسيعه من خلال إضافة خاصية التكبير التلقائي. بموجب هذا الشرط الموسع، يتم حساب DPI المُعاد من Device.getDPI() كما يلي: إذا كان التكبير المُستخدم في آلية التكبير التلقائي لـ SWT يختلف عن التكبير الأصلي، فسيتم حساب DPI المُعاد نسبةً إلى DPI التكبير الأصلي. على سبيل المثال، في تطبيق Windows (مع DPI أساسي 96)، تُعيد هذه الطريقة 120 عند ضبط وضع التكبير التلقائي على عدد صحيح، و96 عند ضبطه على ربع.
• مع إضافة خاصية التكبير المُخصصة لكل شاشة في تطبيق Windows لـ SWT، لم يعد الافتراض الأصلي لقيمة DPI واحدة لكل شاشة، بغض النظر عن عدد الشاشات المتصلة، صالحًا في جميع الحالات. مع هذا الإصدار، تم تعديل الدالة في نظام ويندوز بحيث تُعيد دائمًا قيمة DPI الأساسية للنظام (وهي حاليًا 96) عند تفعيل التكبير/التصغير الخاص بالشاشة، حيث أن التكبير/التصغير التلقائي الذي يستخدمه SWT لواجهة المستخدم في هذا الوضع يكون دائمًا مطابقًا للتكبير/التصغير الأصلي للشاشة التي تُعرض عليها واجهة المستخدم.
• نظرًا لأن الاستخدامات الحالية للدالة Device.getDPI() قد لا تزال تعتمد على الافتراض المذكور، يُنصح بمراجعة هذه الاستخدامات. في كثير من الحالات، قد لا تكون ضرورية أو يمكن استبدالها بحسابات تستند إلى واجهة برمجة التطبيقات الجديدة Shell.getZoom() المُتوافقة مع الشاشة.

واجهة برمجة التطبيقات لتعطيل التكبير/التصغير التلقائي لعناصر التحكم:

• يختلف تطبيق التكبير/التصغير التلقائي في ويندوز اختلافًا جوهريًا عن تطبيقاته في GTK (لينكس) وCocoa (ماك أو إس). في لينكس وماك أو إس، يتم تحقيق التكبير/التصغير التلقائي من خلال حساب وتطبيق عامل تكبير/تصغير عالمي واحد؛ ثم يتولى نظام التشغيل معالجة جميع عمليات التكبير/التصغير اللاحقة داخليًا بشكل شفاف. أما في ويندوز، فالوضع أكثر تعقيدًا بكثير. يجب على تطبيق SWT تحويل كل قيمة مبنية على البكسل – مثل المواضع والأحجام والحدود – بشكل صريح وفقًا لإعدادات التحجيم التلقائي النشطة قبل تمريرها إلى نظام التشغيل. عند استخدام مستويات تكبير/تصغير جزئية (على سبيل المثال، 125% أو 175%)، قد تُسبب هذه التحويلات أخطاء تقريب.
• في معظم الحالات، وخاصة عند العمل مع الأدوات القياسية، نادرًا ما تُسبب تأثيرات التقريب هذه مشاكل مرئية. مع ذلك، عند استخدام عرض مخصص باستخدام وحدة جمع البيانات المهملة (GC)، قد تؤدي بسهولة إلى تشوهات في العرض على لوحة الرسم. ومن الأمثلة الشائعة على ذلك منطقة قص مُحوّلة بشكل غير صحيح، فتصبح كبيرة جدًا أو صغيرة جدًا بعد التحجيم.
• الطريقة الأكثر موثوقية لتجنب هذه المشاكل هي إزالة التحجيم التلقائي لـ SWT تمامًا من العملية، والعرض مباشرةً على وحدة جمع البيانات المهملة باستخدام إحداثيات البكسل. لدعم هذه الحالة، تمت إضافة واجهة برمجة تطبيقات جديدة، وهي Control.setAutoscalingMode(AutoscalingMode).

تتوفر حاليًا ثلاث قيم تعدادية لـ AutoscalingMode:

• مُفعّل: القيمة الافتراضية. يتم تطبيق التحجيم التلقائي كالمعتاد.
• معطل: التحجيم التلقائي معطل؛ ويتصرف عنصر التحكم كما لو كان مستوى التكبير/التصغير 100%.
• معطل_موروث: نفس حالة “معطل”، ولكن يتم توريث وضع التحجيم التلقائي لعناصر التحكم الفرعية المُنشأة حديثًا.
• تُرجع الدالة Control.setAutoscalingMode(AutoscalingMode) قيمة منطقية تُشير إلى ما إذا تم قبول الوضع المطلوب وتطبيقه.
• يرث عنصر التحكم دائمًا سياق العرض الخاص به من عنصر Drawable الذي تم إنشاؤه من أجله. وبالتالي، عند تعطيل التحجيم التلقائي في عنصر التحكم، سيتم أيضًا عرض عنصر التحكم المرتبط به مع تعطيل التحجيم التلقائي.

التحجيم الخاص بالشاشة افتراضيًا (ويندوز):

• يُستخدم التحجيم الخاص بالشاشة كإعداد افتراضي في منتجات RCP على نظام ويندوز منذ إصدار Eclipse 4.36. وحتى الآن، لا يزال SWT يستخدم افتراضيًا دعم HiDPI الموجود مسبقًا بناءً على مستوى تكبير/تصغير واحد للتطبيق بأكمله طوال دورة حياته.
• التحجيم الخاص بالشاشة افتراضيًا في منتجات RCP على نظام ويندوز منذ إصدار Eclipse 4.36. مع هذا الإصدار، يتم تفعيل خاصية تغيير حجم الشاشة تلقائيًا في SWT على نظام ويندوز. ونتيجةً لذلك، ستبدأ جميع التطبيقات التي تعمل بنظام SWT مع تفعيل هذه الخاصية، ما لم يتم ضبطها بشكل مختلف.
• يتضمن هذا التغيير تحديثات لبعض الإعدادات الافتراضية المتعلقة بخصائص تغيير الحجم التلقائي لتوحيد السلوك وتحديد سلوكيات افتراضية مناسبة. يؤثر هذا التغيير على إعداد تغيير الحجم التلقائي (عبر swt.autoScale) وعلى مستوى دقة الشاشة (DPI) المستخدم من قِبل واجهة المستخدم. بينما كان دعم تغيير الحجم الحالي يستخدم swt.autoScale=integer ومستوى دقة شاشة “System” افتراضيًا، يتطلب تغيير حجم الشاشة تلقائيًا swt.autoScale=quarter ومستوى دقة شاشة “PerMonitorV2” ليعمل بشكل صحيح.
• ملاحظة: تم أيضًا تعديل ملف تشغيل Equinox لبدء العملية مع مستوى دقة شاشة “PerMonitorV2″، بحيث يتوافق مستوى دقة الشاشة مع الإعدادات الافتراضية للتطبيق (مع تفعيل تغيير حجم الشاشة). يتوافق هذا مع خاصية دعم DPI الافتراضية في JVM. كان الإعداد الافتراضي السابق لملف تشغيل Equinox هو “النظام” مع دعم DPI. راجع أيضًا الأخبار ذات الصلة.

إعدادات التكبير الافتراضية:

أهم الإعدادات هي الإعدادات الافتراضية الجديدة والسابقة:

• تمكين تكبير الشاشة (بدون إعدادات، الإعداد الافتراضي الجديد): عند إنشاء شاشة عرض،
• تم ضبط حساسية DPI لواجهة المستخدم على “PerMonitorV2″، وقيمة swt.autoScale الافتراضية هي الربع.
• تعطيل التحجيم الخاص بالشاشة (-Dswt.autoScale.updateOnRuntime=false، القيمة الافتراضية السابقة): عند إنشاء شاشة، يتم ضبط حساسية DPI لواجهة المستخدم على “System”، وقيمة swt.autoScale الافتراضية هي عدد صحيح.
• يتوافق هذا الإعداد الأخير مع الإعدادات الافتراضية لمنتجات Eclipse قبل تفعيل التحجيم الخاص بالشاشة افتراضيًا. لاحظ أنه مع تطبيق SWT عادي، سيؤدي استخدام -Dswt.autoScale.updateOnRuntime=false إلى نتيجة مختلفة قليلاً عن السابق. فبينما كانت حساسية DPI تُستمد سابقًا من JVM، فقد تم تغييرها الآن إلى “System”، لأن القيمة الافتراضية لـ JVM “PerMonitorV2” لا تُنتج نتائج مناسبة مع دعم التحجيم المُسبق. قد يكون من المنطقي استخدام قيم مخصصة لخاصية swt.autoScale، مثل “false”، وهو ما يفسر تحديد هذه القيمة المخصصة في هذه الحالة، حيث لا يزال يتم استخدام خاصية DPI الخاصة بـ JVM.
• نتيجةً لذلك، سيستخدم تطبيق وقت التشغيل المُشغَّل من بيئة Eclipse IDE نفس خاصية DPI التي يستخدمها المنتج النهائي المُشغَّل بواسطة برنامج Equinox launcher (إلا إذا تم تحديد قيمة مخصصة لخاصية swt.autoScale). سابقًا، كانت تجربة تعطيل التحجيم الخاص بالشاشة مختلفة في تطبيق وقت التشغيل مقارنةً بالمنتج المُشغَّل بواسطة برنامج Equinox launcher.

قيم swt.autoScale المخصصة:

• تتيح خاصية swt.autoScale تعيين أوضاع تحجيم تلقائي مختلفة، مثل “integer” (تقريب قيم التحجيم الكسرية إلى مضاعفات 100) أو “false” (تعطيل التحجيم التلقائي تمامًا). عند تعيين قيمة مخصصة للتحجيم التلقائي، لا يتم إجراء أي تغيير تلقائي في حساسية DPI لواجهة المستخدم، بل يتم استخدام القيمة الافتراضية لـ JVM. هذا يحافظ على السلوك الحالي للتطبيقات المُخصصة للتحجيم التلقائي. لا يزال بالإمكان تخصيص حساسية DPI عبر خاصية النظام (انظر القسم التالي).
• في حال كنت تستخدم سابقًا قيمة swt.autoScale مخصصة، فقد تحتاج الآن إلى تعيين -Dswt.autoScale.updateOnRuntime=false للحفاظ على سلوكك.
• ملاحظة: عند تفعيل التحجيم الخاص بالشاشة، تكون قيم التحجيم التلقائي الصالحة هي “ربع” و”دقيق”.
• ملاحظة: بدلًا من استخدام -Dswt.autoScale=false، يمكنك الآن تعطيل التحجيم التلقائي على مستوى عناصر التحكم، راجع الأخبار ذات الصلة.

دعم DPI المخصص:

• لتمكين تخصيص دعم DPI للتطبيق دون تعديل ملف البيان الخاص به، تم استحداث خاصية نظامية مناسبة: org.eclipse.swt.internal.win32.dpiAwareness. باستخدام هذه الخاصية، يمكن تحديد دعم DPI إلى “النظام” أو “لكل شاشة” أو “لكل شاشة الإصدار 2”. على سبيل المثال، لتشغيل تطبيق مع دعم DPI للنظام، يمكنك تحديد: -Dorg.eclipse.swt.internal.win32.dpiAwareness=System

بيئة تطوير المكونات الإضافية:

العروض والنوافذ الحوارية:

إضافة نافذة حوارية لتشغيل الحزم:

• تمت إضافة نافذة حوارية جديدة إلى نافذة إعدادات تشغيل Eclipse PDE. تتيح هذه النافذة للمستخدمين عرض قائمة الحزم التي سيتم تضمينها عند تشغيل تطبيق Eclipse. يمكن الوصول إلى هذه الميزة عبر زر “عرض حزم التشغيل” في نافذة إعدادات التشغيل ضمن علامة تبويب “المكونات الإضافية”.
• تمت إضافة نافذة حوارية جديدة إلى نافذة إعدادات التشغيل في Eclipse PDE. يُتيح هذا النظام رؤية قائمة الحزم المُحلّلة لكلٍ من التطبيقات القائمة على الإضافات والتطبيقات القائمة على الميزات. كما يُساعد المطورين على فهم مكونات وقت التشغيل لتطبيقاتهم أثناء إعداد الإطلاق.