תכנון ממשקי משתמש גרפיים

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

אני זוכר מישהו שזגזג בין לבחור בלזרוס לבין בחירה בכל טכנולוגיה אחרת, כאשר מישהו אומר לו משהו על glade, והוא מייד בא ואומר לי "glade יותר טוב כי יש לו את X" ואז אני אומר לו איך לבצע אותו הדבר בלזרוס, והוא חוזר לאותו אדם ואומר לו ש"לזרוס יותר טוב כי יש לו גם את Y " וחוזר חלילה…

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

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

  1. התממשקות ישירה לשפה (ברירת מחדל פסקל מונחת עצמים, אבל אם אתם ממש רוצים, אתם יכולים להוסיף תמיכה בעוד שפות, אפילו יש הדגמה איך לעשות את זה)
  2. הוא לא רק חוצה פלטפורמות, אלא חוצה User Interface. הtemplate הגרפי של החלון שלכם אינו תלוי בפלטפורמה גרפית ספציפית, מה שמשתנה זה התממשקות הגרפית שלכם, לא ה template
  3. ניתן לטעון את הtemplate בזמן ריצה ממש כמו את glade, אבל ברירת המחדל אומרת שבשפה מהודרת, החלון נכנס לתוך התוכנית, מה שאומר אומנם קובץ ריצה גדול יותר, אבל פחות קבצים שמסתובבים ויכולים להיפגם מטעויות או משחקים של משתמשים.
  4. יכולת להשתמש באותו חלון ביותר מתוכנה אחת, ואפילו להכניס אותו לספרייה משותפת בלי להתאמץ כל כך הרבה (ייבוא קובץ בהגדרות הפרוייקט וזהו, הוא אפילו יוסיף את הנתיב לבד להגדרות המהדר).
  5. מאוד פשוט ליצור ממשק גרפי. אין צורך להתחיל להתפשר: "זה עובד לי רק עם GTK 2.14",  אם זה עובד בזמן תכנון אצלכם, אז הוא עובד בכלל, גם בממשקים אחרים לגמרי, הכאב ראש הזה נגמר.
  6. יכולת לקבל פקדים מעורי מסד נתונים ללא קוד מיוחד. כלומר הוספת תוכן, מחיקה, עדכון וכו' יכולים להעשות ללא כתיבת קוד מצידנו, אפילו לא משנה מה המסד נתונים, כל עוד החיבור משתמש בבסיס של TDataset ו TDatabase, אז זה יעבוד בלי קוד מיוחד. במידה והמסד נתונים שלכם הוא read-only, אז גם הפקדים שלכם ידעו להתמודד עם זה. יש הגבלה של 20 תווים ? אז הפקד שלכם כבר יודע את זה, לא צריך להגיד לו במיוחד. מצביעים על רשומה X ? אתם תראו אותה, הרשומה הבאה תוצג כאשר תעברו אליה וכו', עדיין לא כתבתם ולו שורת קוד אחד בשביל זה. כמובן שאפשר להמשיך בדוגמאות.
  7. יכולת התקנת רכיבים נוספים. הרכיבים אפילו לא תמיד קשורים לתכנות גרפי, אבל מסוגלים לעשות לנו חיי פיתוח קלים ונוחים יותר (לדוגמא טיימר, תכונות האפליקציה שלנו, הרצת תהליך חיצוני, עבודה עם קבצי הגדרות ועוד הרבה מאוד פקדים שונים)
  8. יכולות פיתוח שעדיין לא קיימות בהרבה מהעורכים הגרפיים האחרים כדוגמת: יכולת לזהות מתי אירוע שאנחנו הכרזנו לו callbck למשל, אינו נמצא באמת בשימוש, והיכולת להסיר אותו אוטומטית בגלל שהוא לא בשימוש. הצבעה על אותו callback ליותר מפקד אחד, והיכולת להבדיל בין קריאה לקריאה בתוך הקוד, וכמובן שאפשר להמשיך.
  9. יכולות הרחבה שונות לפי מה שאנחנו רוצים מהסביבה הגרפית, כולל שינוי של הסביבה או הוספת תמיכה בשפה/טכנולוגיה חדשה למרות שבמקור היא לא נבנתה לכך, רק צריך להתקין את החבילה המתאימה בתוך לזרוס.
  10. התמודדויות שונות של האפליקציה שלנו לפי המערכת שאליה אנחנו מכוונים. ב Windows יתווסף לנו manifest (במידה ונבחר או לא נסיר את ההגדרה) במאק נכיל תכונות מיוחדות שלו, עדיין לא היינו צריכים ליצור קוד בשביל זה, הסביבה מנהלת את הקוד בשבילנו

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

