Pull to refresh
65
0
Алексей Скобкин@skobkin

Пользователь

Send message
Пока, кажется, проблема прекратилась (возможно, после того как прилетел более свежий билд).
Если возникнет снова — буду репортить с видео.
Последнее письмо от 5 января 2018 («Vivaldi Community | Monthly Roundup, December 2017»).
Интересно. То ли я действительно указал не тот адрес (вряд ли, автодополнение обычно подсказывает мой), то ли письма куда-то пропали.
Ну, у меня он воспроизводится достаточно просто. Я могу записать видео. Но воспроизведётся ли у тестеров — хороший вопрос. Как разработчик я прекрасно понимаю, что на это влияет много факторов.

Точно сломано. Как минимум в одном месте. У меня даже при ручном обновлении (по меню ПКМ или иконке обновления) то ли на всех, то ли на большинстве элементов, у которых есть превью ничего не происходит. То есть, я не могу у части элементов обновить превью никак.
Это раздражает тем, что где-то на превью попала форма логина вместо интерфейса сайта и хоть аутентификацию я уже прошёл, Vivaldi все равно не меняет превью на нормальный вид сайта.
Shpankov, это надо репортить?

Полагаю, речь об этой фиче, которую отломали в Chromium.
Ну вообще лучше бы адекватную поддержку внешних прокси (это гибче и безопаснее) сделали.
Но как уже сказали — это очень сложно (и дорого) из-за того, что Chromium этого тоже не умеет.
Вообще, если на вашем компьютере появляются ячейки, которые удалены на другом компьютере — это баг.

Я на такое не жаловался. У меня проблема в том, что после синхронизации на новой машине превьюшки для элементов Speed Dial не подгружаются автоматически и приходится вручную этот процесс инициализировать.

Проблема сложнее, чем я думал. Будем что-то креативить.

Я надеюсь, речь идёт именно об описанной абзацем выше проблеме :)
Печально (с точки зрения пользователя), но логично (с точки зрения разработчика).
Это в концепции. Я более чем уверен, что люди, которые пользуются одной системной учёткой на двоих (знаю таких) будут использовать это несколько по-другому.
Попробовал сейчас — превью не обновляются. Ну и даже если бы это работало так, то хоткей — это неочевидно для пользователя.
Ну, в текущем билде долго поработать не успел, но серьёзных тормозов в глаза не бросалось. Так что как минимум хуже не стало. Сейчас пишу из-под Windows, где по развлечениям немного вкладок открыто. А вот во время работы в Linux обычно десятки открыты — буду наблюдать. То, что акцент оптимизации был на кейсах, где много вкладок — приятно. Даже тот же Firefox на мощном железе умудряется иногда тормозить в таких ситуациях.
Кстати, если честно, то мне текущий порядок тоже не очень нравится. Заметил, что регулярно приходится стрелочками выбирать адрес перед тем как перейти потому, что первое предлагаемое обычно не совпадает с желаемым.
Как идея (не уверен, что хорошая) — сделать сортировку настраиваемую пользователем.
Если имелось в виду именно это, то «так делают все» — довольно слабый аргумент в защиту данной позиции.

Довольно сильный при учёте, что Vivaldi — браузер на движке Chromium, а не на своём собственном.
Это понятно.
Но кроме итоговой производительности работы есть ещё воспринимаемая пользователями очень тонко визуальная производительность и отзывчивость. Вот на это использование блокировки в движке может повлиять если страницы будут быстрее грузиться. Но может и не повлиять, если он будет (а он будет, судя по всему) хуже блокировать.
А вы (Vivaldi) разве не хвалились раньше тем, что как раз доработали хром там, где он не был удобен типа выделения текста в ссылках и подобных мелочей? Или я неправильно понял?
В курсе. Но они позволяют увидеть технологическую разницу хотя бы в условиях сферического коня в вакууме.
Ну вон профайлы — тоже задача системы, но сделали же разные профайлы в рамках одного системного.
Справедливости ради, так делают все остальные включая Chromium.
И между тем вы сделали профайлы в браузере которые не зависят от системного.

Information

Rating
Does not participate
Location
Архангельск, Архангельская обл., Россия
Date of birth
Registered
Activity