Что вызывает различное поведение отображения GtkIconView в разных версиях GTK?

Картинки пояснят название:

В LMDE и Ubuntu 12.04 мой GtkIconView выглядит так — это правильно с точки зрения расстояния между значками:

Интервал Ubuntu 12 04 RB 96

В Ubuntu 12.10, 13.04 и Fedora 17 тот же код выглядит следующим образом:

Интервал Ubuntu 12 10 RB 97

Н.Б. – Это плагин Python для ритмбокса. Исходный код находится здесь, на GitHub.

Я проверил следующие атрибуты GtkIconView — они точно такие же в Ubuntu 12.04 и в неправильно отображаемой версии 12.10.

  • элемент-заполнение
  • междурядье
  • интервал между столбцами
  • ширина элемента

Такое поведение отображения происходит сразу же, когда я устанавливаю либо text_column, либо markup_column (текст под значками) видимым столбцом, т. е. изменяю значение с -1 на столбец номер.

Если текстовый столбец/столбец разметки скрыт (т. е. значение -1), то отображение будет правильным на всех дистрибутивах.

Поскольку один и тот же код работает с точно такой же музыкальной коллекцией, я могу только предположить, что более новые библиотеки GTK в Fedora 17/Ubuntu 12.10/13.04 ведут себя по-разному.

Мой гугл-фу нашел только эта ссылка, которая звучит идентично. Однако изучение исходного кода ubuntu-accomplishment-viewer меня не просветило.

Кто-нибудь еще сталкивался с этим? Любые предложения о наилучшем способе дальнейшего расследования?

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

#!/usr/bin/env python

from gi.repository import Gtk, GdkPixbuf

window = Gtk.Window()
window.connect('delete_event', Gtk.main_quit)

ui = Gtk.Builder()
ui.add_from_file('reproduce.ui')

page = ui.get_object('main_box')
window.add(page)

ls = Gtk.ListStore(str, GdkPixbuf.Pixbuf)
icon = GdkPixbuf.Pixbuf.new_from_file_at_size(
    str("/usr/share/icons/gnome/48x48/actions/zoom-out.png"), 90, 90)

for i in range(15):
    ls.append(['Item %d' % i, icon])

covers_view = ui.get_object('covers_view')
covers_view.set_model(ls)
covers_view.set_text_column(0)
covers_view.set_pixbuf_column(1)
covers_view.set_item_width(100)

# These lines make it easier to see the problem
crt, crp = covers_view.get_cells()
crt.set_property('background', '#000')
crt.set_property('foreground', '#AAA')
print crt.get_request_mode()

window.set_default_size(600,400)
window.show_all()
Gtk.main()

и поляна - http://pastebin.com/uvQ9mWeg

Из предложения deinonychusaur я просмотрел gtkparasite

К сведению: я использовал готовый PPA от AnthonyWong как для Ubuntu 12.04, так и для 12.10.

Результаты для обеих версий были идентичными. Эксперименты по изменению свойств IconView с помощью приложений не помогли решить эту проблему.

Следующее предложение от дейнонихозавра выглядит очень интересно, и я могу подтвердить - т.е.

IconView CellRendererText в 2 раза больше, чем IconView Pixbuf в Fedora 17/12.10/13.04, но в 1 раз больше, чем IconView Pixbuf в 12.04.


python gtk3 pygobject
person fossfreedom    schedule 30.12.2012    source источник
comment
Две идеи: вы (а) протестировали использование программы проверки gtk, чтобы увидеть, какое свойство может вызывать проблему? И если это невозможно (б) проверил gtk-версии на разных платформах, потому что, может быть, где-то есть хотя бы какой-то список изменений, который приведет вас к правильному пути относительно того, что было изменено?   -  person deinonychusaur    schedule 03.01.2013
comment
инструмент: unix.stackexchange.com/ вопросов/37626/ и что касается журнала изменений, я тоже не знаю, но, возможно, в проекте разработки gtk... привязки python для gtk3 действительно недостаточно документированы.   -  person deinonychusaur    schedule 03.01.2013
comment
Вы правы выше в том, что это относится к тексту, потому что CellRendererText имеет предпочтительную ширину 180, и если установлено значение 100, это значение снова изменяется на window.show_all() на 180. И даже если изменить обратно после того, как все показано, оно все равно изменится на 180 во время Gtk.main(). (На самом деле If установит для себя двойную ширину CellRendererPixbuf, что можно увидеть, если изменить его на 100 вместо 90, в результате чего CellRendererText станет 200)   -  person deinonychusaur    schedule 04.01.2013
comment
Я также могу добавить, что эффект не имеет ничего общего с ориентацией в CellAreaBox, который содержит два средства визуализации (если его ориентация переключена на горизонтальную, проблема остается). То есть это не проблема упаковки + расширения.   -  person deinonychusaur    schedule 04.01.2013
comment
Я добавил несколько строк в ваш код (надеюсь, все в порядке), поэтому размер CellRendererText виден. Кроме того, если вы проверите оператор печати, он скажет <enum GTK_SIZE_REQUEST_HEIGHT_FOR_WIDTH of type GtkSizeRequestMode>, что может быть связано с проблемой? Есть Gtk.SizeRequestMode.CONSTANT_SIZE, но я не знаю, как его изменить.   -  person deinonychusaur    schedule 04.01.2013
comment
Кстати, раньше я сталкивался с проблемами размера текста, особенно с многоточием (кажется, на скриншоте 1) и автопереносом.   -  person Dima Tisnek    schedule 04.01.2013

Ответы (3)


arrow_upward
6
arrow_downward

Причина наблюдения.

