Comments 28
Спасибо за статью. Никак не доходили руки изучить, теперь надеюсь дойдут.
Behavoiurs так и называется или это опечатка в статье?
Кругом этот GitHub…
Планируется ли сделать человеческий сайт для человеков а-ля jquery.com, где документация написана человеческим языком и рассчитана на широкий круг пользователей? Может я один такой тугой, но вот лично для меня порог вхождения на сам GitHub высок, потому как вижу я его впервые (ну ладно вру — второй раз в жизни).
Планируется ли сделать человеческий сайт для человеков а-ля jquery.com, где документация написана человеческим языком и рассчитана на широкий круг пользователей? Может я один такой тугой, но вот лично для меня порог вхождения на сам GitHub высок, потому как вижу я его впервые (ну ладно вру — второй раз в жизни).
Планируется.
Но я вам всё-равно рекомендую изучить GitHub, не пожалеете ;)
Но я вам всё-равно рекомендую изучить GitHub, не пожалеете ;)
А есть режим автоокругления координат фигур, чтобы при его включении они точно попадали в пиксельный растр?
У меня есть тестовый
libcanvas.github.com/shapes/rectangle/creating.html
libcanvas.github.com/shapes/rectangle/points.html
Но я пока не определился с корректным интерфейсом и реализацией.
point.snapToPixel(). Я его использую, например, тут:libcanvas.github.com/shapes/rectangle/creating.html
libcanvas.github.com/shapes/rectangle/points.html
Но я пока не определился с корректным интерфейсом и реализацией.
Да, дело там сложнее, чем кажется на первый взгляд.
Во-первых, нужен глобальный триггер и некий локальный параметр для отдельного вызова.
Во-вторых, выбор способа округления — только вниз, только вверх, к ближайшему.
В-третьих, (в идеале) хочется развить это и сделать ещё выравнивание границ шейпов по аналогии с графическими программами (inside/center/outside). Опять-таки с глобальным параметром.
Чтобы можно было, скажем, в начале установить .snapToPixel = true, .borderAlignment = 'inside' — и гнать блоки конвейером :)
Во-первых, нужен глобальный триггер и некий локальный параметр для отдельного вызова.
Во-вторых, выбор способа округления — только вниз, только вверх, к ближайшему.
В-третьих, (в идеале) хочется развить это и сделать ещё выравнивание границ шейпов по аналогии с графическими программами (inside/center/outside). Опять-таки с глобальным параметром.
Чтобы можно было, скажем, в начале установить .snapToPixel = true, .borderAlignment = 'inside' — и гнать блоки конвейером :)
Угу, я приблизительно так и представлял, но за реализацию пока не брался. Хотя согласен — это очень интересная идея. Кажется, это необходимо добавить к контексту (по аналогии с fillRect и иже с ними):
На самом деле передать параметры везде, куда необходимо — совсем не проблема. Я пока не совсем разобрался с деталями реализации. Необходимо будет написать хорошее приложение, где snapToPixel нужен, чтобы разобраться. Пока такие не встречались.
Если бы был желающий это сделать — я бы с удовольствием помог консультациями и кодом.
context = canvas.getContext('2d-libcanvas');
context.save();
context.snapToPixel = true;
context.borderAligment = 'inside';
context.stroke( shape );
context.restore();
На самом деле передать параметры везде, куда необходимо — совсем не проблема. Я пока не совсем разобрался с деталями реализации. Необходимо будет написать хорошее приложение, где snapToPixel нужен, чтобы разобраться. Пока такие не встречались.
Если бы был желающий это сделать — я бы с удовольствием помог консультациями и кодом.
У меня бродят неопределенные мысли на эту тему, но я пока в JS вообще и Canvas в частности чувствую себя не слишком свободно. Учусь.
Кстати, про округления: нужно даже не три, а пять режимов — директивно к каждому из 4-х углов холста и к ближайшему пикселу.
Ещё непонятно, как рисовать границу, скажем, при выравнивании 'center' и толщине линии 3px… Когда ровно пополам не делится. Действительно, много тонких моментов.
Кстати, про округления: нужно даже не три, а пять режимов — директивно к каждому из 4-х углов холста и к ближайшему пикселу.
Ещё непонятно, как рисовать границу, скажем, при выравнивании 'center' и толщине линии 3px… Когда ровно пополам не делится. Действительно, много тонких моментов.
Замечательно, спасибо, давно присматриваюсь к вашему фреймворку, но останавливала документация только на русском и зависимость от AtomJs.
Посмотрел на AtomJs, не совсем понял, он IE не поддерживает (хотя бы 8+)?
Посмотрел на AtomJs, не совсем понял, он IE не поддерживает (хотя бы 8+)?
А в чём недостатки (для вас) только русской документации и уж тем более зависимости от Атома?
AtomJS и LibCanvas поддерживают IE начиная с девятой версии.
AtomJS и LibCanvas поддерживают IE начиная с девятой версии.
Для меня проблем с русским нет, да и исходники на гитхабе доступны, спасибо вам. Западные товарищи нервничают, что это «is too complex in maintainable».
IE начиная с девятой версии — отлично!
Да я понимаю, что мы (программисты) зажрались и требуем документации и тестов от автора.
У меня есть некоторое свободное время по вечерам в ближайшее время, я могу попробовать помочь вам с документацией на русском и английском.
IE начиная с девятой версии — отлично!
Да я понимаю, что мы (программисты) зажрались и требуем документации и тестов от автора.
У меня есть некоторое свободное время по вечерам в ближайшее время, я могу попробовать помочь вам с документацией на русском и английском.
На самом деле я таки да — обязан предоставить документацию и тесты. Просто честно — не успеваю. К примеру, AtomJS у меня покрыт тестами практически полностью (плохо покрыт DOM) — 255 тестов. Есть исходники в репозитории и можно посмотреть у меня на страницах. Доку на LibCanvas решил писать на русском потому что это быстрее, качественнее и всё-равно надо.
Однозначно жду коммитов, но, главное, чтобы было кому её поддерживать)
Однозначно жду коммитов, но, главное, чтобы было кому её поддерживать)
Постараюсь сделать пул реквест на следующей неделе.
Если вам не сложно, заведите пожалуйста теги в репозитории. Это сильно облегчит жизнь при написании документации, плюс очень удобно состовлять чейнжлоги, а так же это заставляет более вдумчиво именовать коммиты :)
Если вам не сложно, заведите пожалуйста теги в репозитории. Это сильно облегчит жизнь при написании документации, плюс очень удобно состовлять чейнжлоги, а так же это заставляет более вдумчиво именовать коммиты :)
Я как-то с Гитом ещё не очень разобрался.
Вы предлагаете использовать теги только для версий? Или теги используются для деления на виды коммитов — «документация», «багФикс», «новаяФича»?
Вы предлагаете использовать теги только для версий? Или теги используются для деления на виды коммитов — «документация», «багФикс», «новаяФича»?
Вы предлагаете использовать теги только для версий?
Да, теги для версий общепринятый варинат. Тег в общем случае уникально идентифицирует один коммит, т.е. пометить одним тегом два коммита в одной ветке нельзя. Для версий принято считать, что теги в публичном репозитории характеризуют коммит, помеченый тегом, и все нижеидущее коммиты до прошлого тега. Гитхаб использует это соглашение в своем интерфейсе.
На некоторых проектах используют текстовые метки в имени коммита для обозначения его типа, к примеру
git commit -m "[Bug] Fixed bug with ie6"
git commit -m "[Feature] New cool stuff"
git commit -m "[Doc] Docs were updated to 1.1.0"
А как использовать эти теги на практике? Как пометить коммит тегом?
То есть, если я пометил один коммит версией «1.2.3», то все следующие коммиты, пока не будет ещё одного тега будут версии «1.2.3»?
То есть, если я пометил один коммит версией «1.2.3», то все следующие коммиты, пока не будет ещё одного тега будут версии «1.2.3»?
Я наверное путано расказал, изивините.
К примеру у вас есть три коммита в репозитории: С1, C2 и C3
Ветка репозитория это некий стек для коммитов (эту аналогию просто расширить на git stash, git pull --rebase и т.д.).
git log и все известные мне утилиты для просмотра дерева коммитов в графическом виде считают, что более новые коммиты отображаютя в самом верху.
Допустим, вот вывод git log
Когда мы применяем тег, он применяется к верхнему коммиту (последнему по дате создания):
Считается, что все три коммита относятся к версии 0.1
Далее, мы делаем еще два коммита:
Это «бесхозные коммиты», добавляем новый тег:
Коммиты 4 и 5 теперь принадлежат к версии 0.2
Теперь мы можем работать с тегами, не заморачиваясь на хеши коммитов, к примеру вывести diff между версиями
или сделать чейнджлог:
и т.д.
При документировании очень удобно иметь «точку опоры», к примеру знать точно, что документация актуальна на версию XXX, которая помечена тегом. С помощью вышеописанных команд можно быстро посмотреть, что изменилось в коде между версиями и внести изменения в док.
К примеру у вас есть три коммита в репозитории: С1, C2 и C3
Ветка репозитория это некий стек для коммитов (эту аналогию просто расширить на git stash, git pull --rebase и т.д.).
git log и все известные мне утилиты для просмотра дерева коммитов в графическом виде считают, что более новые коммиты отображаютя в самом верху.
Допустим, вот вывод git log
$ git log
* С3
* С2
* С1
Когда мы применяем тег, он применяется к верхнему коммиту (последнему по дате создания):
$ git tag v0.1 && git log
* С3 <-- v0.1
* С2
* С1
Считается, что все три коммита относятся к версии 0.1
Далее, мы делаем еще два коммита:
$ git log
* С5
* С4
* С3 <-- v0.1
* С2
* С1
Это «бесхозные коммиты», добавляем новый тег:
$ git tag v0.2 && git log
* С5 <-- v0.2
* С4
* С3 <-- v0.1
* С2
* С1
Коммиты 4 и 5 теперь принадлежат к версии 0.2
Теперь мы можем работать с тегами, не заморачиваясь на хеши коммитов, к примеру вывести diff между версиями
git diff v0.1 v0.2или сделать чейнджлог:
git log v0.1..v0.2и т.д.
При документировании очень удобно иметь «точку опоры», к примеру знать точно, что документация актуальна на версию XXX, которая помечена тегом. С помощью вышеописанных команд можно быстро посмотреть, что изменилось в коде между версиями и внести изменения в док.
Если вы имели ввиду, что в репозитории будут болтаться «лишние» коммиты, а версия будет старой, то это не проблема. В мастере так и бывает обычно, а для мажорных, к примеру версий, создаются отдельные ветки.
Sign up to leave a comment.
Основы LibCanvas — теория