הפוסט הזה הוא הֶלְחֵם של שני פוסטים. הפוסט הראשון הוא בקטגורית “דברים שלומדים כשעובדים על Wine”, וקרה לי לפני כמה ימים. השני הוא לגבי שימושיות תוכנה, והרעיון לו בא היום. הנושאים, באופן מפתיע, מדברים על אותו הדבר, ועל כן אוחדו.
בואו נתחיל משאלה טיפשית. כאשר מפתח בחלונות קורא לפונקציה שנקראת BringWindowToTop, מה הוא מצפה שיקרה? מותר לכם לקרוא את התיעוד ב-MSDN. אפילו נתתי לכם קישור לתיעוד כפי שהוא מופיע באתר של מיקרוסופט.
אני אתן לכם רמז. אם עניתם “מביא את החלון הרלוונטי להיות עליון”, עניתם תשובה שהיא, במקרה הטוב, חלקית.
כדי להבין את מהות הסתירה, יש להסתכל על הנושא השני שלי לפוסט זה. ב-YNet התפרסמה כתבה על הדברים המעצבנים שמחשבים עושים. אחד הדברים היה…. נכון – זה שחלונות קופצים וגונבים את הפוקוס (החלון שמקבל את העכבר) בזמן שאתה עובדים.
אז מה היה לנו פה. מצד אחד, זה מאוד מעצבן שהחלון שעליו אתם עובדים מפסיק להיות החלון הפעיל/עליון באמצע העבודה, בלי שום אזהרה. מצד שני, לפעמים תוכנה באמת צריכה להיות מסוגלת לקפוץ קדימה, מסיבות לגיטימיות לחלוטין.
מה עשו מיקרוסופט? החל מחלונות 2000 (למעשה, החל מ-98), תוכנה יכולה לקרוא ל-BringWindowToTop רק אם היא בעצמה שולטת כרגע על החלון הפעיל. במילים אחרות, התוכנה יכולה להחליף בין שני חלונות שלה, או לתת פוקוס לחלון של תוכנה אחרת, אבל לא לקחת פוקוס מחלון של תוכנה אחרת. אני מוכן לתת לכם אתגר לנסות למצוא איפה, בתיעוד של BringWindowToTop, כתוב שהפונקציה, בעצם, לא עובדת.
באופן אירוני, ברגע שיודעים מה מחפשים, אז דווקא אפשר למצוא את התיעוד (לא, חלילה, בקלות). בפונקציה “AllowSetForegroundWindow” כן מצויינת ההגבלה, כמו גם מתי היא לא חלה. במילים אחרות, אם אתם יודעים את הפתרון, אז מוכנים לספר לכם מה הבעיה.
ולמה כל זה רלוונטי? לדעתי יש פה סחרחורת לא בריאה. כפי שהכתבה בלמהרשת אומרת במפורש, גם נסיון לחסום חטיפה של החלון הפעיל באמצעות TweakUI לא מובטח שיצליח. כשאני נתקלתי בצורך מצאתי (בסופו של דבר) הסבר אחד על איך לעשות את זה, ובסוף השתמשתי בדרך משלי. במילים אחרות, מי שבאמת רוצה לחטוף חלון יצליח לעשות את זה.
וזו הנקודה האמיתית. מה שבאמת חסר לחלונות זה לא אכיפה טובה יותר של ממשק משתמש ידידותי (ואין שום דבר ידידותי בזה שחלון מתחיל להבהב לכם ב-Task bar, שזו התוצאה הרגילה של שימוש “אסור” ב-BringWindowToTop). מה שחסר לחלונות זה מסמך טוב לגבי מהו בכלל ממשק ידידותי (כמו שיש, למשל, ל-apple). אם נוסיף לכך את כל התוכנות שרוצות להפריע לכם במהלך העבודה, ומה שאנחנו מקבלים זה את הכתבה ב-Ynet. במידה רבה צודקת הכתבה שהבעיה היא בעיית שימושיות של התוכנות, אבל צודק גם מגיב מס’ 2. הבעיה היא (חלקית) לא שהתוכנות לא מספיק ידידותיות, אלא שהן לא שמות את טובת המשתמש לנגד עיניהן. מכיוון שאנחנו לא יכולים (וגם לא רוצים) למנוע מכל התוכנות להקפיץ חלונות בכל מקרה, עדיף לנו להבהיר למפתחים למה זה רעיון לא טוב, ולדאוג שיהיה להם אכפת (למשל, ע”י זה שנשתמש בתוכנות חופשיות, שבהן לא יעשו לנו דברים דווקא).
שחר
יש, ולא מעט, תיעוד של MS איך לפתח לסביבת חלונות. העובדה שאנשים לא ממש בראש שלהם להבין את המורכבויות של פיתוח GUI היא ענין שונה לחלוטין.
מצד שני, בימים הראשונים של האוטומובילים, גם הם היו מלאי תקלות ובעלי טווח מוגבל ביותר.
אז אולי כל הדברים הללו יסתדרו גם הם תוך 30-40 שנה.
🙂
יש רק דבר אחד שאת שוכחת – תוכנה כבר עברה 30 שנה. הסיבה שמיקרוסופט כל כך מבורדקת היא בגלל שהם מתעלמים מההנחיות הסטנדרטיות של “איך בונים תוכנה”.
שחר
אנא פרסם קישור. בבקשה.
ודרך אגב, “לא מעט” סטנרדטים זה הרבה יותר גרוע מאשר “אחד”. The wonderful thing about standards is that there are so many to choose from.
שחר
… בניגוד ללינוקס ששם דבר כזה כמובן לא יכול להיות :
http://planetalinux.blog.br/ubuntu/2006/12/26/gnome-focus-stealing-prevention-a-sick-joke
אגב בקשר למה שמרק אמר הנה :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/anch_uidesigndev.asp
רתם
לא מצליח להגיב , כבר שלחתי פעמיים את התגובה …
רתם
בלא מעט הכוונה היא ללא מעט מאמרים וספרים שמתארים את אותו סטנדרט.
מה שנמצא אצלי בשלוף הוא מאמר העוסק בנושאים של התאמות לlocales שך rtl
http://www.microsoft.com/globaldev/getwr/steps/WRG_mirror.mspx
לא בטוח שהוא דוגמא טובה אבל מבטיח לך שיצא לי לראות ספרים ולקרוא מאמרים על הנושא.
תגובות שמכילות שני לינקים או יותר מעוקבות לאישור, מתוך הנחה שהן ספאם. הרשיתי לעצמי למחוק אחת מהן. אני מקווה שלא תתגעגע.
שחר
אני לא יודע מה gnome עושה. אני כן יודע שאני עובד עם ה-focus stealing preventionשל KDE, והוא עובד לי מצויין.
זה נכון שמה שניסחתי בפוסט לא מספיק מלא. צריך, לדעתי, לא לעקוף את מדיניות הפוקוס בכלל, ולאפשר אחת עם יוצאים מין הכלל. זה, בדיוק, מה ש-KDE עושה, וזה עובד לי מצויין.
שחר
ואני תמיד חשבתי שחלונות מתחילים להבהב ב-Windows בגלל איזה מקבילה מיקרוסופטית ל-UrgencyHint . אני אישית לא מכיר את הבעיה של חלונות גונבים פוקוס מקלדת ב-Windows, כנראה בגלל שאני לא ממש משתמש במערכת הזאת יותר מכמה דקות בחודש.
לעכב עם כ”ף זה לגרום שייקח יותר זמן, לעקב עם קו”ף זה ללכת אחריך כל הזמן. וסליחה על הטרחנות.