Peter Hofmann [Sat, 29 Aug 2015 14:23:03 +0000 (16:23 +0200)]
Retab
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.
Peter Hofmann [Sat, 29 Aug 2015 10:49:53 +0000 (12:49 +0200)]
GtkBox: Don't manually specify a padding
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.
Peter Hofmann [Mon, 5 Jan 2015 19:05:35 +0000 (20:05 +0100)]
Implement a simple certificate trust store
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. :-)
Peter Hofmann [Thu, 1 Jan 2015 08:31:42 +0000 (09:31 +0100)]
The WebKit2 port is "read for use"
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.
Peter Hofmann [Sun, 14 Dec 2014 13:15:04 +0000 (14:15 +0100)]
Quickfix for crashes when downloads start
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.
Peter Hofmann [Sat, 9 Aug 2014 16:25:30 +0000 (18:25 +0200)]
Minor improvement to changed_download_progress()
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".
Peter Hofmann [Fri, 4 Jul 2014 15:19:36 +0000 (17:19 +0200)]
Mod1 + d closes the download manager
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".
Peter Hofmann [Thu, 19 Jun 2014 05:48:38 +0000 (07:48 +0200)]
Rework and extend hotkeys
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.
Peter Hofmann [Wed, 18 Jun 2014 19:37:04 +0000 (21:37 +0200)]
Kick the lousy status bar
- It didn't show the load progress.
- It destroyed the browser's usability. When there's a horizontal scroll
bar, it MUST be placed at the bottom of the screen. There MUST NOT be
any widget below it.
Peter Hofmann [Tue, 17 Jun 2014 17:23:27 +0000 (19:23 +0200)]
Built-in download feature
Downloading via an external tool poses a problem: You have to pass the
current "web context" from the browser to your tool. This context
comprises cookies, the referrer, the user agent and information about
HTTP basic auth. With some effort, you can pass most of this to your
tool -- except for HTTP basic auth.
tl;dr: Downloading via wget is pretty complicated.
With this commit, WebKit handles the downloads. What's missing, are some
GUI elements to monitor and cancel downloads.
Peter Hofmann [Tue, 17 Jun 2014 15:14:34 +0000 (17:14 +0200)]
Fix and enhance creation/destruction of tabs
Websites can now open or close tabs/windows if requested by the user.
- We must not destroy the window in its destroy handler.
- WebKit's "new-window-policy-decision-requested" is totally irrelevant.
- Handle WebKit's "create-web-view" by allocating a new window and an
"empty" WebView.
- Handle WebKit's "close-web-view" by destroying the window, which will
call client_destroy(), which will do exactly the same as closing the
window manually.
Peter Hofmann [Sun, 15 Jun 2014 13:36:21 +0000 (15:36 +0200)]
User configuration using environment variables
I think of these options (language, download dir, zoom) as user
settings. The user does not change them all the time. He sets them once
and for all in his shell rc.
"-e" and friends, however, are considered runtime settings. "THIS TIME,
I want my browser to debug all requests!"