Сервис на самом деле не про графики, а про стилизацию в жанре «нарисовано от руки». Исходными изображениями могут быть иконки, векторные иллюстрации и, как частный случай, диаграммы и графики.
Да, я понимаю. Мой комментарий относится исключительно к примерам применения. И мне кажется, это как раз укладывается в рамки вопроса о потребности )
пример2
Самый красивый, ИМХО.
Кстати, глядя на него, я почему-то подумал об анимации. (В духе советской мультипликации, если помните такую. Когда выводился заголовок и висел какое-то время, постоянно изменяясь. Правда, тогда это был, скорее, нежелательный эффект, обусловленный несовершенством технологии). В общем, если исходная библиотека поддерживает разные варианты штриховки такого типа заливки (как у заголовка «Аналитика...»), из них можно было бы наделать кадров. Возможно, я ошибаюсь, но способ превратить одиночную картинку в анимацию может быть востребован при подготовке рекламных баннеров. (С этой же целью, например, берут картинку и зумят туда-сюда — надеюсь, понятно, о чём речь).
Выглядит круто, но такие бар-диаграммы (ни одну!) я бы точно показывать своим слушателям не стал. Во-первых, глаза же сломать можно, пытаясь понять, кто кого насколько, во-вторых, зачем своими руками создавать ощущение «небрежности», «неточности», «размытости» у людей, у которых уже чуть ли не генетическая память о скандалах с этими барами (например, история с nVidia про вырезание конца и увеличение его в 10 раз).
Диаграмма со стрелками (самая первая) крутая, я бы, возможно, где-нибудь применил подобное, но не знаю, где, а UML в качестве примера меня мало вдохновляет )
Кто вы, люди, держащие панель задач снизу (сверху)?
Мы же говорим про полноценные кнопки на таскбаре с нескрытыми 'labels'?
Чтобы текст был читаем (а не… [выглядел вот так вот]), надо задать ширину хотя бы в 120 пикселей. Вот я только что посмотрел, как текущая конфигурация окон (7 окон браузера, 3 Explorer'а, пара блокнотов, Фотошоп и Студия… 14 окон всего), которая использует 100% горизонтального таскбара, выглядит справа. Оказалось, что так больше половины площади таскбара ничем не занято. На FHD-мониторе это >120*1080*0.5=64800 пикселей чистого убытка.
Вдобавок, я пользуюсь панелью Quick Launch. На вертикальном таскбаре кнопки не отцентрированы по ширине, а прижаты к левому краю. Это само по себе уродство, но хуже того, первая иконка рисуется буквально с первого-второго пикселя ширины. (Left margin у неё нулевой, короче).
Слева и справа от кнопки «Пуск» немаленькие пустые квадраты.
Если причалить таскбар справа, больше нельзя будет сделать одно короткое резкое движение мышью на северо-восток и кликнуть, чтобы закрыть окно.
Если причалить таскбар слева, кнопка «Пуск» займёт самое дорогое место экрана (по любым учебникам UI цена линейно-градиентно снижается с северо-запада на юго-восток прям как на карте Москвы).
Да, есть такое слово. Не уверен, что ваш и мой комментарий релевантны теме, но раз уж речь зашла… В биографической книге Masters of DooM, рассказывается как id Software переехали в Техас, поближе к своим издателям Apogee (позже её переименовали в 3DRealms, а вообще оттуда пошло потом выражение «Техасская игровая мафия»). Джон Ромеро посмотрел, на чём ездят Миллер с компаньоном и грустно сказал Кармаку (цитата по памяти): They are driving badass cars, and we're driving ass cars. It's time to kick ass! (после чего они пошли покупать свои первые Феррари).
Представляю, идёшь себе в пятницу вечером из бара домой. К тебе подбегают и говорят: «Ну-ка, скажи „Шла Саша по шоссе дороге и сосала сушку“». А ты такой: «И-ик… А-а-а, расстреливайте!»
Спасибо, но я мало что понял. Нужно свою АТС? Или взять чужую в аренду?
На всякий случай скажу, что цели представляться кем-то другим у меня нет, зато есть цель понять, насколько можно доверять журналистским расследованиям, включающим в себя эту технологию (ЕВПОЧЯ).
В Quake3 от C++ только классы но хуже он не стал. Уже сто раз видел проЭкты с невероятными мета гуру C++ которые через пол-года убегают оставляя после себя «чукча писатель не читатель».
Мне кажется, Q3 это одновременно очень плохой и очень хороший пример.
Очень плохой он потому, что при мысли об исходниках Q3 на ум в первую очередь приходит Fast inverse square root — ведь именно там же он впервые широко засветился. Такие вещи Кармак и компания делали явно не от хорошей жизни — компьютеры в те времена были намного слабее нынешних. И, следовательно, даже тот копеечный оверхед, который даёт, например, стандартная библиотека, мог играть для них принципиальную роль. Даже сильно позже, намного ближе к нашим дням, я обращал внимание, что писатели движков косо поглядывают на нововведения именно из-за привычки считать такты. Что поделать — эти люди сами выбрали мученическую стезю )) Но для нас, для большинства, эта разница не должна играть большую роль, а значит оглядываться на игропром, тем более такой старый, не очень продуктивно. Жизнь заставит — и на ассемблере будешь программировать!
А хорошим его делает… скажем вежливо, напоминание, что ЯП, вообще-то — инструмент для создания практически полезных программ. Таких как Quake 3, да. Или ядро Линукса. Кто может — тот делает, а кто не может — учит нас «совершенному коду» и «модерновому сиплюсплюсу». Я помню, как в своё время прочитал широко известную в узких кругах книгу Джеффа Элджера. Такую, с чёрненькой обложкой. Вы должны помнить — умные указатели, гомоморфные иерархии, вот это всё. Конечно, ходил под впечатлением: какой вумный дядька! Такое тройное сальто с переворотом и поцелуем себя в задницу в верхней точке при прыжке через горящий обруч — это ж не каждый сделает! А сейчас я поискал 'jeff alger' и ничего толком не нашёл. Вики про него не знает. Что он вообще сделал-то? Книжку написал?
Но само по себе это ещё полбеды. Настоящая беда в том, что эти астронавты летают в настолько разреженных слоях атмосферы, что им оттуда нас, убогих, с нашими повседневными проблемами, очень плохо видно. Процитирую я основоположника, который поставил C++ на те рельсы, по которым он теперь и катится — Александра свет Александровича. Учёного, как рекомендует его Википедия.
Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. То есть в математике вы заканчиваете аксиомой. То же самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы.
Вот так! Теперь вы знаете, почему горячо рекомендуемый в статье std::string ничего не умеет, а алгоритмы навешиваются на него как амбарный замок. Александра Александровича нимало не смущает тот факт, что типичный программист вообще редко пишет алгоритмы (в том смысле, который вкладывает он в это слово) — типичный программист ими в основном пользуется. И что старый, недобрый, пропахший нафталином CString действительно облегчал программисту жизнь при переходе от char*: он, во-первых, худо-бедно, реализовывал абстракцию «строка». Можно было не думать, Юникод там внутри или ещё что-то. (Да, макросы _UNICODE — это, наверно, не очень хорошо. Но это решение! А наличие ДВУХ базовых типов строк — это просто отказ от всяких попыток решить проблему). Во-вторых, он умел весь джентльменский набор по работе с текстом — поиски с обоих концов, замены, капитализации и прочее — прямо внутри класса. Может быть, кто-то думает, что мы таскаем классы просто по факту наличия? Нет. Класс должен приносить пользу. И, в-третьих, что немаловажно, создатели подумали о совместимости с Си. То есть, о том факте, что как на сиплюсплюсе не пиши, а рано или поздно придётся вызывать WinAPI (или API другой ОС). И заложили в него operator LPCTSTR(). Вызов `::CreateWindow(strClassName, strWindowName...` однозначно считывается как `:: СоздатьОкно(оконныйКласс, заголовокОкна...` Напротив, степановское детище заставляет писать так: `::CreateWindow(strClassName.c_str(), strWindowName.c_str()...`. Что в переводе на русский означает: `:: СоздатьОкно(контейнерСодержащийОконныйКласс.извлекаем_строку(), контейнерСодержащийЗаголовокОкна.извлекаем_строку()...`. Конечно, это сделано в интересах трудящихся. Нас же хлебом не корми, дай лишний метод вызвать руками, чтобы напомнить себе, что мы тут не в бирюльки играем, а пишем на взрослом языке. Народ и начал разбегаться, как только стало куда — Java, C#, you name it. Осталась кучка самых стойких, из которых половина просто привязана к сишным API, и воленс-неволенс вынуждена досмотреть этот цирк до конца — так и до тех доковырялись. Плохо, дескать, летаем. Низэнько.
И, кстати, насколько позволяет вспомнить мой склероз, в исходниках, которые генерировала VC6, комбинировались оба подхода: в хедер в начале записывалась прагма, а остальная часть включалась в #ifdef-«скобки» (извините, что я использую такое просторечное выражение вместо гугловского «макроопределение защиты» 8-P).
Не используйте венгерскую нотацию (например, именование целочисленной переменной как iNum)
Это НЕ венгерская нотация, а то, что с ней стало, когда она попала в руки профанов. Изначально Чарльз Симоньи предлагал использовать такие префиксы, как rw для записей (rows), например, rwPosition, us (unsafe string) для строк, нуждающихся в санации (на предмет инъекций и т.п.), d (delta) для разницы зачений, например, dY. Большинство префиксов были семантические и никакой IDE никогда не смог бы верно указать эту семантику при наведении курсора. (Как любят аргументировать противники венгерки). Ну, разве что такие префиксы как pX говорят о типе, но тип указателя — сам по себе семантический.
Потом всё это дело опопсело и упростилось, и действительно стало дублировать информацию о типе, после чего венгерка разделилась на т.н. прикладную и системную. Последнюю иначе как профанацией идеи назвать трудно.
Что касается первой, она, насколько можно судить, во многих местах жива и поныне. Просто теперь префикс принято записывать целиком, не экономя ширину экрана: deltaY и т.д.
Составителям правил оформления, тем более из Гугл, знать такие тонкости, по идее, не помешало бы.
Да, я понимаю. Мой комментарий относится исключительно к примерам применения. И мне кажется, это как раз укладывается в рамки вопроса о потребности )
Самый красивый, ИМХО.
Кстати, глядя на него, я почему-то подумал об анимации. (В духе советской мультипликации, если помните такую. Когда выводился заголовок и висел какое-то время, постоянно изменяясь. Правда, тогда это был, скорее, нежелательный эффект, обусловленный несовершенством технологии). В общем, если исходная библиотека поддерживает разные варианты штриховки такого типа заливки (как у заголовка «Аналитика...»), из них можно было бы наделать кадров. Возможно, я ошибаюсь, но способ превратить одиночную картинку в анимацию может быть востребован при подготовке рекламных баннеров. (С этой же целью, например, берут картинку и зумят туда-сюда — надеюсь, понятно, о чём речь).
То же самое касается приличных медиаплееров. Про pdf-ридеры, правда, не могу ничего сказать — открываю в браузере.
Короче, храни Господь от таких «помощников», а с врагами я сам как-нибудь справлюсь.
В общем, опять «по просьбам трудящихся».
Диаграмма со стрелками (самая первая) крутая, я бы, возможно, где-нибудь применил подобное, но не знаю, где, а UML в качестве примера меня мало вдохновляет )
Мы же говорим про полноценные кнопки на таскбаре с нескрытыми 'labels'?
Чтобы текст был читаем (а не… [выглядел вот так вот]), надо задать ширину хотя бы в 120 пикселей. Вот я только что посмотрел, как текущая конфигурация окон (7 окон браузера, 3 Explorer'а, пара блокнотов, Фотошоп и Студия… 14 окон всего), которая использует 100% горизонтального таскбара, выглядит справа. Оказалось, что так больше половины площади таскбара ничем не занято. На FHD-мониторе это >120*1080*0.5=64800 пикселей чистого убытка.
Вдобавок, я пользуюсь панелью Quick Launch. На вертикальном таскбаре кнопки не отцентрированы по ширине, а прижаты к левому краю. Это само по себе уродство, но хуже того, первая иконка рисуется буквально с первого-второго пикселя ширины. (Left margin у неё нулевой, короче).
Слева и справа от кнопки «Пуск» немаленькие пустые квадраты.
Если причалить таскбар справа, больше нельзя будет сделать одно короткое резкое движение мышью на северо-восток и кликнуть, чтобы закрыть окно.
Если причалить таскбар слева, кнопка «Пуск» займёт самое дорогое место экрана (по любым учебникам UI цена линейно-градиентно снижается с северо-запада на юго-восток
прям как на карте Москвы).По этой причине я всю жизнь путаю bum и bun. (Кстати, коннотация «булки», похоже, международна: см. 'buns', MW n. 3).
шосседороге и сосала сушку“». А ты такой: «И-ик… А-а-а, расстреливайте!»На всякий случай скажу, что цели представляться кем-то другим у меня нет, зато есть цель понять, насколько можно доверять журналистским расследованиям, включающим в себя эту технологию (ЕВПОЧЯ).
Я, наверно, сильно отстал от жизни, но как это в принципе делается?
Мне кажется, Q3 это одновременно очень плохой и очень хороший пример.
Очень плохой он потому, что при мысли об исходниках Q3 на ум в первую очередь приходит Fast inverse square root — ведь именно там же он впервые широко засветился. Такие вещи Кармак и компания делали явно не от хорошей жизни — компьютеры в те времена были намного слабее нынешних. И, следовательно, даже тот копеечный оверхед, который даёт, например, стандартная библиотека, мог играть для них принципиальную роль. Даже сильно позже, намного ближе к нашим дням, я обращал внимание, что писатели движков косо поглядывают на нововведения именно из-за привычки считать такты. Что поделать — эти люди сами выбрали мученическую стезю )) Но для нас, для большинства, эта разница не должна играть большую роль, а значит оглядываться на игропром, тем более такой старый, не очень продуктивно. Жизнь заставит — и на ассемблере будешь программировать!
А хорошим его делает… скажем вежливо, напоминание, что ЯП, вообще-то — инструмент для создания практически полезных программ. Таких как Quake 3, да. Или ядро Линукса. Кто может — тот делает, а кто не может — учит нас «совершенному коду» и «модерновому сиплюсплюсу». Я помню, как в своё время прочитал широко известную в узких кругах книгу Джеффа Элджера. Такую, с чёрненькой обложкой. Вы должны помнить — умные указатели, гомоморфные иерархии, вот это всё. Конечно, ходил под впечатлением: какой вумный дядька! Такое тройное сальто с переворотом и поцелуем себя в задницу в верхней точке при прыжке через горящий обруч — это ж не каждый сделает! А сейчас я поискал 'jeff alger' и ничего толком не нашёл. Вики про него не знает. Что он вообще сделал-то? Книжку написал?
Но само по себе это ещё полбеды. Настоящая беда в том, что эти астронавты летают в настолько разреженных слоях атмосферы, что им оттуда нас, убогих, с нашими повседневными проблемами, очень плохо видно. Процитирую я основоположника, который поставил C++ на те рельсы, по которым он теперь и катится — Александра свет Александровича. Учёного, как рекомендует его Википедия.
Вот так! Теперь вы знаете, почему горячо рекомендуемый в статье std::string ничего не умеет, а алгоритмы навешиваются на него как амбарный замок. Александра Александровича нимало не смущает тот факт, что типичный программист вообще редко пишет алгоритмы (в том смысле, который вкладывает он в это слово) — типичный программист ими в основном пользуется. И что старый, недобрый, пропахший нафталином CString действительно облегчал программисту жизнь при переходе от char*: он, во-первых, худо-бедно, реализовывал абстракцию «строка». Можно было не думать, Юникод там внутри или ещё что-то. (Да, макросы _UNICODE — это, наверно, не очень хорошо. Но это решение! А наличие ДВУХ базовых типов строк — это просто отказ от всяких попыток решить проблему). Во-вторых, он умел весь джентльменский набор по работе с текстом — поиски с обоих концов, замены, капитализации и прочее — прямо внутри класса. Может быть, кто-то думает, что мы таскаем классы просто по факту наличия? Нет. Класс должен приносить пользу. И, в-третьих, что немаловажно, создатели подумали о совместимости с Си. То есть, о том факте, что как на сиплюсплюсе не пиши, а рано или поздно придётся вызывать WinAPI (или API другой ОС). И заложили в него operator LPCTSTR(). Вызов `::CreateWindow(strClassName, strWindowName...` однозначно считывается как `:: СоздатьОкно(оконныйКласс, заголовокОкна...` Напротив, степановское детище заставляет писать так: `::CreateWindow(strClassName.c_str(), strWindowName.c_str()...`. Что в переводе на русский означает: `:: СоздатьОкно(контейнерСодержащийОконныйКласс.извлекаем_строку(), контейнерСодержащийЗаголовокОкна.извлекаем_строку()...`. Конечно, это сделано в интересах трудящихся. Нас же хлебом не корми, дай лишний метод вызвать руками, чтобы напомнить себе, что мы тут не в бирюльки играем, а пишем на взрослом языке. Народ и начал разбегаться, как только стало куда — Java, C#, you name it. Осталась кучка самых стойких, из которых половина просто привязана к сишным API, и воленс-неволенс вынуждена досмотреть этот цирк до конца — так и до тех доковырялись. Плохо, дескать, летаем. Низэнько.
Не поверим. Вы придумали это сидя за клавиатурой!
Это НЕ венгерская нотация, а то, что с ней стало, когда она попала в руки профанов. Изначально Чарльз Симоньи предлагал использовать такие префиксы, как rw для записей (rows), например, rwPosition, us (unsafe string) для строк, нуждающихся в санации (на предмет инъекций и т.п.), d (delta) для разницы зачений, например, dY. Большинство префиксов были семантические и никакой IDE никогда не смог бы верно указать эту семантику при наведении курсора. (Как любят аргументировать противники венгерки). Ну, разве что такие префиксы как pX говорят о типе, но тип указателя — сам по себе семантический.
Потом всё это дело опопсело и упростилось, и действительно стало дублировать информацию о типе, после чего венгерка разделилась на т.н. прикладную и системную. Последнюю иначе как профанацией идеи назвать трудно.
Что касается первой, она, насколько можно судить, во многих местах жива и поныне. Просто теперь префикс принято записывать целиком, не экономя ширину экрана: deltaY и т.д.
Составителям правил оформления, тем более из Гугл, знать такие тонкости, по идее, не помешало бы.