| Age | Commit message (Collapse) | Author |
|---|
|
I want to change ensure_uri_scheme() so it automatically adds "file://"
if we're dealing with a valid local file path. However, this clashes
with "/" as a search prefix.
CC #27.
|
|
|
|
Closes #23.
|
|
|
|
~/.local/share isn't really an appropriate place because it's meant to
contain "data", possibly written by the application.
Usually, lariza's web extensions (.so files) are not placed in your home
directory anyway. Instead, they are installed somewhere in /usr. The
home directory only contains symlinks. So, in a way, those symlinks can
be considered "configuration items". Hence, ~/.config is where they
should live.
|
|
I'm not comfortable with having pixel values in here. The 100px were
mostly personal taste. HiDPI screens might not be happy with 100px
anyway.
|
|
Fixes this:
(lariza:675): Gtk-WARNING **: Negative content width -2 (allocation 0, extents 1x1) while allocating gadget (node block, owner GtkLevelBar)
Funny enough, even without calling gtk_level_bar_set_value(), I get this
warning. Almost feels like a Gtk bug?
Closes #20.
|
|
Edited to retain Mod1+* and just add F2/F3.
|
|
|
|
Closes #14.
|
|
Closes #15.
|
|
For the sake of consistency. There is no reason why this particular
directory can be configured at runtime.
|
|
For years, I've been using a tab size of 4. This, however, conflicts
with the idea of limiting the line length: You can only limit the line
length in a meaningful way if you're using the default tab size of 8.
But 8 is a huge waste of space...
So let's just do this. Retab to 4 spaces and limit the line length to
about 80 characters.
|
|
|
|
This might look good on my display, but on a display with a different
DPI value, it's probably garbage. Specifying space in pixels is
meaningless today.
Yes, this applies to the level bar and the window size as well. I have
not yet found a better way to control those, though.
|
|
I always use a tiling WM, so I never noticed that, when lariza is
floating, the window is unusably tiny and you always have to resize it
first.
|
|
"-C" was kind of broken. It only prevented lariza from writing to the
FIFO which "worked fine" as long as you only had one "-C" instance
running.
|
|
Why? See #13. This commit closes #13.
|
|
|
|
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.
|
