بالنظر الى المشروع نظرة أولية, نلاحظ انه مقسم الى ثلاث solutions, الاثنان الاوليان intern و extern اظن انهما غير مهمين الان, حسب تصوري انهما مجرد مكتبات معدة مسبقا او شي من هالقبيل .. ساغض الطرف عنها في الوقت الحالي.
الـ solution الأساسي هو blender, و هو يحتوي في داخله على العديد من الـ projects. احد هذه الـ projects اسمه blender, و لكن عند النظر اليه فهو مجرد ملف واحد يحتوي على الـ main function
بدايةً, الـ main قد يبدو معقدا, و لكنه في الحقيقة مجرد initialization و الشغل الحقيقي يبدأ عند الدخول في screenmain
لو تضغطوا F10 و تمشوا على الكود خطوة خطوة, ستلاحظون هذا الامر.
داخل screenmain يوجد loop كبيرة جدا,
while( 1 ) { // huge loop ..}تحتوي هذه الـ loop على الية للامساك بالـ events و معالجتها .. و هذا واضح من بعض الأسطر مثل:
else if (event==AUTOSAVE_FILE) {...و لكن هذا ليس كل شيء في هذه الـ loop, فأنا اتصور ان برنامج مثل الـ blender ليس فقط event driven, اقصد ان البرنامج ممكن ان يقوم بعمليات حتى في حال عدم وجود اي events
بعض هذه العمليات اللتي تتم حتى في عدم وجود اي event قد تكون animations مثلا ..
هذا الجزء من الكود procedural و ليس object oriented, لم الق نظرة كبيرة على باقي المشروع, لكن يبدو ان جزءا كبيرا منه مكتوب بالسي, او على الأقل مكتوب بطريقة procedural و ليس oo.
على كل حال,
لو تركت البرنامج يمشي لوحده بضع ثواني (نصف ثانية كافية), ثم وضعت break point داحل اي نقطة في الـ loop, (مثلا عند اول سطر فيها), ستجد ان البرنامج لن يتوقف .. و لن يصل الى الـ breakpoint مهما تركته من الزمن .. الا اذا قمت بالضغط على نافذته .. عندها فقط ستجد انك وصلت الى الـ breakpoint و أن الـ debugger سلمك البرنامج للتحكم به.
ماذا يعني هذا؟
هذا يعني على الأغلب ان البرنامج يمر في حلقة أخرى في مكان آخر من الكود, ينتظر وصول الـ events لكي يتصرف عليها .. و عندما يصل الـ event فقط سيقوم بالخروج من هناك و العودة الى الـ loop الأصلية لمعالجة هذا الـ event الجديد.
على فرض ان هذه النظرية صحيحة .. سنقوم بترك البرنامج مرة أخرى يعمل لعدة ثواني لوحده .. ثم نذهب الى الـ debugger و نضغط على الزر pause (او لعل اسمه بالحقيقة break all)
سنجد ان البرنامج توقف في مكان ما من الكود .. و سيكون المكان اللذي يصادف ان البرنامج ينفذه الان.
هذا ليس مهما .. المهم اننا نستطيع النظر الى الـ call stack لمعرفة اين يقف الكود الان في بالنسبة لـ screenmain؟
في نافذة الـ call stack, سنجد قائمة بالـ functions اللتي دخلناها .. اذا عملنا دبل كليك على اي عنصر في القائمة, سنرى اين يقف الكود في ذلك الـ function
لو دخلنا الى screenmain سنجد انه واقف عند screen_qread
لو دخلنا الى screen_qread سنجد ما هو واقف عليه .. و هكذا
سنجد في النهاية انه يعتمد على winlay_process_events من اجل استقبال الـ events
هنا سندخل في تعقيدات و تفاصيل لا داعي لها ..
فلنعد الى هذا الـ screenmain
هناك شي لفت نظري .. و هو استدعاء screen_find_area_for_pt
يبدو انها من اجل اكتشاف مكان الماوس بالنسبة للبرنامج .. اذا نظرنا داخل screen_find_area_for_pt سنجد انه يمر على linked list لما يبدو انه screen areas و يحاول تحديد في اي منطقة من الشاشة يقف مؤشر الماوس ..
همممم .... حسنا اذا .. هذه بعض الملاحظات الأولية .. و هي مجرد ملاحظات .. لا أكثر ولا أقل.
بالمناسبة, هذه صورة لتوضيح الـ call stack
