9

Pictures will explain the title:

Under LMDE & Ubuntu 12.04 my GtkIconView looks like this - its correct in terms of the spacing between the icons:

Spacing Ubuntu 12 04 RB 96

Under Ubuntu 12.10, 13.04 & Fedora 17 the same code displays as follows:

Spacing Ubuntu 12 10 RB 97

N.B. - This is a rhythmbox python plugin - source code is here on GitHub

I've checked the following GtkIconView attributes - they are exactly the same between Ubuntu 12.04 and in the incorrectly displayed 12.10 version.

  • item-padding
  • row-spacing
  • column-spacing
  • item-width

This display behaviour occurs immediately when I set either the text_column or the markup_column (the text under the icons) to be a visible column i.e. changing the value from -1 to the column number.

If the text column/markup column is hidden (i.e. a value of -1) then the display is correct on all distro's.

Since its the same code running on exactly the same music collection - I can only surmise that the newer GTK libraries in Fedora 17/Ubuntu 12.10/13.04 are behaving differently.

My google-fu has only found this reference which sounds identical. However examining the ubuntu-accomplishment-viewer source code hasnt really enlightened me.

Has anybody else encountered this? Any suggestions on the best way to investigate further?

Ok - I've tried to reduce this to the bare essentials - this simple glade file with this simple code produces this issue. However I'm still non-the-wiser what is causing this visual effect :/

#!/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()

and the glade - http://pastebin.com/uvQ9mWeg

From a suggestion by deinonychusaur I looked at gtkparasite

FYI - I used the ready made PPA from AnthonyWong for both Ubuntu 12.04 and 12.10.

The results for both versions were identical. Experimenting changing the IconView properties using the apps did not really resolve this.

The next suggestion from deinonychusaur looks very interesting and I can confirm - i.e.

The IconView CellRendererText is 2x the size of the IconView Pixbuf in Fedora 17/12.10/13.04 but 1x the size of the IconView Pixbuf in 12.04.

Community
  • 1
  • 1
fossfreedom
  • 2,903
  • 2
  • 19
  • 40
  • Two ideas: Have you (a) tested to use a gtk inspection program to see what property may be causing the problem? And if that's not possible (b) checked gtk-versions on the different platforms, because maybe there's at least some changelog out there somewhere that will lead you on the right track as to what was changed? – deinonychusaur Jan 03 '13 at 18:40
  • tool: http://unix.stackexchange.com/questions/37626/any-tool-for-inspecting-gtk3-elements and as for changelog, I don't know either, but maybe in the gtk-developing project... the python bindings for gtk3 is really under-documented. – deinonychusaur Jan 03 '13 at 19:11
  • 1
    You are right above in that it relates to the text, because the `CellRendererText` has a preferred width of 180 and if set to 100, this value is changed at `window.show_all()` to 180 again. And even if changed back after everything is shown, it still gets changed to 180 during `Gtk.main()`. (If will in fact set itself to 2x width of the `CellRendererPixbuf` which can be seen if that one is changed to 100 instead of 90, causing the `CellRendererText` to become 200) – deinonychusaur Jan 03 '13 at 20:46
  • I can also add that the effect has nothing to do with the orientation in the `CellAreaBox` that holds the two renderers (if its orientation is switched to horizontal, the issue remains). That is, it is not a packing + expand issue. – deinonychusaur Jan 04 '13 at 11:42
  • I added some lines in your code (hope it's OK), so the size of the `CellRendererText` is visible. Also, if you check the print-statement it says ``, which may be the related to the problem? There's a `Gtk.SizeRequestMode.CONSTANT_SIZE`, but I don't know how to change it. – deinonychusaur Jan 04 '13 at 12:31
  • Btw., I've ran into text sizing issues before, especially with ellipsis (screenshot1 appears to suggest) and autowrap. – Dima Tisnek Jan 04 '13 at 12:46

3 Answers3

6

Reason for the observation.

Upstream GTK developers decided to change the algorithm as to how to calculate the width of the TextRenderer cell of the IconView.

Here we go with the same old guess, try the icon size and set double the size of the first icon found in the list, naive but works much of the time

This change was committed after the older GTK version in Ubuntu 12.04 & LMDE. It found its way into the later GTK versions found in Ubuntu 12.10 & 13.04 & Fedora 17.

bug or no bug

Since this issue has been occuring for well over a year now since Ubuntu 12.04 was released, it seems this is not a bug but a design decision.

Perhaps a little odd - on Bugzilla this was reported for another application (Pitivi video editor) but at the time of writing this is still at the unconfirmed state.

workaround

What was useful in that link was an attachment giving a workaround where you create a CellRendererText and assign this to the IconView BEFORE the markup/text column is defined.

Below is my interpretation of the workaround

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)
Community
  • 1
  • 1
