GTK3: Filter Editor misses column headers for filter primitive list

Bug #1066808 reported by su_v on 2012-10-15
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Alex Valavanis

Bug Description

With GTK3 builds, the filter editor dialog has major usability deficiencies:
- the names of the filter primitives are not rendered in the TreeView for the filter primitive list
- the column headers are missing for the list of filter primitives: this causes click (or drag) events to act on a different primitive than the one below the current pointer position (apparently offset by one row - the missing column headers).

Reproduced with Inkscape 0.48+devel 11801 on OS X 10.7.4:
- gtk3/x11 3.4.4, gtkmm 3.4.0, glib 2.32.4
- gtk3/quartz 3.6.0, gtkmm 3.5.12, glib 2.33.10

su_v (suv-lp) wrote :

Screenshot with GTK3/Quartz 3.6.0 on OS X 10.7.4

tags: added: ui
removed: filters-svg
tags: added: gtk3
removed: gtk3-regression
jazzynico (jazzynico) wrote :

Reproduced on Windows XP, experimental GTK3 build (gtk3-3.6.1, gtk3mm-3.4.0), trunk revision 11960.

Changed in inkscape:
importance: Undecided → Medium
status: New → Triaged
Alex Valavanis (valavanisalex) wrote :

* The GTK+ 2 expose_event handler sets up a cairo context using the bin_window.
* The GTK+ 3 draw handler uses the widget window coordinates.

Fixing this should be a case of
1. Change the expose_event handler to use the widget window (so that GTK+ 2 and GTK+ 3 are using the same cairo context)
2. Use the Gtk::TreeView::convert_*_to_*_coords() functions in the draw handler to render things in the correct locations.

Alex Valavanis (valavanisalex) wrote :

Should be fixed in lp:inkscape r11997

Changed in inkscape:
assignee: nobody → Alex Valavanis (valavanisalex)
milestone: none → 0.49
status: Triaged → Fix Committed
su_v (suv-lp) wrote :

Reopening - the filter primitives and the connections are partially drawn outside the filter primitive list (below, over the effect parameter settings, and in the table headers (when scrolling the list of filter primitives of a more complex filter effect) - see also attached screenshot. AFAICT this was introduced with the changes in r11996.

Reproduced with GTK3/X11 3.4.4 and GTK3/Quartz 3.6.2 on OS X 10.7.4.

So far reports about "regressions" with experimental GTK3 builds had been closed as 'Fix Released' without setting a milestone, because the fixed issue never occurred in a stable released version [1]. Has something changed recently with regard to these kind of reports that I missed?

[1] <>

Changed in inkscape:
status: Fix Committed → In Progress
Alex Valavanis (valavanisalex) wrote :

Wow, that's ugly...

Not fully reproduced with Ubuntu 12.10 amd64, Gtkmm 3.5.13/Gtk+ 3.6.0 but I do see some similar glitches when I scroll through the list.

would you mind checking that there are no regressions in the GTK+ 2 build also?

Also, yes, I guess "Fix Released" probably makes sense for GTK+ 3 issues per your description.

su_v (suv-lp) wrote :

> would you mind checking that there are no regressions in the
> GTK+ 2 build also?

GTK2 builds on OS X are ok - tested with both backends of GTK+ (X11, Quartz), independent of gtk theme used, and independent of cairo version.

su_v (suv-lp) wrote :

Another GTK3 screenshot - this time using GTK+/X11 3.4.4, gtkmm 3.4.0, cairo 1.12.2, Ubuntu Ambiance theme (from Precise, for Gnome 3.4). With this theme and backend, the area with the filter primitive description (below the list of currently used filter primitives) is not affected, but the tabs below with the effect parameters still is.

su_v (suv-lp) on 2013-10-04
Changed in inkscape:
milestone: 0.49 → none
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers