Безпосередній GUI - yae чи ne? [зачинено]

Я працював над розробкою додатків з великою кількістю «збережених» GUI-систем (нижче докладніше про те, що я маю на увазі під цим), таких як MFC, QT, Forms, SWING та декілька веб-GUI-фреймів кілька років тому. Я завжди знаходив концепції більшості систем GUI надмірно складними та незграбними. Кількість подій зворотного дзвінка, слухачів, копій даних, щось до чогось - це конверсії (і так далі) завжди були джерелом помилок і головних болів порівняно з іншими частинами програми. (Навіть при "правильному" використанні прив'язки даних / моделей).

Зараз я пишу комп’ютерні ігри :). Я працював з одним GUI до цього часу: Miyagi (мало відома, але в основному та сама ідея, що і всі інші системи.)

Це було жахливо.

Для середовищ візуалізації в режимі реального часу, таких як Ігри, я відчуваю, що "збережені" системи GUI ще більше застаріли. Користувацькі інтерфейси, як правило, не потребують автоматичного розкладки або вікон із зміною розміру під час руху. Натомість їм потрібно дуже ефективно взаємодіяти з постійно мінливими даними (наприклад, 3d-позиціями моделей у світі)

Пару років тому я натрапив на "IMGUI", який в основному нагадує режим негайної графіки, але для користувальницьких інтерфейсів. Я не приділяв надто великої уваги, оскільки я все ще працював над розробкою додатків, а сама сцена IMGUI, здавалося, не дуже широка і не успішна. І все-таки підхід, який вони застосовують, здається таким надзвичайно сексуальним та елегантним, що змусив мене написати щось для наступного проекту, використовуючи такий спосіб користувальницького інтерфейсу (я не зміг переконати нікого в роботі: (...)

дозвольте підвести підсумки, що я маю на увазі під "збереженим" та "негайним":

Збережений графічний інтерфейс: На окремому етапі ініціалізації ви створюєте "елементи керування графічним інтерфейсом", такі як Мітки, Кнопки, TextBoxes і т.д. Елементи управління зберігають більшу частину власного стану в пам'яті, наприклад, X, Y, розмір, рамки, дочірні елементи, текст мітки, зображення тощо. Ви можете додавати зворотні дзвінки та слухачів, щоб отримувати інформацію про події та оновлювати дані в управлінському інтерфейсі.

Безпосередній графічний інтерфейс: Бібліотека графічного інтерфейсу складається з функцій "RenderButton", "RenderLabel", "RenderTextBox" ... (редагувати: не плутати RenderButton)префікс. Ці функції також виконують таку логіку, що лежить в основі таких елементів керування, як опитування користувачів, введення символів, обробка швидкості повторення символів, коли користувач утримує клавішу і так далі ...), яку можна зателефонувати, щоб "негайно" зробити керування (не " не потрібно негайно писати в GPU. Зазвичай його запам'ятовується для поточного кадру та сортується на відповідні партії пізніше). Бібліотека не містить жодного "стану" для них. Якщо ви хочете приховати кнопку ... просто не викликайте функцію RenderButton. Усі функції RenderXXX, які мають взаємодію з користувачем, як кнопки або прапорець, мають значення повернення, які вказують, чи користувач натиснув кнопку. Тож ваш "RenderGUI" Функція виглядає як велика функція if / else, де ви викликаєте чи не викликаєте свої функції RenderXXX залежно від стану гри та вся логіка оновлення даних (при натисканні кнопки) переміщується у потік. Усі сховища даних знаходяться "поза" gui та передаються на вимогу функціям Render. (Звичайно, ви б розділили великі функції на кілька, або використали б деякі абстракції класів для групування частин gui. Ми не пишемо код, як у 1980 році, чи не так;))

Тепер я виявив, що Unity3D насправді використовує той самий базовий підхід до своїх вбудованих GUI-систем. Мабуть, є пара GUI з таким підходом і там?

Все-таки .. коли оглядаєтесь, чи здається, що існує сильний ухил до збережених систем GUI? Принаймні, я не знайшов такого підходу, окрім Unity3D, і оригінальна спільнота IMGUI, здається, досить ... .. тиха.

Тож хтось працював з обома ідеями та має якусь сильну думку?

Редагувати: Мене найбільше цікавлять думки, що випливають із реального досвіду. Я думаю, що на форумі IMGUI є багато гострих дискусій щодо будь-якої "теоретичної слабкості" безпосереднього підходу GUI, але мені завжди цікавіше знати про слабкі місця в реальному світі .

Ні. Я вже робив платну роботу в геймеді на жахливому графічному інтерфейсі «збереженого режиму» та на жахливому графічному інтерфейсі «негайного режиму», і хоча обидва змусили мене захотіти вирвати очі, підхід у режимі збереженого режиму все одно є кращим.

Мінусів негайного режиму багато:

• вони не спрощують художників та дизайнерів налаштувати макет;
• вони змушують вас змішувати логіку з презентацією;
• вони ускладнюють єдину послідовну модель введення;
• вони відмовляють від складних елементів управління динамічними даними (наприклад, перегляди списку);
• шарування стає дуже незручним (наприклад, якщо я зателефоную на RenderComboBox, випадаюче вікно ще не може відображатись, тому що воно повинно переходити над іншою частиною вікна - те саме для підказок інструментів) l
• конфігурація стилю візуалізації закінчується глобальними (ick) або додатковими аргументами функції (ick);
• продуктивність може бути поганою, оскільки виклик усіх цих функцій для запитів значень, які можуть бути або не можуть змінитися, як правило, створює багато невеликих об'єктів, підкреслюючи менеджер пам'яті;
• ... і я навіть не можу уявити, як боляче було б дозволити комусь перетягнути біти GUI навколо себе і переупорядкувати їх. Вам доведеться підтримувати структуру даних, яка вказуватиме вам, куди зробити все - що дуже нагадує самостійно переписати систему збереженого режиму.

Графічні інтерфейси негайного режиму спокушають одиноких програмістів, які хочуть швидкої системи HUD, і для цього вони чудові. Щодо іншого ... просто скажи "ні".

Як хтось із п'ять-шість років фактичного досвіду роботи з IMGUI на робочому столі, я відчуваю себе зобов'язаним захищати це. Усі відповіді (і саме питання) ґрунтуються на дуже обмеженому визначенні IMGUI, і, здається, існує багато сумнівних претензій.

Багато з них походить від припущення, що бібліотека IMGUI не може зберігати будь-які дані під кришкою. Це зовсім не так. Складна бібліотека IMGUI фактично збереже приблизно стільки ж даних, скільки еквівалентна бібліотека RMGUI. Різниця полягає в тому, що бібліотека IMGUI в основному кешує результати, тоді як бібліотека RMGUI підтримує авторитетний стан. У IMGUI додаток забезпечує функцію, яка приймає поточний стан моделі та створює графічний інтерфейс для цього стану. Це авторитетне визначення графічного інтерфейсу. Бібліотека відповідає за те, щоб екранний графічний інтерфейс відповідав результату цієї функції. Це не означає, що йому потрібно повністю оцінити цю функцію кожного кадру та повністю відновити графічний інтерфейс. Це сенс кешування.

Завдяки такому погляду IMGUI ви можете зробити розширений макет, а продуктивність цілком розумна. Ви також можете зберегти фактичний авторитетний стан, якщо це спрощує інтерфейс. Сенс IMGUI - не змушувати додаток зберігати все. Програма, ймовірно, не хоче зберігати положення кожної смуги прокрутки та розширений / згорнутий стан кожного вузла дерева. Сенс у тому, щоб мати можливість процесуально визначати вміст цих вузлів дерева та саме їх існування.

Я б проходив відповідь на всі зауваження IMGUI, але я дуже не розумію їх. Здається, більшість з них випливає з фундаментальної думки, що IMGUI є хакерським, а RMGUI - добре структурованою, що, напевно, випливає з вищезазначених непорозумінь. Немає властивих причин того, що бібліотеки IMGUI повинні мати проблеми зі складністю або повинні бути засмічені глобалами або змішувати логіку з презентацією. Я скажу, що переваги IMGUI стають менш важливими, чим більше керується виконавцем ваш контент, але я не впевнений, чому це насправді було б гірше для вмісту, керованого виконавцями. (Я особисто не використовую вміст, керований виконавцями, окрім таблиць стилів для таких речей, як кольори, розміри шрифту / рамки тощо), але я не розумію, чому це було б важче реалізувати, ніж для RMGUI.)

