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

98

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

Мой вопрос:

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

user3150201
источник
31
потому что Swing пишет свои собственные компоненты графического интерфейса, которые пытаются имитировать нативные, вместо того, чтобы создавать привязку к реальным нативным компонентам, в идее переносимости
ratchet freak
5
Я не эксперт по этой теме, но я полагаю, что это просто вопрос того, сколько усилий поставщики инструментария GUI готовы инвестировать, чтобы все детали были правильными. См., Например, фреймворк C ++ «Qt» и этот SO вопрос: stackoverflow.com/questions/7298441/…
Док Браун
4
Есть много деталей, о которых нужно позаботиться. Например, способ, которым автозаполнение работает в диалоговом окне открытия файла, является одной из точек, где нативно выглядящее Java-приложение не работает.
CodesInChaos
4
Swing имеет «родной» внешний вид, который вы можете подключить вместо стандартного. Кроме того, Java сначала пыталась использовать доступные нативные вещи с AWT, но это не очень хорошо работало, AFAIK из-за внутренних различий между платформами. Вот почему они создали Swing, чтобы приложение Java везде работало одинаково.
marczellm
5
Не забывайте, JavaFX. Это замена SWING, которая по умолчанию входит в JDK / JRE, начиная с Java 8. Она намного более современна, чем SWING и AWT, и выглядит намного более встроенной практически на всех платформах (она во многом привязана к собственному инструментарию пользовательского интерфейса на каждой Платформа). С учетом вышесказанного, как уже упоминали другие, чтобы получить абсолютно естественное приложение из языка «один размер подходит всем», например Java, вам придется проделать определенную работу. Пользовательские интерфейсы Java были / были / все еще предназначены для "наилучшего соответствия всем платформам" из коробки.
SnakeDoc

Ответы:

56

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

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

Я говорю все вышеизложенное на основе Swing, который, конечно, является легким, не родным инструментарием GUI. Вы специально упоминаете, что SWT не выглядит нативным, что немного странно, потому что SWT является нативным. Это инструментарий, который использует JNI для вызова нативных компонентов - поэтому, если что-то там не выглядит, это не произойдет из-за внешнего вида.

berry120
источник
1
Благодарю. Что означает «легкий»? А что на самом деле означает «родной»? Я предполагаю, что это означает что-то, что использует ресурсы операционной системы компьютера или взаимодействует с ним напрямую. Это правда?
user3150201
1
@ user3150201 Конечно, поэтому базовая ОС будет иметь определенное количество кнопок и виджетов, которые могут быть размещены изначально, но, очевидно, эти кнопки будут отличаться между ОС и между платформами - это тяжелые, нативные компоненты. Легкие компоненты - это не компоненты, диктуемые ОС, они нарисованы Java (в данном случае), чтобы выглядеть и вести себя как компоненты графического интерфейса - поэтому они могут выглядеть так, как вы хотите, если вы вкладываете работу (но вы должны эмулировать Если вы хотите этого, вы можете посмотреть на платформу, вы не получите ее бесплатно.)
berry120
14
Расположение кнопок, точные размеры и предпочтительные стили GUI варьируются в зависимости от платформы, и для того, чтобы Java имитировал их, требуется работа. Swing может дать вам нативную кнопку, но если ее высота составляет 10 пикселей, пользователь все равно будет думать, что что-то не так. У Apple есть Рекомендации по интерфейсу пользователя, а у Microsoft есть Рекомендации по интерфейсу пользователя, которые помогут вам получить правильный внешний вид. Вам нужно будет немного изменить пользовательский интерфейс между платформами.
Михаил Шопсин
4
JavaFX выглядит гораздо более «родным», чем SWING и AWT. У этого есть родные прозрачные окна, и т.д. Гораздо более современный взгляд из коробки.
SnakeDoc
2
@SnakeDoc Он выглядит более современным, конечно, но я бы не сказал, что он выглядит «нативным» - он, безусловно, не использует базовые компоненты графического интерфейса платформы, все оформлено в CSS.
berry120
71

