#1611 Black square appears after selecting text

Bug
closed-fixed
3
2015-06-20
2014-06-16
Sworddragon
No

I'm using SciTE 3.4.2 (it seems with a basic default GTK+ theme) on Linux 3.15 and if some text gets selected the first time a black aquare appears on the bottom right corner (in the attachments is a screenshot).

1 Attachments

Discussion

  • Neil Hodgson

    Neil Hodgson - 2014-06-16
    • labels: --> scintilla, gtk
    • status: open --> open-accepted
    • assigned_to: Neil Hodgson
    • Priority: 5 --> 3
     
  • Neil Hodgson

    Neil Hodgson - 2014-06-16

    The bottom right corner has always had problems on GTK+ and I won't be working on it further.

     
  • Colomban Wendling

    Attached is a patch that paints the scrollbars junction specifically, in the same way GtkScrolledWindow does it. It however only works on GTK >= 3.4.

    I however still don't know why we get the weird black background in the first place, because all I can read suggests it should paint the default background the same way other GTK widgets do. This actually seem to be some transparent, but then should just reveal the background of the parent container, ultimately the window at least.

    Anyway, this patch hides the issue on GTK >= 3.4 as it paints above, which is actually the right thing there. But this doesn't fix GTK < 3.4.

     
    • Neil Hodgson

      Neil Hodgson - 2015-05-22

      I'm going to defer this until after 3.5.6.

       
    • Sworddragon

      Sworddragon - 2015-05-25

      If I'm understanding this correctly:

      • The corner is unpainted or transparent and should be fallback to the first painted parent.
      • GTK+ 3.4 introduced a feature that makes it possible to paint such corners.

      Wouldn't this also mean that the black corner is maybe just a GTK+ bug?

       
      • Colomban Wendling

        _

        • The corner is unpainted or transparent and should be fallback to the first painted parent.

        Basically. In practice we have what looks like the appropriate code telling GDK how to paint the back window by default. This should in theory ensure it's painted properly initially, and we just paint above that.

        Well, in the process of trying to understand the issue here I saw we have some slightly suboptimal code paths regarding that, but none of those were the issue (and actually should be just fine in practice).
        I'll probably submit those small changes soon, but none of those fix the issue.

        Also, note that here the issue is in the base widget (the container). The main part of ScintillaGTK is actually 4 widgets:

        GtkContainer (wMain)
         + GtkDrawingArea (wText)
         + GtkScrollbar (scrollbarv)
         + GtkScrollbar (scrollbarh)
        

        The problem here is in how wMain is painted, and it doesn't only affect the corner but all of it. It's only visible there however, because it's the only area of it without anything on top.

        • GTK+ 3.4 introduced a feature that makes it possible to paint such corners.

        Yes. Well, in practice we can very well draw it in earlier versions too, but we don't know the color to use. From what I could try and see, it really is just transparent indeed, so painting again with that won't help.

        We could paint with a random color of our choice, but it wouldn't be a real fix either.

        Wouldn't this also mean that the black corner is maybe just a GTK+ bug?

        Maybe, but I wouldn't be so quick to say that. I never saw that issue with any other GTK widget, which suggests it's something we do (or don't) that breaks it. Also, let's be honest: ScintillaGTK is definitely not the cleanest GTK widget around, containing its fair share of hacks, is it to accommodate to the platform abstraction, or to support a wide range of GTK versions.
        So, while I couldn't find what would be wrong, I'm not positive either it's not our fault.

         
        • Neil Hodgson

          Neil Hodgson - 2015-05-27

          ScintillaGTK is definitely not the cleanest GTK widget around, containing its fair share of hacks, is it to accommodate to the platform abstraction, or to support a wide range of GTK versions.

          The structure of the widget is some of the earliest GTK+ code I wrote for GTK+ 1.2 15 years ago. Its quite likely that something better could be designed now by someone who understands GTK+ more than me. Other platforms now have much different structures: Cocoa uses two views: one for the margin and another for the text so that it can take part in Cocoa's 'responsive' multi-threaded scrolling.

          Using GtkScrolledWindow and implementing GtkScrollable may be a worthwhile direction. This appears to imply pixel based vertical scrolling. While I personally prefer whole line scrolling and Scintilla does not yet provide API support for a partially visible top line, this is not necessarily a blocker. Ideally, the application could choose between pixel and line scrolling and APIs would be added for setting and getting the position in either unit.

           
        • Neil Hodgson

          Neil Hodgson - 2015-05-29

          I never saw that issue with any other GTK widget, which suggests it's something we do (or don't) that breaks it.

          This sort of issue, where a change in state overflows an item, may be due to not restoring some state as expected. We may need some calls to cairo_save/cairo_restore in the drawing code.

           
  • Neil Hodgson

    Neil Hodgson - 2015-05-29

    Fix committed as [b143b6].

    Thanks for writing a good patch with the bug ID in the commit message as this helps understanding the project history.

     

    Related

    Commit: [b143b6]

  • Neil Hodgson

    Neil Hodgson - 2015-05-29
    • status: open-accepted --> open-fixed
     
  • Neil Hodgson

    Neil Hodgson - 2015-06-20
    • status: open-fixed --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks