הלו...

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

לכן ישבתי יום או יומיים ותכננתי את X-Shell, שפה לפיתוח גרפי שמתוכננת לדעתי טוב יותר מאלה הקיימות, ופותרת את הבעיות האלה ובעיות אחרות. העליתי תיאור קצר וראשוני (מאוד, מאוד ראשוני...) של השפה לפה:
http://israblog.nana10.co.il/blogread.asp?blog=642035&blogcode=11062219

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

מה היתרון של זה ע"פ (לדוגמה) סקריפט bash שמשתמש ב־dialog להצגת הממשק?

באמת כבר מזמן לא שיחקתי עם TclTK...

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

פינגווין אדום :

באמת כבר מזמן לא שיחקתי עם TclTK...

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

מה רע ב:

זה
או ב
זה

למה צריך שפה מיוחדת ?!
אה ואם כבר שפה מיוחדת, אפל כבר היו בקטע הזה פעם

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

(ותודה רבה על התגובות, זה חשוב לי לדעת...)

LemonLime :

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

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

אתה יכול לפרט בקשר ל-1...?
אם אני כותב תוכנה שמבוססת על gtk, למשתמש יש אפשרות לשנות אותה בלי להיכנס לקוד...?

בקשר ל-2, אני יודע שזה אפשרי, אבל בתור עובדה, מתכנתים פשוט לא עובדים בצורה הזאת... אז אני אומר, בואו נכריח אותם...
אני חושב על xsh בתור המקבילה הגרפית לסקריפטים של שורת הפקודה... תחשוב על הגמישות שיש לך כשאתה יכול להשתמש בכלים כמו grep, awk, head... לא היה הרבה יותר קל אם הגמישות הזאת היתה קיימת גם עבור תוכנות גרפיות...? למשל, עם כלים שמשנים תיבות טקסט ככה שיוכלו להכיל רק ספרות, או כפתורים שמבצעים פעולות מסויימות ושאפשר להדביק לכל ממשק קיים שיש לך...

את wxPython אתה מכיר?
זה פורט של wxWidgets לפיטון.
זה סקיפטי, מוגדר היטב, גמיש, קל (יחסית) לשימוש, מכיל מגוון רב מאד של פקדים גרפיים.
בקיצור, מה שאתה צריך, אבל בלי להמציא את הגלגל, לא?
תתקין את הדמו המעולה שלהם כדי להתרשם.
http://www.wxpython.org/index.php

LemonLime :

אתה יכול לפרט בקשר ל-1...? אם אני כותב תוכנה שמבוססת על gtk, למשתמש יש אפשרות לשנות אותה בלי להיכנס לקוד...? בקשר ל-2, אני יודע שזה אפשרי, אבל בתור עובדה, מתכנתים פשוט לא עובדים בצורה הזאת... אז אני אומר, בואו נכריח אותם... אני חושב על xsh בתור המקבילה הגרפית לסקריפטים של שורת הפקודה... תחשוב על הגמישות שיש לך כשאתה יכול להשתמש בכלים כמו grep, awk, head... לא היה הרבה יותר קל אם הגמישות הזאת היתה קיימת גם עבור תוכנות גרפיות...? למשל, עם כלים שמשנים תיבות טקסט ככה שיוכלו להכיל רק ספרות, או כפתורים שמבצעים פעולות מסויימות ושאפשר להדביק לכל ממשק קיים שיש לך...

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

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

DanRR :

את wxPython אתה מכיר? זה פורט של wxWidgets לפיטון. זה סקיפטי, מוגדר היטב, גמיש, קל (יחסית) לשימוש, מכיל מגוון רב מאד של פקדים גרפיים. בקיצור, מה שאתה צריך, אבל בלי להמציא את הגלגל, לא? תתקין את הדמו המעולה שלהם כדי להתרשם. http://www.wxpython.org/index.php

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

ik לא מחובר :

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

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

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

יש כמובן גם ממשקי dialog גרפיים, כמו zenity, kdialog ו-xdialog ואם רוצים ממשקים מורכבים יותר, יש את gtk-server המספק גישה מלאה ל-API של GTK לכל מה שיודע להשתמש ב-pipes, ipc וכד':

http://www.gtk-server.org/examples.html

פינגווין אדום :

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

חוץ מ-tk, אילו עוד שפות כאלה יש?
השיפור בביצועים בתוכנה מקומפלת לעומת סקריפט לא נכון לדעתי כשמדובר בתוכנות גרפיות - רוב הזמן מנוצל לעיבודים הגרפיים, שממילא נמצאים בספרייה או במפענח.
אני לא מכיר הרבה יישומים שמאפשרים שינויים בממשק ברמה שפיירפוקס מאפשר.
טעינה של קובץ CSS עובדת גם אם המפתחים לא התכוננו לזה מראש...?
קבצי UI נשמעים כמו משהו שהייתי רוצה שיהיה לי, אני אבדוק את זה... גם הם עובדים בלי שיתוף פעולה מצד התוכנה המקומפלת...?

mksoft :

יש כמובן גם ממשקי dialog גרפיים, כמו zenity, kdialog ו-xdialog ואם רוצים ממשקים מורכבים יותר, יש את gtk-server המספק גישה מלאה ל-API של GTK לכל מה שיודע להשתמש ב-pipes, ipc וכד': http://www.gtk-server.org/examples.html

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

TK אינה שפה אלא ספריה, לרוב שפות האינטרפרטור היום יש בינדינג לספריות הגראפיות הנפוצות.
אמת, שימוש של יישום בCSS (או קבצי UI) דורש "שיתוף פעולה" מובנה שלו.
רבים מהמפענחים (פרל בטוח, PHP בטוח) "מקריבים" זיכרון לטובת ביצועים, זה אומר שביישום גדול שרץ באופן קבוע תהיה צריכת זיכרון גבוהה יותר משמעותית בשפת מפענח (גם אם הOPCODE תופס פחות מקום מקוד-מכונה ממש). בנוסף, יישומים גראפיים הם מטיבם מבוססים על אירועים ושגרות אירוע. המנגנונים שמחוללים שגרת אירוע בכל פעם יהיו איטיים יותר משמעותית כשהשגרה הזו היא קוד בשפת אינטרפרטור. ביישום רציני זה מצטבר להרבה מאד אירועים וסיגנאלים, והרבה מאד קריאות לפונקציות מגיבות, זה יסבול מאוברהד משמעותי יותר מזה של קוד סיריאלי.

פינגווין אדום :

TK אינה שפה אלא ספריה, לרוב שפות האינטרפרטור היום יש בינדינג לספריות הגראפיות הנפוצות. אמת, שימוש של יישום בCSS (או קבצי UI) דורש "שיתוף פעולה" מובנה שלו. רבים מהמפענחים (פרל בטוח, PHP בטוח) "מקריבים" זיכרון לטובת ביצועים, זה אומר שביישום גדול שרץ באופן קבוע תהיה צריכת זיכרון גבוהה יותר משמעותית בשפת מפענח (גם אם הOPCODE תופס פחות מקום מקוד-מכונה ממש). בנוסף, יישומים גראפיים הם מטיבם מבוססים על אירועים ושגרות אירוע. המנגנונים שמחוללים שגרת אירוע בכל פעם יהיו איטיים יותר משמעותית כשהשגרה הזו היא קוד בשפת אינטרפרטור. ביישום רציני זה מצטבר להרבה מאד אירועים וסיגנאלים, והרבה מאד קריאות לפונקציות מגיבות, זה יסבול מאוברהד משמעותי יותר מזה של קוד סיריאלי.

אני מוכן להתערב שתוכנה שתשתמש ב-xsh תצרוך פחות מרבע מהזיכרון של תוכנה מקבילה שמבוססת על gtk, וזמן התגובה שלה יהיה מהיר לפחות פי 20, גם אם נקנפג את מנוע התצוגה של אחת מהספריות ככה שהמראה יהיה זהה.
(אפשר להוסיף להתערבות את התנאי שהספרייה תהיה מוכנה עוד שנה, ואז נבדוק את העניין באוגוסט פינגווין הבא על איזה לפטופ מורעב-זיכרון... המ...)
אחת הסיבות (לא העיקרית אמנם) שהמחשבה על פיתוח של טולקיט חדש הלכה והתחזקה אצלי בשנה האחרונה היא האיטיות הבלתי נסבלת של gtk וזלילת הזיכרון של הספרייה הזאת (למשל, תוכנה שקוראת ל-gtk_init ויוצאת מיד מקצה יותר מ-2 מגה (!!) זיכרון, ואפילו לא טורחת לשחרר את רובו...)

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