Существует буквально полдюжины наборов инструментов, которые можно считать «родными» в некоторых системах. Некоторые из них имеют довольно уникальные концепции или возможности, и их копирование в кроссплатформенный инструментарий утомительно. Внешний вид приложения определяется не только «кожей», но также и макетом и тем, как он ведет себя. Некоторые соображения:

  • В каком диалоге с какой стороны находится кнопка «ОК» - слева или справа? Справедливо, давайте создадим отдельный диалог для каждой системы.
  • Как пометить кнопку по умолчанию на экране? Цветовая тонировка, жирный шрифт, увеличение кнопки? Справедливо, давайте поместим это в таблицу стилей.
  • В Windows концепция «ленты» довольно родная. Как бы это перевести на Mac, где Лента не распространена? Справедливости ради, давайте забудем точную по пикселям компоновку и предоставим разные реализации панели инструментов для каждой системы.
  • Является ли строка меню частью окна (Windows, опционально KDE) или находится в верхней части экрана (Mac, Unity)? Справедливо, давайте напишем разные реализации для каждой системы, так как мы уже отбросили макет с точностью до пикселя
  • Как отображаются шрифты? Как можно более четким или гладким и сглаженным? А какой шрифт нужно использовать? Обратите внимание, что разные шрифты имеют разные метрики, поэтому один и тот же абзац, отображаемый с одинаковой шириной, может иметь разное количество строк в зависимости от шрифта.
  • Является ли фон окна одним цветом, изображением или градиентом? Давайте просто поместим это в таблицу стилей.
  • Как выглядят полосы прокрутки? Где кнопки - если они есть? Насколько они широки или раскрываются только когда указатель перемещается в определенную область?
  • Как мы включаем другие цветовые схемы?
  • Что ожидается быть перетаскиваемым? Где ожидаются контекстные меню?

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

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

Амон
источник
1
+1. Я хотел бы добавить только одну вещь: как насчет того, что система позволяет пользователю настраивать, начиная с «простых» подробностей, таких как открытие контекстных меню? (И я бы предпочел, чтобы в программах для Windows не было лент и приложений для Mac, спасибо. Да, для каждой операционной системы должны быть созданы хорошие графические интерфейсы.)
Кристофер Кройциг,
@ChristopherCreutzig Вот откуда мой опыт: на своем основном рабочем столе я использую KDE в Linux (оба из которых очень настраиваемы сами) и использую QtCurve для настройки внешнего вида приложений. Эти специальные стили прекрасно работают в флагманских приложениях KDE. Хорошо написанные приложения GTK могут использовать слой совместимости, но фоновые градиенты отсутствуют, строка меню остается внутри окна и т. Д. Но затем она быстро начинает ухудшаться, когда программы берут некоторые виджеты из системного стиля (например, полосы прокрутки) , но игнорируя другие (например , рендеринг шрифтов, или тени вокруг меню)
AMON
+1, потому что в этом ответе есть сильные стороны, но есть и слабые стороны. Любая проблема "как этот оконный менеджер рисует X" решается с помощью собственного API. Например, X11 в OS X может рисовать собственные окна OS X, кнопки, полосы прокрутки, диалоги и т. Д. Поэтому многие из этих проблем исчезают. Реальный ответ ниже , что говорит @TheSpooniest: UX это намного больше , чем просто рисование виджетов. Интервалы, время, анимация, ускорение мыши, сенсорный ввод ... есть мир тонких деталей, которые очень дорого воспроизводить с помощью кроссплатформенного инструментария.
Марк Э. Хаас
13

Да, это идет глубже.

Создать кнопку, которая выглядит как кнопка Windows или OS X, легко, если вы создаете только эту кнопку. Но кнопка должна «вести себя» как оригинальные, что может быть непросто: возможно, в одной версии доступно больше места, но не в другой, возможно, цвет больше подходит для вашего дизайна в версии для Windows и т. Д.

Это становится очевидным, когда у вас есть весь графический интерфейс: программа OS X представляет свое содержимое иначе, чем программа Windows. Это почти невозможно записать в одном графическом интерфейсе - вам понадобятся два графических интерфейса, но не так много приложений суетятся. Вместо этого они стремятся к «выглядит нормально на большинстве систем» - это все еще выглядит несколько чуждо, но его можно использовать и намного проще в разработке.

Кристиан Зауэр
источник
9

Нетрудно создать кнопку, которая выглядит как кнопка OSX, кнопка Windows или любой другой инструментарий. Но рекомендации по пользовательскому интерфейсу для большинства сред не так просты, как основы «вот как выглядит кнопка». Существует множество более тонких различий: от расстояния между элементами пользовательского интерфейса до порядка, в котором определенные известные действия должны отображаться в списке, до точного положения диалогового окна «Предпочтения / Параметры» в системе меню. Можно автоматизировать наиболее распространенные случаи для очень простых пользовательских интерфейсов, но многие, если не большинство задач пользовательского интерфейса, требуют более тонкого подхода.

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

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

Ложка
источник
7

