Canvas
Comments 28
+3
Спасибо за статью. Никак не доходили руки изучить, теперь надеюсь дойдут.
-1
Кругом этот GitHub…

Планируется ли сделать человеческий сайт для человеков а-ля jquery.com, где документация написана человеческим языком и рассчитана на широкий круг пользователей? Может я один такой тугой, но вот лично для меня порог вхождения на сам GitHub высок, потому как вижу я его впервые (ну ладно вру — второй раз в жизни).
+2
Планируется.
Но я вам всё-равно рекомендую изучить GitHub, не пожалеете ;)
+2
А что тут холиварить то? Что Git, что Hg — практически идентичны, разница в инфраструктуре и сообществе. Я раньше был на Google Code с Hg, потом перенес все на GitHub. Он и мощнее и практически все JS-прогеры хостятся именно там.
+1
Да я пошутил, что вы прям. Даже смайлик в конце специально добавил (:
Пользуюсь и тем и другим.
0
А есть режим автоокругления координат фигур, чтобы при его включении они точно попадали в пиксельный растр?
0
Да, дело там сложнее, чем кажется на первый взгляд.

Во-первых, нужен глобальный триггер и некий локальный параметр для отдельного вызова.
Во-вторых, выбор способа округления — только вниз, только вверх, к ближайшему.
В-третьих, (в идеале) хочется развить это и сделать ещё выравнивание границ шейпов по аналогии с графическими программами (inside/center/outside). Опять-таки с глобальным параметром.

Чтобы можно было, скажем, в начале установить .snapToPixel = true, .borderAlignment = 'inside' — и гнать блоки конвейером :)
0
Угу, я приблизительно так и представлял, но за реализацию пока не брался. Хотя согласен — это очень интересная идея. Кажется, это необходимо добавить к контексту (по аналогии с fillRect и иже с ними):
context = canvas.getContext('2d-libcanvas');
context.save();
context.snapToPixel = true;
context.borderAligment = 'inside';
context.stroke( shape );
context.restore();


На самом деле передать параметры везде, куда необходимо — совсем не проблема. Я пока не совсем разобрался с деталями реализации. Необходимо будет написать хорошее приложение, где snapToPixel нужен, чтобы разобраться. Пока такие не встречались.

Если бы был желающий это сделать — я бы с удовольствием помог консультациями и кодом.
0
У меня бродят неопределенные мысли на эту тему, но я пока в JS вообще и Canvas в частности чувствую себя не слишком свободно. Учусь.

Кстати, про округления: нужно даже не три, а пять режимов — директивно к каждому из 4-х углов холста и к ближайшему пикселу.

Ещё непонятно, как рисовать границу, скажем, при выравнивании 'center' и толщине линии 3px… Когда ровно пополам не делится. Действительно, много тонких моментов.
0
Ну тогда тренируйтесь, можете очень быстро нагнать свой уровень! Можете обращаться.
+1
Замечательно, спасибо, давно присматриваюсь к вашему фреймворку, но останавливала документация только на русском и зависимость от AtomJs.

Посмотрел на AtomJs, не совсем понял, он IE не поддерживает (хотя бы 8+)?
+1
А в чём недостатки (для вас) только русской документации и уж тем более зависимости от Атома?
AtomJS и LibCanvas поддерживают IE начиная с девятой версии.
+1
Для меня проблем с русским нет, да и исходники на гитхабе доступны, спасибо вам. Западные товарищи нервничают, что это «is too complex in maintainable».

IE начиная с девятой версии — отлично!

Да я понимаю, что мы (программисты) зажрались и требуем документации и тестов от автора.

У меня есть некоторое свободное время по вечерам в ближайшее время, я могу попробовать помочь вам с документацией на русском и английском.
+1
На самом деле я таки да — обязан предоставить документацию и тесты. Просто честно — не успеваю. К примеру, AtomJS у меня покрыт тестами практически полностью (плохо покрыт DOM) — 255 тестов. Есть исходники в репозитории и можно посмотреть у меня на страницах. Доку на LibCanvas решил писать на русском потому что это быстрее, качественнее и всё-равно надо.
Однозначно жду коммитов, но, главное, чтобы было кому её поддерживать)
+1
Постараюсь сделать пул реквест на следующей неделе.

Если вам не сложно, заведите пожалуйста теги в репозитории. Это сильно облегчит жизнь при написании документации, плюс очень удобно состовлять чейнжлоги, а так же это заставляет более вдумчиво именовать коммиты :)
0
Я как-то с Гитом ещё не очень разобрался.

Вы предлагаете использовать теги только для версий? Или теги используются для деления на виды коммитов — «документация», «багФикс», «новаяФича»?
0
Вы предлагаете использовать теги только для версий?


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

На некоторых проектах используют текстовые метки в имени коммита для обозначения его типа, к примеру

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"
0
А как использовать эти теги на практике? Как пометить коммит тегом?

То есть, если я пометил один коммит версией «1.2.3», то все следующие коммиты, пока не будет ещё одного тега будут версии «1.2.3»?
+2
Я наверное путано расказал, изивините.

К примеру у вас есть три коммита в репозитории: С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, которая помечена тегом. С помощью вышеописанных команд можно быстро посмотреть, что изменилось в коде между версиями и внести изменения в док.

0
Хм. Спасибо. Имхо, лучше было бы наоборот, но стандарт есть стандарт)
Спасибо за объяснение. А вы хорошо разбираетесь в Гите? Можно задавать вопросы в Джаббере?
0
Если вы имели ввиду, что в репозитории будут болтаться «лишние» коммиты, а версия будет старой, то это не проблема. В мастере так и бывает обычно, а для мажорных, к примеру версий, создаются отдельные ветки.
Only those users with full accounts are able to leave comments.  , please.