| Age | Commit message (Collapse) | Author |
|---|
|
The WebKit1 version of lariza simply ignored certificate errors. I could
have turned off validation in WebKit2 as well, but I wanted to try to do
it right. :-)
Closes #12.
|
|
|
|
This is kind of a quickfix as well (related to #10). I'll have to use
this for a while to see if I'm happy with it.
|
|
Every new window added download_handle_start() as a signal handler to
the global WebKitWebContext. This is wrong anway, because the signal
handler sets the destination path; this should not be done multiple
times.
The actual crash happened when a window was closed and *then* a download
started. The window's signal handler still existed with a pointer to the
window's "struct Client". This struct, however, is now free'd and
invalid. Hence the crash.
To get rid of the crashes, only add the signal handler once. Sad thing
is, this makes the "status" level bar useless: It would only work for
the very first window ever created -- if it still existed. If that
window has been closed as well, we would still crash. Thus, remove
"status" completely.
We'll have to find a new way to announce the start of a download.
Closes #10.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
... because it's WebKit2's default.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
