The user can now configure the following:
* Whether to prefer CSDs or SSDs. But note that this is only a hint to
the compositor - it may deny our request. Furthermore, not all
compositors implement the decoration manager protocol, meaning CSDs
will be used regardless of the user configuration (GNOME/mutter
being the most prominent one).
* Title bar size and color, including transparency
* Border size and color, including transparency
Also drop support for rendering the CSDs inside the main surface.
When the compositor wants us to decide the size (it sends a configure
event with width/height == 0), then use the last unmaximized size, if
there is one.
If there isn't one, use the size from the user configuration.
Up until now, we've centered the grid on the main surface. Meaning, we
calculated the unusable area, added the user configured padding and
then centered the grid.
This may look nice at first, but doesn't anymore when you start
resizing the window. Resizing the window will cause the top+left
margins to change, which makes the text "jump" or "wobble".
So, now we fix the grid in the upper left corner defined by the user
configured padding (plus CSDs if they aren't positioned outside the
main surface).
For now, this behavior is controlled with an ifdef. At least kwin
seems very buggy when the decorations are positioned like this (but
normally you'd use server-side decorations with kwin anyway).
This commit also changes 'use_csd' to be a tri-state variable;
when instantiating a window it is set to 'unknown'.
If there's no decoration manager available (e.g. weston), we
immediately set it to 'yes' (use CSDs).
Otherwise, we wait for the decoration manager callback to indicate
whether we should use CSDs or not.
In unhook, add the generated image to a list of finished sixel images,
along with positioning and size information.
When rendering, loop this list of images, and render the images (or
parts of) that are visible.
When scrolling, check if any part of the images cover the re-cycled
lines, and if so, remove the *entire* image from the list.
This means we have the following limitations:
* The renderer always renders the whole (visible area of) the
image(s). There are times when this isn't necessary - for example,
when the image is scrolled inside the visible area.
* It would be nice if we could crop the image when parts of it is
scrolled out.
This implements basic parsing of sixel data. Lots of limitations and
temporary solutions as this is still work-in-progress:
* Maximum image size hardcoded to 800x800
* No HLS color format support
* Image is always rendered at 0x0 in the terminal
