Error: unknown Blosxom flavour "txt"

I'm afraid this is the first I've heard of a "txt" flavoured Blosxom. Try dropping the "/+txt" bit from the end of the URL.

Thu, 02 Mar 2006

The Galeon 1.3.x Rant, Part 2: Kazehakase is the real succssor of Galeon 1.2.x

Well, I’m somehow suprised that my Galeon 1.3.x rant got so much response and especially so many
constructive, non-ranty responses. Thanks, guys, you made my day!

A few of my arguments against Galeon 1.3.x are solved now (which of
course was one of the targets of the rant ;-)… On the other hand,
some of my statements were claimed false, but I still believe them to
be right. I just strongly disagree with pure simplification
being the right way in UI design.

But more important, I now know that Galeon 1.3.x will never be like
Galeon 1.2.x and that it’s no legitimate successor of Galeon 1.2.x,
because the focus and the design principles changed to more focus on
beginners who may be confused by too many options and features and
therefore excludes people which — for working efficently —
need a tool being highly configurable regarding their customs.

Galeon and GNOME developers should take a leaf out of Kazehakase’s
book: They claim to be user-friendly by castrating the configuration
window without any pointer in the program (help doesn’t count here!)
to more options via the gconf-editor or
about:config and therefore
castrating their old users which are just used to have the power to
modify the behaviour of an application.

Kazehakase just does what both, beginners as well as experienced users
want and e.g. Lynx also does since ages: Letting the user (and not the
developer) choose the user’s level. On the first tab of the Kazehakase
configuration window, you can choose between UI levels “Beginner”,
“Medium”, “Expert”. The default was “Beginner”, I’ve chosen “Expert”
and I’m happy with it. GNOME developers may choose “Beginners” —
for their clientele which I no more belong to.

But that’s not enough. Tommi Komulainen
pointed me to about:config for the details. That’s fine. But
Galeon doesn’t. Which isn’t fine. Kazehakase does. It has a menu entry
“Detailed preferences” which just opens a new tab with about:config. IMHO a very
elegant if not perfect solution. I really hope that at least this will
be copied by the Galeon developers. So, Tommi, please tell the Galeon
Developers on the GNOME Developer’s Summit in Boston next weekend,
that I wish just two more menu entries beyond “Preferences”:

“Detailed browser preferences” which opens a new tab with about:config and

“Detailed UI preferences” which opens gconf-editor /apps/galeon.

With this, you probably help a lot of disappointed Galeon 1.3.x
users. (And I know for sure that I’m not the only one. /me winks at Myon.)

OK, enough ranty sentences. If you want a more detailed and
less ranty discussion, read on…

Many of the stuff you are complaining about is mostly the old “I need
more features” mistake. Features do not increase usability (or as you
called it “ergonomy”) by sheer quantity.

