I just want to throw in, that tabbing may be a bloat-feature. Just because every modern browser has it and everybody wants it, i needn't to be necessary. I watched a similar discussion some time ago and a wise argument convinced me, that tabbing is not a task for a browser. Before you call me loony, listen. Tabbing is about handling different windows, but handling windows is nothing a browser should do. Leave to the programs, which are made for especially that: Window Managers! Tabbing should not be implemented in a browser, but in the window manager. Sorry, if KDE and Gnome don't support it (i think, am i wrong?) Just my 2ct ;) mfg Andreas Zwinkau | web: andi.dasstellenwirinsinternet.de | mail: andi@buxach.de | jabber: beza1e1@amessage.de
On Tue, 17 Jun 2003, Andreas Zwinkau wrote:
I just want to throw in, that tabbing may be a bloat-feature. Just because every modern browser has it and everybody wants it, i needn't to be necessary. I watched a similar discussion some time ago and a wise argument convinced me, that tabbing is not a task for a browser.
Before you call me loony, listen. Tabbing is about handling different windows, but handling windows is nothing a browser should do. Leave to the programs, which are made for especially that: Window Managers! Tabbing should not be implemented in a browser, but in the window manager.
Sorry, if KDE and Gnome don't support it (i think, am i wrong?)
Just my 2ct ;)
I think, thats why we have the configure options :)
On Tue, Jun 17, 2003 at 02:46:04PM +0200, Andreas Zwinkau wrote:
I just want to throw in, that tabbing may be a bloat-feature. Just because every modern browser has it and everybody wants it, i needn't to be necessary. I watched a similar discussion some time ago and a wise argument convinced me, that tabbing is not a task for a browser.
I really don't mind if tabs are out of dillo. And in the end I will agree, that having tabs is something that is not needed. However, in this case, as I said in some time ago, it looks like the coding design can easily be used to implement frames. I haven't looked at the code yet, though. But if the implemented division of browser window and interface is done as I think it is done, then frames are a natural consequence to code. That is the main reason why I am that interested in this patch. Btw, I think the binary increased by only 10kB on my machine. Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198
Andreas Zwinkau writes:
I just want to throw in, that tabbing may be a bloat-feature. Just because every modern browser has it and everybody wants it, i needn't to be necessary.
Bloat is when you embed a flight simulator into a spreadsheet program. Tabs do not bloat Dillo. When it comes to software, "everybody wants it" is a really, really good sign that the feature is necessary. Maybe the feature could be implemented in the window manager, but not everybody uses PWM, or wants to. It would not be easy to use since the toolkit (Gtk) is not tightly integrated with the window manager (any of 600 crappy things on Freshmeat). Implementing it in the application is the best way to do it, given the realities of the X Window System. Thank you, Frank! Tabbing is great.
On Tue, Jun 17, 2003 at 09:04:12 -0700, Chris Palmer wrote:
Bloat is when you embed a flight simulator into a spreadsheet program. Tabs do not bloat Dillo.
I agree on this. If tabbing takes us closer to frames, they are ok. Otherwise, i couldn't more disagree with your views.
When it comes to software, "everybody wants it" is a really, really good sign that the feature is necessary.
"Everybody" doesn't want tabs inbrowser. That's a fact. Look around you.
Maybe the feature could be implemented in the window manager, but not everybody uses PWM, or wants to.
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. 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. Simple tabbing support built into a browser can however be wery usefull in certain situations, and an implmentation like the one in question is a wery good exmple of a well made job.
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. 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. 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.
(any of 600 crappy things on Freshmeat).
There are many great window manager projects developed, 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.
Implementing it in the application is the best way to do it, given the realities of the X Window System.
As someone pretty happily using a tabbing window manager - could I get closer information on this, thank you. 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_. Please get your acts together. I've used to expecting quality posts in this list. -- shared, sorry for feeding it, it just looked so wery hungry
At 10:43 AM 6/17/2003, Jyri Jokinen wrote:
When it comes to software, "everybody wants it" is a really, really good sign that the feature is necessary.
"Everybody" doesn't want tabs inbrowser. That's a fact. Look around you.
That's just semantics. Perhaps not "everybody," but certainly many people love using tabs with their web browsers. Tabs were the main "killer feature" for Mozilla 1.0 (every review of Mozilla for months talked about them), and were requested immediately upon the announcement of Safari. Tabbed browsing (of some sort) is extremely popular. The main disagreement is over where to put the code.
Implementing it in the application is the best way to do it, given the realities of the X Window System.
As someone pretty happily using a tabbing window manager - could I get closer information on this, thank you.
I don't mean to put words in anyone's mouth, but the way I read this was that the "realities" of X are that there are many different window managers out there, and that the most popular ones do *not* handle tabs themselves. When KWM, Metacity (or whatever Gnome is using by then), and other WMs shipped by default feature well-done tabbed windowing, then putting the code in the browser will be redundant. But for now, they don't, and the best way to handle everyone who wants this for their web browser - assuming it doesn't triple the size of the code (and this doesn't appear to) - is to go ahead and put the code in the browser. Kelson Vibber SpeedGate Communications <www.speed.net>
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."
On Tue, Jun 17, 2003 at 07:29:54 -0700, Chris Palmer wrote: I won't even start to comment on all of it, mainly because this is going off-topic and it would make a really long message.
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.
You really haven't looked in to how tabbing window managers work, have you? If so, imho, you are in no place to make comments about the subject. Making it a simple and short story: Clients/windows can be identified by many means, and the window manager can be instructed to group all the windows that match those criterias.
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 must be a pure looney for having a working tabbing window manager without such a protocol then. Guess I've just imagined it all for several years now. -- shared, don't bother to answer, i know you didn't get it
I see your arguments and understand them. The last i wanted was to offend somebody or downgrade Franks work. This patch is something many people wish and so they should get it. Sorry, if i started something, which runs out of order. The problem is not Dillos it is one of the society. We see the most popular window managers/desktop environments Gnome, KDE, OS X, Windows. These dominate the market and everybody else has to adobt and live with it. If these programs have their faults the programs under them have to build around them, while it would be better to change the source of the problems itself. I seems like the HTML problem. Browser do not show everything as they should, so webdesigner use HTML4.01 transitional and <font> to show pages in older browsers as well. Leaving tabbing to the window manager is like leaving layout to CSS. The difference is that the major browsers support it. This world has problems and faults, so we must improvise. I see browser-tabbing as improvising for the people, who like the eye candy of the major window managers. Please don't take this as provocation, activate your browser tabbing and be happy. I deactivate it and i'm happy as well. 'nough said mfg Andreas Zwinkau | web: andi.dasstellenwirinsinternet.de | mail: andi@buxach.de | jabber: beza1e1@amessage.de
Andreas Zwinkau wrote:
I just want to throw in, that tabbing may be a bloat-feature. Just because every modern browser has it and everybody wants it, i needn't to be necessary. I watched a similar discussion some time ago and a wise argument convinced me, that tabbing is not a task for a browser.
Before you call me loony, listen. Tabbing is about handling different windows, but handling windows is nothing a browser should do. Leave to the programs, which are made for especially that: Window Managers! Tabbing should not be implemented in a browser, but in the window manager.
Sorry, if KDE and Gnome don't support it (i think, am i wrong?)
Just my 2ct ;)
Have a look at the numbers I included on the 'bloat' caused by tabs. You can find this information in the doc/Browser_Tabs.txt file: CFLAGS ------------------------------------------------------------------------- tabs | -g -g stripped -O2 -O2 stripped -Os -Os stripped ........|---------------------------------------------------------------- enabled | 3558892 390204 384453 316444 359821 291868 | disabled| 3468465 381916 374382 308188 350454 284316 | (before)| 3332856 377920 373773 308000 349141 283424 Versions and settings --------------------- gcc: 3.2.2 binutils:2.13.90.0.18 In other words, tabs add all of 7552 bytes to Dillo, on a total size of 291868 bytes. Now please tell me if this is bloat. Also, remember that tabbing window managers are not for everyone. And tabbing is OPTIONAL. Use the --disable-tabs option and there will be no tab code in you binary. So what is the problem again? Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
participants (7)
-
Andreas Schweitzer -
Andreas Zwinkau -
Chris Palmer -
Frank de Lange -
Jyri Jokinen -
Kelson Vibber -
Madis Janson