الأسئلة الشائعة
TDF ليبر اوفيس Community Blogs Pootle TestLink ODFAuthors Nextcloud Redmine اسأل ليبر اوفيس | Donate
Contents
- 1 ايهما افضل( String ) او ( rtl::OUString )?
- 2 كيف يمكنني تصحيح ( تتبع علل ) LibreOffice ?
- 3 ماذا تعني هذه التعليقات:#iXXXX# / fdo#XXXX / الخ. ?
- 4 ما هو ( binfilter )?
- 5 ايهم افضل الامر( make ) او البناء الجزئي بعد القيام بتعديل؟
- 6 ما كل هذه الاختبارات: ( unit tests, smoketests, subsequent tests )؟
- 7 فشل ( smoketest )، كيف يمكنني تصحيح ذلك؟
ايهما افضل( String ) او ( rtl::OUString )?
جرب و استخدم الفئة " rtl::O(U)String " قدر المستطاع. لمزيد من المعلومات او للحصول على المساعدة يمكنك الاطلاع على صفحة: Development/String Classes .
كيف يمكنني تصحيح ( تتبع علل ) LibreOffice ?
الجزء المهم هو تمرير --enable-debug
الى ./autogen.sh
. لمزيد من المعلومات او للحصول على المساعدة يمكنك الاطلاع على صفحة: Development/How to debug
ماذا تعني هذه التعليقات:#iXXXX# / fdo#XXXX / الخ. ?
- #iXXXXXX# او i#XXXXXX تشير الى معرف علة خاص بـ( OpenOffice.org )، مثال: #i100000# هو is https://issues.apache.org/ooo/show_bug.cgi?id=100000
- rhbz#XXXX تشير الى معرف علة خاص بـ ( RedHat )، مثال: rhbz#680460 هو https://bugzilla.redhat.com/show_bug.cgi?id=680460
- #nXXXXXX# او n#XXXXXX اوالمفضل bnc#XXXXXX تشير الى معرف علة خاص بـ ( Novell )، مثال: #n672421# هو https://bugzilla.novell.com/show_bug.cgi?id=672421
- fdo#XXXXX تشير الى معرف علة خاص بـ ( freedesktop )، مثال: fdo#38425 هو https://bugs.freedesktop.org/show_bug.cgi?id=32275
- tdf#XXXXX fdo#32275 هو https://bugs.documentfoundation.org/show_bug.cgi?id=32275
- #XXXXXXX# تشير الى متقفى علل ( StarDivision ) الداخلية، وهي غير متاحة للعامة، لذلك سيتم إزالتها من المصدر.
- b#XXXXXX# تشير الى متقفي علل ( Sun ) الداخلية، وهي غير متاحة للعامة، لذلك سيتم إزالتها من المصدر.
- lp#XXXXXX تشير الى ( launchpad )، على سبيل المثال: https://launchpad.net/bugs/775608
ما هو ( binfilter )?
الغرض من ( binfilter ) هو تحميل (أيضا كان يستخدم سابقا لحفظ) تنسيقات الملفات الثنائية القديمة من ستارأوفايس 5.2 و ما قبله. ولان هذا التنسيق مرتبط بالفئات الداخلية، اُتُخِذ قرار بأخذ لقطات من النسخ القديمة لتطبيقات الرئيسية ( writer, calc, draw, ... ) ومن ثم تجريدها للوصول إلى القطع الرئيسية المطلوبة لتحميل و حفظ هذه الصيغ و لعمل استيراد / تصدير لها إلى ملفات بصيفة ( xml ) جديدة و ربط الكتل الناتجة لتكوين مرشح منفصل. هذا سمح بإزالة الملفات الداعمة لصيغ الثنائية القديمة من الوحدات العادية، مما سمح بتحرير الفئات الداخلية الخاصة بها من وجوب التوافق مع صيغ الملفات القديمة.
binfilter يدعم القديم.
- لا تهتم في ترجمة الوثائق هناك، انها لا تستحق العناء
- تبدء معظم الاسطر بأحد هذه الرموز: ( /*N*/ ) وتعني على الاغلب " ضروري ". او ( /*?*/ )و تعني على الاغلب " غير ضروري ". لا تهتم بتغيير ذلك، حيث انه غير مهم.
- في الوحدات العادية الغير داعمة لـ ( binfilter )، من الممكن ان تجد التعليق : ( //CHINAXXX )في المكان الذي تم فيه ازالة الملفات الداعمة لصيغ القديمة. وهو غير مهم لذلك يمكنك ازالته.
- إذا كنت ترغب في إصلاح بعض التحذيرات في ( binfilter )، إلقاء نظرة على الاصدار الاحدث و المماثل له لإصلاح التحذيرات ( backporting ). لاحظ ان هذا العمل غير مهم على الارجح.
- لا تحصل على تعليق في هذه الوحدات. وان حدث هذا، فأنت على الغالب في المكان الخطاء.
- من الجيد ان تقوم بتحويل الوحدات الى ملحق مستقل قابل للبناء خارج LibreOffice، مثلا عن طريق استخدام ( SDK )وبتال من الممكن استضافته كمشروع مستقل خارج شجرة LibreOffice المصدرية. قد يعتبر هذا قدر هائل من العمل بسبب اعتماد ( binfilter ) بشكل كبير على ( VCL )، لان محاولة تشغيل ( vcl ) على الملحق ستكون مهمة صعبة.
ايهم افضل الامر( make ) او البناء الجزئي بعد القيام بتعديل؟
اذا قمت بعمل بعض التعديلات على النص المصدري و من ثم اردت التحقق ما إذا كان النص المصدري لايزال يبنى؟ هل تحتاج الى بناء الكل او جزء معين؟ للإجابة على كل هذه الاسئلة واكثر، ثمة شرح مقدم من قبل Norbert Thiebaud على الرابط: http://lists.freedesktop.org/archives/libreoffice/2011-March/009271.html
ما كل هذه الاختبارات: ( unit tests, smoketests, subsequent tests )؟
تمت الاجابة على هذا السؤال من قبل Bjoern Michaelsen في الرابط التالي: http://lists.freedesktop.org/archives/libreoffice/2011-March/009834.html
( make check ) من المستوى الاعلى ستنفذ بناء كامل، ومن ثم عمل كافة الاختبارات اللاحقة ( subsequent tests )، بينما ( make subsequentcheck ) من المستوى الاعلى ستقوم بتشغيل كافة الاختبارات اللاحقة( subsequent tests ) فقط. ستجد المزيد من المعلومات حول ااختبارات الوحدة ( unit tests )هنا، اما بنسبة للإختبارات الاحقة( subsequent tests ) فستجدها QA/Testing/Subsequenttests.
فشل ( smoketest )، كيف يمكنني تصحيح ذلك؟
اذا فشل ( make dev-install ) او ( smoketestoo_native )، فإن التثبيت الذي فشل في ( smoketest ) لازال موجود في: solver/350/*/installation/opt/program/ يمكنك تشغيل ( smoketest )يدويا ومن ثم تفحص خلايا التقرير الحمراء/الخضراء لمعرف سبب الفشل بتحديد.
cd solver/350/*/installation/opt/program/ ./swriter
قم بإغلاق امن وحدات الماكرو، مثال: ادوات-> خيارات-> امن وحدات الماكرو-> مكتب الاغلاق والانخفاض
./swriter $SRC_ROOT/smoketestdoc/*/bin/smoketestdoc.sxw
انقر على زر بدأ ( smoketest )
بديل اخر هو بدأ soffice
في وقت مبكر ثم الطلب من ( smoketest ) ان يتصل به عوض عن قيامة ببدأ واحد بنفسه ( انظر “installationtest.mk: allow override of tested soffice process”). يمكنك بعد ذلك تشغيل soffice.bin
تحت سيطرة المصحح. المشكلة الوحيدة ان الامر make smoketestoo_native
سيقوم باالكتابة على الامر soffice
والذي بدأ للتو مع مجموعة التثبيت الجديدة، نظرا الى اعتماد cpptest
على localinstall
في smoketestoo_native/makefile.mk
.
لذلك، ينبغي عليك عمل التالي:
make smoketestoo_native # in case no solver/*/installation yet
sed -i 's/cpptest : localinstall/#&/' smoketestoo_native/makefile.mk
solver/*/installation/opt/program/soffice --accept=pipe,name=mytest\;urp &
# wait for soffice to come up, attach gdb, etc.
OOO_TEST_SOFFICE=connect:pipe,name=mytest make smoketestoo_native
git checkout smoketestoo_native/makefile.mk