Существует компромисс между ожиданием того, что ваше приложение будет выглядеть максимально естественно в каждой системе, и ожиданием того, что ваше приложение будет работать одинаково в каждой системе. Нет «правильного» выбора.

Более того, даже если вы выберете «естественную» сторону, вы можете защитить пользователей своего графического инструментария от «улучшений» в базовых собственных компонентах и ​​API, которые могут неожиданно сломать их приложение.

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

Обратите внимание, что эта проблема не специфична для Java, но сталкивается с каждой компанией, выпускающей независимые от платформы наборы инструментов

Никола Мусатти
источник
Вместо молчаливого подавления голосов вы окажете большую услугу сообществу, объяснив, что вы считаете неправильным, с ответом. Если только это не личная проблема ...
Никола Мусатти
4

Это все из-за истории.

Sun хотела, чтобы все программное обеспечение Java работало одинаково на всех машинах.

Для того, чтобы программное обеспечение казалось «родным», оно должно работать так же, как и другое программное обеспечение в данной ОС.

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

В наши дни очень немногие Java-программисты заботятся о чем-либо, кроме программного обеспечения на основе веб-сервера.

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

Любой, кто пишет настольное программное обеспечение, которое заботится о «внешнем виде», уже давно научился не использовать Java, и его взгляды усиливаются каждый раз, когда они используют любое программное обеспечение Oracle.

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

Ян
источник
5
«Sun сделала все возможное, чтобы затруднить написание программного обеспечения Java, интегрированного с ОС», - неправильно. Они просто не прикладывают больших усилий, чтобы сделать это легко. «Sun убила Java на настольном компьютере, обманув всех программистов, которые использовали системы на основе Java от Microsoft», неправильно, взаимная вражда между Microsoft и Sun вынудила Microsoft создать версию библиотек AWT, которая не была совместима с требованиями Sun, что привело к печально известной Sun / MS иски.
jwenting
1
@jwenting, Sun больше заботился о том, чтобы создавать проблемы для Microsoft, чем о программистах, которые решили использовать систему Microsoft на основе Java. Поэтому я отказался от Джейва и продолжал работать с MFC до выхода C #.
Ян
3
может быть, некоторые люди в Sun, но это чувство было взаимным. Если вы разрабатываете исключительно для одной платформы, встроенный инструмент для этой платформы ВСЕГДА является предпочтительным вариантом, это не имеет ничего общего с корпоративной политикой. Если вы выбираете свои инструменты на основе «Я ненавижу Sun» или «Я ненавижу Microsoft», это очень плохо отражается на вашем профессиональном отношении. Я в основном использовал Java, но наряду с этим я также использовал Delphi, C #, Ruby, C ++, C, Progress - все, что было лучше для работы под рукой. И чаще всего это окажется гибридным решением.
jwenting
3

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

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

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

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

Reactgular
источник
1
+1, в эпоху Windows 95 существовал «стандартный» вид элементов управления Windows. Теперь не так много.
GrandmasterB
Да, прошло несколько лет с тех пор, как я программировал десктоп, но я был удивлен, что .NET не поставляется с ленточным управлением, несмотря на то, что оно стало неотъемлемой частью программного обеспечения, созданного MS.
Буровая установка
@Rig Начиная с NET 4.0, в .NET есть хороший нативный контроль ленты. Вот хорошая статья: c-sharpcorner.com/UploadFile/0b73e1/ribbon-control-in-wpf-4-5
Кристиан Сауэр
1
@Rig Вам понадобится .NET 4.5, а не .NET 4. Visual Studio 2010 может работать только с 4; вам понадобится VS2012 или новее для цели 4.5. Я вижу это при нацеливании на 4.5 в VS2013, но не когда меняю целевую версию на 4.
Боб
1
@Rig Можно использовать ленту в Net 4.0 - вы можете скачать ее с Microsoft, и тогда она появится: 10rem.net/blog/2010/10/22/wpf-ribbon-october-release (Не уверен, если это это последняя версия). Лучше скачать его с Nuget. Я должен был сделать это для программы, которая должна была работать в Windows XP - прекрасно работает и в основном совместима с вариантом Net 4.5, так что вы можете удалить 4.0, когда XP наконец выйдет из строя.
Кристиан Зауэр
-1

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

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

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

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

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

Anony-Мус
источник
-2

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

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

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

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

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

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

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

Валентин Кузуб
источник
2
это не отвечает на вопрос, аскер уже рассмотрел этот вопрос: «Swing, возможно, был разработан специально для того, чтобы иметь отличительный вид»
комнат
Я не согласен, но спасибо за комментарий к вашему минусу (?)
Валентин Кузуб,