| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
With WebKit2, adblock is no longer a trivial task. It must be realized
as a "web extension" in WebKit2. See, for example:
http://blogs.igalia.com/carlosgc/2013/09/10/webkit2gtk-web-process-extensions/
We need to connect to the "send-request" signal and stop the request
from being sent in the first place.
|
|
|
|
|
|
|
|
Plus, my "80 characters" only work with 4-spaced-tabs anyway. I might
rethink that.
|
|
MB is good enough, I don't care about byte, kilobyte, megabyte,
gigabyte, ...
Yes, SI units.
|
|
I checked WebKit's source code: webkit_download_get_destination_uri()
never returns NULL in lariza. It's because we set the destination URI in
the signal handler for the download request.
If g_filename_from_uri() really returned NULL for some reason, then it'd
be just plain wrong to announce the "suggested file name", because we
might be saving the download ... somewhere else. I doubt this function
ever returns NULL in lariza, though, but you never know.
So, now, the download manager will correctly show the URI if the
destination URI is "unknown".
|
|
CC #6.
|
|
Ugly hackaround. Closes #6, though.
|
|
CC #5.
|
|
Closes #5.
|
|
As suggested by @okraits in #2.
|
|
While Mod1 + q is consistent with the main window, it also poses the
risk of accidentally closing the main window. With Mod1 + d it's more
like a "toggle the download manager".
|
|
|
|
Let's stick to WebKit's and GNOME's terminology.
|
|
|
|
Disconnect the handler for "notify::progress" because that signal might
get fired after "c" has been free'd which resulted in a reproducible
crash.
|
|
|
|
|
|
GLib catched these errors but it's wrong nevertheless.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Invalid regexes are no longer added to the list.
- Lines starting with a "#" are ignored.
|
|
|
|
|
|
|
|
This allows for launching lariza like this:
$ LARIZA_FIFO_SUFFIX=1 lariza file:///home/void/bookmarks.xhtml
And another instance like this:
$ LARIZA_FIFO_SUFFIX=2 lariza http://www.startpage.com
|
|
|
|
hjkl is nice in a terminal, but it poses a problem in GUI programs: If
your program is not ENTIRELY controlled via keyboard, your right hand
has to reach from the mouse to the keyboard to the mouse to the
keyboard... That's nasty.
Now, all hotkeys can be hit using your left hand.
I also think that using Control as a modifier is uncomfortable. Your
pinkie has to do a lot of work and stays in an uncomfortable position.
Using Alt/Mod1 feels better.
Secondly, there's no need for scrolling hotkeys. This only makes sense
if your program has keyboard-only usage. I can scroll using the mouse
(plus, I have screen barriers to support this).
Furthermore, there's a hotkey now that enters search mode and hotkeys to
create or destroy windows/tabs.
I also differentiate between single-handed hotkeys and dual-handed
hotkeys. When you enter the location bar or search mode, you are going
to begin typing -- thus, your right hand MUST move from the mouse to the
keyboard. As a result, it doesn't make sense to make these hotkeys
reachable using only your left hand. Mod1+l to enter the location bar is
totally fine and so is Mod1+k for searching.
Of course, it's more comfortable if you can also close the download
manager using Mod1+q. Reloading is useful as well and I NEVER want to
have "reload WITH using the cache" (major annoyance of other browsers).
To sum it up, your left hand can stay relaxed over q, w, e, d.
|
|
|
|
Hit ^D to open it.
According to sloccount, we have reached 731 lines of code now.
|
|
|
|
|
|
|
|
- It didn't show the load progress.
- It destroyed the browser's usability. When there's a horizontal scroll
bar, it MUST be placed at the bottom of the screen. There MUST NOT be
any widget below it.
|
|
Downloading via an external tool poses a problem: You have to pass the
current "web context" from the browser to your tool. This context
comprises cookies, the referrer, the user agent and information about
HTTP basic auth. With some effort, you can pass most of this to your
tool -- except for HTTP basic auth.
tl;dr: Downloading via wget is pretty complicated.
With this commit, WebKit handles the downloads. What's missing, are some
GUI elements to monitor and cancel downloads.
|
|
Websites can now open or close tabs/windows if requested by the user.
- We must not destroy the window in its destroy handler.
- WebKit's "new-window-policy-decision-requested" is totally irrelevant.
- Handle WebKit's "create-web-view" by allocating a new window and an
"empty" WebView.
- Handle WebKit's "close-web-view" by destroying the window, which will
call client_destroy(), which will do exactly the same as closing the
window manually.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit 26713eb349b4c8b7d2fb22a5973e898ea43e1b7f.
It's a break between lariza and tabbed -- the latter responds to
button-press-events.
|
