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.
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.
I also never saw Galeon as part of GNOME, but as a very useful browser which unfortunately has this GNOME stuff in, but still is faster and more useable than Mozilla or Firefox with their XUL rendered GUI. So I used it and used parts of GNOME with it. I always wished SkipStone would have been as powerful as Galeon. But already the first comment to my Galeon 1.3.x rant pointed me to the true Galeon 1.2.x successor — without GNOME and just with pure GTK: Kazehakase. Thanks Miroslav Kure!
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
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”:
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
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 MB RAM) is just a lots faster than Galeon 1.3.x on my AMD K6 Sarge test server with 500 MHz and 256 MB RAM. 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 MB RAM (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 MB RAM 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
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
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.
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… ;-)
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.
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
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. ;-)