التطوير

From The Document Foundation Wiki
Jump to: navigation, search

كيفية المشاركة

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

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

الإبلاغ عن العلل

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

العلل المتعلقة باللغة العربية

هناك صفحة بجميع العلل المختصة بالكتابة من اليمين إلى اليسار والتي تتضمن أيضا جميع العلل المتعلقة باللغة العربية: RTL Bugs. بإمكانك استخدام هذه الصفحة قبل الإبلاغ عن علة للتحقق من كون العلة مُبلّغ عنها أم لا، وفي حالة الإبلاغ عن أي علة يحبّذ إضافتها للصفحة.

العثور على أول مهمة: تعديلات سهلة

من أجل تسهيل دخول المساهمين الجديد، قام فريق LibreOffice بجمع قائمة من التعديلات السهلة. والغرض من ذلك هو مساعدتك للعثور على المهمة الأولى. لمزيد من المعلومات العامة انظر إلى العرض المقدم من Michael Meeks Easy Hacks Talk في FOSDEM 2012.

بالطبع هناك ايضا علل/تحسينات في Bugtracker:

قوائم من التحسينات والميزات المفقودة

إلى جانب صفحة الويكي للتعديلات السهلة، تم انشاء العديد من قوائم التحسينات والميزات المفقودة:

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

إعداد ملف الإصلاح

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

  • ابدأ مع فرع رئيسي غير معدل
  • عدل الشفرة لقلب المحتوى (إن كنت تخطط لشيء أكبر, فكر باستخدام ميزة الفروع)
  • أودع التغييرات الخاصة بك محلياً

اعتماد تعديلاتك محلياً

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

  • هذه الطريقة ستودع جميع الملفات المعدلة: git commit -a
  • بينما git add ملف1 ملف2يسمح لك بتحديد ملفات بعينها لضمها. انظر the Pro Git Book للتفاصيل.

ثم قم بـ:

 git commit 

لاعتماد تعديلاتك محلياً. عندما تكتب رسالة الإعتماد:

  • ابدأ السطر الأول بذكر مرجع العلة مثل: fdo#12345، إذا توفر طبعاً (انظر التفاصيل بالأسفل)
  • استخدم بقية السطر الأول كملخص ممتنع عن التعديلات التي قمت بها
  • اترك السطر الثاني فارغاً
  • وبداية من السطر الثالث يمكنك شرح كيف وماهية التعديلات التي عملت ولأي سبب.

إذا كانت ملف الإصلاح الذي عملت يصلح علةً تم الإبلاغ عنها مسبقاً في Bugzilla، فيمكنك إذاً أن تستفيد من ميزة الإبلاغ التلقائي عن العلل والتي تفعّل برسائل الاعتماد: عندما يكون السطر الأول من رسالة الاعتماد تحتوي على مرجع علّة ما في النموذج fdo#12345، سيتم إدراج تعليق بخصوص العلة في تقريرها الخاص بها، في اللحظة التي تدفع فيها الرقعة إلى المخزن. انظر إلى الإعلان الموضوع على mail-archive.com أو على fdo-listarchive (باللغة الإنجليزية) للمزيد من التفاصيل.

بعد اعتماد تعديلاتك محلياً سيكون لديك ثلاثة خيارات:

إرسال ملف الإصلاح مباشرةً إلى gerrit.libreoffice.org

يمكنك دفع ملف الإصلاح إلى http://gerrit.libreoffice.org للمراجعة المباشرة. مجرد أن تنشيء حساباً (لا يستغرق أكثر من دقيقة) كل ما عليك فعله هو:

 ./logerrit submit

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

بديل: إرسال ملف الإصلاح يدوياً إلى القائمة البريدية

كبديل، يمكنك اتباع المدرسة القديمة وقراءة هذه الملاحظات عن كيفية استعمال قائمة التطوير البريدية ومن ثم:

  • إنشاء ملف الإصلاح التي تود إرسالها إلى البريد. إذا كنت في مخزن واحد يمكنك استخدام git مباشرةً للحصول على سبيل المثال آخر تعديل في الفرع كملف فروق فقط (diff) مع:
git format-patch HEAD~1

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

