Trouble with accessibility and GtkTreeViewColumn with multiple cells
I have a GtkTreeViewColumn with three cell renderers: a toggle, an image and a label. This renders nicely, but Orca only reads the last item in the column: the label. I need it to read the checkbox as well. How can I go about making that happen? Here's a snippet of code, for context. (I'm using Python with PyGObject): pkg_column = Gtk.TreeViewColumn() pkg_column.set_title(_(Install)) pkg_column.set_property(spacing, 4) pkg_toggle_renderer = Gtk.CellRendererToggle() pkg_toggle_renderer.set_property(ypad, 2) pkg_toggle_renderer.connect(toggled, self.on_update_toggled) pkg_column.pack_start(pkg_toggle_renderer, False) pkg_column.add_attribute(pkg_toggle_renderer, 'active', LIST_TOGGLE_ACTIVE) #pkg_column.set_cell_data_func(pkg_toggle_renderer, self.pkg_toggle_renderer_view_func) pkg_icon_renderer = Gtk.CellRendererPixbuf() pkg_icon_renderer.set_property(ypad, 2) pkg_icon_renderer.set_property(stock-size, Gtk.IconSize.MENU) pkg_column.pack_start(pkg_icon_renderer, False) pkg_column.set_cell_data_func(pkg_icon_renderer, self.pkg_icon_renderer_view_func) pkg_label_renderer = Gtk.CellRendererText() pkg_label_renderer.set_property(ypad, 2) pkg_column.pack_start(pkg_label_renderer, True) pkg_column.set_cell_data_func(pkg_label_renderer, self.pkg_label_renderer_view_func) pkg_column.set_sizing(Gtk.TreeViewColumnSizing.FIXED) pkg_column.set_expand(True) self.treeview_update.append_column(pkg_column) Thank you! Dylan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_filename_to_uri() issue in glib-win32
On Wed, May 23, 2012 at 06:48:31AM +0100, John Emmas wrote: But whatever that (second) character looked like, it's decimal value would always be 246 (because the UTF-8 sequence C3 B6 translates to decimal 246). The URI translation of decimal 246 is %F6. This is nonsense. Percent-encoding consists of % followed by *two* hexadecimal digits and encodes *bytes*, see http://tools.ietf.org/html/rfc3986#section-2.1 If things worked as you suggest you would not be able to encode any codepoint larger than 255 and the entire thing would be pretty useless. Yeti ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_filename_to_uri() issue in glib-win32
On Wed, 2012-05-23 at 06:48 +0100, John Emmas wrote: But whatever that (second) character looked like, it's decimal value would always be 246 (because the UTF-8 sequence C3 B6 translates to decimal 246). The URI translation of decimal 246 is %F6. U+00F6 is the Unicode codepoint but URI percent encoding never directly uses codepoints as you can encode only a single byte at a time and the range of Unicode codepoints is much larger than that (up to U+10). As Krzysztof already wrote, byte-wise encoding of UTF-8 strings is the generally recommended way to encode URIs. See also the following links: http://tools.ietf.org/html/rfc3987#section-6.4 http://www.w3.org/International/O-URL-code.html Regards, Jürg ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_filename_to_uri() issue in glib-win32
On 23 May 2012, at 08:40, Jürg Billeter wrote: U+00F6 is the Unicode codepoint but URI percent encoding never directly uses codepoints as you can encode only a single byte at a time and the range of Unicode codepoints is much larger than that (up to U+10). As Krzysztof already wrote, byte-wise encoding of UTF-8 strings is the generally recommended way to encode URIs. See also the following links: http://tools.ietf.org/html/rfc3987#section-6.4 http://www.w3.org/International/O-URL-code.html Oops, sorry Jürg, I also meant to thank you for those links. Still a bit confused really... :-( John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_filename_to_uri() issue in glib-win32
On 23 May 2012, at 10:05, John Emmas wrote: Still a bit confused really... :-( Not any more My confusion arose from the fact that the notes for g_filename_to_uri() (i.e. the note inside gconvert.c) states that its based on the requirements of RFC 2396:- http://www.ietf.org/rfc/rfc2396.txt which has no requirement for a URI string to be pre-converted into UTF-8. However, I've just been told by a colleague that RFC 2396 has been superseded by RFC 3986:- http://tools.ietf.org/html/rfc3986 by which time, the requirement had been introduced (see the very last paragraph of section 2). So yes - it looks like Glib is doing the right thing and the problem must be elsewhere. Thanks for everyone's help with this. John___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gdk threads ...
On 05/22/2012 04:46 PM, Michael Meeks wrote: On Tue, 2012-05-22 at 16:07 +0200, Stef Walter wrote: If you have more details/links on how VCL gets around this, I'd be interested. A bit of a morbid curiosity perhaps :P Sure; here is some of it: http://cgit.freedesktop.org/libreoffice/core/tree/vcl/win/source/window/salframe.cxx#n1023 Grok for ImplSendMessage I guess, lots of it is synchronous to the main thread. Those messages are handled here: http://cgit.freedesktop.org/libreoffice/core/tree/vcl/win/source/app/salinst.cxx#n732 Some boring stuff there for sure, but only ~70 lines of it. Interesting. That's an okay approach if you make sure all Win32 windows (and DC's and so on) are created explicitly in your code and not via other APIs. FWIW, g_main_context_invoke() + g_main_context_acquire() can be used to create a function with similar behavior as SendMessage. That is, it invokes its callback directly if running within the main thread, and if not invoke it as an idle and, then wait for the results using a GCond. So there's not a big performance hit for code running in the main thread. Cheers, Stef ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
