одна только раскладка да, не решит, нужен ещё софт который это поймёт и распарсит соответствующим образом. так что это я просто немного помечтал: AltGr + s набрать легче, чем \sigma
я тоже не очень понимаю, о чём речь. нельзя ли для непосвящённых пояснить, что означает:
— реактивные GUI-приложения
— реактивное программирование
— композиция в данном контексте
— механизм и политика
— DSL со статической проверкой всего и вся
— total FPL
— FTW
— атрибутные грамматики
по-вашему, это, похоже неявный способ. это плохо? :)
вообще, свойства стилей — это немного не то. состояния виджетов обычно хранятся в каких-нибудь слоях, которые показываются при изменении соотв. свойства, это всё связывается в конструкторе виджета. а свойства стилей определяют именно «скин», то есть имеется возможность модифицировать скин некоторого поддерева виджетов, но я не думаю, что их нужно менять по различным событиям. пока в heliwidgets нету api по выделению неправильно заполненных полей, и я ещё не думал об этом, посему пока не знаю как это будет реализовано.
> А как быть, когда зависимости подымаются снизу вверх? Например, при размещении элементов так оно и есть: позиция элемента определяется сверху вниз, а размер занятой области снизу вверх (и пр. вариации).
Геометрия, как уже писал, не есть свойство стиля (тут, похоже, будет путаница, потому что слово «стиль» сразу же ассоциируется с css, надо бы не забыть описать это в мануале :) ). Кстати говоря, в heliwidgets я как раз сейчас остановился на реализации этой фичи, так что я пока даже не могу сделать обычный скроллинг :). Думаю, как снова появится время займусь как раз этим.
> Стили тоже могут подыматься: примером будет text input, предок которого подсвечивается особым цветом
Я думаю, что в этом случае будет подсвечиваться сам виджет, а не его предок. Сложные древовидные формы — это редкий случай, я такого не видел.
> Бывает еще, когда зависимости распространяются слева направо и справа налево, и другими способами.
Не хочу усложнять, пока не найдётся конкретный юзкейс, для которого это понадобится.
> но выкладывайте записи/презентацию в интернеты, почитаю.
Я думаю, что в скором времени обновлю домашнюю страничку в соответствии с комментариями и частозадаваемыми вопросами здесь и на мероприятии. То, как я всё описываю часто не совпадает с тем, что хочет увидеть потенциальный читатель :) В частности, Вам я благодарен за комментарий номер 4 (http://xpostman.habrahabr.ru/blog/68291/#comment_1935958), постараюсь на него ответить в ближайшие дни.
> также могу открыть свои доки с идеями, а сорцы здесь
постараюсь поглядеть в ближайшее время, если оно найдётся. хотя я с эгоистической точки зрения рассуждаю :) (то есть, у меня в голове вопросы, из серии, «что полезного я могу извлечь оттуда для гелиоса» :) ). но совместный брейншторм может оказаться взаимовыгодным.
однако же при разработке на C++ мне приходится ждать ещё и перекомпиляции. аналогичная ситуация, полагаю, и при использовании подхода GWT/Eclipse RAP. не считаю это недостатком.
> а зачем его вырезать? если для возможности сохранения на диск, то с собранными в один файл скриптами даже лучше. если для разработки без поднятия сервера, то не слишком это нужно.
не люблю усложнять без необходимости. для разработки клиентской части сервер не нужен, можно писать клиента отдельно, нужно лишь согласовать протокол с тем, кто будет писать сервер.
> кстати, а что мешает kernel.js засунуть прямо в хтмл, раз больше ни для чего этот хтмл и не нужен?
хтмл код находится в .html файле, джаваскрипт — в .js. по-моему, так логично :)
ничто не мешает юзать соглашения и в моём случае, в либах для гелиоса я тоже старался их придерживаться. я лишь считаю, что не нужно навязывать, потому что возникают исключения, когда удобней поступить по-иному.
и ещё мне кажется существенным тот факт, что мне наконец-то удалось полностью вырезать клиент из сервера. хотя, это может быть из-за фанатизма к своему же проекту =)
если я правильно понял:
это накладывает соглашение об именовании объектов и модулей, где они объявлены? я думаю, что самостоятельно определять структуру модулей иногда удобнее. кроме того, если в одном модуле есть два объекта, из которых, возможно, использоваться только один, тогда имеет смысл разделить эти модули. тогда и при моём подходе ничего лишнего грузится не будет, и также не будет лишней нагрузки на сервер
простые вещи не всегда сразу в голову приходят. на самом деле пересматривая код я часто нахожу разные идиотизмы, которые сначала не замечал. наверное, про kernel.js это больше всего верно — как только я его дописал до такого состояния, что у меня прошли все тесткейсы на основных броузерах — я обрадовался и с головой погрузился в написание либов. а codereview мне было не с кем провести пока, среди моих знакомых прогеров, из тех, что хоть немного в теме, большинство высказывают комменты вроде «вах, вот это неимоверно круто, респект чувак». от такого фидбэка, понятное дело, толку мало :)
Заголовок поправьте
в хроме завелось у кого-нибудь? :(
А можно в пост покидать ссылок на приложения на сайтах авторов?
— реактивные GUI-приложения
— реактивное программирование
— композиция в данном контексте
— механизм и политика
— DSL со статической проверкой всего и вся
— total FPL
— FTW
— атрибутные грамматики
свойство стиля предоставляет сеттер и геттер, и я бы подписал его на сигнал, примерно так:
myWidget.sigMouseOver.listen( myWidget.setStyleProp( «color», "#ffffff" ) );
myWidget.sigMouseOut.listen( myWidget.setStyleProp( «color», "#000000" ) );
по-вашему, это, похоже неявный способ. это плохо? :)
вообще, свойства стилей — это немного не то. состояния виджетов обычно хранятся в каких-нибудь слоях, которые показываются при изменении соотв. свойства, это всё связывается в конструкторе виджета. а свойства стилей определяют именно «скин», то есть имеется возможность модифицировать скин некоторого поддерева виджетов, но я не думаю, что их нужно менять по различным событиям. пока в heliwidgets нету api по выделению неправильно заполненных полей, и я ещё не думал об этом, посему пока не знаю как это будет реализовано.
> А как быть, когда зависимости подымаются снизу вверх? Например, при размещении элементов так оно и есть: позиция элемента определяется сверху вниз, а размер занятой области снизу вверх (и пр. вариации).
Геометрия, как уже писал, не есть свойство стиля (тут, похоже, будет путаница, потому что слово «стиль» сразу же ассоциируется с css, надо бы не забыть описать это в мануале :) ). Кстати говоря, в heliwidgets я как раз сейчас остановился на реализации этой фичи, так что я пока даже не могу сделать обычный скроллинг :). Думаю, как снова появится время займусь как раз этим.
> Стили тоже могут подыматься: примером будет text input, предок которого подсвечивается особым цветом
Я думаю, что в этом случае будет подсвечиваться сам виджет, а не его предок. Сложные древовидные формы — это редкий случай, я такого не видел.
> Бывает еще, когда зависимости распространяются слева направо и справа налево, и другими способами.
Не хочу усложнять, пока не найдётся конкретный юзкейс, для которого это понадобится.
> но выкладывайте записи/презентацию в интернеты, почитаю.
Я думаю, что в скором времени обновлю домашнюю страничку в соответствии с комментариями и частозадаваемыми вопросами здесь и на мероприятии. То, как я всё описываю часто не совпадает с тем, что хочет увидеть потенциальный читатель :) В частности, Вам я благодарен за комментарий номер 4 (http://xpostman.habrahabr.ru/blog/68291/#comment_1935958), постараюсь на него ответить в ближайшие дни.
> также могу открыть свои доки с идеями, а сорцы здесь
постараюсь поглядеть в ближайшее время, если оно найдётся. хотя я с эгоистической точки зрения рассуждаю :) (то есть, у меня в голове вопросы, из серии, «что полезного я могу извлечь оттуда для гелиоса» :) ). но совместный брейншторм может оказаться взаимовыгодным.
не люблю усложнять без необходимости. для разработки клиентской части сервер не нужен, можно писать клиента отдельно, нужно лишь согласовать протокол с тем, кто будет писать сервер.
> кстати, а что мешает kernel.js засунуть прямо в хтмл, раз больше ни для чего этот хтмл и не нужен?
хтмл код находится в .html файле, джаваскрипт — в .js. по-моему, так логично :)
и ещё мне кажется существенным тот факт, что мне наконец-то удалось полностью вырезать клиент из сервера. хотя, это может быть из-за фанатизма к своему же проекту =)
это накладывает соглашение об именовании объектов и модулей, где они объявлены? я думаю, что самостоятельно определять структуру модулей иногда удобнее. кроме того, если в одном модуле есть два объекта, из которых, возможно, использоваться только один, тогда имеет смысл разделить эти модули. тогда и при моём подходе ничего лишнего грузится не будет, и также не будет лишней нагрузки на сервер
простые вещи не всегда сразу в голову приходят. на самом деле пересматривая код я часто нахожу разные идиотизмы, которые сначала не замечал. наверное, про kernel.js это больше всего верно — как только я его дописал до такого состояния, что у меня прошли все тесткейсы на основных броузерах — я обрадовался и с головой погрузился в написание либов. а codereview мне было не с кем провести пока, среди моих знакомых прогеров, из тех, что хоть немного в теме, большинство высказывают комменты вроде «вах, вот это неимоверно круто, респект чувак». от такого фидбэка, понятное дело, толку мало :)