Announcement

Collapse
No announcement yet.

GNOME Terminal Gets Text Rewrap On Resizing

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by n3wu53r View Post
    Still under heavy development; no real release. You will likely have to build from git.
    Still a lot of performance issues.
    Just tried that. It looks really great, but the performance issues are not the worst part. Copy & paste doesn't even work. Waiting for a real release.

    Comment


    • #17
      Originally posted by pizzapill View Post
      Just tried that. It looks really great, but the performance issues are not the worst part. Copy & paste doesn't even work. Waiting for a real release.
      https://github.com/p-e-w/finalterm/issues/7

      It will be fixed for the final release.

      Comment


      • #18
        It's nice that it's available but I'd rather Gnome adopt Final Term (http://finalterm.org/). It's nowhere near ready yet (doesn't handle output properly for even something like top, and uses too much memory/cpu) but it has such a good start. Its borrowed features from fish, hotwire, and probably others. That is what a nextgen terminal should look like.

        Comment


        • #19
          They say, that the feature was removed in a restructuration process of the old code base, in order to raise the code quality. Some memory leaks could be fixed that way. Maybe it will return in the future. I'm wondering if this transparency was portable to wayland, anyway. But I couldn't care less, as I préfère a solid background - makes the output way better readable for me than anything transparent.

          Comment


          • #20
            How can anyone use a transparent terminal?
            If the clean up of the code base resulted in the rewrap functionality the loss of transparency was a good sacrifice.
            Last edited by Akka; 12-10-2013, 06:19 PM.

            Comment


            • #21
              Originally posted by Akka View Post
              How can anyone use a transparent terminal?
              If the clean up of the code base resulted in the rewrap functionality the loss of transparency was a good sacrifice.
              Small monitor (laptop/netbook) & reading/applying documentation. Having a cheat sheet for new/seldomly used software in the background (vim, tmux).
              I'm a software developer and I can totally understand that they wanted to get rid of a badly written codebase, but transparency is a essential feature for me.

              Comment


              • #22
                Originally posted by oleid View Post
                I'm wondering if this transparency was portable to wayland, anyway.
                I suspect not. I don't know about how gnome-terminal did it (I've never used that feature), but the approach taken elsewhere is pretty hacky. You can't get real transparency, so what they do is basically take a screenshot, and use that as a background image for the window. And that's definitely something that would be suspect under Wayland - it's a real security issue, for starters - and I know that with the port to Wayland, the Gnome screen capture tool had to be re-written such that the compositor does most of the work.

                The correct way to do it would be for the application to integrate with the compositor, requesting non-opaque blending for a particular region of the window... but I imagine that would need a bit of work to pull off.

                Comment


                • #23
                  Originally posted by Delgarde View Post
                  I suspect not. I don't know about how gnome-terminal did it (I've never used that feature), but the approach taken elsewhere is pretty hacky. You can't get real transparency, so what they do is basically take a screenshot, and use that as a background image for the window. And that's definitely something that would be suspect under Wayland - it's a real security issue, for starters - and I know that with the port to Wayland, the Gnome screen capture tool had to be re-written such that the compositor does most of the work.

                  The correct way to do it would be for the application to integrate with the compositor, requesting non-opaque blending for a particular region of the window... but I imagine that would need a bit of work to pull off.
                  fwiw, the screenshot-the-desktop approach is just fallback if you don't have a proper compositing window mgr.. and ARGB windows/surfaces are completely possible with wayland, probably easier since you don't have to worry so much about fallback paths (ie. non-compositing window mgr, etc)

                  BR,
                  -R

                  Comment


                  • #24
                    Originally posted by robclark View Post
                    fwiw, the screenshot-the-desktop approach is just fallback if you don't have a proper compositing window mgr.. and ARGB windows/surfaces are completely possible with wayland, probably easier since you don't have to worry so much about fallback paths (ie. non-compositing window mgr, etc)
                    How does it work, for the application to declare that *part* of the window is, say, "black, 80% opaque"? It's easy for a compositor to automatically make an entire window translucent, or to make the window decorations and border glassy (like Windows 7 does), but it's much harder for the application to tell the compositor that "everything is opaque except for this bit in the middle"...

                    Comment


                    • #25
                      Originally posted by Delgarde View Post
                      How does it work, for the application to declare that *part* of the window is, say, "black, 80% opaque"? It's easy for a compositor to automatically make an entire window translucent, or to make the window decorations and border glassy (like Windows 7 does), but it's much harder for the application to tell the compositor that "everything is opaque except for this bit in the middle"...
                      I don't know too much about wayland. Wayland doesn't draw on behalf of the clients, and the client does all the drawing themselves, that's where my idea comes from. What I want to ask is: considering the above, does "drawing" include alpha information? If so, then does it mean that the client can control the transparency of different parts of its window?

                      Comment


                      • #26
                        Originally posted by Delgarde View Post
                        How does it work, for the application to declare that *part* of the window is, say, "black, 80% opaque"? It's easy for a compositor to automatically make an entire window translucent, or to make the window decorations and border glassy (like Windows 7 does), but it's much harder for the application to tell the compositor that "everything is opaque except for this bit in the middle"...
                        I don't know for sure, but I think what Rob's alluding to is the compositor should/could use the alpha transparency the application draws it's background with to do the blending. So if the alpha is 50% (128, 0x80) then the background will be blended 50% with what's behind it.

                        Comment


                        • #27
                          Originally posted by robclark View Post
                          fwiw, the screenshot-the-desktop approach is just fallback if you don't have a proper compositing window mgr.. and ARGB windows/surfaces are completely possible with wayland, probably easier since you don't have to worry so much about fallback paths (ie. non-compositing window mgr, etc)
                          The fallback for the non-composed desktop was not using a screenshot, but the current desktop wallpaper. I don't know how the composed case worked, though.

                          I don't know for sure, but I think what Rob's alluding to is the compositor should/could use the alpha transparency the application draws it's background with to do the blending. So if the alpha is 50% (128, 0x80) then the background will be blended 50% with what's behind it.
                          That would be the cleanest solution, IMHO. It might work for wayland, but I have a feeling it won't work for X11. AFAIR X11-windows are opaque, however, you can make the whole window transparent.

                          Comment


                          • #28
                            This is fantastic! But I guess it has a performance impact, the terminal has to keep all the output in a buffer of some sort, and reprint it to the new size of the terminal. Before, the terminal could just render the output, and then throw the text strings away, right? Or have they always kept the actual strings in memory?

                            Comment


                            • #29
                              Originally posted by Delgarde View Post
                              How does it work, for the application to declare that *part* of the window is, say, "black, 80% opaque"? It's easy for a compositor to automatically make an entire window translucent, or to make the window decorations and border glassy (like Windows 7 does), but it's much harder for the application to tell the compositor that "everything is opaque except for this bit in the middle"...
                              surfaces can be ARGB, so if a app wants part of a window to be translucent, it just plugs in appropriate alpha component value

                              (application can declare an opaque-region, but that is simply an optimization hint for the compositor)

                              Comment


                              • #30
                                Originally posted by Azpegath View Post
                                This is fantastic! But I guess it has a performance impact, the terminal has to keep all the output in a buffer of some sort, and reprint it to the new size of the terminal. Before, the terminal could just render the output, and then throw the text strings away, right? Or have they always kept the actual strings in memory?
                                They keep them in the rollback buffer, but reflowing is some additional complexity.

                                Comment

                                Working...
                                X