Re: Introducing emacs-webkit and more thoughts on Emacs rendering (was Rethinking the design of xwidgets)

[martin rudalics]

> Another issue is that emacs uses a GtkFixed (or a custom subclassed
> EmacsFixed for gtk3) as the container widget for the main frame
> area. There isn't a mechanism to control z-ordering of child widgets
> other than removing and re-adding them in the desired z-order, which
> is what emacs-webkit has to do in order for child frames to not render
> below the webkit widget.

I think I see something like this in the pgtk branch - a child frame
appearing beneath the parent frame's horizontal scroll bar.

> This is more an issue on the gtk side of things. With the webkit
> widget it isn't an issue since the widget doesn't define a minimum
> size so any size you request it to render at, it will obey. However
> other widgets, such as buttons, sliders, etc, have a minimum size they
> will render at. If you tell it to render itself smaller, it will
> refuse and so it's impossible to simply tell the widget "here's the
> space you have to go in". This becomes a problem when the widget needs
> to be clipped at a window boundary as gtk will happily draw the
> widgets across them as gtk has no internal knowledge of Emacs window
> boundaries being a place that widget must be clipped at. Thus every
> widget that will live in a buffer will need to be inside a custom
> container than handles this clipping for the widget.

We are already bitten by this often enough: Toolbars that auto resize
their frame, scroll bars that extend into the next window.

martin