fossfreedom
  • 2,903
  • 2
  • 19
  • 40
2

Using what @qama said about 'on-resize-set-size-request hack', the behavior can be fixed (though in a really hackish way).

Just add a callback:

def keep_size(crt, *args):

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

And connect it to the CellRendererText:

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

If you add a print crt, args to the callback you can see that it goes there about 10-20 times... dealing both with properties width and wrap-width

deinonychusaur
  • 7,094
  • 3
  • 30
  • 44
  • +1 Thanks for your help on this - your workaround does work. It was your observations that helped with this and as such, whilst I will mark my answer as the accepted one - I will give you the bounty since you led me in the right direction. Cheers. – fossfreedom Jan 04 '13 at 20:41
0

In order to reproduce this properly:

  • don't use system gtk rc
  • don't use user gtk rc
  • apply your own gtk rc only
  • set up both versions in e.g. virtualbox
  • equalize system parameters, e.g. dpi
  • run with same data
  • post exact versioned used, py, pygtk, gtk+, dependent libs

Having said that, I have ran into issues where different versions of gtk+ behaved differently enough that I could not reliably develop on linux (up to date gtk) and deploy to windows (fixed version).

Bugs are fixed in gtk+ over time, new features introduced, you cannot really expect pixel-perfect reproduction between different versions.

Dima Tisnek
  • 11,241
  • 4
  • 68
  • 120
  • I see your points, but if you check my comments above, there seems to be a rule in some gtk themes and/or versions of gtk that say: 'In IconView make CellRendererText 2x width of CellRendererPixbuf'. That should be possible to override somehow. – deinonychusaur Jan 04 '13 at 12:39
  • Unlikely a rule, if it is, find it and override in app rc. To see if it is text-related, try without labels. In the end it could very well be a bug in gtk. Regardless, you need to triage first, is it data, rc or gtk? – Dima Tisnek Jan 04 '13 at 12:44
  • (I'm not the one that asked the q), but my vote is that it is not relating to data but to rules, because when I chained the CellRendererPixbuf width to the CellRendererText width it got itself into a loop which ended at both becomming 6400 wide (which I guess is a max) and problem remains even if text is just 'I' for all items. – deinonychusaur Jan 04 '13 at 12:49
  • Oops, didn't notice, I've had something similar with ellipsized text, in some cases, mine was scrolled window, ellipsized or autowrapped text wouldn't ellipsize or autowrap, but expand instead. I had to override that with awful on-resize-set-size-request hack. That was years ago, and I hope that case is fixed in gtk+ by now and op sees a different issue. In any case, to get good answer, op has to reproduce and triage. I suspect screenshot2 is from user or another dev. – Dima Tisnek Jan 04 '13 at 12:56
  • @qarma - thanks for the answer - just to confirm, the ellipsize is our code - no wrapping text, just two lines "\n" pango etc. The screenshots are from the same OP using the same source data and same code - one on ubuntu 12.04 (screenshot 1) and ubuntu 12.10 (screenshot 2) - and I've independently verified the situation on LMDE and Fedora 17. The CellRenderer stuff looks like the correct place to look. – fossfreedom Jan 04 '13 at 13:26