בכלל תיקנו את ה RTL ב tcl/tk כבר? או שהוא עדין לא עובד?

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

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

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

אני לא מבין למה כולם מציעים שפות קיימות , למה לא לעזור ללמון-ליים לכתוב את ה-XSH שהוא הציע ???

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

ככה שתחשבו על זה מממווואאההה.

תודה...
(מה זתומרת "יש מצב שיהיה הבדל משמעותי בביצועי המערכת"...? ברור שיהיו כאילו... זה חלק מהעניין כאילו... )

בכל מקרה... ניסיון שני:
http://israblog.nana10.co.il/blogread.asp?blog=642035&blogcode=11065760
האמת היא שאין כמעט שום קשר בין הניסיון הראשון לניסיון השני, למרות שאצלי בראש הם התפתחות ישירה אחד של השני...
בין השאר ויתרתי על הרעיון הקצת טיפשי ליצור שפה חדשה ותכננתי את זה בתור סתם ספרייה כמו כולם...
ככה שהשם xsh נשאר רק מסיבות היסטוריות (גם אתמול זה סוג של היסטוריה, לא...?) וגם כי כבר הספקתי להיקשר אליו רגשית...

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

עם השנים נוצרו כמה וכמה טולקיטים שהיו אמורים להיות "יותר מהירים". בדרך כלל הם היו מהירים כי הם עטפו את XLIBS בלי הרבה תוספות. שימוש בטולקיטים האלו לא שיפר משמעותית (אם בכלל) ביצועי יישומים כי זה סתם אילץ את מפתחי היישומים לממש בעצמם שכבות אבסטרקציה מסויימות שלא היו בטולקיט. מימוש השכבות האלו על-ידי מפתח האפליקציה עשוי לעתים לספק מהירות כי רק מה שהאפליקציה צריכה ימומש, אבל במקרים רבים הוא יהיה פחות מהיר מטולקיט שכולל את השכבות האלו, ושנעשתה עליו עבודה רצינית בעניין ביצועים (לדוגמא - QT וcopy-on-write).
ועדיין, לכל טולקיט שהוכיח את עצמו במהלך השנים יש בינדינג לשפות האינטרפרטור הנפוצות, למי שרוצה ומוכן לשלם בביצועים, ולא נראה לי שעוד אחד יפתור פה בעיה ממשית.
אם כבר משקיעים במשהו כזה, אז אולי שווה להשקיע בטולקיט שיהיה מראש תפור לXCB במקום לXLIBS הישן. XCB מסודר יותר, נקי ומודולארי הרבה יותר ומהיר יותר. נכון להיום הוא נמצא בשימוש דרך שכבת תאימות ל- XLIBS, לכתיבת קוד ישירות מול הAPI שלו יכול להיותר יתרון משמעותי.

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

איך אפשר לקרוא, זו תמונה מספיק שה-AA נראה נורא על המסך שלי, כבר בלתי קריא.

נקודה מעניינת לגבי מה שצריכים. לפחות מה שצריכים כאן בארץ: מה לגבי עברית?

ובהזדמנות זו: סדרת המאמרים (הלא גמורה עדיין) של שחר שמש בנידון:

http://www.lingnu.com/en/programming.html

נו מה אני אעשה... אי אפשר בישראבלוג להעלות קטע קוד כי היישור לשמאל שלהם רק משנה את text-align ולא את ה-direction...
לא חשבתי שתהיה בעייה עם זה למישהו... אני אעתיק את זה לפה אם ככה (פה אתר טוב... לא מפלים לרעה טקסטים על בסיס כיווניות...):

קוד:

