OK, it is now safe to write this post. The April 1st has passed, and
now all of us (except the Onion news authors, obviously) are returning
to the every-day reality.
Unfortunately, I don’t have enough time lately to do anything
serious, so I’ve tackled the multi-process web browser that I have mentioned last time.
It received some standard web-browsing features such as loading a
page when you type the address in the address bar, and similar :)
But that’s not the reason behind writing this this post. You know how
Firefox and Konqueror ask you whether you want to restore your last
session after a crash? Well, it is a good feature, but I’ve got one even
better.
Webbie Notifications
When a site makes an illegal move, and induces a crash in QtWebKit,
instead of crashing the whole application (like in most other browsers),
it only closes the tab it belongs to. OK, that’s not new. The new thing
is that I’ve ported a notification system that I made some time ago for
another application, so that when a tab is lost, it can be recovered
very easily - just click ‘Reopen’ (see the screenshot).
I haven’t used KDE’s system wide notifications since I wanted to make
them local (there’s no point in bogging the system notifications with
things like these).
The next step will be to implement more advanced, but still standard
browsing features. The smart address bar will be one of the first. It
could probably end up in Konqueror and Rekonq eventually. (Nepomuk tags
for bookmarks…)
Since Raptor is coming slower than we are hoping, I decided to give
you all a preview of what it will behave like.
Starting with the revision r945664, you’ll be able to see all the
glory of the Raptor mode for Lancelot.
This is probably the last feature that will be introduced in Lancelot
for KDE 4.3. I’m not sure about the category buttons on top, because
they don’t really have a purpose now, and the no-click paradigm doesn’t
really work in Raptor mode, but it is still retained as an option.
There are some layout problems, but those will be fixed in time for
4.3.
I hope you’ll like it. If you want to test it before 4.3, just
compile the SVN trunk.
I was wondering how hard would it be to create a web-browser that is,
like Google’s Chrome, separated in different processes for different
tabs. You know, the whole “security problems and crashing are restrained
to single tab” thing.
As it turned out, it is not all that difficult. Create the main
window, start the WebKit (QWebView) in another program, then X-Embed the
later in the former, and communicate via D-Bus. (I got the idea to do
this from Embed Window plasmoid :) )
If the child crashes, only one tab is gone. If the main application
crashes, tabs become independent windows.
I’m not sure whether I’ll continue to work on this, but if I find the
time, you could see a Rekonq-based (http://rekonq.sourceforge.net/)
browser that is similar to Chrome someday.
Since I’m planning to make the Favourites section a bit smarter
sometime in the future (something like Amarok’s score/rating system),
but it will not happen in time for KDE 4.3, I’ve come up with an idea of
tracking the user’s (your) behaviour and to record which applications
you start. And, maybe, which item you choose from the list when you
search for something.
Before you start throwing rocks at me, here are some details about
the idea.
It would be local only. The collected data would not be sent
anywhere and would remain in your .kde directory for all times. It would
be optional. Though I don’t know whether to turn it on by default or
not. In any case, I think some “what’s new / set up the new features”
notification would be needed.
The data would not be used in the KDE 4.3 version, but in a later
one.
So, in a nutshell, it would collect the data which would be used once
the Favourites section becomes smart.
My questions here are:
Should the tracking be turned off by default? *
Should it be implemented at all before the Fav section gets
smarter?
Note that once the Fav section does become smart, it will be
changed to ‘on by default’.