Of course, it does not. But many of the things I missed and argue
about were only small changes in behaviour but which slowed down the
whole handling of the browser. And a UI which was fast to use was one
of the “features” I liked Galeon for. And sorry, many of those
“features” increased my efficency with the browser a lot. (I don’t see
this as features, btw, just as well thought out UI. You don’t have to
use them, if you don’t want, but I do not expect, that anyone is
confused that dropping a link in the same tab as it origins from, that
it will just open the appropriate website.

I’ve seen users get totally confused by the amount of options they
have to decide upon.

Have a look at Kazehakase or Lynx. A simple switch “UI level” or “User
level” solves that problem perfectly without to alienate the more
experienced users.

About the speed of the GUI (not the rendering engine): Sorry, but my
Galeon 1.2.x from Woody on my 400 MHz PII desktop (578 MBRAM) is just
a lots faster than Galeon 1.3.x on my AMD K6 Sarge test server with
500 MHz and 256 MBRAM. It takes tenths of seconds unless something
happens after I’ve chosen another tab on that machine. I don’t notice
such delays with Galeon 1.2.x on the 400 MHz box. And the UI of Galeon
1.3 at work on 2.4 GHz and 384 MBRAM (or something like that) SuSE
(*grmpf*) machine seems not to be that much faster than on my 400 MHz
box.

Interestingly Kazehakase’s UI seems even as fast as Galeon 1.2.x’s,
since I can use Kazehakase on my PI with 133 MHz, 64 MBRAM and Sid
running without any big pain. Only the rendering seems slower than on
the 400 MHz box.

Note that the gtk theme engine has an effect on performance. Choose a
lightweight engine and it will be much faster. This applied to GTK 1,
too - except that very few people chose a heavyweight engine. So just
don’t use grandcanyon or similar engines.

I use the default theme and spinner which comes with Sarge for Galeon
1.3.x and the Aquatic theme and pipeon spinner for Galeon 1.2.x. So no
slowing down Galeon 1.3.x with heavyweight themes.

Then you are complaining about the focus issues in galeon, which have
improved a lot, and are to blame on mozilla embedding. Just because
galeon 1.2 uses an anicent mozilla doesn’t make them galeon 1.3s
fault.

There you may be right. I noticed that the focus bugs changed with
every 1.3.x version I used.

On the missing preferences in the dialog: so what? I never open the
preferences dialog anyway. I don’t even remember where it is!

If that’s the way most developers think, it’s no wonder, Galeon is no
more usable. It reminds to times, where seats of cars were built so
that fitted the chief developers body.

If you want additional preferences, get gTweakUI.

Don’t tell me that in a blog posting. Tell me that in the Galeon
preferences menu! (The same counts for about:config and gconf-editor.)

Just for the record: gtweakui-galeon solves my wish for for
configurable tab location. But that’s all regarding my list of
unconfigurable things in Galeon 1.3.x. gtweakui-menus sovled all the
menu issues. (Which I fixed using gconf-editor before, but thanks
anyway.)

And I bet you are welcome to provide patches if you find
anything else missing.

Since the tenor of how a powerful web browser should look like seems
to have changed, I don’t think I should waste any time with Galeon
1.3.x anymore. I’ll better try to patch bugs in Kazehakase than
patching “unwanted” features into Galeon or any external (sic!)
application to configure it.

The Ctrl+U behavious works for me exactly as you requested it.

Sorry, here it just doesn’t. I just clicked into the location field
and pressed Ctrl-U and I got the source of the current tab.

Maybe you should choose Emacs-Style keybindings when you want
Emacs-style keybindings.

You may be right and I noticed again, why I don’t want a web browser
which is that heavily tied into a desktop environment… But since
there was no better browser than Galeon I used it.

But back to the subject: Where the heck do I find that switch for
Emacs keybindings. Tried gnome-control-center and gconf-editor. Tommi
pointed me to ~/.gtkrc-2.0, but this
tip unfortunately doesn’t seem to work.

Oh, and btw something I never understood is, why Ctrl-U is said to be
an Emacs keybinding. Ctrl-U in Emacs is a prefix switch since I use
GNU Emacs (18.34 IIRC) and nowhere in Emacs Ctrl-U clears a
line. *justwondering*

You can drop hyperlinks of a page onto itself. Drop them onto
the tab an they will open in the current window.

I know that, but it’s just awkyard that I have to target the tab if I
just could move the mouse just a few pixels off al drop the link. Ever
thought, why mouse gestures are so efficient? Because you don’t have
to target anything small, you just use the same move whereever you
are. It’s just the same here.

The search window opens very quickly for me. […] For me it’s
Ctrl+F and start typing. A “search in current page” widget would be so
useless… and slow! If I have to type anyway, why should I use my
mouse to go to the widget?

If the window opens fast, you’re completely right. So that’s probably
just an issue which just comes up on slower computers.

As for the tabs menu - I rarely have that many tabs, I could easily do
without the tabs menu. Having more tabs than I can see is the point
where I need to clean up… (just like having more applications open
than desktops)

Well, I’d like to keep tabs open if I know, I’ll need the content of
that page quite soon again. Even more, I use them as reminders, that I
have to do something with them. And with Opera or Kazehakase there is
a very nice feature not (yet) present in any Galeon version: Reopen
recently closed tabs.

Although this feature doesn’t help with huge automatically started
sessions. (But I usually process the windows with many tabs serially.)
When I login and my Galeon starts, it usually opens several windows
(one virtual desktop for each) with each having several tabs, e.g. one
window with several Symlink tabs (malinglist admin, main page, IRC
log, list of my comments — to look for replies, story stats,
admin story list, and the new submissions list) or one window with
other newstickers and blogs (most important ones plus two tabs with
two different pages of an RSS feed reader for the rest), and one for
all my daily comics. I guess, I load about 50 (internal and external)
web pages when I log in. (Impossible without tabs, btw.)

Oh, and I do want my “empty new tabs” to open at the end of the
list. This is much more predictable. I would often be annoyed by your
preferred behaviour…

That’s ok. That’s your preference. And it was configurable in Galeon
1.2.x. For the rest of the discussion see above.

Having *one* network proxy setting for your desktop makes much more
sense than having one for each application.

Not if you’re a webdeveloper. I have a proxy which modifies the
content of pages for everyday browsing (Privoxy: It removes ads,
banners, annoying JavaShit, zero width frame borders, etc.), but if
e.g. a customer complains about a page I should temporarily switch off
the proxy just to ensure, my proxy doesn’t modify the page and I see
it as the customer sees it. This is very nice solved in Galeon 1.2.x
(Disabled, Manually, Automatically) and even better in Kazehakase and
one of the proxy chooser plugins for Firefox (they let me also choose
between several manual proxy configurations).

You are of course welcome to write a proxy chooser applet if there is
none. (Yes, this will affect galeon without a restart). Oh, and you
can reach the proxy settings via the gnome menu with two clicks and no
waiting for the galeon preferences dialog.

I do not use a desktop environment, I use a web browser. There is no
panel and no menu on my desktop. There are just windows: Browser and
terminals. I use Galeon because it’s a good browser (1.2.x ;-), and
not because it’s built on GNOME.

But please stop requesting feature overload for the dialogs.

Nope.

This is an old discussion and has been done with.

Then it ended with the wrong result, namely to alienate users which
were happy with Galeon and GNOME before.

Sometimes you just have to accept that many people have a different
opinion,

I do accept that others have a different opinion, if they accept
mine.

and maybe adopt to the new situation.

Yes, that means to drop Galeon 1.3.x and GNOME in favour of Kazehakase.

Otherwise your applications would still terminate when you press
Ctrl+C…

I would be happy, if they would so in some cases, yes. Or at least, if
it would be configurable… ;-)

