согласен с предыдущим ответившим вам. Проблем с жестами не было никогда, учитывая что я использовал тачпады разной степени всратости: малюсенькие на ультрабюджетных нетбуках 2010-х годов, среднего размера на макбуке тех же лет, большие современные из сегмента “выше среднего”, а также большие современные ультрабюджетные варианты - и ни в одном из случаев не было проблемы распознавания жестов.
Но при этом у знакомого на моём ноутбуке, действительно, получалось скроллить двумя пальцами через раз. Из возможных причин, которые я мог наблюдать: либо слишком близко пальцы друг к другу, либо касается только один палец, либо пальцы слишком слабо касаются тачпада. Быть может, дело привычки. Но я сам, если что, больше фанат нормальной мыши, чем тачпада.
@Fenex привёл пример с использованием итераторов, где берётся const-ссылка на array, что запрещает дальнейшее взятие mut-ссылки на array при вызове push. Если, однако, использовать обычные индексы
for i in 0..array.len() {
println!("item: {}", array[i]);
if array[i] == 4 {
array.push(5); // now it's OK
}
}
println!("item: {array:?}");
то array.len() вызовется один раз для формирования range, не создавая const-ссылку. И в массив действительно добавится новый элемент, но цикл будет до 4.
А как же вы скроллите без колёсика тогда? Наверное, двумя пальцами вверх-вниз. Аналогично, тап двумя пальцами вызывает контекстное меню (ПКМ), тап тремя пальцами эмулирует нажатие на колёсико (СКМ). Конечно, если речь не про древний тачпад с полосочкой для скроллинга сбоку; на таком можно забиндить, как выше сказали, СКМ = ПКМ + ЛКМ.
“всё” не только Kate Mobile, но и любые более-менее популярные альтернативные клиенты, у которых пользователи суммарно отправляют более 100 млн API-запросов в месяц.
Вселенная - это материя. Для нас она бесконечно “растет” “из ничего”.
Если положить, что мы осознаём только три измерения пространства, а пространство на самом деле четырёх- или более мерное, то осознаём мы только трёхмерную проекцию пространства. А значит можно представить расширение/сжатие вселенной в виде колебания пространства вселенной в четвёртом (или ещё каком) одном измерении. Подобно тому, как колеблющийся шар в сечении двумерной плоскостью будет образовывать на ней циклично расширяющийся/сжимающийся круг из “ничего”.
линукс в дуалбуте для задач, которые на семерке не запускаются
заголовки у всех окон должны быть абсолютно единообразны
В линуксе имеет место тенденция замены протокола Xorg на Wayland. Оконный менеджер и композитор сливаются воеидно, а отрисовкой окна и, соответственно, window decorations занимается само приложение. И там полная свобода действий. Единообразия можно достичь разве что путём использования приложений на одном и том же графиическом тулките (Qt, GTK и подобные) и соответствующей графической среды, в которой этот тулкит будет основным. Иначе будет разрозненность во внешнем виде - не только в заголовках окон, но и в самих компонентах интерфейса. Можно, конечно, различными махинациями и совместимыми темами минимизировать такие различия, но дело не только во внешнем виде, но и поведении (стандартные горячие клавиши, стандартное поведение элементов интерфейса и т. д.).
так я про OBS и спрашивал, использовался ли там аппаратный кодек. Потому что странно называть OBS прожорливым в режиме софтверного кодирования, сравнивая с программой, использующей аппаратное кодирование...
вот незадача — OBS заставляет ваш ноутбук задыхаться
У меня ультрабюджетный ноутбук на Intel N100. И вот уж OBS его задыхаться точно не заставляет, в режиме записи 1920x1080@60 потребляет максимум процентов 10 процессорного времени. Вы же используете аппаратное ускорение кодирования видео при записи? Используете же? Если следовать вашей истории про индуса, то разность в качестве аппартного и софтверного кодирования не играет роли, тогда почему бы и да?
Кстати про неоновые интерфейсы. Не читая текст новости, а только лишь увидев скриншот приложения, сразу подумал, что нейрослоп. По аналогии с результатами экспериментов в комментариях под новостью про новую модель Qwen: раз, два. В обоих случаях тоже неоновый интерфейс. Забавно, сначала научились различать графический нейрослоп, потом текстовый, теперь вот ещё UI/UX-нейрослоп...
стандартная библиотека Rust — чтобы собирать и запускать приложения, написанные на чистом Rust;
Неужели планируется динамическое связывание программ на Rust со стандартной библиотекой Rust (кажется, видел такое в Redox OS)? Внешние крейты при сборке не выносятся в shared objects, а просто добавляются к бинарю? Просто приложения на "чистом Rust" в большинстве своём после сборки представляют собой большой почти статический бинарь, имеющий в зависимостях разве что libc и ещё пару системных библиотек.
Ещё вопрос не по теме. Читал предыдущие части, слог довольно приятный. Вы пишете текст/наброски статьи по ходу работы или апостериори?
Есть люди, у которых ПК в аптайме по нескольку месяцев (от обновления до обновления), и всё это время всякие IDE, браузеры и прочие программы запущены с момента загрузки ПК 🙂
Думаете, без потерь получится меньше 20 байт на кадр в среднем получить (в том же разрешении и с тем же фреймрейтом)? Допустим, даже если дизеринг отключить, сделав картинку менее "шумной"; запомнить временные точки инвертирования цветовой палитры в видео (иначе невыгодно будет спускаться в одноцветные блоки)... Не верится) upd. Но вообще затея интересная, если не лень будет, хотя бы сожму просто для понимания масштабов, мб и правда лучше будет таким алгоритмом воспользоваться.
Чуть выше я лихо упомянул серию алгоритмов LZ**, они обращаются к распакованным данным и требуют их буферизации в оперативе, чтобы можно сделать окно достаточно большим, а в меге её всего 2 килобайта (а я музыку ещё планировал прикрутить). Но не упомянул про обычное кодирование по Хаффману. Сейчас каждый блок весит по байту, но самыми популярными с огромным отрывом являются полностью чёрный и полностью белый, для которых, учитывая разрыв, Хаффман, скорее всего, выдаст двухбитовые коды, что примерно раза в полтора уменьшит размер данных (скажем, с текущих 30 килобайт до 20). Освободившихся 10 килобайт с головой хватит для музыки, быть может даже фреймрейт получится поднять немного.
Вы буквально описали схему, которую я использовал) Только фокус ещё в выборе тех самых 256 ключевых блоков, после кластеризации детали гораздо лучше выглядят.
Да и просто это неспортивно — использовать внешнюю память, когда на плате установлены безумные 32 мегабайта памяти,
Так подумал и я... и сжал с потерями Bad Apple в 7 FPS в разрешении 40x32 и впихнул данные видео и кодек целиком в 32 килобайта памяти atmega328p / Arduino UNO. Данные ещё можно сжать в два раза с помощью LZ77, оставив несколько килобайт под синтезатор и данные музыки. Вот только статью об этом всё руки не доходят написать...
согласен с предыдущим ответившим вам. Проблем с жестами не было никогда, учитывая что я использовал тачпады разной степени всратости: малюсенькие на ультрабюджетных нетбуках 2010-х годов, среднего размера на макбуке тех же лет, большие современные из сегмента “выше среднего”, а также большие современные ультрабюджетные варианты - и ни в одном из случаев не было проблемы распознавания жестов.
Но при этом у знакомого на моём ноутбуке, действительно, получалось скроллить двумя пальцами через раз. Из возможных причин, которые я мог наблюдать: либо слишком близко пальцы друг к другу, либо касается только один палец, либо пальцы слишком слабо касаются тачпада. Быть может, дело привычки. Но я сам, если что, больше фанат нормальной мыши, чем тачпада.
@Fenex привёл пример с использованием итераторов, где берётся const-ссылка на
array, что запрещает дальнейшее взятие mut-ссылки наarrayпри вызовеpush. Если, однако, использовать обычные индексыто
array.len()вызовется один раз для формирования range, не создавая const-ссылку. И в массив действительно добавится новый элемент, но цикл будет до 4.Можно перейти к циклу while, чтобы включить ещё и добавленный элемент в вывод:
А как же вы скроллите без колёсика тогда? Наверное, двумя пальцами вверх-вниз. Аналогично, тап двумя пальцами вызывает контекстное меню (ПКМ), тап тремя пальцами эмулирует нажатие на колёсико (СКМ). Конечно, если речь не про древний тачпад с полосочкой для скроллинга сбоку; на таком можно забиндить, как выше сказали, СКМ = ПКМ + ЛКМ.
я брал контекст из вот этого поста
“всё” не только Kate Mobile, но и любые более-менее популярные альтернативные клиенты, у которых пользователи суммарно отправляют более 100 млн API-запросов в месяц.
Если положить, что мы осознаём только три измерения пространства, а пространство на самом деле четырёх- или более мерное, то осознаём мы только трёхмерную проекцию пространства. А значит можно представить расширение/сжатие вселенной в виде колебания пространства вселенной в четвёртом (или ещё каком) одном измерении. Подобно тому, как колеблющийся шар в сечении двумерной плоскостью будет образовывать на ней циклично расширяющийся/сжимающийся круг из “ничего”.
ослепляющие 3000 заклёпок :D
(в оригинале “nits”)
В линуксе имеет место тенденция замены протокола Xorg на Wayland. Оконный менеджер и композитор сливаются воеидно, а отрисовкой окна и, соответственно, window decorations занимается само приложение. И там полная свобода действий. Единообразия можно достичь разве что путём использования приложений на одном и том же графиическом тулките (Qt, GTK и подобные) и соответствующей графической среды, в которой этот тулкит будет основным. Иначе будет разрозненность во внешнем виде - не только в заголовках окон, но и в самих компонентах интерфейса. Можно, конечно, различными махинациями и совместимыми темами минимизировать такие различия, но дело не только во внешнем виде, но и поведении (стандартные горячие клавиши, стандартное поведение элементов интерфейса и т. д.).
так я про OBS и спрашивал, использовался ли там аппаратный кодек. Потому что странно называть OBS прожорливым в режиме софтверного кодирования, сравнивая с программой, использующей аппаратное кодирование...
У меня ультрабюджетный ноутбук на Intel N100. И вот уж OBS его задыхаться точно не заставляет, в режиме записи 1920x1080@60 потребляет максимум процентов 10 процессорного времени.
Вы же используете аппаратное ускорение кодирования видео при записи? Используете же? Если следовать вашей истории про индуса, то разность в качестве аппартного и софтверного кодирования не играет роли, тогда почему бы и да?
Кстати про неоновые интерфейсы. Не читая текст новости, а только лишь увидев скриншот приложения, сразу подумал, что нейрослоп. По аналогии с результатами экспериментов в комментариях под новостью про новую модель Qwen: раз, два. В обоих случаях тоже неоновый интерфейс. Забавно, сначала научились различать графический нейрослоп, потом текстовый, теперь вот ещё UI/UX-нейрослоп...
Ещё чем-нибудь занимаетесь помимо программирования? В плане увлечений. Может нужно отвлечься?
С этим примерно понятно. А что имеется ввиду под
Неужели планируется динамическое связывание программ на Rust со стандартной библиотекой Rust (кажется, видел такое в Redox OS)? Внешние крейты при сборке не выносятся в shared objects, а просто добавляются к бинарю? Просто приложения на "чистом Rust" в большинстве своём после сборки представляют собой большой почти статический бинарь, имеющий в зависимостях разве что libc и ещё пару системных библиотек.
Ещё вопрос не по теме. Читал предыдущие части, слог довольно приятный. Вы пишете текст/наброски статьи по ходу работы или апостериори?
Извините
... пока оба операнда отличны от NaN :)
только для целочисленного деления. В случае чисел с плавающей точкой существуют ±inf и NaN.
Есть люди, у которых ПК в аптайме по нескольку месяцев (от обновления до обновления), и всё это время всякие IDE, браузеры и прочие программы запущены с момента загрузки ПК 🙂
Думаете, без потерь получится меньше 20 байт на кадр в среднем получить (в том же разрешении и с тем же фреймрейтом)? Допустим, даже если дизеринг отключить, сделав картинку менее "шумной"; запомнить временные точки инвертирования цветовой палитры в видео (иначе невыгодно будет спускаться в одноцветные блоки)... Не верится) upd. Но вообще затея интересная, если не лень будет, хотя бы сожму просто для понимания масштабов, мб и правда лучше будет таким алгоритмом воспользоваться.
Чуть выше я лихо упомянул серию алгоритмов LZ**, они обращаются к распакованным данным и требуют их буферизации в оперативе, чтобы можно сделать окно достаточно большим, а в меге её всего 2 килобайта (а я музыку ещё планировал прикрутить). Но не упомянул про обычное кодирование по Хаффману. Сейчас каждый блок весит по байту, но самыми популярными с огромным отрывом являются полностью чёрный и полностью белый, для которых, учитывая разрыв, Хаффман, скорее всего, выдаст двухбитовые коды, что примерно раза в полтора уменьшит размер данных (скажем, с текущих 30 килобайт до 20). Освободившихся 10 килобайт с головой хватит для музыки, быть может даже фреймрейт получится поднять немного.
Вы буквально описали схему, которую я использовал) Только фокус ещё в выборе тех самых 256 ключевых блоков, после кластеризации детали гораздо лучше выглядят.
Влезает тютелька в тютельку (32720 байт).
Так подумал и я... и сжал с потерями Bad Apple в 7 FPS в разрешении 40x32 и впихнул данные видео и кодек целиком в 32 килобайта памяти atmega328p / Arduino UNO. Данные ещё можно сжать в два раза с помощью LZ77, оставив несколько килобайт под синтезатор и данные музыки. Вот только статью об этом всё руки не доходят написать...