./g format-patch --suffix=.@REPO@.patch -o/home/me/somedir/to_save_my_patches_in origin/master..HEAD
  • اكتب بريداً لـdevelopment list وضمن به ملفات الإصلاح.
  • اكتب عنوان الرسالة كما يلي: "[PATCH] fdo#<رقم العلة>: <عنوان العلة>". مثال: "[PATCH] fdo#43398: FORMATTING: Documents opened in LibreOffice Writer incorrectly appear as right justified"، بجب استخدام اللغة الإنجليزية في جميع رسائل البريد إلى قوائم LibreOffice البريدية.
  • إذا كنت تريد العودة إلى المنبع الرئيسي بعدما تنتهي من إرسال ملف الإصلاح، يمكنك استخدام الأمر التالي:
./logerrit nextchange

أو أدلة التعليمات هذه للحصول على النسخة الأصل.

بديل: توفير فروع git للسحب

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

مباديء البرمجة العامة

إنجاز أول بناء للبرنامج

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

استخدام Git لتطوير LibreOffice

Git نظام تحكم مؤرشف (DVCS). على الرغم من قوته البالغة إلا أنه نظام بسيط جداً، لكن إذا لم تكن معتاداً على الـDBCS، من الممكن أن تكون العملية مربكة. لحسن الحظ هناك العديد من المصادر الرائعة على الإنترنت لتعلم Git. يستحسن بك زيارة http://git-scm.com/ .

معظم النص المصدري لـLibreOffice في مخزن 'core'، لكن القليل من الوحدات في مخازن منفصلة: 'translations'، 'help'، 'dictionaries' و'binfilter'. في معظم الحالات لن تحتاج للتعديل على هذه المستودعات، لكن يمكنك أن تقرأ استخدام Git لتطوير LibreOffice حول أداة ./g الذي يجب أن يساعدك على جعل هذه العملية أقل إزعاجاً.

الحصول على صلاحيات الإيداع واستخدامها

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

اتفاقيات الشفرات

ينبغي استخدام sal_Bool عندما يتعلق الأمر بـ UNO، ويفضل استخدام BOOL في خلاف ذلك. للمزيد من المبادئ التوجيهية يمكن الاطلاع على:


تصحيح العلل


التأكيدات والتسجيلات

لتأكيد الثوابت من الشفرات (التي يمكن أن تنتهك فقط إذا كان هناك أخطاء برمجية) استخدم معيار الـC/C++ assert. يتم تعريف NDEBUG في بناء الإنتاج "Production builds"، بينما لايتم تعريف --enable-debug/--enable-dbgutil. لا تتبع assert بشفره تهدف إلى التخفيف من آثار اكتشاف الأخطاء البرمجية في بناء الإنتاج "Production builds".

لتسجيل تحذيرات حول أحداث غير عادية (التي مع ذلك تحتاج الشفرات إلى معالجتها بطريقة ما، مثل إدخال تالف أو فشل إدخال/إخراج)، استخدم الماكرو SAL_WARN/SAL_WARN_IF منsal/log.hxx . بشكل عام فإنه من الأفضل الإبلاغ عن مشكلة تم اكتشافها أعلى مكدس الاستدعاءات "call stack" عن إسكات ذلك محلياً. ذلك يعني أن SAL_WARN على الأغلب تكون متبوعه بـ throw، و الشفرات لا يجب أن تمسك وتكتم الاستثناءات التي لا يمكنها معالجتها بشكل مجدي.

لتسجيل معلومات أخرى مفيده من أجل تصحيح العلل، استخدم الماكرو SAL_INFO/SAL_INFO_IF.

من أجل مخرجات تصحيح علل مؤقته، استخدم الماكرو SAL_DEBUG. خطاف الاعتمادات "Commit hooks" تمنع الاعتمادات العرضية.

الماكرو SAL_WARN/SAL_INFO غير نشط في بناء الإنتاج، لتنشيطه استخدم --enable-debug/--enable-dbgutil. في الواقع مخرجات سجل الاستدعاءات يتم التحكم بها بواسطة متغير البيئة SAL_LOG. للحصول على المزيد من التفاصيل راجع المستندات الموجوده في sal/log.hxx.

الوظائف التي تتيحها osl/diagnose.h و tools/debug.hxx تُلغى من قبل sal/log.hxx.


للمزيد من تلميحات المطور