All functions in this library are thread-safe and re-entrant, with the exception of xsh_init() and xsh_deinit(). 1. Library Initialization XSH_RETURN xsh_init(int *p_argc, char ***p_argv) Initializes the library. Must be called before any of the other library functions described here. This function is not thread-safe. void xsh_deinit(void) Destroys all objects and releases all resources used by the library. This function is not thread-safe. 2. Global Settings xsh maintains a global list of name-value pairs that can be used from all parts of the application. The following functions can be used to manage this list: int xsh_isset(xsh_name name) Returns non-zero if the specified setting is set, or zero otherwise. XSH_RETURN xsh_get(xsh_name name, xsh_value *value) If a setting with the specified name is set, *value is assigned this setting's value and XSH_OK is returned. Otherwise, *value is unchanged and XSH_E_NOTFOUND is returned. XSH_RETURN xsh_set(xsh_name, xsh_value value, xsh_value *old_value) Sets the global setting with the specified name to the specified value. If the setting is already set and old_value is not NULL, the old value is stored in *old_value. XSH_RETURN xsh_unset(xsh_name name) Removes the specified setting from the list. 3. Interface Functions Interfaces are described in external files. They contain specification of widgets and windows, and define actions to be taken when messages are received from the application. The format of interface files is TBD. XSH_RETURN xsh_load(char *path, xsh_interface interface) Reads the interface file at the specified path and stores its data in the passed structure. void xsh_unload(xsh_interface interface) Unloads the interface and releases all resources used by it. XSH_RETURN xsh_show(xsh_interface interface, xsh_id window_id, xsh_handle *handle) Displays the specified window on the screen and starts its message loop in a separate thread. The interface must be loaded and contain a window with the specified id. A handle to the message loop is stored in handle (which must not be NULL, or XSH_E_INVAL is returned). XSH_RETURN xsh_wait(xsh_interface interface, xsh_handle handle) Blocks until the message loop defined by handle is terminated (ie. its associated window is destroyed). 4. Message Handlers The application can install functions that intercept messages coming from widgets, do some processing based on them and either forward or block them. Such a function is defined as follows: XSH_FUNC(name) {    // ... } These functions are passed several arguments which contain information about the message and data defined by the spec argument to xsh_link(). They must not be accessed directly, but only through the library functions described below. Return values are of type XSH_FUNC_RETURN and can be either XSH_FORWARD (to forward the message to the next handler) or XSH_BLOCK (to block further processing of the message). functions for handling arguments: TBD. functions for manipulating and sending messages: TBD. XSH_RETURN xsh_link(xsh_interface interface, xsh_id id, xsh_func func, xsh_spec spec, xsh_handle *handle) Installs @func as a handler for messages sent from the widget identified by @id in @interface. Arguments to the function are defined by @spec (spec format TBD). If handle is not NULL, it is assigned a value that can be used in xsh_unlink(). XSH_RETURN xsh_unlink(xsh_interface interface, xsh_id id, xsh_handle handle) Removes a previously-installed function from a widget's functions list, so that it will no longer will be called for messages sent by the widget. If a message from this widget is being processed when xsh_unlink() is called, it blocks until message processing is done, and then removes the function. XSH_RETURN xsh_reset(xsh_interface interface, xsh_id id) Removes all functions installed by the application for the specified widget. If a message from this widget is being processed when xsh_reset() is called, it blocks until message processing is done, and then removes the functions. 5. Message Producers Functions can be defined as message producers, ie. They run in the background and send messages that can be handled by the interface. Producers are defined as follows: XSH_PRODUCER(name) {    // ... } These functions are passed several arguments which contain data defined by the spec argument to xsh_start(). They should be accessed in the same way as in message handlers (see above). Producers should not return a value. XSH_RETURN xsh_start(xsh_producer producer, xsh_spec spec, xsh_handle *handle) Starts a producer in a separate thread. If handle is not NULL, it is assigned a value that can be used in xsh_kill(). XSH_RETURN xsh_kill(xsh_handle handle) Stops execution of a producer. Use carefully... 6. Return Values The following return values are currently defined: XSH_OK : Successful XSH_E_MEM : out of memory XSH_E_NOTFOUND : a requested resource could not be found XSH_E_INVAL : invalid argument XSH_E_FORMAT : invalid format (eg. for interface files, spec arguments, etc...) XSH_E_ERRNO : a system function has failed, inspect errno for the specific error code

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