חיוג מהיר ל OpenMoko חלק ראשון

מאז העדכון האחרון, בנתיים FPC בגרסה 2.5.1 מכיל bootstrap שעובד במוקו -> ניסיתי עם shr, אז החלטתי לבנות תוכנית לניסוי עם לזרוס עבור OpenMoko.

אחד הדברים החסרים לי במיוחד זו תוכנה לבצע Speed Dial שאני משתמש בה עבור מספרים שאני משתמש בהם הרבה.  אז החלטתי לבנות אחת.

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

אז בהתחלה יצרתי את הרכיב כמו שרציתי אותו בתוכנה, אבל אז הבנתי שאני שוב מצמיח אוזניים ארוכות, אז שיניתי שוב את הגישה לרכיב כללי יותר שמתאים ליותר מצבים.

תוך כדי, גיליתי ששוב אני כותב יותר מידי קוד על שום דבר שבאמת צריך. ושאלתי ברשימת הדיוור כמה שאלות ופתאום במקום 20 שורות הקוד שכבר כתבתי יכולתי לקבל את אותה העבודה עם 3 שורות קוד בלבד. ועם עוד בעיה שנתקלתי בה, גיליתי שגם איתה אפשר להתמודד עם שורת קוד אחת.

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

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

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

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

2 מחשבות על “חיוג מהיר ל OpenMoko חלק ראשון

  1. לב

    עברתי משהו דומה:
    לאחר שנים של תכנות ב-Windows עם VS על גרסאותיו, התרגלתי שכל חלון, בין אם זה חלון ראשי של תוכנה ובין אם זה חלון "בן" כגון כפתור, חייב לקבל גודל ומיקום אבסולוטיים בפיקסלים ואם אני רוצה שבמצב כלשהוא הגודל או המיקום ישתנו אני חייב להשקיע, לתפוס את ה-event הרלוונטי ולכתוב את הקוד הנחוץ.

    אפילו MFC (אוסף מחלקות שנועדו לפשט עבודה עם Win32 API) עם כל המשקל שלו לא נתן מענה.

    ואז גיליתי את Linux ואחרי שהבנתי קצת מה היא ערכת כלים גרפית (מושג שלא קיים ב-Windows) ניסיתי לייצר חלון בסיסי עם כפתור בעזרת glade.
    ונתקעתי!
    הכפתור התעקש למלא את החלון ולא יכולתי לשלוט בגודל או במיקום שלו.

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

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

    בקיצור, זה הכל עניין של הליך מחשבתי…

  2. ik_5 מאת

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

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

    יותר מזה, הקוד שאני כתבתי (הגרפי -> את רובו לא כתבתי פיזית בקוד אלא בצורה גרפית) מתאים גם לעבוד ב Qt, הוא מתאים לעבוד במערכות שעובדות בWindows CE, הוא מתאים ל Iphone וכו'. כל עוד FPC תומך במערכת כלשהי הקוד שלי יכול לעבוד בו וזה יתרון ענק על פני כלים כמו VC או אפילו Glade.

    הדבר היחיד שדורש עבודה אמיתית בו זה התממשקות פר סוג מכשיר טלפון, כל השאר נתמך Out of the box.

כתיבת תגובה

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

הלוגו של WordPress.com

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

תמונת Twitter

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

תמונת Facebook

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

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

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

מתחבר ל-%s