| Age | Commit message (Collapse) | Author |
|---|
|
By default, WebKit only responds to release events. The old code
listened for press events. That's probably not the right way to do
things. We should properly "override" the release events.
Closes #56.
|
|
I was probably thinking about multibyte encodings when I left that note,
but we explicitly check whether the first two bytes are ':' and '/', so
it's fine to skip them.
|
|
|
|
Yes, this needs the two void casts to make the compiler not complain
about unused parameters, but I think "explicit is better than implicit"
here. And none of the other callbacks use this trick.
|
|
Thanks to @jun7 for helping me out!
Closes #54.
|
|
|
|
Closes #47.
|
|
|
|
|
|
CC #36.
|
|
|
|
CC #35.
|
|
CC #32.
|
|
The main process and the process that sends the message might have
different working directories. As a result, the main process might not
be able to detect "foo.html" as a file when called as "lariza foo.html".
|
|
|
|
I was still seeing this warning whenever the GtkLevelBar was set to a
value of 0:
Negative content width -2 (allocation 0, extents 1x1) while
allocating gadget (node block, owner GtkLevelBar)
This happens even in a minimal test program:
#include <gtk/gtk.h>
int
main(int argc, char **argv)
{
GtkWidget *win, *progress;
gtk_init(&argc, &argv);
win = gtk_window_new(GTK_WINDOW_TOPLEVEL);
progress = gtk_level_bar_new();
gtk_level_bar_set_value(GTK_LEVEL_BAR(progress), 0);
gtk_container_add(GTK_CONTAINER(win), progress);
gtk_widget_show_all(win);
gtk_main();
}
It would appear that it's illegal to call gtk_level_bar_set_value() with
a value of 0. Or, and that's just as likely, I don't understand how a
GtkLevelBar is supposed to work. You don't even have to call
gtk_level_bar_set_value() at all, since 0 is the default value of such a
bar.
All of this doesn't really matter, though, since GtkEntry has a built-in
progress bar that we can use.
CC #20.
|
|
I think this is a good thing to do in any case. One crashed tab/window
should no longer be able to crash all other tabs as well.
CC #28: This change also appears to be a workaround for scenario number
two (`Alt+e` can crash WebKit/lariza).
|
|
|
|
CC #28.
|
|
|
|
Closes #27.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