Разработчики вышестоящего GTK решили изменить алгоритм того, как для вычисления ширины ячейки TextRenderer IconView.

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

Это изменение было зафиксировано после более старой версии GTK в Ubuntu 12.04 и LMDE. Он нашел свое применение в более поздних версиях GTK, найденных в Ubuntu 12.10 и 13.04 и Fedora 17.

ошибка или не ошибка

Поскольку эта проблема возникает уже более года с момента выпуска Ubuntu 12.04, кажется, что это не ошибка, а конструктивное решение.

Возможно, немного странно — на Bugzilla об этом сообщалось для другого приложения (видеоредактор Pitivi ), но на момент написания это все еще находится в неподтвержденном состоянии.

обходной путь

Что было полезно в этой ссылке, так это вложение, дающее обходной путь, где вы создаете CellRendererText и назначаете его IconView ДО того, как будет определен столбец разметки/текста.

Ниже моя интерпретация обходного пути

cover_size=100
markup_text="some text"

self._text_renderer = Gtk.CellRendererText()
self._text_renderer.props.alignment = Pango.Alignment.CENTER
self._text_renderer.props.wrap_mode = Pango.WrapMode.WORD
self._text_renderer.props.xalign = 0.5
self._text_renderer.props.yalign = 0
self._text_renderer.props.width = cover_size
self._text_renderer.props.wrap_width = cover_size
self._cover_view.pack_end(self._text_renderer, False)
self._cover_view.add_attribute(self._text_renderer, 'markup', markup_text)
person fossfreedom    schedule 04.01.2013

arrow_upward
2
arrow_downward

Используя то, что @qama сказал о «взломе при изменении размера-установки-размера-запроса», поведение можно исправить (хотя и действительно хакерским способом).

Просто добавьте обратный вызов:

def keep_size(crt, *args):

    crt.handler_block(crt_notify)
    crt.set_property('width', 100)
    crt.handler_unblock(crt_notify)

И подключите его к CellRendererText:

crt, crp = covers_view.get_cells()
crt_notify = crt.connect('notify', keep_size)

Если вы добавите print crt, args к обратному вызову, вы увидите, что он идет туда примерно 10-20 раз... имея дело как со свойствами width, так и со свойствами wrap-width.

person deinonychusaur    schedule 04.01.2013
comment
+1 Спасибо за вашу помощь в этом - ваш обходной путь работает. Именно ваши наблюдения помогли в этом, и поэтому я отмечу свой ответ как принятый — я дам вам награду, поскольку вы вели меня в правильном направлении. Ваше здоровье. - person fossfreedom; 05.01.2013

arrow_upward
0
arrow_downward

Чтобы воспроизвести это правильно:

  • не используйте систему gtk rc
  • не использовать пользователя gtk rc
  • применяйте только свой собственный gtk rc
  • настроить обе версии, например. виртуальный бокс
  • выравнивание системных параметров, т.е. точек на дюйм
  • запустить с теми же данными
  • публиковать точные использованные версии, py, pygtk, gtk+, зависимые библиотеки

Сказав это, я столкнулся с проблемами, когда разные версии gtk+ вели себя достаточно по-разному, поэтому я не мог надежно разрабатывать на Linux (актуальная версия gtk) и развертывать на Windows (исправленная версия).

Ошибки в gtk+ исправлены с течением времени, введены новые функции, вы не можете ожидать идеального воспроизведения пикселей между различными версиями.

person Dima Tisnek    schedule 04.01.2013
comment
Я вижу ваши точки зрения, но если вы проверите мои комментарии выше, кажется, что в некоторых темах gtk и/или версиях gtk есть правило, которое гласит: «В IconView сделайте CellRendererText в 2 раза шире CellRendererPixbuf». Это должно быть возможно как-то переопределить. - person deinonychusaur; 04.01.2013
comment
Вряд ли это правило, если оно есть, найдите его и переопределите в app rc. Чтобы увидеть, связано ли это с текстом, попробуйте без меток. В конце концов, это вполне может быть ошибка в gtk. Несмотря на это, вам нужно сначала провести сортировку, это данные, rc или gtk? - person Dima Tisnek; 04.01.2013
comment
(Я не тот, кто задал вопрос), но мой голос заключается в том, что это относится не к данным, а к правилам, потому что, когда я привязал ширину CellRendererPixbuf к ширине CellRendererText, он попал в цикл, который закончился в обоих случаях. Ширина 6400 (я думаю, это максимум), и проблема остается, даже если текст просто «I» для всех элементов. - person deinonychusaur; 04.01.2013
comment
Упс, не заметил, у меня было что-то похожее с эллиптическим текстом, в некоторых случаях мое окно было прокручиваемым, эллиптический или автоматический перенос текста не эллиптический или автоматический перенос, а вместо этого расширялся. Мне пришлось переопределить это ужасным хаком on-resize-set-size-request. Это было много лет назад, и я надеюсь, что к настоящему времени этот случай исправлен в gtk+, и оператор увидит другую проблему. В любом случае, чтобы получить хороший ответ, оператор должен воспроизвести и провести сортировку. Я подозреваю, что скриншот 2 сделан пользователем или другим разработчиком. - person Dima Tisnek; 04.01.2013
comment
@qarma - спасибо за ответ - просто чтобы подтвердить, размер эллипса - это наш код - без переноса текста, только две строки \n pango и т. д. Скриншоты взяты из одной и той же операционной системы с использованием тех же исходных данных и того же кода - один на Ubuntu 12.04 (скриншот 1) и ubuntu 12.10 (скриншот 2) - и я независимо проверил ситуацию на LMDE и Fedora 17. Материал CellRenderer выглядит как правильное место для поиска. - person fossfreedom; 04.01.2013