Не понятен смысл «на чистом js», если сразу говорите о hammer.js. jQuery тоже написан на чистом js в таком случае. И второе имхо — писать события пальцев можно и без библиотек, там ничего сложного нет для подобных задач. Ещё один момент заметил — таймаут, равный длительности css-анимации. Повсеместное заблуждение, что они равны. На самом деле закончить могут совсем в разное время, не смотря на одинаковые числа.
Все диснеевские анимации, и прочих контор, неестественны по сей день. Что-то в них может и улучшается, но не сильно. Я могу двигаться как их персонажи, с такими же глупыми изингами в начале и конце движений (неверное ускорение), или вскидывать брови и губы как будто у них огромная инерция, или делать доводку движений, как будто у них есть конечная позиция. Думаю, что им стоит отказаться вообще от всего, что они выдумали, и создать теорию заново, потому что техника уже должна позволять такие вычисления.
В этой статье вы делаете крупную физику тел, нюансов например лица и эмоций тут нет. Но и у вас есть всё те же проблемы. Например в конце есть доводка руки до конечного положения. Почему у персонажа не случаются рандомные отхождения от плана? тики всякие, зажимы мышц, подскоки позвоночника, мотание головой, собственная воля и индивидуальность, и прочее? Не соглашусь с теми, кто скажет, что это дорого в плане ресурсов или времени. Рандом почти бесплатный. И не надо бояться его. Персонажи должны делать «не пойми что», а не только «по физике». И должны уметь прерывать или переназначать любые силы за мгновение.
Может меня заминусят и наверное для хабра такой блоговый формат не катит, но мне понравилось, что статья написана именно так. Напоминает времена, когда сайты были душевными, когда ощущался мир человека. Сейчас у статей везде только поток данных, бывает приправленный выверенными шутками. А здесь рассказ человека, как он ковырялся во всём этом. Приятно.
В самих классах нет ничего плохого, они используются повсеместно. И они уже есть в js и выдумывать их заново не нужно. Просто используйте их, в них вопросы о которых вы пишете давно решены.
Слишком сложно вылавливать из этого потока какой-то смысл. Попробуйте писать в обратном порядке - сначала тезис, а потом по порядку его разворачивать, и перед публикацией менять порядок. Может тогда эта сумбурность уйдёт сама собой. И для программистов такие "равно" и мышление "классами" - это скорее показатель заигрывания "типа_в_теме", странности или незрелости, потому что эти классы и так уже в печёнке каждый день. Выбросьте из текста всё "программистское" и оставьте обычное. И можно писать в 10 раз короче, без дословных подробностей мысленного потока. Только не делайте вывод что у вас нет опыта, вас не оценили, не поняли, захейтели и прочее - просто вы ещё не набили опыт письменного изложения. Позже будет лучше.
Алгоритмы ютуба абсолютно убогие, об этом говорят все мои знакомые. Держат в одном информационном пузыре, из которого не возможно выбраться. Я на главной странице постоянно почти у всех роликов ставлю что они мне не интересны. Так в основном теперь там только пара роликов или вообще пустая страница. То есть за пределами какого-то информационного пузыря алгоритм вообще не способен даже рандомный ролик показать, то есть ему важнее держать юзера в пузыре. И ни дай бог что-то лайкнуть, он думает что я теперь молюсь на это круглосуточно. Проставление "не интересует" и "не рекомендовать канал" не работают в полной мере. Потому что некоторые ролики я проставлял уже несколько раз. Самый простой способ борьбы с этим в фаерфоксе - заходить под другим контейнером (стандартная фича браузера в пару кликов).
Перегрузка - прекрасный инструмент. В языках, где перегрузка делается манглированием, ситуация получше, там функций несколько с одинаковым именем, то есть несколько реализаций. Это позволяет не выдумывать разные имена при отличии аргументов, что нужно довольно часто. Например метод суммирования логично назвать Sum, а не SumInt, SumFloat, SumDouble, SumShort, SumLong, SumUint, SumUlong, ... А потом DivideInt, DivideFloat, DivideDouble, ... и всё прочее по списку.
А когда вот так нужно сначала написать сигнатуры методов и потом слепить реализацию в одну на ифах - это какая-то жесть. Тут нет ни выигрыша в понятности кода (сначала сигнатуры потом огород ифов и борьба с аргументами), ни выигрыша в производительности (компиляция большой функции и разбор аргументов ифами, вместо исполнения только нужной отдельной функции), ни простого добавления очередной функции (придётся переписать реализацию). Всё это есть при "нормальной" перегрузке.
Ещё пример где перегрузка нужна - это конструктор. Например когда какой-то метод создаёт объект, зная только его класс. Такой метод не знает с какими аргументами создать этот объект, поэтому создаёт его дефолтным образом - без аргументов, просто new Object() или CreateInstance( type ). А если требуется создавать такой объект "вручную", то для этого пишется перегрузка с нужными аргументами.
Для JS и отчасти TS это менее полезно потому, что в них функция принимает на вход что угодно и так. А в статически типизированных языках функция не может принимать что угодно на вход, ей нужно скомпилироваться во что-то конкретное.
Отличная библиотека и очень нужная. Почему-то для C# в нашем веку простой png и jpg ещё может являться проблемой. Я искал то, что можно просто взять и использовать, и не тащить какие-то комбайны, и ваша библиотека вне конкуренции.
Хорошо выразили. Когда-то именно так у меня выключился диалог. Остались только "предпосылки мышления" без слов. Потом это стало простым навыком в любое время. Только такому мышлению присуща скорее нейросетевая модель (граф), нежели конкретные решения (односвязный список). Для конкретных решений нужно проходить пайплайн обычного ума, иначе будет всё прекрасно, но хаотично-параллельно. Сделать чай например можно без единого слова. Но в этом чаю может быть кофе вместо чая, или не будет сахара. Потому что нет страха ошибиться и последовательность действий менее корректируется. Так что я бы не стал прорабатывать проект детально таким способом :) .
И всё же есть различные уровни этого мышления, так сказать. Отказ от произнесения слов внутри - это "меньшая остановка ума", чем например оставить только созерцание. Можно сделать так, что мир перестанет складываться в какую-то картину, будут разрозненные проявления, без реакций на них. И можно "остановить" (отказаться) настолько, что будет провал вроде потери бытия. То есть теряется любой бит какой-либо информации. Это как провал в памяти, после которого будет обратный процесс загрузки первых проявлений и затем индивидуальности. То есть мозг может "останавливаться" до полной потери индивидуального аспекта. Он сохраняет какой-то стейт, но не в контексте индивидуальности. И по сути это не магический навык, а что-то вроде обесточивания нерва или пережимания артерии. Представьте, что из мозга посредством операции выдернули отдел, отвечающий за считание себя собой или считающий себя точкой восприятия, обесточили этот выдернутый отдел, подождали пару секунд, потом запитали и воткнули обратно. Это если смотреть на процесс снаружи.
Это даёт различные более фундаментальные понимания. В основном они происходят на контрасте проходимых состояний-этапов инициализации или распада сознания.
Например здесь в комментариях видел различие на внутренний и внешний мир. Но после того как любой мир схлопывается сознательным желанием, интерпретируется как угодно, или сформирован только на 10%, он уже не может так делиться на два полюса внутренний / внешний (между которыми нет вразумительной разницы).
Или например может теряться время по желанию. Без всяких рассуждений на эту тему и философий. Потому что для времени требуется, чтобы мозг держал указатель на прошлое, предвкушал будущее, и инкапсулировал это в иллюзию длительности. Наподобие трёхмерной модели, только с особым оттенком-ароматом-камертоном, который мозг научился слушать иначе и считать временем. Если какой-то аспект этого нарушить или перестать поддерживать, то останется только безвременное сейчас. Я например включаю время только в крайне редких ситуациях, например когда нужно что-то поставить в календарь, или чтобы понять смысл сказанных кем-то слов о времени.
Так можно играться с любыми деталями сознания. Это может иметь как позитивные, так и негативные физические и психиатрические последствия.
В случае с TS так и получается. Пока пишешь на нём, всё подсвечивается и более-менее верно. А потом типы просто выбрасываются. В рантайме на вход функции может прилететь что-то неверное и пройти в глубины, и это никак не будет предотвращено, если не писать везде рантаймные проверки. Надёжность только во время разработки, но не во время исполнения. В других языках типа C++ или C# то, что типизировано, будет таковым и в рантайме, и дополнительных проверок не нужно. Плюс к этому, TS имеет типы, несовместимые с JS, то есть попросту неверные, но при этом преобразуется в JS в итоге. Например типа void в JS нет. И функция, возвратившая промис, в TS может считаться не возвратившей ничего, и тогда понять это и перехватить исключение промиса не возможно, что приведёт к краху процесса.
Вебовские и журнальные законы в играх могут иметь применение в похожих интерфейсах, но в целом у игр больше свободы. В играх очень яркие надписи на полностью чёрном фоне для акцентов - это вполне хорошо. И не читаемые надписи тоже могут играть позитивную роль, например подчёркивать темноту комнаты. При проблемах со зрением можно менять гамму монитора или настройки игры. Человек с проблемами будет испытывать их во всех играх, и скорее всего имеет уже какие-то глобальные настройки для этого. Я когда-то был приверженцем приятных сочетаний и паст[э]льных тонов, но это оказалось скучно для игр. Получается правильно и приятно, но не интересно.
В начале статьи и в её тегах идёт речь о разработке тёмного интерфейса игры. Далее статья об удобстве чтения текстов. У вас игра про чтение текста? В играх совсем другая задача - впечатления.
Про текстуры я имел в виду чтобы в шейдере для одного спрайта было сразу две текстуры, то есть чтобы у метода Draw было два первых аргумента текстуры. Одна для цвета, другая для свечения. И там это нельзя сделать, потому что в вершинах передаётся только одна текстура, и прочие данные в вершинах в шейдер тоже передать нельзя, например второй цвет.
На Vulkan писать сложнее, чем на OpenGL. И C# не совсем предназначен для таких целей, там приходится со всякими указателями работать и выделять память без сборщика мусора. Но в итоге в моём случае всё это стоит усилий, потому что удаётся сделать что хочешь. Готовый движок не подходит, потому что есть особенности физики, генерация мира как в террарии, но многослойная, и движки обычно с 2D плохо работают, или игрушечные весьма.
Я это пишу в тему про моногейм просто чтобы сказать мысль, что можно опуститься на более низкий уровень, чем сражаться с неудобствами и ограничениями. Что есть в принципе в любой библиотеке.
Пилил я 2D пиксельную игру на моногейме, в целом поначалу устраивало, для старта вполне годная штука. Но как только появились не примитивные требования, моногейм стал проблемой. Например потребовалось у спрайта две текстуры вместо одной, и такой возможности нет. Для не квадратных фигур пришлось писать свой код и вызывать какие-то внутренние методы, потому что моногейм рисует только прямоугольники. Не хватило также умных сортировок спрайтов, а не только мгновенной или по текстуре. И не понравилась постоянная возня со утилитами для ресурсов и какие-то промежуточные форматы для всего. А сейчас они уже месяц не могут выкатить минорную версию, где обновлена версия сишарпа, без новых фич, которая якобы готова. И OpenGL уже устарел, а Vulkan-а в моногейме нет. В общем плюнул я на это всё, и делаю на вулкане теперь. Сложно и времени на всё много уходит, но доступно всё API, а не урезанная абстракция.
Можно натренировать себя ощущать шесть пальцев вместо пяти. Главное убрать в сознании любые предпосылки вроде "не", "да ну", "непривычно" и прочее, которые не дают сменить прошлый автоматизм. Тогда можно будет перебирать по столу шестью пальцами, и мозг даже не будет возражать, и будет приходить правдоподобное ощущение от пальцев, и даже будете сбиваться при их счёте когда смотрите на них. Не думаю, что у всех получится, зависит от навыков, которые в повседневности не особо нужны, например навык обмана мозга, наблюдения за его процессами, воображение на грани проявления в субъективной реальности, и так далее. В осознанных снах можно добиться любых конечностей. Мозг точно умеет всё это.
Откуда вы знаете за другого пользователя если не видите конкретного человека? Может и как старая бабка прицеливаются. Бывает что нужно на автомате что-то делать типа скролла, а глаза и мозг уже мутные под конец дня и любой обрыв автоматизма приводит к усилиям и негативной реакции. Представьте, бывают другие люди не такие как вы и не в таких идеальных состояниях и условиях.
А мне полосы в Windows нравятся больше всего. По ним можно попасть без прицеливания и без ожидания увеличения размера. Они состоят из пяти элементов с разной функцией, а не только из ползунка. И везде одинаковые. Если скролл меньше 5 миллиметров по ширине линейкой на экране, то это декорация, а не функциональный компонент. Потому что тогда нельзя переместить на них курсор и прокрутить без прицеливания и задержки для увеличения (лишнее прерывание намерения, как если бы все кнопки были сначала миллиметр в высоту). А самые плохие видел в убунту, где по умолчанию прокрутку не видно, и нужно догадаться и проскроллить мышкой, чтобы появился какой-то квадратик всегда одинакового размера, на который не всегда удобно попадать за пределами окна:
В этой статье вы делаете крупную физику тел, нюансов например лица и эмоций тут нет. Но и у вас есть всё те же проблемы. Например в конце есть доводка руки до конечного положения. Почему у персонажа не случаются рандомные отхождения от плана? тики всякие, зажимы мышц, подскоки позвоночника, мотание головой, собственная воля и индивидуальность, и прочее? Не соглашусь с теми, кто скажет, что это дорого в плане ресурсов или времени. Рандом почти бесплатный. И не надо бояться его. Персонажи должны делать «не пойми что», а не только «по физике». И должны уметь прерывать или переназначать любые силы за мгновение.
Может меня заминусят и наверное для хабра такой блоговый формат не катит, но мне понравилось, что статья написана именно так. Напоминает времена, когда сайты были душевными, когда ощущался мир человека. Сейчас у статей везде только поток данных, бывает приправленный выверенными шутками. А здесь рассказ человека, как он ковырялся во всём этом. Приятно.
В самих классах нет ничего плохого, они используются повсеместно. И они уже есть в js и выдумывать их заново не нужно. Просто используйте их, в них вопросы о которых вы пишете давно решены.
Чем это оправдано? У классов сейчас 96% поддержки.
Вы зачем-то так сконцентрировались на классах и их реализации, хотя это банальная вещь и не имеет отношения к библиотеке.
Слишком сложно вылавливать из этого потока какой-то смысл. Попробуйте писать в обратном порядке - сначала тезис, а потом по порядку его разворачивать, и перед публикацией менять порядок. Может тогда эта сумбурность уйдёт сама собой. И для программистов такие "равно" и мышление "классами" - это скорее показатель заигрывания "типа_в_теме", странности или незрелости, потому что эти классы и так уже в печёнке каждый день. Выбросьте из текста всё "программистское" и оставьте обычное. И можно писать в 10 раз короче, без дословных подробностей мысленного потока. Только не делайте вывод что у вас нет опыта, вас не оценили, не поняли, захейтели и прочее - просто вы ещё не набили опыт письменного изложения. Позже будет лучше.
Алгоритмы ютуба абсолютно убогие, об этом говорят все мои знакомые. Держат в одном информационном пузыре, из которого не возможно выбраться. Я на главной странице постоянно почти у всех роликов ставлю что они мне не интересны. Так в основном теперь там только пара роликов или вообще пустая страница. То есть за пределами какого-то информационного пузыря алгоритм вообще не способен даже рандомный ролик показать, то есть ему важнее держать юзера в пузыре. И ни дай бог что-то лайкнуть, он думает что я теперь молюсь на это круглосуточно. Проставление "не интересует" и "не рекомендовать канал" не работают в полной мере. Потому что некоторые ролики я проставлял уже несколько раз. Самый простой способ борьбы с этим в фаерфоксе - заходить под другим контейнером (стандартная фича браузера в пару кликов).
Перегрузка - прекрасный инструмент. В языках, где перегрузка делается манглированием, ситуация получше, там функций несколько с одинаковым именем, то есть несколько реализаций. Это позволяет не выдумывать разные имена при отличии аргументов, что нужно довольно часто. Например метод суммирования логично назвать Sum, а не SumInt, SumFloat, SumDouble, SumShort, SumLong, SumUint, SumUlong, ... А потом DivideInt, DivideFloat, DivideDouble, ... и всё прочее по списку.
А когда вот так нужно сначала написать сигнатуры методов и потом слепить реализацию в одну на ифах - это какая-то жесть. Тут нет ни выигрыша в понятности кода (сначала сигнатуры потом огород ифов и борьба с аргументами), ни выигрыша в производительности (компиляция большой функции и разбор аргументов ифами, вместо исполнения только нужной отдельной функции), ни простого добавления очередной функции (придётся переписать реализацию). Всё это есть при "нормальной" перегрузке.
Ещё пример где перегрузка нужна - это конструктор. Например когда какой-то метод создаёт объект, зная только его класс. Такой метод не знает с какими аргументами создать этот объект, поэтому создаёт его дефолтным образом - без аргументов, просто
new Object()илиCreateInstance( type ). А если требуется создавать такой объект "вручную", то для этого пишется перегрузка с нужными аргументами.Для JS и отчасти TS это менее полезно потому, что в них функция принимает на вход что угодно и так. А в статически типизированных языках функция не может принимать что угодно на вход, ей нужно скомпилироваться во что-то конкретное.
Отличная библиотека и очень нужная. Почему-то для C# в нашем веку простой png и jpg ещё может являться проблемой. Я искал то, что можно просто взять и использовать, и не тащить какие-то комбайны, и ваша библиотека вне конкуренции.
Хорошо выразили. Когда-то именно так у меня выключился диалог. Остались только "предпосылки мышления" без слов. Потом это стало простым навыком в любое время. Только такому мышлению присуща скорее нейросетевая модель (граф), нежели конкретные решения (односвязный список). Для конкретных решений нужно проходить пайплайн обычного ума, иначе будет всё прекрасно, но хаотично-параллельно. Сделать чай например можно без единого слова. Но в этом чаю может быть кофе вместо чая, или не будет сахара. Потому что нет страха ошибиться и последовательность действий менее корректируется. Так что я бы не стал прорабатывать проект детально таким способом :) .
И всё же есть различные уровни этого мышления, так сказать. Отказ от произнесения слов внутри - это "меньшая остановка ума", чем например оставить только созерцание. Можно сделать так, что мир перестанет складываться в какую-то картину, будут разрозненные проявления, без реакций на них. И можно "остановить" (отказаться) настолько, что будет провал вроде потери бытия. То есть теряется любой бит какой-либо информации. Это как провал в памяти, после которого будет обратный процесс загрузки первых проявлений и затем индивидуальности. То есть мозг может "останавливаться" до полной потери индивидуального аспекта. Он сохраняет какой-то стейт, но не в контексте индивидуальности. И по сути это не магический навык, а что-то вроде обесточивания нерва или пережимания артерии. Представьте, что из мозга посредством операции выдернули отдел, отвечающий за считание себя собой или считающий себя точкой восприятия, обесточили этот выдернутый отдел, подождали пару секунд, потом запитали и воткнули обратно. Это если смотреть на процесс снаружи.
Это даёт различные более фундаментальные понимания. В основном они происходят на контрасте проходимых состояний-этапов инициализации или распада сознания.
Например здесь в комментариях видел различие на внутренний и внешний мир. Но после того как любой мир схлопывается сознательным желанием, интерпретируется как угодно, или сформирован только на 10%, он уже не может так делиться на два полюса внутренний / внешний (между которыми нет вразумительной разницы).
Или например может теряться время по желанию. Без всяких рассуждений на эту тему и философий. Потому что для времени требуется, чтобы мозг держал указатель на прошлое, предвкушал будущее, и инкапсулировал это в иллюзию длительности. Наподобие трёхмерной модели, только с особым оттенком-ароматом-камертоном, который мозг научился слушать иначе и считать временем. Если какой-то аспект этого нарушить или перестать поддерживать, то останется только безвременное сейчас. Я например включаю время только в крайне редких ситуациях, например когда нужно что-то поставить в календарь, или чтобы понять смысл сказанных кем-то слов о времени.
Так можно играться с любыми деталями сознания. Это может иметь как позитивные, так и негативные физические и психиатрические последствия.
Да, идеальных альтернатив пока нет. Не пробовал.
В случае с TS так и получается. Пока пишешь на нём, всё подсвечивается и более-менее верно. А потом типы просто выбрасываются. В рантайме на вход функции может прилететь что-то неверное и пройти в глубины, и это никак не будет предотвращено, если не писать везде рантаймные проверки. Надёжность только во время разработки, но не во время исполнения. В других языках типа C++ или C# то, что типизировано, будет таковым и в рантайме, и дополнительных проверок не нужно. Плюс к этому, TS имеет типы, несовместимые с JS, то есть попросту неверные, но при этом преобразуется в JS в итоге. Например типа void в JS нет. И функция, возвратившая промис, в TS может считаться не возвратившей ничего, и тогда понять это и перехватить исключение промиса не возможно, что приведёт к краху процесса.
Вебовские и журнальные законы в играх могут иметь применение в похожих интерфейсах, но в целом у игр больше свободы. В играх очень яркие надписи на полностью чёрном фоне для акцентов - это вполне хорошо. И не читаемые надписи тоже могут играть позитивную роль, например подчёркивать темноту комнаты. При проблемах со зрением можно менять гамму монитора или настройки игры. Человек с проблемами будет испытывать их во всех играх, и скорее всего имеет уже какие-то глобальные настройки для этого. Я когда-то был приверженцем приятных сочетаний и паст[э]льных тонов, но это оказалось скучно для игр. Получается правильно и приятно, но не интересно.
В начале статьи и в её тегах идёт речь о разработке тёмного интерфейса игры. Далее статья об удобстве чтения текстов. У вас игра про чтение текста? В играх совсем другая задача - впечатления.
Про текстуры я имел в виду чтобы в шейдере для одного спрайта было сразу две текстуры, то есть чтобы у метода Draw было два первых аргумента текстуры. Одна для цвета, другая для свечения. И там это нельзя сделать, потому что в вершинах передаётся только одна текстура, и прочие данные в вершинах в шейдер тоже передать нельзя, например второй цвет.
На Vulkan писать сложнее, чем на OpenGL. И C# не совсем предназначен для таких целей, там приходится со всякими указателями работать и выделять память без сборщика мусора. Но в итоге в моём случае всё это стоит усилий, потому что удаётся сделать что хочешь. Готовый движок не подходит, потому что есть особенности физики, генерация мира как в террарии, но многослойная, и движки обычно с 2D плохо работают, или игрушечные весьма.
Я это пишу в тему про моногейм просто чтобы сказать мысль, что можно опуститься на более низкий уровень, чем сражаться с неудобствами и ограничениями. Что есть в принципе в любой библиотеке.
Пилил я 2D пиксельную игру на моногейме, в целом поначалу устраивало, для старта вполне годная штука. Но как только появились не примитивные требования, моногейм стал проблемой. Например потребовалось у спрайта две текстуры вместо одной, и такой возможности нет. Для не квадратных фигур пришлось писать свой код и вызывать какие-то внутренние методы, потому что моногейм рисует только прямоугольники. Не хватило также умных сортировок спрайтов, а не только мгновенной или по текстуре. И не понравилась постоянная возня со утилитами для ресурсов и какие-то промежуточные форматы для всего. А сейчас они уже месяц не могут выкатить минорную версию, где обновлена версия сишарпа, без новых фич, которая якобы готова. И OpenGL уже устарел, а Vulkan-а в моногейме нет. В общем плюнул я на это всё, и делаю на вулкане теперь. Сложно и времени на всё много уходит, но доступно всё API, а не урезанная абстракция.
Можно натренировать себя ощущать шесть пальцев вместо пяти. Главное убрать в сознании любые предпосылки вроде "не", "да ну", "непривычно" и прочее, которые не дают сменить прошлый автоматизм. Тогда можно будет перебирать по столу шестью пальцами, и мозг даже не будет возражать, и будет приходить правдоподобное ощущение от пальцев, и даже будете сбиваться при их счёте когда смотрите на них. Не думаю, что у всех получится, зависит от навыков, которые в повседневности не особо нужны, например навык обмана мозга, наблюдения за его процессами, воображение на грани проявления в субъективной реальности, и так далее. В осознанных снах можно добиться любых конечностей. Мозг точно умеет всё это.
Откуда вы знаете за другого пользователя если не видите конкретного человека? Может и как старая бабка прицеливаются. Бывает что нужно на автомате что-то делать типа скролла, а глаза и мозг уже мутные под конец дня и любой обрыв автоматизма приводит к усилиям и негативной реакции. Представьте, бывают другие люди не такие как вы и не в таких идеальных состояниях и условиях.
Где? У вас просто задача сказать наперекор?
А мне полосы в Windows нравятся больше всего. По ним можно попасть без прицеливания и без ожидания увеличения размера. Они состоят из пяти элементов с разной функцией, а не только из ползунка. И везде одинаковые. Если скролл меньше 5 миллиметров по ширине линейкой на экране, то это декорация, а не функциональный компонент. Потому что тогда нельзя переместить на них курсор и прокрутить без прицеливания и задержки для увеличения (лишнее прерывание намерения, как если бы все кнопки были сначала миллиметр в высоту). А самые плохие видел в убунту, где по умолчанию прокрутку не видно, и нужно догадаться и проскроллить мышкой, чтобы появился какой-то квадратик всегда одинакового размера, на который не всегда удобно попадать за пределами окна:
Hidden text