This is still a hack, until WebKitGTK gives us a more practical and
stable way to do that. Manipulating directly the DOM inside a
webextension is a pain and only usable with unstable API atm.
Don't forget to always set the title to the current uri, this way it's
up to date when there is no title on the page (ie for local file
exploration).
Thanks to pickfire for reporting the issue.
Introduce a new string pointer overtitle in Client to be able to keep
the targeturi intact while modifying the former for overriding or not
the window title.
Connect to GDK_ENTER_NOTIFY to restore overtitle when refocusing on
window.
Instead of forcing class and instance names, which is what GTK does by
default anyway, allow the user to set the instance name, but keep the
general class as “Surf”.
Is we won't support a “-name” parameter and don't implement a parsing of
RESOURCE_NAME env variable, let's fallback on the third behaviour, use
the name of the calling executable.
That would let the user do things like 'ln -s ./surf ./surf-other;
./surf-other' and set different parameters for the two instances (in dwm
for example).
Try to generate a unique WM_WINDOW_ROLE (within the surf process)
composed of “Surf” and the view ID.
Rename *togglestat to plural *togglestats, add frame flatenning
indicator, resize array in consequence.
Use a static index instead of a dynamic one as we always use all values
anyway.
Better handling of different URIs. Filter out “about:” scheme, dont
touch URI if it contains a complete scheme (we assume "://", denotes
one), else test if given path is an actual reachable file on the
filesystem, else prepend arbitrary http:// scheme.
Regroup all toggles in an enum and handle them with a unique function
via a switch. That lets us take different actions for each toggle.
Add a frame flatenning and a dns preteching options.
Slightly new behaviour: searching again for the same string (via MOD+/)
resets the search (ie restarts search from document top).
Searching for an empty string stops the search (ie all highlights are
removed).
In fact, we have a scrolling handle ersatz for now using JavaScript
calls as we don't have access anymore to scrollbars.
We'll have to manipulate the DOM directly (later).
Quentin Rameau
Christoph Lohmann