To position the page-info window we have to tunnel all the
way from the current scaffolding, via its top-level gui window,
through to the toolbar. In the toolbar we look up the URL bar
and then determine the screen coordinates of the scaffolding
via the top level widget GTK semantics.
Finally we place the page-info window 4 pixels down and right of
the bottom-left of the entry box, which should look nice.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
In order for GTK windows to be styled properly, in the context
we use them, the page-info windows need to be marked as popup
windows (typically used for transient popups such a menus, so
ideal for us).
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
This makes the page info properly transient and causes it
to handle activity in the corewindow and outside itself
properly. This includes ensuring that actions outside
the window will close it, etc.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
Some mouse actions perform a positive action (such as opening
the SSL certificate viewer). As such, provide an out param
which will be set to true if the action did something. This
parameter is not touched in the case of nothing happening in
case it is used in alternating logic in the caller.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
When we close the JS compartment we try and cancel all callbacks so that
they do not fire after the compartment is closed. However if we have
in-train callbacks, they can gum up the closedown and so we need to check
and if we've done all we can, we break out of the callback removal loop.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
This reduces the source complexity of the html_mouse_action()
previously this was a single function of several thousand
lines with over 30 local variables allocated on the stack.
Variables are now mostly held in a single static structure which
drasticaly reduces the size of stack frame required and improves
lookup locality.
The generated code does cause two additional function calls as the
compiler avoids inlining the sub functions. The optimiser seems to
produce somewhat better code within the sub functions.
In the final analysis there appears to be no significant performance
loss or gain with this change, just more readable source.
