Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Задание 1 часть_В1-В34.docx
Скачиваний:
4
Добавлен:
19.09.2019
Размер:
3.05 Mб
Скачать
  1. Отформатировать текст по стп мгупи. Оформить рисунки и программный кода

Быстрый язык MigLayout

Сама идея расположения большинства объектов интерфейса по сетке, придавая им разное выравнивание, размеры, и, возможно, количество ячеек сетки, занимаемое ими позволяет быстро набросать интерфейс, даже не имея никаких визуальных инструмен­тов. Некогда, до достаточного развития таблиц стилей CSS, именно так разрабатыва­лось расположение содержимого многих Web-страниц.

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

Однако сама идея неплоха, остается лишь более быстрым и удобным языком указы­вать менеджеру расположения, как и где должны располагаться компоненты в сетке. Мы уже создали вспомогательный класс, предлагающий удобными методами руководи-; действиями GridBagLayout. Также одним из удачных примеров реализации такого менед­жера является бесплатно распространяемый менеджер MigLayout.

По сути, вспоминая наше рассмотрение табличного менеджера GridBagLayoutи ег: основных концепций, можно сказать, что в целом мы представляем себе, как работа етMigLayout. Другим способом осуществляется лишь описание ячеек таблицы — в bill; строчек очень компактного, насыщенного смыслом текста, что без сомнения ускоряв процесс создания интерфейса. Вы добавляете компоненты примерно таким методом - add(K0Mn0HeHT, “описание ячейки"). Более того, MigLayoutобладает несравненно более пз- роким набором функций, в сравнении со стандартными менеджерами Java. Дальней; -- знакомство мы проведем с помощью примера, тем более что язык MigLayoutдостато1 легко понять.

// MigLayoutStart.java

// Знакомство с MigLayout

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

Прежде всего, необходимо набросать примерный внешний вид будущего интерфей­са. Конечно, можно обойтись и без этого, но тогда легко увлечься и в процессе разработ­ки обнаружить, что вы полностью потеряли контроль над тем, что делаете, особенно когда дело касается сложных вариантов расположения. По поводу способа дизайна поль­зовательских интерфейсов сломано немало копий, защищены докторские диссертации и написаны тысячи статей, но область эта по прежнему сродни искусству. На сайте кни­ги ipsoftware.ruвы найдете ссылки на некоторые интересные статьи. Существуют даже отдельные компании, занимающиеся так называемым «usability» (с трудом переводимое слово, что-то вроде «удобство в использовании»), означающим создание интерфейса, максимально удобного и понятного пользователю. Компании дизайнеров предлагают различные варианты внешнего вида интерфейсов. Одна часто программисту самому приходится проектировать интерфейс.

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

При создании пользовательского интерфейса можно пойти двумя путями. Можно самому быть «законодателем мод» в своем приложении, определяя, как и что будет в нем выглядеть и функционировать. Такой подход особенно хорош, если вы специально раз­работаете для своих приложений собственный внешний вид, однако это и долго, и до­рого. А можно принять стандарт создателя Java — фирмы Sun (теперь уже Oracle), пред­ложившей ряд рекомендаций относительно внешнего вида приложений. Команда Sun провела приличную исследовательскую работу, привлекла художников и дизайнеров, и нужно признать, что приложение, созданное в полном соответствии с этими реко­мендациями, выглядит действительно гармонично. К тому же вы можете бесплатно за­

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

Рекомендации от Sun

Рекомендации по созданию интерфейса Java-приложений (JavaLook&FeelDesignGuidelines) — это довольно объемный труд, выпущенный компанией Sun/Oracle специаль­но для разработчиков Java-приложений. Там содержится действительно много полезной информации, необходимой при создании промышленных приложений. Рекомендации от Sun, в том числе, касаются способов расположения компонентов на форме, и особенно интересной, на взгляд автора, является информация о пространстве между компонента­ми. Следуя этим рекомендациям, можно в результате получить действительно привлека­тельный внешний вид. Однако учтите, что все рекомендации касаются только внешнего вида Metal или производного от него, используемого в Swing по умолчанию, а в случае дру­гого внешнего вида стоит обратить внимание на рекомендации его производителя.

Рисуя набросок будущего диалогового окна для нашего приложения, мы, сознатель­но или подсознательно, оставили некоторое пространство между компонентами и от­ступили от границ окна. Это неудивительно — такой подход диктуется логикой, и нам кажется вполне естественным более акцентировано отделять логически малосвязанные компоненты, чем тесно связанные. Другой вопрос — насколько именно нужно раздви­нуть эти компоненты, чтобы получить наилучший результат? Можно проводить долгие эксперименты или нанять дизайнеров. Можно этого не и не делать. Почему? Это уже проделано командой Sun. Никто не утверждает, что это — идеальный вариант и ничего лучше уже придумать невозможно. Но, тем не менее, он дает более чем приемлемый результат. Итак.

  • Расстояние между логически тесно связанными компопе)тами.Чаще всего такими компонентами являются кнопки JButton, флажки JCheckBoxи переключатели JRadioButtonв группах, отвечающие за выбор пользователем одного из возможных вариантов (вряд ли вообще можно придумать более тесно связанные компоненты Их следует отделять друг От друга на 5 пикселов (в некоторых случаях рекомендуем­ся 6 пикселов, однако это уже чрезмерные тонкости, а на современных дисплея;; с высоким разрешением увидеть разницу в один пиксел можно, наверное, тольк: с лупой). Наглядный пример в нашем случае — пара кнопок ОКи Отмена.

  • Расстояние между группами компонентов. Здесь имеются в виду те же самые группь из флажков и переключателей. Обычно, если они присутствуют в интерфейсе то не поодиночке (каждая группа отвечает за выбор определенного условия). Та* вот, расстояние между ними должно быть 12 пикселов (здесь также есть вариант - 11 пикселов, связанный с неоднозначным восприятием человеком белых теней компонентов, но к нему вполне применим комментарий из предыдущего пункта В нашем интерфейсе таких групп нет, но откройте любое диалоговое окно, пред­назначенное для настройки программы, и вы их увидите.

  • Пространство между границами окна и другими компонентами. Задавая такое рассто­яние, мы акцентируем внимание на интерфейсе и -отделяем его от границ ос-^ служащих для других целей. Те же соображения относятся и к панелям с рамкам■ набор которых в Swing просто потрясает воображение. Такие панели помогав» четко структурировать интерфейс, хотя ни в коем случае не следует ими злоупо­треблять. От границ этих панелей компоненты также нужно отделять. Для тагг-з ситуаций используйте значение в 12 пикселов.

  • Расстояние между «обычными» компонентами. Под обычными компонентами подраз­умеваются те, которые, как правило, не встретишь в логически связанных группах. К ним относятся текстовые поля JTextField, надписи к компонентам JLabel, индика­торы процесса JProgressBar, ползунки JSIiderи т. д. И здесь следует использовать уже встретившееся нам значение в 12 пикселов.

  • Пространство между компонентами, выполняющими абсолютно разные функции. Такие компоненты нечасто можно встретить в интерфейсе. Но нам повезло — в нашем диалоговом окне они есть. Текстовые поля служат для сбора информации от поль­зователя, а кнопки — для получения от него команд. Их целесообразно разделить более явно, и для этого используется немаленькое расстояние в 17 пикселов. Обыч­но это — единственный вариант применения такого расстояния (отделение кнопок управления от «собирательной» части или информационной части интерфейса).

  • Внешний вид кнопок JButton. Вообще-то это уже совершенно особый случай, и о нем следовало бы упомянуть в главе, посвященной элементам управления вообще и кнопкам в частности, но раз в нашем диалоговом окне есть кнопки, скажем об этом сейчас. Необходимо отделять смысловое наполнение кнопок (обычно текст, иногда значки) от их границ слева и справа на четкое расстояние в те самые 12 пик­селов. Когда вы просто создаете кнопку, в соответствие с внешним видом Melal рас­стояния получаются чуть большими, порядка 14 пикселов. Видимо, такое расстоя­ние необходимо, чтобы выдержать общий «стиль» в 12 пикселов.

Это наиболее важные положения рекомендаций Sun, относящиеся к расположению компонентов (для интерфейса, который мы сейчас создаем, этого вполне достаточно). Но этими положениями рекомендации Sun не исчерпываются, в них вы можете най­ти множество полезной информации, касающейся того, как следует использовать про­писные и строчные буквы в надписях компонентов, какой стиль письма подходит для пользовательских интерфейсов, какие должны быть значки для приложений с внешним видом Metal, как выглядит набор стандартных диалоговых окон и т. п. Также неплохо освещена сама философия пользовательского интерфейса. К сожалению, это не явля­ется темой данной книги (хотя кое-что их этих рекомендаций мы используем в главах, посвященных компонентам Swing, а за остальным можете обращаться на сайт java.sun. com). Аналогичные рекомендации вы сможете найти и для других известных внешних видов: Windows, Apple и остальных, если захотите создать свое Swing-приложение в по­хожем стиле.

Вернемся к нашему диалоговому окну. Как видно, выдержать стиль Java-приложения не так уж и трудно, по крайней мере, в отношении расстояния между компонентами и их расположения. Основным расстоянием везде служат 12 пикселов, ну а в особых случаях применяются 5 и 17 пикселов.

  1. Отформатировать таблицу по СТП МГУПИ

  1. Отформатировать текст по СТП МГУПИ, ввести формулы с помощью инструмента MSEquation

В вычислительной практике наиболее употребителен дискретный вариант опи­санных алгоритмов. По аналогии со случаем вырожденных ядер можно опреде­лить класс вырожденных матриц. Пусть М — множество квадратных матриц размерности т, представимых в виде

Вариант № 32