Почему трудно заставить Java-программу выглядеть «родной»?

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

Мой вопрос:

Почему разработчикам языка Java сложно разработать систему графического интерфейса, которая точно копирует внешний вид родного интерфейса? Что отличается в родном интерфейсе? Разве это не только вопрос разработки кнопок, которые выглядят как «родные» кнопки? Или это идет глубже, чем это?

Разве это не только вопрос разработки кнопок, которые выглядят как «родные» кнопки?

Ну, вроде, для кнопок. Но это может быть сложнее, чем вы думаете. В наши дни графика, используемая для представления компонентов графического интерфейса, не так проста, как случайные растровые изображения, которые растягиваются (поскольку они вообще не очень хорошо масштабируются) - это часто векторная графика с большим количеством угловых случаев, запрограммированных в них ( поэтому, когда кнопка достигает края экрана, она может выглядеть, например, немного по-другому.) И, конечно, при нажатии кнопки вам понадобится другая графика. По соображениям авторского права разработчики часто не могут просто использовать эту существующую графику напрямую, поэтому их необходимо воссоздать - и хотя они по большей части хорошо выполняют свою работу, неизбежно некоторые вещи упускаются из-за огромного массива графических компонентов.

Я говорю все вышеизложенное на основе 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, и его взгляды усиливаются каждый раз, когда они используют любое программное обеспечение Oracle.

Поэтому в наши дни нет никакой потребности в «появлении нативного» программного обеспечения на Java от программистов на Java.

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

Это станет еще хуже, так как Microsoft и Apple добавляют динамические функции пользовательского интерфейса к своим платформам ОС. Предоставление разработчикам возможности создавать скины / стилизовать свои приложения так же, как веб-дизайны создают стили для веб-сайтов.

Java на платформе Android идет по этому пути. Создание элементов пользовательского интерфейса для Android, определенных в XML, со стилями скинов.

Java никогда не была очень популярна в качестве настольной платформы. В результате эти изменения в отрасли не распространяются вплоть до времени выполнения рабочего стола. Просто не хватает разработчиков, готовых потратить время на решение проблемы.

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

Вы просто не можете быть родным для всех из них 100% времени.

SWT и т. Д. - это лучший способ выглядеть так, как если бы вам нужно было достичь компромисса .

И на самом деле, этот компромисс становится все труднее достичь; не столько из-за операционных систем, сколько из-за устройств ввода. Для сенсорных экранов вам на самом деле приходится проектировать по- другому, потому что нет правой кнопки мыши. Следовательно, в противном случае вам необходимо обеспечить такую ​​же функциональность.

Никогда не будет волшебной кнопки, которая бы перемещала функциональность «интуитивно» от правой кнопки мыши к гостям, без указания вами каждого подробного аспекта для каждого устройства ввода (в этот момент вы являетесь родным для каждой платформы, которую вы рассматривали, но тем не менее - Родные ни к кому ты не причислял).

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

Я думаю, что ответ довольно прост, и многие ответы на самом деле не вникают в проблему.

Если ваш язык позволяет рисовать пиксель на экране, то на 100% возможно создать на его основе графический интерфейс, который будет точно имитировать внешний вид элементов управления Windows.

Поскольку Java является кроссплатформенной, также вполне возможно убедиться, что в зависимости от фактического типа работающей системы (Mac / Windows) пользовательский интерфейс выбрал бы различный вид на обеих платформах, соответствующий стилю платформы времени выполнения.

Как вы можете видеть в XAML, например, пользовательский интерфейс может быть легко представлен в очень структурированной форме и на языке. Выбор «нативного» поведения также возможен, если для этого требуется время.

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

Итак, мы переходим к Swing, это всего лишь одна инфраструктура GUI из потенциальной бесконечности структур GUI, которые могут быть созданы для Java. Он ведет себя так, как был запрограммирован, что не соответствует описанному выше процессу, и вы получаете странно выглядящие приложения в обеих системах. Это выбор, сделанный разработчиками Swing, никто не заставлял их делать это и вести себя таким образом.