Project

General

Profile

Actions

Bug #1429

closed

Панель вкладок теряет свою позицию при обновлении вкладки.

Added by Mellon about 11 years ago. Updated almost 11 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
Core
Target version:
Start date:
11/14/2013
Due date:
% Done:

100%

Estimated time:
3:00 h
Reported in:
master

Description

Допустим, открыто n=ck вкладок, причем k=w/m, где w - ширина панели, m - минимальная ширина вкладки.
Допустим, вкладки r,s,t пошуку поставлены на автообновление.
Допустим, сейчас активна вкладка d=2*k
Тогда не зависимо от того какое положение занимало d относительно окна до очередного обновления r,s,t, после обновления d займет крайнюю правую позицию.
Допустим, нам надо переключится непосредственно на вкладку e>d+4.
Как это сделать средствами только панели вкладок, если в каждый момент времени обновляется одна из вкладок r,s,t?
Никак.
Для этого существуют отдельные костыли - glance & tablist, вызов которых и работа с которыми не столь быстры как хотелось бы.

Expected result:
Панель не меняет своего положения, а вкладки своей позиции отностиельно окна при их обновлении(изменении).

Actual result:
:(

STR:

System information:
LeechCraft 0.5.95-3349-g38bedc1
Built with Qt 4.8.5, running with Qt 4.8.5
Running on: NAME=Gentoo x86_64 3.11.4-gentoo #1 SMP PREEMPT Wed Oct 9 16:06:14 MSK 2013


Related issues 1 (0 open1 closed)

Related to Feature #1430: Использование альтернативных событий с устройств ввода для прокрутки панели вкладок.Closed0xd34df00d11/14/2013

Actions
Actions #1

Updated by 0xd34df00d almost 11 years ago

Это особенность поведения кутишного таббара, и я не знаю, как её починить без того, чтобы писать свой таббар целиком руками.

Олсо, что может быть быстрее, чем нажать Ctrl+Shift+L, а затем пару цифер с номером вкладки?

Actions #2

Updated by Mellon almost 11 years ago

Узнай, чо :3

Олсо, проблема в том, что костыли. Панель вкладок - это универсальный интерфейс присущий практически всем браузерам и пользователь привыкает использовать его единообразно, могут конечно быть различия, но они несущественны и не затрагивают ранее накопленный опыт.

Нет такого, чтобы часть действий при n<=k выполнялась через таббар, а при n>k - через что-то другое, особенно, если это что-то не входит в минимальную установку. Это очень плохо в плане пользовательского опыта, потому, что при виде панели пользователь ожидает, что она полнофункциональна, и если это не так, то пользователя ЛОМАЕТ. А этого нам надо меньше всего и от этого надо избавляться, несмотря, что это традиция личкрафтов.

Actions #3

Updated by 0xd34df00d almost 11 years ago

В общем-то, есть два варианта:
  1. Отключить скроллинг вкладок вообще (так делают всякие оперы-хромы, к тому же).
  2. Фиксировать ширину вкладок, чтобы изменение текста на вкладке не меняло её ширины.

Я, если честно, склоняюсь к первому — сразу куча проблем исчезнет с этим скроллингом.

Actions #4

Updated by 0xd34df00d almost 11 years ago

Собственно, никуда не деться, второй вариант не катит, и вот почему.

Любое изменение текста вызывает обновление лейаута вкладки (вызов d->refresh() в QTabBar::setTabText(), например). Внутри обновления же независимо от ширины текста текущая вкладка делается видимой (вызов makeVisible в QTabBarPrivate::refresh(), например).

Так что да, либо писать свой таббар, либо отключать скроллинг вкладок.

Actions #5

Updated by 0xd34df00d almost 11 years ago

  • Status changed from New to Assigned
  • Target version set to 0.6.60
  • Estimated time set to 3:00 h
Actions #6

Updated by 0xd34df00d almost 11 years ago

  • Status changed from Assigned to Resolved
  • % Done changed from 0 to 100

Applied in changeset main|commit:43f5a29655e94e08569e1f5034c3095a83e7f3d4.

Actions #7

Updated by 0xd34df00d almost 11 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF