Чому важко зробити програму Java "здаватися рідною"?

Більшість програм Java не виглядають так, як програми C / C ++. Swing, можливо, був розроблений спеціально, щоб мати розрізнений вигляд, але виходячи з того, що я прочитав, SWT, наприклад, намагався "виглядати рідним", і це не досягає успіху.

Моє запитання:

Чому розробникам мови Java важко розробити систему GUI, яка точно копіює вигляд рідних графічних інтерфейсів? Що відрізняється від рідних графічних інтерфейсів? Хіба це не лише питання створення кнопок, схожих на "рідні" кнопки? Або це заглиблюється?

Хіба це не лише питання створення кнопок, схожих на "рідні" кнопки?

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

Я кажу, що все вище описано на основі Swing, який, звичайно, є легким, не рідним інструментарієм GUI. Ви конкретно згадуєте, що SWT не виглядає рідним, що трохи дивно, тому що SWT є рідним. Це інструментарій, який використовує JNI під ним для виклику натільних компонентів - тому якщо щось там не виглядає прямо, це не буде через зовнішній вигляд.

Існує буквально півдесятка наборів інструментів, які можна вважати “рідними” в якійсь системі. Деякі з них мають досить унікальні концепції чи можливості, а їхнє тиражування в інструментарії міжплатформних інструментів є стомлюючим. Зовнішній вигляд програми визначається не лише "шкірою", але також і макетом та способом його поведінки. Деякі міркування:

• У діалоговому вікні, на якій стороні належить кнопка «ОК» - зліва чи справа? Досить справедливо, давайте побудуємо окремий діалог для кожної системи.
• Як позначити кнопку за замовчуванням на екрані? Тонування кольорів, жирний шрифт, збільшення кнопки? Досить справедливо, давайте покладемо це на таблицю стилів.
• У Windows концепція «Стрічки» є досить рідною. Як би це було перекладено на Mac, де стрічка не є звичайною? Досить справедливо, давайте забудемо точний макет пікселів і надамо іншу реалізацію панелі інструментів для кожної системи.
• Чи є рядок меню частиною вікна (Windows, необов'язково KDE), чи він сидить у верхній частині екрана (Mac, Unity)? Досить справедливо, давайте напишемо різну реалізацію для кожної системи, оскільки ми вже відкинули макет точного пікселя
• Як відображаються шрифти? Наскільки чіткіше, або гладке та антиалізійне? І який шрифт потрібно використовувати? Зауважте, що різні шрифти мають різні показники, тому один і той же абзац, наданий на однакову ширину, може мати різну кількість рядків залежно від шрифту.
• Чи фон вікна є одним кольором, зображенням або градієнтом? Давайте просто покладемо це також на таблицю стилів.
• Як виглядають смуги прокрутки? Де кнопки - якщо вони є? Наскільки вони широкі, або вони розкриваються лише тоді, коли вказівник переміщується на певний регіон?
• Як ми включаємо інші кольорові схеми?
• Що передбачається перетягувати? Де очікуються контекстні меню?

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

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

Так, це все глибше.

Побудувати кнопку, схожу на кнопку Windows або OS X, дуже просто, коли ви будуєте лише цю кнопку. Але кнопка повинна «поводитись» як оригінальні, що може бути непростим: можливо, в одній версії доступно більше місця, але в іншій, можливо, колір більше відповідає вашому дизайну у версії Windows тощо.

Це загострюється, якщо у вас є цілий графічний інтерфейс: програма OS X представляє його вміст інакше, ніж програма Windows. Це поруч із неможливим захопленням в одному графічному інтерфейсі - вам знадобляться два графічні інтерфейси, але не дуже багато додатків викликають стільки суєти. Натомість вони прагнуть "виглядає нормально у більшості систем" - це все ще виглядає дещо чужо, але це зручно та набагато легше розвивати.

Не важко зробити кнопку, схожу на кнопку OSX, або кнопку Windows, або будь-яку іншу набір інструментів. Але вказівки щодо користувальницького інтерфейсу для більшості середовищ не такі прості, як основи "так виглядає кнопка". Існує багато тонких відмінностей - від інтервалу між елементами інтерфейсу користувача до порядку, в якому певні відомі дії повинні відображатися в списку, до точного положення діалогового вікна «Налаштування / Параметри» в системі меню. Можна автоматизувати найпоширеніші випадки для дуже простих інтерфейсів користувача, але багато, якщо не більшість завдань інтерфейсу вимагають набагато точнішого дотику.

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

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

Існує компроміс між очікуванням, що ваша заявка виглядатиме максимально природно в кожній системі, і очікуванням, що ваша програма працюватиме однаково в кожній системі. Немає «правильного» вибору.

Крім того, навіть якщо ви обрали сторону "природного вигляду", ви можете захистити користувачів вашого графічного набору інструментів від "вдосконалень" основних вбудованих компонентів та API, які можуть несподівано порушити їх застосування.

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

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

Все це пов’язано з історією.

Sun побажав, щоб все програмне забезпечення Java працювало однаково на всіх машинах.

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

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

У наші дні дуже мало програмістів Java переймається чим-небудь, крім програмного забезпечення на базі веб-серверів.

Sun не вбив Java на робочому столі, переміщаючи всіх програмістів, які використовували системи Java на базі Microsoft Java, отже, будь-який програміст, який вибирає Java в перші дні, виглядає погано.

Усі, хто пише програмне забезпечення для настільних комп’ютерів, яке піклується про "зовнішній вигляд", давно навчилися не використовувати Java, а їх погляди посилюються щоразу, коли вони використовують будь-яке програмне забезпечення Oracle.

Тому в наші дні програмісти Java не вимагають "з'являтись рідними" на настільному програмному забезпеченні.

На вашу думку, nativeце власне додатки, які роблять свої речі, тоді як набори інструментів, такі як SWT, відповідають опублікованим стандартам для інтерфейсу цієї ОС. Проблема полягає в тому, що ніхто не створює програми, керуючись цими стандартами, тому, коли ви запускаєте додаток Java. Здається, це не рідне. Наприклад, майже всі проекти Microsoft (Office, Outlook тощо) не можуть бути відтворені візуально за допомогою стандартних елементів керування Windows.

Це стане ще гірше, оскільки і Microsoft, і Apple додають динамічні функції інтерфейсу користувача до своїх платформ ОС. Дозволяючи розробникам обробляти / стилювати свої програми приблизно так само, як веб-дизайни створюють стилі для веб-сайтів.

Java на платформі Android йде цим шляхом. Створення елементів інтерфейсу для Android, визначених у XML, із стилями, які можна зняти.

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

Яку операційну систему ви також хочете виглядати "рідною"?

Ви просто не можете бути рідними для всіх них 100% часу.

SWT тощо - це найкращий підхід для того, щоб виглядати як рідне для всіх, як це виходить, коли вам потрібно досягти компромісу .

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

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

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

Я думаю, що відповідь досить проста, і багато відповідей насправді не вникають у питання.

Якщо ваша мова дозволяє малювати піксель на екрані, то на 100% можливо створити на його основі рамку gui, яка точно імітуватиме елементи керування формою Windows.

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

Як ви бачите, наприклад, у XAML, інтерфейс користувача може бути легко представлений у дуже структурованій формі та мові. Вибір "рідної" поведінки також можливий, якщо для цього буде потрібно час.

Таким чином, можна було б створити графічний інтерфейс GUI, який би дозволяв розробникам Java отримувати додатки, які виглядатимуть на рідній версії Mac та Windows.

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