22 מחשבות על “תכנון ממשקי משתמש גרפיים

  1. spellchecker

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

  2. מאיר

    1. אולי הוא חוצה פלטפורמות מבחינת חומרה, אך אינו חוצה פלטפורמות מבחינת שפות פיתוח כמו ש-glade מסוגל. glade (ו-gazpacho) ו-gtkbuilder יורשו אינם תלויים בשפה (עם כל המשתמע מכך לטוב ולרע).

    2. דלפי לא היה הראשון בתחום של ה-RAD, דברים כמו PowerBuilder עשו זאת לפניו (אולי היה ראשון שלא בתחום ה-4GL).

    3. ישנה אפשרות להוסיף רכיבים מותאמים אישית (שאף כתובים בשפה אחרת, לדוגמא, דינאמית).

    יש מחיר אשר משלמים עבור גמישות. ברגע שאני משתמש בלזרוס, אני בתכל'ס נועל את עצמי לשפה, או מוסיף תלות – לא תודה.

  3. ik_5 מאת

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

    בקשר לדבר שטויות, ברור שאני מדבר שטויות, אחרת אנשים עוד היו מקשיבים לי באמת 🙂 אני מראה את מה שאני חושב על דברים, אפשר לקבל את זה, או שלא זו בחירה שלכם.

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

  4. ik_5 מאת

    מאיר כמו שכתבתי כאן:

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

    ברגע שאתה עובד עם Glade אתה די נעול לGUI מסויים, וברגע שאתה נעול לזה, אתה בכל מקום צריך להתקין אותו. מה קורה אם אתה צריך שהתוכנה שלך תעבוד גם עם QT וגם עם GTK ? אז אתה כבר בבעיה. אתה לא מרוויח כאן משהו, כי לגמישת שאתה מדבר עליה יש מחיר הרבה יותר גבוהה. גם יותר תלויות בטכנולוגיות שונות, וגם החוסר יכולת להתגמש מבחינת ממשקים. אם מחר תרצה לעבוד עם הממשק של Enlighment, בלזרוס יהיה הרבה יותר קל ליישם את זה ועדין לא תהיה צריך להחליף קוד בנגוד לעבודה עם Glade.

  5. מאיר

    1. ב-glade, qt designer וכד' אני לא צריך להשקיע כלום.

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

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

    4. ובלזרוס אני לא נעול ל-LCL ? או שאני יכול להשתמש בכל widget שאי פעם יעלה על דעתי שאמצא ? לדוגמא, Qwt. אני גם לא מבין את "בכל מקום צריך להתקין אותו". הרי gtkbuilder מובנה ב-gtk+. היכן שיש gtk+ יש אותו, לא צריך להתקין כלום.

    5. גם אם אכתוב ל-enlightenment אני עדיין נעול לרכיבי המכנה המשותף הנמוך המסופקים ע"י ה-lcl.

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

  6. ik_5 מאת

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

    2. אני לא מדבר עם TurboVision, לבורלנד פסקל היתה סביבה ב Windows ובDOS לפיתוח ממשקים גרפיים בשיטה של גרור ושחרר. הגרסגה הכי מוכרת היתה ל windows אבל היה גם משהו לDOS (עכשיו שאני חושב על זה, אני לא חושב שזה היה של בורלנד אלא של חברה צרפתית שהשתמשה בפסקל בשביל זה). אני מדבר אתך על תחילת אמצע שנות ה90 לפני שדלפי יצא.

    3+4. אם אני כותב עכשיו תוכנה ל GTK 2 עם Glade, בשביל שהיא תעבוד לי במאק או בווינדוז, אני צריך GTK 2. במידה ואני כותב בלזרוס, אז אני לא צריך את GTK 2, אלא אני צריך את cooca ואת win Gdi, והם קיימים בכל מקרה בווינדוז ומאק.

    5. ה LCL בנוי בצורה כזו שאתה יכול לגשת אליו גם מתוך widget ספציפי ואפילו הדגמתי איך לעשות את זה עם http://ik.homelinux.org/index.rhtml/projects/fpc/hebtoeng

    6. אני כמעט בכלל לא מפתח תוכניות גרפיות בלינוקס, אבל סתם לדוגמא נקח את ה client XML-RPC שכתבתי, לקח לי שעה שלמה לכתוב אותו, להיכנס לקוד שאני לא מכיר בשביל לתקן באגים ספריית סוקט שמדברת HTTP בשביל שהמוצר עכשיו אחרי שנתיים עדיין עובד ועושה 100% ממה שהייתי צריך בלי ולו בעיה אחת. וכתבתי אותו עם לזרוס. הכמות אנרגיה שלך לכתוב את אותו הדבר עם glade או כל מוצר אחר היתה רבה יותר בשביל לפחות רבע ממה שאני יצרתי.
    אני שותף לדעה שיש הרבה פיספוסים בפרוייקט של לזרוס, אבל השוק עדיין צריך תוכניות desktop ולא רק web.

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

  7. מאיר

    1. ל-gtk/builder/glade יש תמיכה נרחבת מספיק (c, c++, פייתון, רובי, ג'אווה, פרל, c#, shell scripts, php, lua אפילו פסקל).
    http://www.gtk.org/language-bindings.html

    2. אם כך זה לא בורלנד (וזכור לי שלא היה להם כלי כזה). בכל מקרה, לפחות לפי וויקיפדיה, PowerBuilder הראשונה שוחררה ב-91.

    3. אתה עדיין כותב למכנה המשותף הנמוך ביותר.

    כבר הגענו למסקנה שאתה די מקובע. זה שקשה לך לעשות משהו (כי אתה רגיל לדרך אחת) לא אומר שזה באמת כך. אתה כותב כאילו זה משהו מיוחד, או שללא לזרוס אף אחד לא מסוגל לבנות יישומים עשירים: הרי גם אני יכול לכתוב מודול עם api שמשתמש בקובץ ה-glade ולהשתמש בו ב-1000 פרוייקטים. זה שאתה לא מסתדר זו בעיה שלך, לא שלי (הרי אתה גם לא מסתדר עם layout managers, זו לא אשמת אף אחד).

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

  8. ik_5 מאת

    1. שוב, האם אני יכול עם glade ליצור ממשק לספרייה גרפית שהיא לא GTK ?
    2. אתה מוזמן לקרוא את התקציר לספר הזה: http://www.amazon.com/Object-Oriented-Programming-Pascal-Graphical-Approach/dp/020162883X
    ותראה שכן היה דבר כזה, זה שאתה לא יודע שהיה, לא אומר שלא היה.

    3. מכנה נמוך ביותר ? תסביר את הכוונה שלך בבקשה

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

    מאוד נחמד שאתה יכול לשלב את glade אבל שוב האם היא נותנת לי את הכלים שאני צריך ? האם ההשקעה של העבודה איתה באמת שווה את זה ?
    אם אני רוצה עכשין לקחת קוד שלי שיצרתי נכון בלזרוס בסביבה גרפית ואני רוצה שיעבוד לי עם QT4.5, אז אני צריך להגדיר בדיאלוג מסויים שזה המצב, וההידור שאני יעשה יצור לי תוכנית עבור QT 4.5. האם אני יכול להשיג את זה עם glade בכל שפה שהיא ?
    האם אני יכול לשים ממשקים שלמים של glade תחת ספריות משותפות שכולם יכולו להשתמש בזה בלי קשר עכשיו אם מעניין אותו GTK ? אני רק רוצה שמשהו ינהל את הממשק הגרפי ואני אנהל את הלוגיקה של התוכנה שלי ?

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

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

  9. ik_5 מאת

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

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

  10. מאיר

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

    לגבי מכנה משותף נמוך ות'כלס: זה נחמד שאפשר "לקמפל" ל-Qt, Gtk+, cocoa וכד', אבל אתה לא משתמש בהם באמת, אלא רק במה שה-lcl נותן לך (ומגביל אותך אליו). הדוגמא הכי פשוטה: גם Qt וגם Gtk+ נותנים לך BiDi מובנה ויכולת היפוך ממשק אוטומטית לפי הצורך של אותה אפליקציה, ללא צורך בהזזת פקדים וכד' (gtk+ לדוגמא גם יודע לטפל בכיווניות של האייקונים הסטנדרטיים שלו כשזה בעל משמעותית, לדוגמא חיצים, ולהציגם בהתאם לכיווניות).

    זה שלקחת וקימפלת את האפליקציה שלך ל-gtk, לא אומר שתקבל את התכונות (או של Qt, או של cocoa) ושאר הדברים שהם יכולים לספק (לדוגמא: layout managers של כל אחד), מקסימום מראה. אז תטען שאפשר לרדת ל-low level ולעבוד ישירות מול toolkit אבל אז אתה לא יכול לקמפל ל-toolkit אחר (אלא אם תתחיל להסתבך ולבדוק define ועוד שטויות).

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

  11. ik_5 מאת

    שמע בשורה התחתונה לפני דלפי היתה לבורלנד סביבת פיתוח וויזואלית אחרת.

    "
    גבי מכנה משותף נמוך ות’כלס: זה נחמד שאפשר “לקמפל” ל-Qt, Gtk+, cocoa וכד’, אבל אתה לא משתמש בהם באמת, אלא רק במה שה-lcl נותן לך (ומגביל אותך אליו). הדוגמא הכי פשוטה: גם Qt וגם Gtk+ נותנים לך BiDi מובנה ויכולת היפוך ממשק אוטומטית לפי הצורך של אותה אפליקציה, ללא צורך בהזזת פקדים וכד’ (gtk+ לדוגמא גם יודע לטפל בכיווניות של האייקונים הסטנדרטיים שלו כשזה בעל משמעותית, לדוגמא חיצים, ולהציגם בהתאם לכיווניות).
    "
    אתה מתעלם לגמרי מה toolkit אם זה מה שאתה אומר. זו תכונה של ה toolkit שצריך לעשות לה trigger ואתה מקבל כלי מוכן שעושה (או שלא) טריגר לזה. אם זו היתה תכונה של הממשק של GTK ו QT אז הוא לא היה צריך התערבות של שום toolkit או של LCL או משהו אחר. ה layout שאתה מדבר עליו הוא תכונה ששיכת ל glade ולא ל GTK. אפשר ליצור את אותה תכונה גם ל windows וגם ל QT, אבל נשאלת השאלה האם היא מאפשרת ככה לעבוד טוב יותר ?
    בוא ניקח דוגמה אחרת: יש לי ממשק גרפי, המבנה הוויזואלי שלו מכיל הרבה דברים שאסור להם להשתנות במיקום ובמראה שלהם, בעוד שבפקדים אחרים במידה וצריך דו כיוניות יהיה טוב אם יהיה אפשר להפוך את הסדר שלהם. האם אתה יכול באמצעות layout לשלוט בדיוק מה ישתנה ומה לא ? עד כמה שאני מבין איך זה עובד, אתה לא מסוגל לשלוט על איך האורך ורוחב של דברים יהיו, שלא לדבר על התהגויות יותר קריטיות לפעמים.
    אני יודע, אתה הולך על התצוגה המופשטת: תווית טקסט, מקום לכתוב טקסט וכפתורים. אז מה אם זה לא מספיק ברור למשתמש הוא יתרגל לזה. זה לפחות מה שאני מבין מהתגובות שלך עד עכשיו אני מקווה שאני טועה.

    החוכמה בתכנות זה לדעת להתאים את הכלי המתאים למצב שאתה רוצה. לא להתפשר ולהגיד אני אעבוד בשיטה X או בשיטה Y. זו הסיבה העיקרית שאני לא אוהב את ג'אווה למשל. ג'אווה מחייבת אותך לבחור רק בדרך יישום אחת של דברים: תכנות מונחה עצמים. גם אם זה לא מתאים למה שאתה צריך אתה לא יכול להתחמק מזה.

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

    1. ממשק המשתמש הכללי של המשתמש (כלומר הצבע של החלון, טקסט וכו' שהמשתמש בחר לסביבה הכללית שלו)

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

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

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

    דבר נוסף, lcl הוא כמו wxWidgets לא כמו GTK או QT. גם Gnome הוא לא GTK, הוא משהו שמשתמש ב GTK בשביל להשיג מטרה מסויימת. הוא משנה התנהגויות איפה שנוח לו הוא משתמש ביכולות של GTK איפה שזה נוח לו.
    אותו הדבר לגבי KDE.

  12. מאיר

    עכשיו אתה מנסה לשכנע שהמוגבלות של לזרוס/lcl "היא לא באג, אלא פיצ'ר" ? הדעות שלך לגבי דו-כיווניות לא מעניינות אותי (וגם בזה אתה מקבע, אבל זה עניין של טעם, אז אין מה להתווכח שם), מה גם שלמשתמש יש שליטה מלאה על כך (להריץ עם locale אחר, qt עם דגל reverse וכד').

    גם למפתח יש שליטה מלאה על כך (לדוגמא: ב-gtk יש לך אפשרות להכריח direction ללא קשר ל-locale וכן הלאה).

    אז gtk מתנהג בדיוק כמו שהוא צריך בברירת מחדל, ולמפתח ישנה אפשרות לשליטה מלאה אם הוא לא חפץ בברירה המחדל. לעומת זאת lcl לא יכול אפילו להתנהג בצורה השניה – הוא מוגבל מאוד מהבחינה הזו ומגביל מאוד גם אותי (ולא משנה לאיזה toolkit הוא מקומפל).

    כמובן ש-lcl הוא כמו wxWidgets (למרות של-wx כבר יש תמיכה בסיסית ב-bidi), זו בדיוק הסיבה שאני גם לא משתמש ב-wx – הוא גרוע על כל הפלטפורמות (כל פעם שאני נוגע ב-flamerobin בא לי לשבור למפתחים את הראש).

  13. ik_5 מאת

    מאיור, מבין שנינו אתה מי שמקובע. לך נוח משהו ואתה מחליט שזה נוח לכולם. אתה תלחם באנשים שיאענו משהו אחר.

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

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

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

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

  14. ik_5 מאת

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

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

    ואני לא מאמן שאני זוכר משהו שהיה לפני קרוב ל20 שנה (אולי יותר קצת).

  15. מאיר

    אתה מנסה לסובב את הדיון ? אני לא ניסיתי לשכנע אף אחד – זה אתה שכותב פוסט על כמה גלייד דפוק ולזרוס שולט.

    אמרתי לך שכבר יש לך שליטה מלאה על הכל (כולל צבעים ומה לא, אף שאני מעדיף המנעות מבחירה קשיחה של אלמנטים), אבל אתה עדיין ממשיך לחפור בנקודה הזו ? בסופו של דבר glade/gtk ו-qt מספקים שליטה מלאה, וגם אפשרות ל-bidi ראוי ושאר ירקות – שתי הגישות. בלזרוס לא (וזו רק דוגמא אחת שנתתי למכנה המשותף הנמוך שלזרוס מכוון אליו).

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

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

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

  16. ik_5 מאת

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

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

    זו הפתיחה של הפוסט הזה. הבנת הנקרא במה מדובר ? בניסיון שלי של גלייד מול דלפי/לזרוס.

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

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

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

    אתה יודע שהסיבה היחידה שאני ממשיך לנסות את פיתון היא כי אתה מציג אותו בתור משהו שאני לא מצליח למצוא אותו. אתה מראה כמה הוא יעיל וטוב לך ואני לא צליח לראות את זה מייושם אצלי.
    אני שומע אותך מתלונן על עודף הסימנים שיש ברובי, אבל כאשר אני מציג אותם שמתקיימים גם בפיתון, הדיון שלך הופך לתקיפה חזיתית. למשל כשהצגתי לך לפני כמה שנים את הממשק שאני יצרתי ל xml-rpc client הדבר הראשון שעשית זה לתקוף וכמה פשוט לעשות את זה בפיתון וכמה אני בטח מפספס את היכולות להתחרב ולהשתנות, למרות שיצרתי לעצמי כלי שנבנה למטרה מסויימת, לקח לי שעה כולל התמודדות עם באגים בקוד שלא ראיתי מעולם ליצור אותו והוא עונה על 100% מהצרכים שלי.

    אני לא מבין אותך. כאשר זה נוח לך אתה תוקף ומראה כמה הטכנולוגיה שאתה בוחר בה טובה, וכאשר לא טוב לך אתה תוקף כי מנסים להראות טכנולוגיה אחרת.

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

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

  17. מאיר

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

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

    מתחסד ? בקרוב ל-20 השנה האחרונות אין חודש שלא עבדתי/תחזקתי עם פסקל/דלפי לדורותיהם, אני מכיר את הגישות טוב מאוד (כולל ה-ui) והיום נמצא במצב שהשפה והכלים האלה מגבילים אותי לעומת מה שאני יכול להשיג בעזרת כלים אחרים. כבר עברתי הלאה, אני לא נתלה בעבר (גם את OS/2 אני מאוד אוהב ועוקב אחר גלגוליה הנוכחיים, זה שאני לא משתמש בה היום אומר שהצרכים שלי השתנו מאוד והיא לא יכולה לספק אותם). אבל ברור שהניסיון שלך הרבה יותר חשוב משלי ומצרכי.

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

    אני מתנצל שאיני מתלהב מהלהג השיווקי כמו בספר שקישרת, בסה"כ זו טכנולוגיה שטחנתי כמה שנים וכיום עולה לי בכאבי ראש תחזוקתיים ולוגיסטיים, כך שזה ממש לא ממש מזיז לי, been there, done that. בפעם הבאה אני מבטיח להתלהב מאוד, אולי גם לפרסם איזה שלט חוצות בנושא ואתה יודע מה, אף להזמין את הספר מאמזון.

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

כתיבת תגובה

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

הלוגו של WordPress.com

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

תמונת Twitter

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

תמונת Facebook

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

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

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

מתחבר ל-%s