Blogging is futile

Conkeror in the Debian NEW queue

abe+blog@deuxchevaux.org (Axel Beckert) — Tue, 01 Jul 2008 21:39:11 +0200

I already mentioned a few times in the blog that I’m working on a Debian package of the Conkeror web browser. And now, after a lot of fine-tuning (and I still further new ideas how to improve the package ;-) Conkeror is finally in the NEW queue and hopefully will hit unstable in a few days. (Update Thursday, 03-Jul-2008, 18:13 CEST: The package has been accepted by Jörg and should be included on most architectures in tonight’s updates.)

Those who could hardly await it can fetch Conkeror .debs from http://noone.org/debian/. The conkeror package itself is a non-architecture specific package (but needs xulrunner-1.9 to be available), and its small C-written helper program spawn-process-helper is available as package conkeror-spawn-process-helper for i386, amd64, sparc, alpha, powerpc, kfreebsd-i386 and kfreebsd-amd64. There are no backported packages for Etch available, though, since I don’t know of anyone yet, who has successfully backported xulrunner-1.9 to Etch.

Interestingly the interest in Conkeror seems to have risen in the Debian community independently of its Debian packaging. Luca Capello, who sponsored the upload of my Conkeror package, pointed me to two blog post on Planet Debian, written by people being fed up with Firefox 3 already and are looking for a more lean, but still Gecko based web browser: Decklin Foster is fed up with Firefox’ -eh- Iceweasel’s arrogance and MJ Ray is fed up with Firefox 3 and its SSL problems.

Since my previously favourited Gecko based web browser Kazehakase never became really stable but instead became slow and leaking memory (and therefore not much better than Firefox 2), I can imagine that it’s no more an candidate for people seaking for a lean and fast web browser.

Conkeror has some “strange” concepts of which the primary one is that it looks and feels like Emacs:

The current location is shown in a status bar below the website, where Emacs usually shows buffer names. All input, even entering new URLs to go to, is done via the mini-buffer, an input line below the status bar.
Instead of tabs it uses Emacs’ concept of buffers. So no tab bar clutter and though easy access to all currently open pages.
It has no buttons, menu-bar or such. And except the status bar and mini-buffer, it uses the whole size of the window for the displayed web page. This is the main reason why I prefer Conkeror on the 7” EeePC: I don’t want to waste any pixels for buttons or menu bars and still have a fully functional web browser.
It of course has Emacs alike keybindings (with a slight touch of Lynx). While this may seem awkward for the vi world (Hey, they have the vimperator^*, also in Debian since a few days!), as an Emacs user you just have to remember that you web browser now also expects to be treated like an Emacs. It just works:

C-x C-c
Exit Emacs -eh- Conkeror

C-x C-f
Open File -eh- web page in new buffer

C-x C-b
Change to some other tab -eh- buffer

C-x C-v
Replace web page in this buffer and use the current URL as start for entering the new one

C-x 5 2
Open new frame -eh- window

C-x 5 0
Close current frame -eh- window

C-x k
Close tab, -eh- kill buffer

C-h i
Documentation

C-s
Incremental search forward

C-r
Incremental search backward

C-g
Stop

l
Go back (Think info-mode)

g
Go to (Open web page in this buffer)

(Hehe, I like the faces of vi users having read these keybindings and now wondering how to remember them. SCNR. Well, sometimes vi key bindings are a mystery to me, too. :-)
There are of course many more and nearly all are the same as in Emacs, even the universal argument C-u and the M-x command-line are there. E.g. C-u g lets you open a web page in a new buffer, too.
Conkeror also has very promising concept for following and copying links with the keyboard only. Opera is very inefficient here since you have to jump from link to link to get to the one you want. In Conkeror you just press f for following or c for copying links and then all links on the currently shown part of the page show a small number attached to it. Then you just enter the number (and additionally press enter if the number is ambigous) and the link is either opened or copied to the clipboard.
A funny anecdote about how this concept grew over the time: Early versions of Conkeror (back in the days when it just was a Firefox externsion as vimperator) numbered all links on the page, not only the visible ones. On large pages with many links or buttons (e.g. my blog ;-), this took minutes to complete. The idea to just number the visible links is so simple and important – but someone first needed to have it. :-)

Footnotes

*) I just noticed that there is now also muttator, making Thunderbird look and behave like vim (and probably also mutt), too. Wonder into which e-mail client the Emacs community will convert Thunderbird. GNUS? RMAIL? VM? Wanderslust? What will it be called? Wunderbird? Thunderslust? (SCNRE ;-)

Surfing on two screens?

abe+blog@deuxchevaux.org (Axel Beckert) — Wed, 25 Apr 2007 22:31:38 +0200

At work, I’ve got two screens on my Sarge workstation “snitch”. Since I want to switch virtual desktops independently on both screens, I don’t have a Xinerama setup but a Dual Screen setup. So my left and right screen do have different $DISPLAY (“:0.0” and “:0.1”) set.

This is neither a problem for FVWM nor xlock nor XScreenSaver. But it is a problem for nearly every modern web browser available which checks, if there’s already an instance of it running. So if you try to start a new instance of a web browser on the other screen, most graphical web browsers make more or less problems:

Galeon 1.3 and Epiphany always opens new tabs or windows on the display where its first instance is running, i.e. ignores $DISPLAY completely except on the first call.
Kazehakase (0.3.7) just opens a new tab in the running instance.
Firefox 2.0 thinks it crashed and asks if it should restore tabs and windows. Haven’t tried any further.
Opera 9.20 pops up a dialog, says, there seems already a copy of Opera running and asks if it should continue with startup. If you say yes, only the bookmarks of one of the two instances get saved, probably those of the one with the last added bookmark or the one which exited last.

