- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] Anti-Tab

by Chris Palmer

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."

June 18, 2003

RE: [Dillo-dev] [RFC] Plans for next version of tab patch

by Eric Gaudet

> I'd advise you to choose a date from CVS and improve the patch > against it (not trying to catch up with current); that way the > patch can be polished without too much hassle and with the > feedback of interested developers. > I recommend we tag cvs for such things, to get an easy reference, or better yet, we branch, so merging is easy.

June 17, 2003

Re: [Dillo-dev] [RFC] Plans for next version of tab patch

by Jorge Arellano Cid

Hi Frank, On Tue, 17 Jun 2003, Frank de Lange wrote: > Hej! > > Now that the first release of my tab patch is 'out there', I'd like to > give a short overview of my plans for the next version of this patch. If geocities stops working just let me know, or ask Andreas who mirrored the patch... > I > do not know when I'll be able to release this next version, as I'm busy > this week, followed by a trip to the UK (back the 13th of juli), but I > will try to make it relatively soon... No problem. Some time ago (maybe a lot), Arvind told me he had developed a "tabs" patch for dillo: http://www.dillo.org/test/dillo_tabs.png He had to work on it some more, then he got very busy, and I haven't heard of it in a long time... Technically, what interests me more about the patch is the separation of interface code out of document code. Now Sebastian is working on another separation; for CSS (it also involves several files), so I think it is better to keep both works separated until our re-structuring of the parser is well defined. I'd advise you to choose a date from CVS and improve the patch against it (not trying to catch up with current); that way the patch can be polished without too much hassle and with the feedback of interested developers. Then, when the time to merge comes, it will be stable, clean and polished. Personally, I can't look at it right now (because of the above mentioned reasons, plus I'm dedicated to the dillo plugins extensions). NOTE: We have advanced a lot with Ferdi on dpid, so it will soon be integrated and commited. ... it has come a tradition (or better, our way of development) to test a lot the patches before commiting them in. That way, the CVS keeps stable, the code clean, and we can keep up with the ideal of always releasing a better Dillo than the former. As you noticed, the patch generated a lot of feedback. I hope patches start to come just as bug notes! ;) > [...] > > Jorge, let me know if/when you plan to commit the patch to CVS (read above) Last, but not the least, I also think that tabbing is a function that should/must be done by the WM. I always try to find "the right place" to put a patch, and IMO it belongs to the WM. Now, as these days only a few WMs come with good tabs support, and as the patch seems small, it should pose no major trouble to eventually commit it. Welcome aboard! Jorge.-

June 17, 2003

Re: [Dillo-dev] Anti-Tab

by Frank de Lange

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(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

June 17, 2003

Re: [Dillo-dev] Anti-Tab

by Kelson Vibber

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>

June 17, 2003

Re: [Dillo-dev] Suggestion for a next dillo version

by Kelson Vibber

At 03:16 AM 6/16/2003, Manuel Serrano wrote: >I was wondering if it could be possible to have an automatic >hidden bar such as in many window manager (fluxbox, kde, gnone, >...). That is the navigation bar is automatically hidden until the >mouse fly over the very top lines. Whether it's technically feasible or not, I don't think this would be very usable, except perhaps in full-screen mode (by which I mean having the dillo window taking up the entire screen, with no title bar at the top). The activation area for one of these has to be narrow, or else you use up the space you gained by hiding it. And having a narrow area - say, the size of a window border - only works if you (a) are doing something that requires precision anyway, like resizing a window, or (b) can't miss it. The reason auto-hide and auto-show works for window managers is that they are at the edge of the screen, and there's nowhere else for the mouse cursor to go. You don't have to worry about hitting an exact area, you just send it in that direction and the toolbar appears. This is true for KDE, Gnome, Windows, Mac OS X, and so on. Putting this in a window would mean hitting something like a 5-pixel wide border, then hitting the toolbar buttons - essentially making it a drop-down menu that's hard to reach and extends horizontally instead of vertically. IMO, it would be more usable to take it a step further and make it an actual drop-down menu, with an activation area the size of the "show controls" button. (I'm not sure how the URL control would fit into this, though.) The exception would be if this were aimed at a true full-screen mode, in which case you gain the same advantages that window managers have by stopping at the edge of the screen. Kelson Vibber www.hyperborea.org

June 17, 2003

Re: [Dillo-dev] IFRAME element stub

by Jorge Arellano Cid

On Sat, 14 Jun 2003, Stephen Lewis wrote: > On Wed, 11 Jun 2003 11:32:22 -0400 (CLT) > Jorge Arellano Cid <jcid(a)softhome.net> wrote: > > > > > Nikita, > > > > > Hi all Dillo developers ! > > > > > > There is a very small patch to support IFRAME HTML element. It does > > > nothing except handling IFRAME via FRAME handler so special IFAME > > > attributes(width and height) are not handled but this patch is > > > suitable for current temporary solution (as we do not have real > > > frame support for now). > > > > Done! > > Just a comment about this - I'm using a recent CVS version some time > after this was integrated, and it causes some display issues with a lot > of sites. In particular, sites that use narrow IFRAMEs for ads in a > table(e.g. http://www.osnews.com, http://arstechnica.com/ ). The > displayed URL seems to force the column width to be much, much wider > than it normally would, making these websites look very bad (very wide > column with ads, very narrow column with actual text :/ ) > > It's great having this patch apart from the display issues it causes. > Would it be possible to make the displayed URL wrap? > [...] > I just wanted to make sure it hadn't > slipped through unnoticed. Of course, if I'd actually read your Well, I noticed the problem shortly after commiting, but as I'm working hevily in dpid (with Ferdi) I didn't have the time to address it. > As an aside, it was quite an eye-opener viewing websites with this > patch, I discovered many sites which I had thought to be free from > advertising were in fact saturated with it > - they were having about as > much effect on me using Dillo as all of those pop up/under ads I hear > about all the time ;) Dillo helps a lot with advertising filtering. Also, popups don't show because of no javascript support. Yes, it was an "eye opener" to see those instrumentations. After some thought I decided to name the link "IFRAME" (the destination shows on the status bar). The patch is now in the CVS. There may still be some problems (if IFRAME is used as a web bug; i.e. invisible IFRAME for spying). I think it will be very interesting to browse and "see" what comes down the line. Another goodie of this approach is that you can search for the "IFRAME" word, and locate them. Cheers Jorge.-

June 17, 2003

Re: [Dillo-dev] Anti-Tab

by Jyri Jokinen

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

June 17, 2003

Re: [Dillo-dev] [PATCH] Tabbed version of Dillo, now available on geocities

by Phil Pennock

On 2003-06-17 at 10:44 +0200, Frank de Lange wrote: > On Tue, Jun 17, 2003 at 10:10:22AM +0200, Andreas Schweitzer wrote: > > - On my FreeBSD 4.8 system with gcc version 2.95.4 I need > > to move one line to make it compile like : > > Yeah, the code needs some cleanup still. I'll go through it for the next patch, > and try it on FreeBSD as well. That particular problem wasn't caused by FreeBSD. It's because the code made use of a C99 feature, allowing variables to be declared anywhere, not just at the head of a function. If you're using gcc 3.<something>, then you can use "gcc -std=c89" to ensure conformance to the older standard. It _should_ highlight issues like this one. HTH, -- 2001: Blogging invented. Promises to change the way people bore strangers with banal anecdotes about their pets. <http://www.thelemon.net/issues/timeline.php>

June 17, 2003

Re: [Dillo-dev] Anti-Tab

by Chris Palmer

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.

June 17, 2003