Age | Commit message (Collapse) | Author |
|
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.
|
|
Add a gitignore file (Fix #17)
|
|
|
|
|
|
|
|
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.
|
|
This reverts commit 5f595f1cad47a3b70c0571b4a80d240214a45b5f.
@okraits mentioned in #8 that his fork no longer exists.
|
|
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.
|
|
Addressing the issues mentioned in the README:
- I'm using it every day and I haven't found any more bugs (in lariza).
- "View source" mode is still not implemented. However, I don't see any
other way than re-downloading the current weg page and showing the
results in some to-be-written widget that displays text (+ HTML syntax
highlighting + maybe other stuff). That's quite a lot of overhead for
a rarely used feature, so I decided to drop it.
- That "annoying border around the WebView widget" is related to my gtk
theme (upstream "Raleigh"). Adwaita, the current GTK+ 3 default theme,
does not have that border.
tl;dr: The WebKit2 port is as ready as it can get and it's "more bug
free" than the WebKit1 version.
|
|
|
|
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.
|
|
|
|
|
|
|
|
As suggested by #8.
|