Jyri Jokinen writes:
"Everybody" doesn't want tabs inbrowser. That's a fact. Look around you.
Mere semantics, as Kelson Vibber noted.
There are a lot of window managers other than PWM that support window tabbing - one of the best is Pekwm, wich i've been using for surfing with dillo for an eternity now. Waimea and Fluxbox are also getting there slowly, but their implementations lack usability at the moment.
Three obscure window managers, and of those, only one is usable enough even for a motivated expert user like yourself. Let's pretend mainstream window managers like Window Maker, KWM and Gnome WM Of The Week all supported tabs. How would Dillo tell the window manager to attach the new window to an existing tab group? Afaik there is no general protocol for this. I'm pretty sure ICCCM has nothing to say on this topic.
Having tab support in a window manager is flexiple. Much more flexiple then they can ever get in a, lets say browser, without writing a complete internal window manager.
If the functionality doesn't exist, you have to create it. It didn't exist, and Frank created it. Are you going to create a protocol for tabbing in window managers, and convince all the wm developers to adopt it? Are you going to help them implement it?
It would not be easy to use since the toolkit (Gtk) is not tightly integrated with the window manager
How should this be of any importance? Please enlighten me, who wonder in the dark.
See above. If the toolkit used for both the application and the window manager were the same, and the toolkit had a general mechanism for tabs, it would be pretty easy. But not all window managers are implemented in Gtk, so a protocol is needed.
I care to object on the plea of ease of use. This far all the tabbin browsers i have tried have been overly complicated to use compared to the way pekwm handles it.
It's a simple Ctrl-T in Phoenix and Command-T in Camino to create new tabbed windows. Ctrl-W/Command-W closes them. You can drag links to the tabs to cause that link to load in the indicated tab. That's pretty simple. Of course, your window manager will trap or ignore those keystrokes, making that very simple mechanism impossible. The window manager will have to support all of the several possible drag-and-drop protocols applications might use. Oops!
And the sheer fact that i can rebind my keys and mouse clicks with the window manager but not with the browsers is enough to convince me of ease of use.
Hacking configuration files is not my idea of great ease of use. Software usability is acheived in part by defining and adhering to a user interaction policy. The X Window System and related projects have always eschewed policy setting; instead, only a mechanism is provided. (In some cases, not even a mechanism was provided: window management itself was an afterthought, as was drag-and-drop.) That leaves application developers "free" to devise their own wacky schemes, all different. The inevitable result is pain for users.
There are many great window manager projects developed,
The very idea of a window manager as a distinct entity is stupid, from a usability point of view. There aren't 200 window managers for Mac OS, Mac OS X, Windows, PalmOS or BeOS. The makers of those products were trying to make something people could use.
and i do hope you take attleast that one back. After all, dillo once was a petty crappy piece of software (and still is for an untrained eye), but it has potential. Just like many of those window manager projects, which you seem to doom as a byproduct to make a wery pointed point.
My point is simply this: For Dillo to succeed, it must meet the needs of users. Web browser users tend to open many documents at a time, and surf between them. They need a way to manage the clutter, and Frank has provided that in a manner similar to that used in other web browsers. Users also need HTTPS, which has also generously been provided. As of right now (I just updated CVS), HTTPS support is not in the source tree.
Closing word, The fact that dillo now could and probably will have tabbing support is absolutely great. The fact that the work put into it might get us closer to having frame support is absolutely great. The fact that I can toggle it off at compilr time is absolutely great. People being more or less out of order in a mailing list about a matter like this is _not_great_.
I agree! Everyone should be sending Frank cases of beer, not yelling at him for adding "bloat" or saying "That's great, but we prefer to do it in a way that is pretty much impossible to implement, so no thanks."