wxWidgets out LCL in

כאשר אני מנסה להסביר על LCL לאנשים, השאלה היא "איך הוא מסוגל לעבוד עם הרבה מערכות גרפיות, מה הוא משתמש ב wxWidgets" ? ובכן ממש לא !

LCL פירושו Lazarus Component Library. הLCL הוא הספרייה הגרפית המגיעה עם Lazarus, ומספקת API אחיד עבור כל הממשקים הגרפיים שבה היא תומכת.

כאשר אנשים מציעים ללזרוס לתמוך גם ב wxWidgets, הם בעצם לא מבינים שהLCL עושה אותו הדבר, רק בצורה שלדעתי גמישה יותר.

אז איך ה LCL בעצם עובד ?

נגיד ויש לנו API של ספרייה בשם GTK 2. הספרייה מכילה עבודה עם אותות (signals) בשביל אירועים, ובנוייה בצורה מאוד מסויימת. למשל List box ו TreeList (נו האייקונים, רשימה וכו' של קבצים), שניהם מכילים את אותו ה API, כי זה אותו הדבר. מה שמשתנה זה התוכן בתוך הרכיב. ואז אם אני רוצה לכבות את החיפוש שיש ב GTK 2 (אבל לא קיים בספריות האחרות), אני צריך להגיד ב GTK לתת הרכיב של הרשימה לכבות את האפשרות.

בQT, יש לנו אובייקטים שהם הרכיבים שלנו ואפשר לשנות להם את התכונות, להפעיל שגרות וכו'. האירועים בQT, מתרחשים ע"י מימוש מחלקות של אירועים ורישום שלהם (לפחות עד כמה שהבנתי מהדוקומנטציה, אין לי ניסיון).

על פניו צריך לממש כל דבר כזה לבד נכון ? ובכן ה LCL מספק API אחיד, שיוצר רכיב, מה שאומר שListBox תמיד יהיה זהה (בהתנהגות ובAPI שלו) ללא קשר אם אנחנו משתמשים ב GTK, QT או אנחנו בכלל משתמשים ב WinCE.

היות והAPI אחיד, הקוד הנמוך בLCL שנמצא תחת ספריית interfaces, אשר בעצם מרכז את ההתנהגות על ידי ביצוע API של כל ספרייה, אל מול הAPI הגבוהה יותר. אם ספרייה לא תומכת בכלל בתכונה מסויימת, או בפקד מסויים, אז או שנמצא מימוש מלא שלה באמצעות הLCL, ע"י בנייה שלו ממש מ0 ע"י הAPI ה"בעייתי", או שנקבל דיווח שהיא אינה נתמכת באותה ספרייה (במידה ואי אפשר ליצור אותה, או תכונה מסויימת אינה ממומשת).

כך למשל, צביעת הרקע של כפתור בWindows אינה אפשרית, אלא אם אנחנו מציירים כפתור מ0 בעצמנו, מה שאומר שיש 2 (למעשה 3) סוגים של כפתורים, כפתור "טבעי", שמשתמש בAPI של כל המערכות השונות שמספקות כפתור, ועוד ביצוע שמצייר מ0 כפתור, בשביל שתיהיה אפשר לשים תמונה, צבע, שינוי המיקום של הטקסט וכו'.

כאשר מדובר באירועים, האירועים הם בשמות של הLCL, ובכך לא משנה אם QT ממש אירועים באמצעות מחלקות ספציפיות, בעוד שGTK ממש ע"י אותות. גם לא משנה מה השם של האירוע בכל API נמוך, כי ברמה שאנחנו עובדים, השם נשאר אותו הדבר.

אם אנחנו מעוניינים, עדיין ניתן לגשת ולבצע פעולות ברמה הנמוכה על הרמה הגבוהה בתוכנה שלנו, אבל בד"כ עדיף שלא, ואם כן, אז לעשות את זה ברוח הפרוייקט, שזה לממש API גבוהה ללא קשר למערכת עצמה.

היה בעבר התחלה של המרת הLCL לשפת ++C, שיוכלו גם תוכנות שכתובות בשפה המוזרה והאקזוטית הזו, כך שפעולות Binding לשפות שונות גם אפשריות אם אתם מעוניינים.

הדגש הוא כמובן על אחידות, בלי קשר לסביבה הגרפית, או מערכת ההפעלה. אני חושב שהיות והדבר נכנס פיזית לקוד הריצה שלנו (אלא אם אנחנו ממש רוצים לעשות קוד גרפי בתוך ספרייה משותפת), מה שחוסך את הצורך בספרייה עצמה בתור תלות.

כתיבת תגובה

הזינו את פרטיכם בטופס, או לחצו על אחד מהאייקונים כדי להשתמש בחשבון קיים:

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת / לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת / לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת / לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת / לשנות )

מתחבר ל-%s