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

[martin rudalics <rudalics@gmx.at>]

 > 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