GNOME Bugzilla – Bug 765699
Not showing line numbers
Last modified: 2016-10-29 20:14:06 UTC
Created attachment 326902 [details] Screenshot I'm using Archlinux with MATE desktop. Since an gtk3 and mate update 2-3 weeks ago, bluefish 2.2.8 is not showing line numbers any more. I tried: - bluefish svn-version - change many gtk/mate-themes - delete $HOME/.bluefish/ but without any success. Thank you!
Information: Same problem on another Archlinux computer with MATE desktop.
I have not a clue what could cause this... I've not yet seen this on other computers. Perhaps mate has a patch on gtk that interferes with this feature?
What can i do for find/debugging the problem? I use bluefish every day for work :(
Created attachment 327486 [details] gtk messages when bluefish started in a shell
The errors you posted are errors in the GTK theme that you use. Have you tried if this is a theme issue? If you change to a different gtk theme, does that change anything?
Okay. I tried every theme on my system. Adwaita, Mate Themes, Traditional Themes, Vertex Themes and so on. Of couse the theme in bluefish changed, but with every theme there is a "blank" line numbers column on the left. Same issue on my friends laptop with archlinux and mate-desktop, too. Thank you! :)
This bug is being caused by a change in behavior introduced with the release of GTK 3.20. I have been really busy at work. So I have not yet had time to look at exactly what it causing the problem. It effects anything displayed in the left margin. Not just the line numbers. I should have time to fix it this weekend.
I spent a couple hours on this last night with no luck fixing this bug yet. What I see is broken, there may be more... Anything displayed in the left margin. The right margin still works. Current line highlighting Highlight cursor position A search this morning turned up a couple useful links. But a quick try this morning with the changes listed still did not fix the bug. I'll try to look at it some more tonight. https://blogs.gnome.org/mclasen/2015/11/20/a-gtk-update/ https://feaneron.com/2016/01/04/quick-guide-to-port-an-app-for-gtk-3-20/
Any news for this annoying bug: bluefish is almost unusable without line numbers.
My apologies i have not had time to look at this again. I'm hoping that the upcoming holiday weekend will give me the time to finally resolve this issue.
Thanks. Bluefish is an awesome app, and we like it bug free! :)
Just an update for everyone. Apparently in GTK 3.20 the way layers are drawn on GtkTextView was changed. A draw_layer vfunc was added in GTK 3.14, but it's behavior was changed in 3.20. From the docs.. The draw_layer vfunc is called before and after the text view is drawing its own text. Applications can override this vfunc in a subclass to draw customized content underneath or above the text. In the GTK_TEXT_VIEW_LAYER_BELOW_TEXT and GTK_TEXT_VIEW_LAYER_ABOVE_TEXT the drawing is done in the buffer coordinate space, but the older (deprecated) layers GTK_TEXT_VIEW_LAYER_BELOW and GTK_TEXT_VIEW_LAYER_ABOVE work in viewport coordinates, which makes them unnecessarily hard to use. These were added in 3.20 and the old ones depreciated. GTK_TEXT_VIEW_LAYER_BELOW_TEXT The layer rendered below the text (but above the background). Since: 3.20 GTK_TEXT_VIEW_LAYER_ABOVE_TEXT The layer rendered above the text. Since: 3.20 Because we currently draw the left margin before the parent class draw event is called, our left margin is being painted over. Simply moving the call to the parent class draw event first restores the left margin. However this is not the fix. Highlight current line and highlight cursor position overwrite the drawn text. For GTK >= 3.20 all of the custom drawing code will have to be moved/rewritten to work in the draw_layer vfunc.
I'm trying to install a virtual machine with gtk 3.2 (fedira rawhide failed, so switching to ubuntu unstable right now) to see if I can work it out
ok, I can reproduce it now.
Created attachment 329168 [details] [review] patch for bug 765699 Patch is attached. It should be tested to make sure it still compiles/works with GTK versions < 3.20 before it's committed.
Created attachment 329176 [details] screenshot of distance Thanks, the patch works fine on Arch! Harmless blemishes: the distance between line numbers and content looks a littlebit tiny.
Created attachment 329183 [details] screenshot spacing different theme A different theme on my system makes the small gap not as noticeable. A slightly larger spacing would look better.
the patch works fine on gtk 3.10 and gtk 3.20 The gtk-3.20 test was in a virtual machine in which Xorg took a few times 100% cpu while testing but that might be caused by the VM and not by the patch. My only problem is: why does the patch work? your code touches the cursor and current line highlighting, not the line numbers? Or was the call to the parent class draw function missing for the line numbers?
(In reply to Olivier Sessink from comment #18) > The gtk-3.20 test was in a virtual machine in which Xorg took a few times > 100% cpu while testing but that might be caused by the VM and not by the > patch. That's a vm issue. Not a problem with the patch. Works fine with GTK 3.20. > > My only problem is: why does the patch work? your code touches the cursor > and current line highlighting, not the line numbers? Or was the call to the > parent class draw function missing for the line numbers? The call to the parent class draw event was always there and still is in the same place for older GTK versions. It just needs to be called first with GTK 3.20 or the left margin is drawn then painted over. I added a 3.20 only call first. The left margin, current line and cursor highlighting were all broken by the changes in 3.20. From my earlier reply in comment 12. This is a key part... "In the GTK_TEXT_VIEW_LAYER_BELOW_TEXT and GTK_TEXT_VIEW_LAYER_ABOVE_TEXT the drawing is done in the buffer coordinate space, but the older (deprecated) layers GTK_TEXT_VIEW_LAYER_BELOW and GTK_TEXT_VIEW_LAYER_ABOVE work in viewport coordinates" It took me while to figure out what they changed in 3.20. I knew what the problem was as soon as I read the above in the docs. Everything I could find before that passage, led to believe it was just a color related issue from all the CSS changes in 3.20. It drove me crazy for a little while trying to figure it out.
*** Bug 767518 has been marked as a duplicate of this bug. ***
I can confirm the patch works on Bluefish 2.2.8