Answer to Tommi Komulainen’s Galeon rant rant

The first trackback, which came in, was from Tommi Komulainen’s Galeon
rant rant — a title I like very much. Unfortunately calling
this post the “Galeon rant rant rant” wouldn’t be as good. ;-)

[…] And as it [Galweon 1.3.x] is a rewrite, things don’t suddenly
just appear unless someone does the work and writes the code.

That’s ok. I just never did unterstand the reason for a complete
rewrite, except that perhaps the switch GTK 1.x to GTK 2.x made it
necessary.

So far no one has bothered to do so (just as no one has bothered
porting the apparently “perfect” Galeon 1.2 to GNOME 2.x either.)

Well, Galeon 1.2.x wasn’t perfect, it just counts the same as for
mutt: All web browsers suck. This one just sucks less. :-)

And btw, Kazehakase looks to me a lot like Galeon 1.2.x and it seems
to me as someone has bothered porting the nearly “perfect” ;-) Galeon
1.2.x away from GNOME just in the sense of the good ol’
SkipStone. Sorry, GNOME guys, you’ve lost — a good browser.

Regarding the Ctrl-U thing again:

This is rather funny, actually, as Galeon is trying very hard to
support Emacs-keybinding

Indeed, it does, but probably not as hard as galeon 1.2.x
did. (Altough I often quit both, 1.3.x when trying to use Ctrl-Q to
insert some special character as I’m used to in Emacs trough ssh
sessions. Solved the problem by disabling the Ctrl-Q shortcut, because
I usually just close the browser when I log out. And for that seldom
event, I can use the menu. ;-)

and in general trying to make some sense between actions with
shortcuts in menus and actions built into widgets. The order in which
keyboard events are handled in gtk+ is peculiar, but basically the
ugly hacks in Galeon should ensure most Emacs keybindings (which
conflict with HIG bindings) should just work.

Just another reason, why I prefer Galeon over other browsers, yes.

Of course this needs a setting similar to gtk-key-theme-name = “Emacs”
in your ~/.gtkrc-2.0

The things you mentioned worked on Debian and SuSE also without that
setting (for luck!), but unfortunately it didn’t solve the Ctrl-U
problem… :-/

The way tabs work in Galeon is that related tabs are kept together
while unrelated tabs are opened at the end. A link on a page opened in
a new tab is considered related, opening a new (blank) tab from menu
or command line is not.

Yes, I expected this logic behind that behaviour. But if I open a new
tab manually, I usually do it, because I want it side by side with the
current open tab (which was configurable with Galeon 1.2.x). It’s
seldom the case that I have to open unrelated tabs.

I also don’t argue against the default, I just argue about that I
can’t reverse it to the former, for me usefuller behaviour. Galeon
just doesn’t know if I consider a tab related or not.

Example: I have web site open and need a word translated. I cut &
paste it into my dict.leo.org Smart Bookmark and hit Ctrl-Enter. I want that page
to open directly besides the current tab.

BTW: Smart Bookmarks are also a very nice feature of Galeon (1.2.x as
well as 1.3.x :-). That’s one of the things I still miss in
Kazehakase. But I’m sure, it will come… ;-)

Have you ever actually looked at the number of options in
about:config? I seriously hope you’re not seriously suggesting moving
them all in the UI.

Nope. Even more, I expected that those, you’d better should not play
with unless you’re know what your’re doing (disabling HTTP 1.1 e.g.)
should not show up in the UI.

I think even Mozilla left out some options from distracting the user.

They did. But not because they would distract the user but because
they’re dangerous if you don’t know their implications.

The defaults should just work. If most users are likely to want or
need to tweak some preference it’s in the UI. For niche uses there’s
gconf-editor an about:config.

Then — again &mdahs; there should be a either menu entry
“Detailed XY preferences” or “Expert XY preference” which opens up about:config or gconf-editor or there should be a switch “User
level” or “UI level”. But silently removing configurations options is
just anything but user-friendly.

I can’t help it but the overall impression I got from the rant was
basically Galeon 1.3 is different from Galeon 1.2…

You’ve got it! Galeon 1.3 is different from Galeon 1.2! That’s what I’m
complaining about. Galeon is no more Galeon. Galeon 1.2.x was a good
and configurable browser. But now, with 1.3.x, Galeon is a browser.

The whole Galeon team will be in the GNOME Developer’s Summit in
Boston next weekend. You might want to bribe us with few beers to fix
your Galeon pet peeves :-)

Sorry, too far away. But after this quite interesting but also
disappointing discussion about the GNOME directions of UI design, my
main wish is — as I already wrote in the beginning of this
posting — to include menu entries for about:config and the appropriate path in the gconf-editor. This would be a small help for
all those which disagree with where the current direction of GUI
design in GNOME seems to go: Pure simplification without
regarding any collateral damages on experienced and habitual
users.

Humans are habitual beings — and this should never be forgotton
in HCI. (And maybe in that point, I’m even more human than other
humans. ;-)

But my biggest problem with Kazehakase at the moment is, that I can’t
remember it’s name correctly (nor do I no know how to pronounce it
correctly). Perhaps it should just refer to it as “Aleon”: “Galeon”
without the GNOME part. ;-)