В приложении надо решать задачи. Если задачей является «использовать вспомогательные звуковые эффекты» то надо решать именно эту задачу а не какие-то другие.
API javax.sound.midi не позволяет по-простому проиграть музыкальный фрагмент или отдельный звук. Данная библиотека предоставляет такую возможность (см. пример в каментах выше) одной строкой
Tools.playNote(…
Кроме того, во многих приложениях (казуальные игры) желательно менять воспроизводимую композицию для отражения того что происходит на экране. Если сравнить с API Android то там для этих целей используется http://developer.android.com/reference/android/media/JetPlayer.html — в файле заранее готовятся куски MIDI-фрагментов и их можно воспроизводить меняя последовательность на ходу.
API javax.sound.midi простого пути для подобного не предоставляет. В EasyMIDI это достаточно легко делается.
Не очень понятно почему вообще идёт речь о синхронизации и соответствии требованиям стандарта MIDI. У библиотеки чётко очерчена область применения в начале статьи. И эта область гораздо обширней (по количеству приложений) задач написания муз.произведений.
Часто в приложениях желательно использовать какие-то вспомогательные звуковые эффекты, например пикнуть динамиком при ошибке или проиграть мелодию на новое письмо.
Если стоит задача проиграть, скажем, аплодисменты по окончанию загрузки в базу или ещё что то можно использовать
Tools.playNote(…
а можно подключить DirectShow, JNI, заказать у проф.музыканта семпл и встроить его в приложение.
Результат будет одинаковый с точки зрения пользователя но первый способ, стесняюсь говорить об очевидном, как-то проще, быстрее и дешевле.
Часто в приложениях желательно использовать какие-то вспомогательные звуковые эффекты, например пикнуть динамиком при ошибке или проиграть мелодию на новое письмо.
я бы посоветовал выбирать выражения. Стандарт MIDI, в той части которая касается этой библиотеки (воспроизведение звука), поддерживается практически всеми звуковыми картами. В этом можно убедиться запустив тестовое приложение.
Что касается аппаратного MIDI то в статье оно не упоминается и библиотеки никак не касается.
Можно настроить разрешение экрана в виндовс на 1024х768. Точно такое же разрешение можно сделать и на нетбуке с экраном 11" по диагонали и на офисном мониторе 20" по диагонали.
В результате DPI на нетбуке будет почти в два раза ниже чем на офисном компе. Можно взять линейку и посчитать количество пикселов на дюйм.
DPI это термин из полиграфии, никакие менеджеры компоновки его не учитывают.
на скриншоте видно как форма ведёт себя при ресайзе. В статье и в каментах сравнивается не функционал (он достаточный) а простота достижения цели, читабельность кода, лёгкость модификации макета и вероятность допустить ошибки.
DPI это количество точек на дюйм (Dots per inch). Касается он физичесикх размеров монитора либо распечатанного материала. Все менеджеры компоновки работают с пикселами, не понимаю зачем про этот DPI вообще спрашивать.
Как видим, сходство с первым скриншотом почти полное, осталось добавить код чтобы сделать высоту кнопки "..." равной высоте текстовых полей и изменить размер отступа между полями.
Читабельность этой кучи констант и методов по сравнению с предидущими примерами применения MigLayout не изменилась. То же про вероятность ошибок и сложность изменения.
Это и есть итог обсуждения:
простую форму никому не удалось воссоздать с первого раза и точно как на картинке (понятно что возиться лень а на раз-два не выйдет).
Это концептуальная проблема выноса логики компановки в LayoutManager
— если сделать просто как в FlowLayout то функционала будет недостаточно
— если сделать многофункционально как GroupLayout то чрезмерная сложность будет затруднять рисование элементарных вобщем-то окошек
Этих проблем лишён Layoutless
— правила использования просты как правила игры в перетягивание каната
— binding позволяет добиться гибкости бОльшей чем есть у многих менеджеров компоновки
что ж такого ужасного на заводе. Я работал на заводе слесарем в 90-х, когда всё началось рушиться и работы не было никакой вообще. Ничё особенного.
Кроме того, по скриншоту несложно догадаться что контролы на форме динамически меняют размер/положение в зависимости от размеров окна т.е. никаких «прибитых гвоздями» размеров там нет.
да ничего не похоже. Это вроде сразу видно. Если сделать похоже (например чтоб кнопка "..." была по высоте как и поля, чтоб по таким же правилам размеры полей менялись, чтоб были отступы между надписями и границами и т.д.) то кода потребуется больше чем в примере из статьи.
по поводу ошибки неясно. Я продолжаю что-то дописывать (например не хватает SQL-подобных выражений, чтоб уж окончательно закрыть все потребности).
Проверил только что — всё компилится и работает.
По поводу основ — что-то похожее будет в JavaFX. Я им долго занимался (см. мой сайт на javafx.me. К сожалению с участниками проекта JavaFX у меня как-то не заладилось, у них собственная реализация. На мой взгляд у них хуже.
этот код сделает форму даже примерно не похожую на скриншот.
Да, есть куча компоновщиков с большим количеством возможностей. Ноесли сделать такую же форму как в первом скриншоте (вобщем-то ничего сложного нет, всего-то несколько полей и кнопок) то кода уйдёт на это больше чем в примере из статьи. Я уж не говорю о читабельности и пр.
является ли первый вариант более читабельным и локаничным чем второй?
Ну и сам собой напрашивается ответ — да это пистец какой-то. Вообще ничего невозможно разобрать.
Это ж не соревнование кто больше времени тратит на изучение кода который делает тривиальные вобщем-то вещи. Всего лишь форма с несколькими полями и кнопками.
в каментах ниже и выше приводились примеры кода похожей формы для MigLayout и для FormLayout. Я привёл вполне логичный разбор и показал что недостатков у Layoutless меньше. Будет другие примеры — можно сравнить с ними.
Относительно кто кому должен доказывать — для этого и существует обсуждения в комментариях к статьям. Сразу сделать описание понятное для всех непросто.
если нарисовать именно такую форму как в скриншоте то кода с MigLayout'ом будет не меньше. И будет он уже состоять из нетривиальных вещей.
по простоте представления (читабельности) — опять же можно сравнить конкретный код. У MigLayout: panel.add( field1, «growx, split» );
— без контекста абсолютно не ясно где это будет лежать. Причём в зависимости от спецификации в менеджере (эти самые «0[]7[]7[]push[]0») может иметь разное положение и поведение.
у Layoutless:
.item(new ComponentBox()
.component(jTextField1)
.width(layoutless.width().minus(labelsWidth).minus(16).minus(50))
.height(22)
.x(labelsWidth+8)
.y(8+25*0)
)
— вполне ясно где это находится и какого размера. И если зависит от других параметров (от размеров формы layoutless.width() например) то это сразу видно в определении самого компонента.
так что читабельность всё таки выше
Это скорей проблема всех статей
— если сделать простой пример то всем будет казаться что это очень просто и любым другим инструментом можно повторить
— если сделать сложный пример то мало кто разберётся
API javax.sound.midi не позволяет по-простому проиграть музыкальный фрагмент или отдельный звук. Данная библиотека предоставляет такую возможность (см. пример в каментах выше) одной строкой
Tools.playNote(…
Кроме того, во многих приложениях (казуальные игры) желательно менять воспроизводимую композицию для отражения того что происходит на экране. Если сравнить с API Android то там для этих целей используется http://developer.android.com/reference/android/media/JetPlayer.html — в файле заранее готовятся куски MIDI-фрагментов и их можно воспроизводить меняя последовательность на ходу.
API javax.sound.midi простого пути для подобного не предоставляет. В EasyMIDI это достаточно легко делается.
Не очень понятно почему вообще идёт речь о синхронизации и соответствии требованиям стандарта MIDI. У библиотеки чётко очерчена область применения в начале статьи. И эта область гораздо обширней (по количеству приложений) задач написания муз.произведений.
Часто в приложениях желательно использовать какие-то вспомогательные звуковые эффекты, например пикнуть динамиком при ошибке или проиграть мелодию на новое письмо.Если стоит задача проиграть, скажем, аплодисменты по окончанию загрузки в базу или ещё что то можно использовать
Tools.playNote(…
а можно подключить DirectShow, JNI, заказать у проф.музыканта семпл и встроить его в приложение.
Результат будет одинаковый с точки зрения пользователя но первый способ, стесняюсь говорить об очевидном, как-то проще, быстрее и дешевле.
Часто в приложениях желательно использовать какие-то вспомогательные звуковые эффекты, например пикнуть динамиком при ошибке или проиграть мелодию на новое письмо.Это часто встречаемая, вполне типовая задача.
Что касается аппаратного MIDI то в статье оно не упоминается и библиотеки никак не касается.
На похожих принципах можно компоновать содержимое форм в .NET
http://msdn.microsoft.com/en-us/library/system.windows.forms.control.anchor%28v=vs.71%29.aspx
и во Flex'е
http://livedocs.adobe.com/flex/3/html/help.html?content=size_position_5.html
Можно настроить разрешение экрана в виндовс на 1024х768. Точно такое же разрешение можно сделать и на нетбуке с экраном 11" по диагонали и на офисном мониторе 20" по диагонали.
В результате DPI на нетбуке будет почти в два раза ниже чем на офисном компе. Можно взять линейку и посчитать количество пикселов на дюйм.
DPI это термин из полиграфии, никакие менеджеры компоновки его не учитывают.
http://habrahabr.ru/blogs/java/127339/#comment_4204183
Как видим, сходство с первым скриншотом почти полное, осталось добавить код чтобы сделать высоту кнопки "..." равной высоте текстовых полей и изменить размер отступа между полями.
Читабельность этой кучи констант и методов по сравнению с предидущими примерами применения MigLayout не изменилась. То же про вероятность ошибок и сложность изменения.
Это и есть итог обсуждения:
простую форму никому не удалось воссоздать с первого раза и точно как на картинке (понятно что возиться лень а на раз-два не выйдет).
Это концептуальная проблема выноса логики компановки в LayoutManager
— если сделать просто как в FlowLayout то функционала будет недостаточно
— если сделать многофункционально как GroupLayout то чрезмерная сложность будет затруднять рисование элементарных вобщем-то окошек
Этих проблем лишён Layoutless
— правила использования просты как правила игры в перетягивание каната
— binding позволяет добиться гибкости бОльшей чем есть у многих менеджеров компоновки
результат:
forMSSQL: select top 10 * from table1
forPostgreSQL: select * from table1 limit 10
dialect: MS SQL, command: select top 10 * from table1
/let dialect isn't MS SQL
dialect: PostgreSQL, command: select * from table1 limit 10
/let command = select field1,filed2 from table1 limit 10
command: select field1,filed2 from table1 limit 10
forMSSQL: select top 10 * from table1
forPostgreSQL: select field1,filed2 from table1 limit 10
— видно что при изменении command также меняется и связанная с ней по условию переменная
ЗЫ
Note.iF это тоже самое что и new Fork() только короче
Кроме того, по скриншоту несложно догадаться что контролы на форме динамически меняют размер/положение в зависимости от размеров окна т.е. никаких «прибитых гвоздями» размеров там нет.
Проверил только что — всё компилится и работает.
По поводу основ — что-то похожее будет в JavaFX. Я им долго занимался (см. мой сайт на javafx.me. К сожалению с участниками проекта JavaFX у меня как-то не заладилось, у них собственная реализация. На мой взгляд у них хуже.
Да, есть куча компоновщиков с большим количеством возможностей. Ноесли сделать такую же форму как в первом скриншоте (вобщем-то ничего сложного нет, всего-то несколько полей и кнопок) то кода уйдёт на это больше чем в примере из статьи. Я уж не говорю о читабельности и пр.
Layoutless тоже «универсально, гибко, кроссплатформенно», это пропускаем.
Далее не буду повторяться, просто посмотрим на строку
frame.add( new JTextField(«jTextField1»,10), new GridBagConstraints( 2, 0, 1, 1, 1.0, 0.0, GridBagConstraints.WEST, GridBagConstraints.HORIZONTAL, new Insets(0,0,0,0), 0, 0 ) );
сравним с этим
.item(new ComponentBox()
.component(jTextField1)
.width(layoutless.width().minus(labelsWidth).minus(16).minus(50))
.height(22)
.x(labelsWidth+8)
.y(8+25*0)
)
Зададим вопрос:
является ли первый вариант более читабельным и локаничным чем второй?
Ну и сам собой напрашивается ответ — да это пистец какой-то. Вообще ничего невозможно разобрать.
Это ж не соревнование кто больше времени тратит на изучение кода который делает тривиальные вобщем-то вещи. Всего лишь форма с несколькими полями и кнопками.
Относительно кто кому должен доказывать — для этого и существует обсуждения в комментариях к статьям. Сразу сделать описание понятное для всех непросто.
по простоте представления (читабельности) — опять же можно сравнить конкретный код. У MigLayout: panel.add( field1, «growx, split» );
— без контекста абсолютно не ясно где это будет лежать. Причём в зависимости от спецификации в менеджере (эти самые «0[]7[]7[]push[]0») может иметь разное положение и поведение.
у Layoutless:
.item(new ComponentBox()
.component(jTextField1)
.width(layoutless.width().minus(labelsWidth).minus(16).minus(50))
.height(22)
.x(labelsWidth+8)
.y(8+25*0)
)
— вполне ясно где это находится и какого размера. И если зависит от других параметров (от размеров формы layoutless.width() например) то это сразу видно в определении самого компонента.
так что читабельность всё таки выше
Это скорей проблема всех статей
— если сделать простой пример то всем будет казаться что это очень просто и любым другим инструментом можно повторить
— если сделать сложный пример то мало кто разберётся