The only graphical web browsers which simply just work on a Dual Screen setup are Konqueror, Links2 (called with the -g option for a GUI), Chimera 2, Amaya and of course Dillo. Unfortunately I’m neither a fan of KDE nor of Konqueror and I do want a web browser with CSS and tab support… And Amaya is, well, only a reference implementation… (Chimera 2 from Sarge btw. segfaulted on two of the four pages I tested it with. Seems to have problems with PNG images.)

So my current setup is to have Kazehakase as my main work web browser (with all the local web applications I need) on the right screen while I have Opera on the left screen for surfing, looking up documentation, testing web pages and other things.

BTW: I don’t use Gecko based browsers for surfing on that box at the moment, since there are some web pages (the spammer vandalised Kazehakase wiki for example, at least a few months ago) which manage to be rendered in such an ugly way by Gecko so that XFree86 with the binary Nvidia (at least the last five or six versions I tried) just crashes away — either at once or when you try to switch to a text console by pressing e.g. Ctrl-Alt-F1 while such a page is displayed.

wApua now in Debian Unstable

abe+blog@deuxchevaux.org (Axel Beckert) — Sun, 15 Oct 2006 00:38:30 +0200

Hey, the actual version 0.06 of my Perl written WAP browser wApua now is in Debian Sid!

It’s the first software written by me which has entered the Debian repository as its own package (since pum is included in the package pisg which is in testing now for a while) as well as the first software debianized by me which reached Debian Unstable.

Things are always exciting when they happen the first time. ;-)

Thanks to Myon for sponsoring the package.

wApua 0.06 released

abe+blog@deuxchevaux.org (Axel Beckert) — Thu, 28 Sep 2006 03:33:59 +0200

I today released version 0.06 of my WAP browser wApua (Release announcement at Freshmeat).

The one big new thing is user friendly documentation: wApua and wbmp2xbm (which has been renamed from wbmp2xbm.pl) now have POD documentation and therefore also man pages. Besides that a lot of minor bugfixes and enhancements complete the new version.

The other big new thing is that there now is a Debian package of wApua. The package should work fine on Debian Woody (3.0), Sarge (3.1) and Etch (upcoming 4.0) and probably also works on other Debian-based distributions like Ubuntu.

Thanks to sponsoring by Christoph “Myon” Berg the Debian package is also in the Debian New Queue and hopefully will be included in Debian Etch.

wApua 0.05.1 released

abe+blog@deuxchevaux.org (Axel Beckert) — Mon, 01 May 2006 21:21:55 +0200

After more than five years without new release, there is now a new version of Perl written WAP browser wApua: 0.05.1. (Release announcement at Freshmeat)

It mainly fixes the use with newer Tk version as shipped with recent Ubuntu and Gentoo releases (Sarge still works fine with 0.05, but Etch won’t). It also fixes the local installation documentation.

Thanks to all who reported these bugs.

The World without a sage web browser? — or — Why Firefox sucks

abe+blog@deuxchevaux.org (Axel Beckert) — Tue, 21 Mar 2006 11:44:18 +0100

Although I read our Debian’s Joey’s blog posting about not being able to produce Mozilla security updates for Debian, only now, after reading about other Debian’s Joey’s try to fix a security hole in Debian’s Mozilla Firefox, I see how asshole-like the Mozilla Foundation’s security policy looks to Linux (and maybe other operating system’s) distributions, who favour stableness over feature richness.

As many know (or at least were forced to know ;-) I don’t like Firefox, because in spite of all the plugins it can’t cope with all the useful features of Galeon 1.2.x or Opera. That’s the UI point of view.

But from the political (correctness) point of view, we have to ask ourself: What sage browser does the open source world still have?

Mozilla does not provide security patches, so Firefox, Mozilla (RIP), Epiphany and Galeon are no more acceptable for distribution use.
Konqueror has planed to drop KHTML in favor of Mozillas Gecko. So see above.
Dillo’s rendering engine is fast but not really state of the art. Same counts for glinks (aka “links -g”).
Lynx, links and w3m somehow don’t count since the distributions (and sometimes, me too ;-) primarily need a graphical web browser.

But back to usaility: I heard from quite a few people — even open source people — evaluating or even already using Opera as an alternative, because there is no sage open source web browser, even if you don’t count Mozillas security policy. And I can understand them. If Galeon wouldn’t exist, I probably would be a convinced Opera on Debian user myself, although Opera is closed source. But I and many more can’t live without a working and sage web browser.

The only thing, I don’t like with Opera is that this company seems to be (or at least was a few years ago) very chaotic and uncoordinated. (And I really wonder, how they are able to produce such impressive software.) But that’s another story…

Wikipedia at your fingertips

abe+blog@deuxchevaux.org (Axel Beckert) — Thu, 02 Mar 2006 02:07:32 +0100

Via nion’s blog I got notice of two other blog entries of two people of whom each wrote a shell script to display Wikipedia articles as plain text in a pager.

While the first one called wiki2 queries Google and fetches then the first Wikipedia hit there, the second one (funnily just called wiki) queries Wikipedia directly, supports different Wikipedia languages and has a lot of other nice features.

Since the idea and especially the second script definitely belongs to the group of programs you never thought about, but, when you found it, you knew, you missed it until now, I decided to use it as the first program, I want to package for the Debian project to be included in the next release which will be called Etch.

Because of “wiki” being a quite ambigous name, I plan to name the package wikipedia2text.