Age | Commit message (Collapse) | Author |
|
|
|
Hide progress bar once the webpage has finished loading
|
|
|
|
CC #36.
|
|
CC #36.
|
|
This was relevant some years ago. Today, Flash is dying quickly and I
don't even care about Java anymore. On top of that, support for these
two things never was a feature of lariza but of WebKit.
|
|
|
|
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.
|
|
|
|
|
|
|
|
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 #25.
|
|
|
|
|
|
|
|
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.
|
|
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.
|