הבלוג של ארתיום
בלוג על לינוקס, תוכנה חופשית, מוזיקה, סלסה, ומה לא!
כתיבת GUI יכולה להיות נסבלת
לפני מספר חודשים, הייתי צריך להתחיל לעבוד על פרויקט בתחום מתמטיקה וויזואליזציה. הייתי צריך לכתוב יישום שמדגים כל מיני דברים מתמטיים מסובכים בצורה יפה ואינטואיטיבית. אחת הדרישות הייתה --- תמיכה בריבוי פלטפורמות (לא הייתי בא למרצה עם יישום שאפשר להריץ רק על לינוקס).
לפני עמדו מספר אפשרויות:
- לממש את הכל ב-Matlab.
- לקחת שפה כמו python עם איזשהם bindings שהם לא תלויים בפלטפורמה.
- לכתוב ב־C++ ולקחת כלי שהוא בלתי תלוי בפלטפורמה:
- להשתמש ב־wxWidgets.
- להשתמש ב־GTKmm.
- להשתמש ב־Qt4.
לצורך העניין, עד היום, הניסיון היחיד שהיה לי בבניית GUI, היה רק עם MFC.
את האפשרות הראשונה פסלתי די מהר. למרות שזה היה מפשט את כל המתמטיקה בצורה משמעותית, כתיבת יישומים אינטרקטיביים ב־matlab זה סיוט. שלא לדבר על כתיבת GUI באופן כללי.
כמובן, אני כבר לא מדבר על העובדה, שלא אוכל להריץ דבר כזה על octave בכלל ואהיה כבול בטכנולוגיה שהיא לא חופשית.
האפשרות השניה, שימוש ב־Python עם numpy, גררה אחריה תלויות רבות (במיוחד עבור התקנה ב־windows ובכלל). בנוסף, עדיין יש תלות ב־toolkit בלתי תלוי בפלטפורמה עבור GUI, מה שלא מוסיף קלות ההתקנה ב־windows.
לכן, די מהר הגעתי למסקנה, שאצטרך לכתוב GUI אמתי ב־C++, העובדה שלא שימחה אותי במיוחד, לאור הניסיון המר שהיה לי בעבר.
התחלתי לבדוק כלים שונים. הדבר הראשון שבדקתי היה wxWidgets. אחרי מעבר קצרצר על tutorials התחלתי להריח MFC עם בניית event tables שלהם וכל מיני דברים מגעילים נוספים. אמרתי, לא!.
עכשיו, ההתלבטות שלי הייתה בין GTKmm לבין Qt4.
התחלתי לקרוא את התיעוד של GTKmm. אהבתי מספר דברים:
- הם לא עושים "הרחבות" של C++ כמו ש־Qt עשו.
- הם עובדים עם refcounting עבור ניהול זיכרון.
- העבודה עם סיגנלים היא הרבה יותר דומה למה ש־boost עושים.
- רישיון LGPL שלא מגביל אותך לתכנה חופשית בלבד.
אבל, יחד עם זאת זיהיתי מספר מגרעות חשובות:
- התקנה מסובכת בטירוף, המשלבת מספר לא מבוטל של תלויות שצריך להתקין בנפרד (אני מדבר על Windows).
- תיעוד לוקה בחסר, ליתר דיון המדריכים שלהם לא ממש מביאים אותך להבנה, כיצד לבנות יישום GUI.
- מראה לא טבעי בסביבת Windows. שמורגש היטב ביישומים כמו gimp, dia ועוד.
לכן, התחלתי להסתכל בכיוון Qt4.
היו איתו מספר בעיות שגרמו לי לחשוב האם להכנס אליו בכלל:
- הרחבה ל־C++ של signals, slots, emit ועוד. בגלל ש־signal זה Keyword ב־Qt, זה פוגע ב־toolkitים אחרים שמתמשים במילה הזו, כמו Boost.Signals. בנוסף, יש כל מיני בעיות קטנות כמו שחייבים להכניס כל QObject לקובץ C++ נפרד.
רישיון GPL. או ליתר דיוק, חובה לשחרר קוד תחת רישיון חופשי (יש ל־Qt הסתייגויות עבור כמעט כל רישיון חופשי קיים).
לא שהתכוונתי לעשות אחרת, פשוט, אם אי פעם אצטרך לעבוד על פרויקטים שלא יהיו שייכים לי, או אפילו להעביר את הקוד למרצה לשימוש שהוא רוצה לעשות בו. יש בעיה עם "חובת GPL".
- QString שעובד עם utf-16, אני חושב שזו טעות גדולה שגורמת להמון באגים.
אבל, התחלתי לקרוא את התיעוד שלהם. הוא היה הקש ששבר את גבו של הגמל. פשוט, קראתי ותוך שעה־שעתיים יכולתי לכתוב יישומי GUI בצורה מהירה ופשוטה. יצירת יישום, ציור, בניית Layout היו די פשוטים וטבעיים.
הרגשתי, שאני עובד עם כלי שהושקעה בו מחשבה רבה, מחשבה שנועדה בראש ובראשונה להקל על המפתח. לתת לו את כל הכלים שדרושים כדי לא להמציא את הגלגל מחדש.
אומנם היו פה ושם קטעים מעצבנים, זה פשוט עבד:
- תיעוד מעולה עם דוגמאות והסברים על כל פונקציה.
- התקנה פשוטה מאוד ב־Windows שנותנת תוך זמן קצרצר סביבת בנייה מלאה.
- מראה יישום טבעי ב־Windows (שוב).
אז, GPL... אז מה! מי שלא מפתח תכנה חופשית שיקנה רישיון. הכלי הזה שווה את הכסף.
בסוף, יצא לי לדבר עם חבר טוב שלי, שמומחה גדול בפיתוח ב־Windows ומכיר את כל הקוד של MFC היטב. אחרי שהראיתי לו את הקוד שכתבתי... הוא התלהב מ־Qt4...
אני לא אגיד שזה Toolkit מושלם, לדגומה, לא אהבתי שאין שימוש ב־namespaces, לא אהבתי הרחבות שונות, לא אהבתי שהוא מנסה להיות תואם קומפיילרים עתיקים. מה שהיה חשוב מבחינתי, הוא מאיץ את הפיתוח.
בקיצור, נדמה לי, שלמרות כל המגרעות, Qt4 מנצח.
תגובות
מצטער אותי שזה הניסיון שיש לך בעולם, ושאתה לא טעמת דברים יותר ידידותיים למתכנת.
QT בתור ספרייה לפיתוח גרפי היא הספרייה הכי נחמדה בעולם מניסיון, אבל יש דרכים אחרות לעבוד, בהם אתה עובד הרבה פחות קשה, הדרך העיקרית היא כמובן RAD.
היותו כרגע אני מאוד לא אוהב את ההתנהלות של לזרוס, אני לא אנסה להכניס אותך לתמונה, אני רק אגיד לך שזו כבר שיטה שהיתה חוסכת ממך הרבה אנרגיות ותלויות, והיית מרוויח מכל העולמות + מגלה עולם חדש.
יש לי בעיה עם כלי RAD. כך, למשל, לא השתמשתי ב־QtDesigner. שאפילו מאפשר לך "לצייר" יישום ולאחר מכן, למלא בו תוכן.
בעיה העיקרית, היא שאתה מאבד שליטה על מה שאתה מכניס, יותר מזה, אם אתה רוצה לעשות שינויים כלי RAD עוד יותר בעיתיים.
להזכירך, אני עבדתי עם MFC ו־VS ייצר עבורי קוד. זאת בדיוק הייתה הבעיה שלי -- הבעיה העיקרית.
לדוגמה, במערכת שבניתי, אני מסיר ומוסיף פקדים בצורה דינאמית (בהתאם למימד הנבחר), זאת בדיוק הנקודה שרוב הכלים ל"ציור" ה־GUI נופלים.
כלי RAD הם אין אלא אשליה. הם עוזרים לך לעשות דברים פשוטים, אבל מאוד מסבכים אותך כשאתה מנסה לעשות משהו מחות לקופסה.
huh ?! ממתי VC נהיה RAD ?! זה שהוא מאפשר לך ליצור resource "גרפי" לא הופך אותו ל RAD לא משנה כמה ינסו לשכנע אותי שכן.
ארתיום קח לסיבוב את לזרוס במקרה הזה ותראה את ההבדל ! ממש לא מסובך ליצור פקדים בצורה דינמית בהתאם לצורך גם כשה template המקורי שלך עם פקדים קיימים. למעשה זה יוצר לך פחות עבודה. זה כמובן שאתה משתמש בכלי RAD אמיתי ולא בכלים כדוגמת VC שהקשר בינו לבין Visual זה בערך כמו הקשר של עיפרון ועולם הדפוס. שניהם מספקים כתיבה, אבל עיפרון זה לא דפוס, זה רק סוג של גרף.
אם אתה מתעקש ד"א לעבוד עם ++C תוריד לWindows את גרסת הניסיון של C++ Builder או איך שקוראים לה כיום ותנסה אותה, ואתה תראה את ההבדל בין RAD לבין משהו שמתיימר להיות.
שוב, כמו שאמרתי לעיל, הבעיה שלי היא לא בנוחות הכלי, אלא בעובדה שהקוד נוצר ע"י יישום צד ג' כך שאין לי שליטה על הקוד שלי.
בעבר עסקתי בפיתוח מנשק לפני כשנה בתחום המתטמי . ממליץ בחום על gtkmm (שאיתו היה לי ניסיון ) ואף כדאי לבדוק את ה wx-widget שוב פעם.
שים לב שאם אתה כותב במסגרת אקדמית אז GPL והרישוי של מקום הלימודים מתנגש הרבה פעמים. בגלל זה LGPL עונה על חלק מההתנגשויות ופה יש בעייה רצינית אם נושא האקדמיה . אינני יודע מה המסגרת אצלך אומרת אבל שלי טוענת כי כל פיתוח הינו רכוש המוסד שזה סעיף מאוד מעניין אבל בסדר.
בנוגע לכלי RAD בשימוש מטתמטי זה סיוט ממדרגה רצינית בגלל כל מיני זבל שאתה מקבל (שבשביל להוציא אותו יוצאת לך הנשמה ). אם בהתחלה אתה מאמין שזה נוגע רק לעבודת הgui לאט לאט אתה מגלה שהפגיעה בקושר העובדה (מהירות תגובה FPS וכו'... ) הינה ממש בלתי נסבלת ואכשיו לך תתקן קוד אוטומטי.
זה כמו לעבוד עם קוד natural שתורגם ל java (ממליץ בחום לבדיקת של חומרי הרגעה).
העניין הוא שאני כן נותן את כל הקוד שלו, אפילו תחת רישיון MIT. ל־Qt יש הסתייגות עבור MIT. מה שכן, אם אוניברסיטה תרצה להשתמש בקוד הזה ולבנות תכנה סוגרה וגם להפיץ אותה... היא תצטרך לרכוש רישיון.
חוץ מזה, אין שום מניעה לקחת את הקוד שלי. אגב, גם אין מניעה שאוניברסיטה תהיה בעלות על קוד תחת GPL...
ד"א, מה אתה חושב שקורה עם סטודנטים שמפתחים יישומים ב־Vs.Net הבאה תחת רישיון אקדמאי ולאחר מכן רוצה להפיץ את התכנה? כן, הם צריכים לקנות רישיון מלא עבור VS.
בקיצור. עזבו אתכם רישיונות. אם האוניברסיטה תרצה את הקוד, שהיא תשבור את הראש :)
לא הבנתי למה דילגת בבחירותיך על http://wxpython.org/
(מעולם לא כתבתי אליו, ולכן איני ממליץ עליו, רק מזכיר שהוא קיים)
קודם כל לא דילגתי, כמו שאמרתי לעיל, Python הייתה אחת האופציות, אבל כפי שאמרתי היא גררה שתי תלויות כבדות: numpy ואחד ה-toolkitים הגרפיים, בפרט wxPython אחד מהם.
במזרים השתמשתי בפייתון ו- pythoncard (שמבוסס על wxpython). אמנם יש תלויות, אבל באמצעות py2exe יצרתי קובץ exe עצמאי. לא פתרון אלגנטי אבל לא מסובך לביצוע.
אני מסכים עם עידו קנר: הכלי הכי נוח ליצירת Gui חוצה פלטפורמות הוא לזרוס (אבל צריך ללמוד פסקל בשביל זה...)
pythoncard זה נחמד אבל השאלה היא עד כמה זה מסובך לעבוד עם גרפיקה שם, בסה"כ אני עושה דברים די מסובכים ברמת ציור, סיגנלים, הוספה הסרה של רכיבים בצורה דינאמית ועוד.
מאוד פשוט!
pythoncard מתבסס על wxpython אבל חוסך מימך לצייר "על עיוור" את ה- gui. ב- pythoncard אתה יכול לצייר את ה- gui בעצמך, להסתכל על ה- properties של כל caption ועוד... (ההפעלה של pythoncard באמצעות resourceEditor).
רשימתcomponents
תמיכה ב- events
דוגמא: ציור לוח שנה
תנסה את המדריך למתחילים ותבדוק אם מתאים לך.
מצטער, שכחתי שאתה לא משתמש בוורדפרס (ולכן כל הקישורים שסיפקתי לא נרשמו היטב "ובילגנו" את התגובה)
אל תדאג, סידרתי את זה, פשוט בפעם הבאה... "תצוגה מקדימה" :)
אילן, אני אשלח לך קישור לתכנה בדוא"ל (כי לא רוצה לפרסם אותה כאן, זאת עבודה לאוניברסיטה)
תסתכל על מה שאני עושה שם (תשים לב לכפתורי dim/vectors) ותראה איך זה עובד.
אני לא בטוח שזה יהיה פשוט לעשות עם python card: שינויי GUI דינאמיים.
הוסף תגובה:
חובה לאפשר JavaScript כדי להגיב.