Кроме высокого FPS, честно говоря, у библиотеки особенностей пока нет. Интерактивность примитивная — уловить правую кнопку мыши невозможно. Никаких средств для работы с текстом, графикой — исключительно спрайты: хочешь вывести текст? рисуй в канвасе, конверти в спрайт. Все объекты — прямоугольники, что создаёт вопросы об областях выделения.
Документация и примеры грошовые, поддержку найти практически нереально, следует лезть в код и искать ответы там.
Будем надеяться, со временем ситуация изменится к лучшему.
∷ — искал такую иконку недавно, в виде четырех квадратов, намекающих на лэйаут плиткой. Есть вариант из девяти ∶∶∶, но он смазывается на мелких шрифтах ≤12px.
Неплохо бы также откорректировать иконку простого списка ☰ — смазывается.
Сложный макет за 1 день? Ну примеры, что у вас в портфолио — может быть, если поднапрячься. Но если надо мало-мальски сделать через эффекты через CSS, адаптивную вёрстку, там, замысловатый лэйаут, типографический или интерфейсный тулкит — u’re fuckd. Там порой и неделей не отделаешься.
Типа appearance в иллюстраторе?
Предпосылка идеи неверна вообще. Слои — лишь частность общей идеи процедурной обработки изображений. Вон, в nuke можно целые алгоритмы обработки составлять.
Но даже предпосылка идеи обработки изображений для софта, моделирующего интерфейсы, неверна. Следует исходить из сущностей. Их не надо дублировать где-то в слоях — они вот, на полотне лежат, ими и следует манипулировать. Слои могут быть применимы в рамках одной сущности, для формирования нужной картинки, но не как отражение всего документа. Это вообще главный косяк фотошопа для интерфейсов.
Ваши методики прямо вдохновили. Очень практичная и эффективная точка зрения на процесс разработки интерфейсов. Сейчас делаю редизайн портала афиши мероприятий, погряз в стереотипах, несмотря на то, что, казалось бы, всё делается по методикам (подход Купера). Всё в целеориентированном подходе здорово, но как доходит до дела — т. е. дизайна, всё тем не менее сводится к субъективному представлению идеального варианта использования. В итоге прихожу к пониманию, что выполнение наиболее простых, понятных и интересных участков работы в первую очередь гораздо эффективнее, чем какой-то общий подход типа скетч -> вайрфрейм -> мокап -> прототип. Оказывается, можно делать сразу прототип, если представлять, как это всё работает.
Мне казалось, что на хабре когда-то имелось негласное правило вежливости в виде объяснения своего несогласия. Теперь-же в моде молчаливый слив? Не думаем, просто выражаем злость? Отлично. Видимо, я нарвался на аудиторию хипстеров и студентов.
Честно говоря, геморроя с этими виджетами больше, чем проку.
Все эти методы быстрее и легче реализовать самому, чем подключать внешнюю зависимость в виде jQueryUI.Core с jQueryUI.Widget.
Create, options, trigger, запись в data-аттрибут элемента — всё это рутинные вещи для любого адекватного jQuery-плагина на основе класса. Более того, самому в разы проще расширять функционал: к примеру, сделать AMD-модуль, подключить модели бэкбон, сделать биндинги методов, событий и прочее. Независимый код гораздо проще переносить, в нём нет зависимостей и лишнего, а накладные расходы минимальны.
Как показывает практика, писать код в архитектуре лайк MVC/jQueryUI очень и очень муторно, простой функционал отнимает сил более надобного. Проекты типа meteor выглядят очень вкусной альтернативой.
Осталось только заиметь список готовых компонентов, тогда, видимо, это и будет фреймворк.
А пока – ничего нового из того, что не делает jQuery UI, Backbone или любая другая нормальная архитектура на js.
Еее! Первые приложения на node-webkit!
Вам бы интеграцию в систему сделать, по типу autohotkey, чтобы шифровать/дешифровать по нажатию клавиш, а не в отдельном окне.
Только для этого придется использовать node-ffi и курить нативные API…
Документация и примеры грошовые, поддержку найти практически нереально, следует лезть в код и искать ответы там.
Будем надеяться, со временем ситуация изменится к лучшему.
Неплохо бы также откорректировать иконку простого списка ☰ — смазывается.
Предпосылка идеи неверна вообще. Слои — лишь частность общей идеи процедурной обработки изображений. Вон, в nuke можно целые алгоритмы обработки составлять.
Но даже предпосылка идеи обработки изображений для софта, моделирующего интерфейсы, неверна. Следует исходить из сущностей. Их не надо дублировать где-то в слоях — они вот, на полотне лежат, ими и следует манипулировать. Слои могут быть применимы в рамках одной сущности, для формирования нужной картинки, но не как отражение всего документа. Это вообще главный косяк фотошопа для интерфейсов.
Все эти методы быстрее и легче реализовать самому, чем подключать внешнюю зависимость в виде jQueryUI.Core с jQueryUI.Widget.
Create, options, trigger, запись в data-аттрибут элемента — всё это рутинные вещи для любого адекватного jQuery-плагина на основе класса. Более того, самому в разы проще расширять функционал: к примеру, сделать AMD-модуль, подключить модели бэкбон, сделать биндинги методов, событий и прочее. Независимый код гораздо проще переносить, в нём нет зависимостей и лишнего, а накладные расходы минимальны.
Как показывает практика, писать код в архитектуре лайк MVC/jQueryUI очень и очень муторно, простой функционал отнимает сил более надобного. Проекты типа meteor выглядят очень вкусной альтернативой.
«Кроссбраузерная кастомизация системного скроллбара. …демо…, …аннотированный код…».
Вы такие милые!
А пока – ничего нового из того, что не делает jQuery UI, Backbone или любая другая нормальная архитектура на js.
Вам бы интеграцию в систему сделать, по типу autohotkey, чтобы шифровать/дешифровать по нажатию клавиш, а не в отдельном окне.
Только для этого придется использовать node-ffi и курить нативные API…