Это в концепции. Я более чем уверен, что люди, которые пользуются одной системной учёткой на двоих (знаю таких) будут использовать это несколько по-другому.
Ну, в текущем билде долго поработать не успел, но серьёзных тормозов в глаза не бросалось. Так что как минимум хуже не стало. Сейчас пишу из-под Windows, где по развлечениям немного вкладок открыто. А вот во время работы в Linux обычно десятки открыты — буду наблюдать. То, что акцент оптимизации был на кейсах, где много вкладок — приятно. Даже тот же Firefox на мощном железе умудряется иногда тормозить в таких ситуациях.
Кстати, если честно, то мне текущий порядок тоже не очень нравится. Заметил, что регулярно приходится стрелочками выбирать адрес перед тем как перейти потому, что первое предлагаемое обычно не совпадает с желаемым.
Как идея (не уверен, что хорошая) — сделать сортировку настраиваемую пользователем.
Это понятно.
Но кроме итоговой производительности работы есть ещё воспринимаемая пользователями очень тонко визуальная производительность и отзывчивость. Вот на это использование блокировки в движке может повлиять если страницы будут быстрее грузиться. Но может и не повлиять, если он будет (а он будет, судя по всему) хуже блокировать.
А вы (Vivaldi) разве не хвалились раньше тем, что как раз доработали хром там, где он не был удобен типа выделения текста в ссылках и подобных мелочей? Или я неправильно понял?
О, кстати.
Меня вот что ещё выбесило. Я на двух машинах под двумя ОС (итого 4 раза) на каждой устанавливал Vivaldi и прокликивал все несколько десятков элементов Speed Dial чтобы у них подгрузились превью.
Уже потом я обнаружил, что можно с того же Speed Dial выбрать «Bookmarks», там выбрать «Speed Dial» и в панели нажать «Update thumbnails», но это достаточно неочевидная последовательность действий и мне кажется, что обычному пользователю до этого будет сложно догадаться и он бы ожидал, что если на других компьютерах он это (получение превью) делал, то после синхронизации на новом компьютере превью тоже должно подгрузиться.
Я, конечно же, не имею в виду, что вам нужно синхронизировать сами превью в ваше хранилище, но, например, статус «есть превью» или «нет превью» у элемента можно было бы сохранять и при первой синхронизации для элементов где оно есть (хотя бы на Speed Dial) — обновлять. Opera так делала, если мне память не изменяет. Я на это дело много времени убил пока СЛУЧАЙНО не обнаружил, что можно было быстрее.
Подытожу. Мне кажется, тут есть два направления для работы: автоматическое обновление после синхронизации и более интуитивный доступ к ручному массовому обновлению (например в ПКМ по Speed Dial и по «папкам» на нём, а не только элементам внутри них).
Полагаю, vmchaz говорит о фиче подобной обсуждаемому выше мастер-паролю для базы паролей, только применимой ко всему профилю. То есть, при запуске браузера появляется требование ввести пароль и только после его ввода инициализируется профиль.
Соответственно, с диска сторонним софтом и вредоносами не получится спереть данные — только из памяти браузера.
UPD: От себя добавлю, что скорее всего, это нужно немногим и на данном этапе гораздо проще реализовать это шифрованием уровня ФС нежели ждать реализации в Vivaldi. Потому что, скорее всего, слишком много кода Chromium нужно будет перелопатить чтобы заставить такую обширную фичу работать.
Насколько я знаю, можно использовать расширения и сторонний софт.
Ну вот я вам скриншот из расширения приложил к комментарию (и к релизу 2.0 тоже писал об этой проблеме). И в прошлом треде по 2.0 было обсуждение, где лично я пришёл к выводу, что проблема корнями уходит в Chromium. Мой вопрос скорее в том, будет ли это конкретно в Vivaldi исправляться как делается с некоторыми другими противными проблемами апстрима.
Запустите браузер из консоли и выполните предлагаемые команды. По лицензионным ограничениям мы не можем включить библиотеку в браузер.
Вы мне выше пишете, что я невнимательно читаю, но, кажется, тоже не дочитываете до конца абзацы. Я написал, что я ПОНИМАЮ, почему не бандлится библиотека. Также я написал, что я решил эту проблему рекомендуемым костылём из CLI. А ещё я написал что у меня в дистрибутиве вообще-то есть решение из пакетного менеджера, с которым другие браузеры (Chromium) работают, а Vivaldi почему-то нет.
Не вижу жалоб на подобные проблемы у нас в BTS.
Понятно. Поживу, посмотрю как будет себя вести 2.6. Если будет досаждать — подумаю как оформить багрепорт.
Это невозможно. Может, адрес указали неверно?
Ваш баг-репорт номер VB-54573. Подтверждён.
Адрес указан — *******-**@ya.ru. Это верный адрес?
Да, адрес мой. При поиске «vivaldi» в ящике до сегодняшнего дня (комменты с Хабра) только отбивки по комментам с Хабра на 2.0.
Может быть, Яндекс сожрал антиспамом ваше письмо? Не подскажете, с какого адреса приходят отбивки багтрекера?
Ну и главное что репорт зарегистрирован. Надеюсь, со временем эту фичу реализуют.
в пользу этого говорят строки про изменения в апстриме Chromium
Лично мне интересно было бы на бенчмарки посмотреть. Особенно в рамках Vivaldi. В рамках Chromium, скорее всего, уже давно сделано кем-то в сообществе.
Ну, немного противоречит приоритетам, возможно. Шифрование паролей везде уже есть, а в Vivaldi ещё не завезли. Хотя стоило бы сделать это изначально.
Если говорить утрируя (некорректно, но с долей истины), то лампочки Hue браузер стал поддерживать, кажется, больше года назад, а пароли не шифрует до сих пор.
Ну почему же?
Если он у вас тоже написан на JavaScript — скорее всего, ваша реализация даже если и быстрее, то точно менее функциональна в перворелизном виде.
А вот если у вас там на уровне C++ кода в движке всё работает (в пользу этого говорят строки про изменения в апстриме Chromium) и разница в производительности разительная (интересно было бы бенчмарк посмотреть) — тогда имеет смысл задуматься.
Как идея (не уверен, что хорошая) — сделать сортировку настраиваемую пользователем.
Довольно сильный при учёте, что Vivaldi — браузер на движке Chromium, а не на своём собственном.
Но кроме итоговой производительности работы есть ещё воспринимаемая пользователями очень тонко визуальная производительность и отзывчивость. Вот на это использование блокировки в движке может повлиять если страницы будут быстрее грузиться. Но может и не повлиять, если он будет (а он будет, судя по всему) хуже блокировать.
Меня вот что ещё выбесило. Я на двух машинах под двумя ОС (итого 4 раза) на каждой устанавливал Vivaldi и прокликивал все несколько десятков элементов Speed Dial чтобы у них подгрузились превью.
Уже потом я обнаружил, что можно с того же Speed Dial выбрать «Bookmarks», там выбрать «Speed Dial» и в панели нажать «Update thumbnails», но это достаточно неочевидная последовательность действий и мне кажется, что обычному пользователю до этого будет сложно догадаться и он бы ожидал, что если на других компьютерах он это (получение превью) делал, то после синхронизации на новом компьютере превью тоже должно подгрузиться.
Я, конечно же, не имею в виду, что вам нужно синхронизировать сами превью в ваше хранилище, но, например, статус «есть превью» или «нет превью» у элемента можно было бы сохранять и при первой синхронизации для элементов где оно есть (хотя бы на Speed Dial) — обновлять. Opera так делала, если мне память не изменяет. Я на это дело много времени убил пока СЛУЧАЙНО не обнаружил, что можно было быстрее.
Подытожу. Мне кажется, тут есть два направления для работы: автоматическое обновление после синхронизации и более интуитивный доступ к ручному массовому обновлению (например в ПКМ по Speed Dial и по «папкам» на нём, а не только элементам внутри них).
Соответственно, с диска сторонним софтом и вредоносами не получится спереть данные — только из памяти браузера.
UPD: От себя добавлю, что скорее всего, это нужно немногим и на данном этапе гораздо проще реализовать это шифрованием уровня ФС нежели ждать реализации в Vivaldi. Потому что, скорее всего, слишком много кода Chromium нужно будет перелопатить чтобы заставить такую обширную фичу работать.
Ну вот я вам скриншот из расширения приложил к комментарию (и к релизу 2.0 тоже писал об этой проблеме). И в прошлом треде по 2.0 было обсуждение, где лично я пришёл к выводу, что проблема корнями уходит в Chromium. Мой вопрос скорее в том, будет ли это конкретно в Vivaldi исправляться как делается с некоторыми другими противными проблемами апстрима.
Вы мне выше пишете, что я невнимательно читаю, но, кажется, тоже не дочитываете до конца абзацы. Я написал, что я ПОНИМАЮ, почему не бандлится библиотека. Также я написал, что я решил эту проблему рекомендуемым костылём из CLI. А ещё я написал что у меня в дистрибутиве вообще-то есть решение из пакетного менеджера, с которым другие браузеры (Chromium) работают, а Vivaldi почему-то нет.
Понятно. Поживу, посмотрю как будет себя вести 2.6. Если будет досаждать — подумаю как оформить багрепорт.
Да, адрес мой. При поиске «vivaldi» в ящике до сегодняшнего дня (комменты с Хабра) только отбивки по комментам с Хабра на 2.0.
Может быть, Яндекс сожрал антиспамом ваше письмо? Не подскажете, с какого адреса приходят отбивки багтрекера?
Ну и главное что репорт зарегистрирован. Надеюсь, со временем эту фичу реализуют.
Я там же пишу говоря про реализацию в движке:
Лично мне интересно было бы на бенчмарки посмотреть. Особенно в рамках Vivaldi. В рамках Chromium, скорее всего, уже давно сделано кем-то в сообществе.
Если говорить утрируя (некорректно, но с долей истины), то лампочки Hue браузер стал поддерживать, кажется, больше года назад, а пароли не шифрует до сих пор.
Если он у вас тоже написан на JavaScript — скорее всего, ваша реализация даже если и быстрее, то точно менее функциональна в перворелизном виде.
А вот если у вас там на уровне C++ кода в движке всё работает (в пользу этого говорят строки про изменения в апстриме Chromium) и разница в производительности разительная (интересно было бы бенчмарк посмотреть) — тогда имеет смысл задуматься.