На мій погляд, IMGUI - це безперечно гарна річ. Це дає вам набагато кращу модель для міркувань щодо вашого графічного інтерфейсу. Це стає набагато більш функціональним і реактивним, і ви мінімізуєте кількість змінних станів, про які вам доведеться міркувати. З іншого боку, реалізація складної бібліотеки IMGUI є досить складним завданням, і, безумовно, складніше, ніж впровадження еквівалентної бібліотеки RMGUI. Це компроміс між складністю бібліотеки та складністю програми. Якщо ви плануєте створювати складні додатки (або навіть багато простих додатків), компроміс дуже хороший. Якщо ви робите це для однієї програми, і це досить просто, ви, ймовірно, швидше досягнете своєї мети за допомогою RMGUI.

У будь-якому випадку, удачі!

Бібліотека графічного інтерфейсу складається з одномоментних "RenderButton", "RenderLabel", "RenderTextBox" ... функцій, які можна викликати, щоб "негайно" надати керування (не потрібно негайно записувати в GPU. Зазвичай його пам'ятають для поточного кадру та відсортовано у відповідні партії пізніше).

Я б пішов так далеко, щоб сказати, що це не є бібліотекою GUI. Це лише купа функцій візуалізації.

Надання GUI - це найпростіша частина створення графічного інтерфейсу. Візьмемо, наприклад, текстове поле. Я припускаю найпростіший можливий випадок: просте текстове поле для введення одно рядків.

RenderTextBoxпросто намалює текстове поле. Це зробить просте вимірювання тексту та намалювати на екрані гліфи. Це буде НЕ

• Визначте, що користувач натиснув мишу в елементі управління та перемістіть курсор у потрібне місце в рядку.
• Визначте, що користувач двічі клацнув мишкою в елементі управління та виберіть блок тексту.
• Визначте, що користувач натиснув клавішу «Головна» та перемістіть курсор на передню частину тексту.
• Визначте, що користувач натиснув дійсну клавішу, та змініть рядок відповідно. Якщо текст був вибраний, вибрана частина буде замінена вставленим текстом.

Я можу продовжувати, але я думаю, що моя суть зрозуміла. Якщо ви хочете використовувати RenderTextBoxтекстове поле, все, що ви отримаєте, - це статичне, нефункціональне текстове поле. Будь-яка фактична функціональність повинна бути реалізована вами.

Виконуєте вимірювання тексту та малюєте гліфи? Це легка частина роботи графічного інтерфейсу. GUI означає «Графічний інтерфейс користувача». Останні два слова, де ви берете інформацію від користувача і щось робите з нею, є важкою частиною.

Ігрові гравці очікують, що управління GUI працює розумно. У середовищі стилю ПК (наприклад, миша та клавіатура), якщо гравці бачать текстове поле, вони очікують, що воно буде працювати як звичайне текстове поле. Вони очікують, що зможуть пересуватися в ньому за допомогою клавіш зі стрілками, стрибати на передню частину і закінчуватися додому та видаляти, вибирати в ній літери тощо.

Це означає, що вам доведеться реалізувати весь цей код інтерфейсу. Ви повинні перевірити, на який елемент було натиснуто управління. Тоді вам доведеться зробити щось, на основі чого було натиснуто управління. Ви повинні мати поняття "активного" управління, того, яке отримує введення з клавіатури. Різні елементи керування повинні по-різному реагувати на різні типи взаємодії користувачів.

В основному, вам потрібен TextBoxWindowклас.

Скажімо, ви реалізуєте екран параметрів гри. Таким чином, у вас є різні групи варіантів: геймплей, графіка, звук, елементи керування тощо. Отже, у лівій частині екрана у вас є список різних груп. Кожна група пропонує ряд елементів управління, якими користувач може керувати. Що відбувається, коли користувач натисне клавішу Tab?

Ну, це залежить від того, який контроль активний. Якщо один із елементів управління в групі активний (останній раз натискали), він переходить до наступної групи. Якщо замість цього один із елементів управління в групі активний, він переходить до наступного елемента керування в цій групі. Ось так покликана працювати система.

Отже, не тільки має бути активним введенням клавіатурного процесу керування, він тепер повинен обробляти будь-який необроблений вхід до елемента керування, який йому належить . Або це, або елементи керування повинні бути в якомусь пов'язаному списку, щоб він міг переходити вперед і назад. Це означає, що в кожному елементі управління повинно бути поведінка за замовчуванням.

Це все більше схоже на збережений графічний інтерфейс, чи не так? Різниця лише в тому, що ... ти - той, хто робить важку роботу. Використання чужого графічного інтерфейсу повинен бути спосіб зробити менше роботи. Але зусилля, необхідні для того, щоб графічний інтерфейс відповів, як очікує користувач, нетривіальний.

Пам'ятайте: інтерфейс користувача не для вас, а для ваших користувачів . Це для гравця. Він повинен вести себе так, як вони цього очікують. А якщо цього не відбувається, то ви провалилися.

Користувацькі інтерфейси, як правило, не потребують автоматичного розкладки або вікон із зміною розміру під час руху.

Це обмежена і обмежує думка.

Я міг би дати пригоди про різні іграх , що мають різні потреби інтерфейсу, що деякі ігри робити потрібно Resizeable вікна і так далі. Але є набагато більша проблема.

Ваш вид мислення призводить до проблеми безкоштовних космічних битв.

Якщо ви ніколи не грали в цю гру, це дешева гра, інді та дуже GUI-важка. Фактичний геймплей робиться в графічному інтерфейсі (це «настроювання підрозділів і дивіться їх боротьбу»). Проблема?

GUI НЕ МОЖЕ ВІДКРИТИ!

О, це добре, якщо ви використовуєте звичайний монітор або нормальний зір. Але якщо ви, наприклад, у мене керує смішно величезним монітором (один настільки великий, що у вас Windows набирає розмір усього тексту, щоб ви могли його прочитати), це жахливо . Текст мікроскопічний. Неможливо змінити розмір шрифту.

Зрозуміло, GSB - це гра на основі графічного інтерфейсу, тому для них це абсолютно недоцільно. Гра з графічним інтерфейсом може, можливо, піти з нею.

Ніколи не вважайте, що ваш користувач дивиться на їх гру саме так, як ви. Робити це глупо.

Наявність системи GUI, яка може змінити масштаб себе до роздільної здатності користувача, справді незалежний графічний інтерфейс, вимагає, щоб макет був частиною самої системи GUI. Якщо ви цього не збираєтесь надавати, то ваш текст буде здаватися крихітним на чиємусь гігантському моніторі. Це не дуже добре.

Тому я б сказав, що ваше мислення з цього приводу короткозоре. Ви дійсно потрібен цей матеріал. Вам потрібно те, що надають збережені графічні інтерфейси. О, вам може не знадобитися все, що надає будь-яка система GUI. Але вам це потрібно дещо.

Робота котла, яку вам потрібно зробити, щоб отримати дані в систему, - це невелика ціна, яку потрібно платити поряд з розумною впевненістю, що користувач може правильно взаємодіяти з елементами управління та що він змінить розмір, щоб відповідати потребам гравця.

Можливо, вам вдасться піти з графічного інтерфейсу в режимі прямого режиму, якщо ви не забираєте багато користувачів від програвача. Але це було б про це.

Нещодавно IMGUI також зацікавив мене, як тест я написав кілька навчальних посібників, щоб ознайомитись із методиками (почніть тут, якщо вам цікаво, але це не набагато більше, ніж C # / XNA + оригінальний "підручник" тут ) .

На короткий час мені дуже сподобалися IMGUI, тому що інформація, яку вони відображають, завжди є актуальною та правильною (оскільки немає стану, який ви завжди подаєте на фактичні дані). Але врешті-решт я втратив інтерес, тому зазвичай я знову використовую збережені графічні інтерфейси.

Врешті-решт я подумав, що безпосередність GUI ускладнює відокремлення GUI від даних, а часом я намагався деакулювати речі, вводячи деякий стан, порушуючи елегантність IMGUI. Я також не думаю, що написання коду для збережених графічних інтерфейсів - це більше робота, ніж написання коду для IMGUI, і мені подобається, що збережені графічні інтерфейси можна звільнити і забути, і мені дуже подобаються події :).

Однак кожен раз, коли хтось згадує про IMGUI, що-небудь всередині мене хоче спробувати ще раз, і намагатись більше, щоб виправити це правильно, адже там дійсно є якась елегантність, я просто не впевнений на 100%, чи завжди це полегшить вашу роботу. Я б сказав, спробуйте, можливо, спробуйте, як я це робив, і написати кілька навчальних посібників (я вважаю, що найкращий спосіб вивчити нові методи - це пояснення їх іншим).

Я багато працював із системою GUI Unity3D, яка працює так, як ви описали. І треба сказати, ненавиджу це з пристрастю.

"Негайний" підхід у деяких випадках справді хороший. По-перше, коли вам знадобиться лише пара кнопок і міток - подумайте, наприклад, шутер HUD. Створювати їх із "утриманим" підходом не дуже складно, але це дуже просто з UnityGUI. Другий випадок, коли вам потрібно набити багато елементів керування на екрані, але насправді не хвилюється компонування. Особливо, коли точні елементи керування відомі лише під час виконання. Це насправді не корисно в будь-якій грі, але дуже корисно при створенні інструментів, що працюють в редакторі Unity.

Однак будь-який напівскладний графічний інтерфейс - наприклад, для RPG (MMO) або стратегічної гри - неминуче перетворюється на жахливе безладдя нерозбірливого коду, повний особливих випадків і розбиваючись на багато способів. Створюючи такий графічний інтерфейс, у вас зазвичай є досить конкретний макет, який повинен працювати для будь-якої роздільної здатності та мати можливість показувати будь-які дані, які ви надсилаєте. Вам потрібні такі речі, як, наприклад, переміщення деяких кнопок нижче, щоб зробити шлях довшим текстом. З "збереженим" графічним інтерфейсом ви можете мати керування, яке робить це автоматично. У режимі "негайного", контролю немає , тому потрібно робити все явно.

Інша проблема UnityGUI (не впевнений, чи трапляється це з усіма графічними інтерфейсами прямого режиму) полягає в тому, що, наприклад, Button()виклик працює без врахування будь-яких інших дзвінків GUI. Отже, якщо одна кнопка знаходиться над іншою, натискатиме клацання обидві кнопки одночасно. Це, безумовно, не те, що очікує користувач, тому це додає ще один особливий випадок для обробки.

Щоб жити з усім цим, я завжди писав свою власну обгортку навколо UnityGUI, яка перетворює її на «збережену» систему режимів: елементи керування, які зберігають свій власний стан і просто викликають потрібні GUIфункції для кожного кадру для мене.

Я не можу сказати, що "негайний" режим, безумовно, гірший, ніж "збережений", але я, безумовно, відчуваю себе набагато краще, працюючи в "утриманому" режимі.

Я збираюся захищати тут IMGUI, оскільки деякі проблеми, які були перераховані раніше, можна вирішити, якщо ви готові написати код для цього. Крім того, якщо ви пишете код для нього, то у вас є надійна бібліотека, яка може бути повторно використана і лише дуже рідко вимагає змін.

• завантаження графічного інтерфейсу із схеми

можливо, спочатку здається, що художники не мають великої гнучкості з IMGUI, це вирішується або вдосконалюється завантаженням макета графічного інтерфейсу із схеми xml або JSON.

• шар меню малювати дзвінки

ця проблема вирішується сортуванням, вам слід створити клас UI Manager, який сортує порядок малювання, я вирішив цю проблему в C # XNA з переміщуваними панелями, що мають можливість натискання, які малюють один на одного. Я можу розмістити псевдо-код, якщо запитаєте.

• списки

ви можете намалювати рядки з масиву? чи можна визначити області прямокутника з висоти та ширини шрифтів цих рядків? чи можете ви створити співвідношення розміру вашої кнопки прокрутки по висоті всіх цих прямокутників, доданих разом? Тоді ви перебуваєте на півдорозі, щоб створити список списків з прокручуваною кнопкою для переміщення вгору або вниз. Я думав, що це буде важко, але виявилося набагато простіше, ніж я думав. ніяких буферів, жодних станів, жодних зворотних викликів.

• відокремлення даних від GUI

не дозволяйте окремим панелям, кнопкам, скринькам зберігати дані. Я знаю, що моя перша спроба IMGUI була негайною, але лише в графічному сенсі. Я допустив помилку зберігання даних про інтерфейс користувача. Це було майже філософським зрушенням думати по-різному про те, де розміщувати та змінювати дані через зміни інтерфейсу користувача.

• GUI від SDK

це обмеження та функціональність коду SDK, а не ваш. Я вважаю, що інтерфейс SDK (Hammer, Unity, UDK) - це майже нова мова, яку слід вивчити в будь-якому разі. Насправді вони схожі на мене як Windows.Forms, обидва створені для найширшої можливості і для цього мають додаткову вагу у складності.

і нарешті дивіться це> http://mollyrocket.com/861

Користувацькі інтерфейси, як правило, не потребують автоматичного розкладки або вікон із зміною розміру під час руху. Натомість їм потрібно дуже ефективно взаємодіяти з постійно мінливими даними (наприклад, 3d-позиціями моделей у світі)

Це залежить від жанру та гри, про яку йдеться. Гарна система управління запасами є життєво важливою для більшості будь-яких RPG. Вам потрібно щось, що обробляє макети для вас, підтримує смуги прокрутки, перетягування, підказки та інші функції, що набагато простіше реалізувати за допомогою збереженого графічного інтерфейсу.

Я не можу придумати спосіб перетягування з негайного графічного інтерфейсу, який не потребує великого жонглювання або збереження стану користувача, наприклад, тимчасово змінюючи буфер Z та зберігаючи інформацію про час, щоб виключити клацання, яке сталося для переміщення біт.

Але з точки зору дизайну у мене складно уявити світ без моїх графічних подій. Також негайний графічний інтерфейс не сумісний з OOP, що змушує вас вдатися до процедурного програмування.

Простота, надана безпосередніми графічними інтерфейсами, виникає за рахунок додаткової складності у вашому коді, яка швидко зростає в міру збільшення складності, необхідної вашим інтерфейсом користувача; де як хороший збережений графічний інтерфейс спочатку складніший, але масштабується краще. Отже, нижче певної точки складності, негайний графічний інтерфейс є достатньою, але для більшості ситуацій я вважаю за краще збережений графічний інтерфейс.