- Dillo-dev - lists.mailman3.com

Re: Thanks

by Scorpio Rising

Behold, Maurice McCarthy scribed in runic symbols on a tube chassis: > Hi all > > As a linux learning running Woody from a home pc I'd just like to thank > you all for a great browser. The newer versions of Dillo compile quite nicely on Woody (that's what I have). If on the ./configure something appears "missing", apt-get the associated -dev file for that package and you'll be set! -- Gregg

Oct. 21, 2003

Re: [Dillo-dev] Thanks

by Johann Koenig

On Tuesday October 21 at 08:40pm Maurice McCarthy <maurice.mccarthy(a)ntlworld.com> wrote: > Hi all > > As a linux learning running Woody from a home pc I'd just like to > thank you all for a great browser. > > Came across it by chance looking for something else then was totally > surprised to find it in the Woody CD's! > > It goes great with Mutt. Fast. Heh, and you're using the version from woody, which is about a year or two old. Try CVS sometime, the improvements will blow you're mind :) If that's not enough, try Frank's tab/frame patch. It's wonderful. -- -johann koenig My public pgp key: http://mental-graffiti.com/pgp/johannkoenig.pgp

Oct. 21, 2003

Thanks

by Maurice McCarthy

Hi all As a linux learning running Woody from a home pc I'd just like to thank you all for a great browser. Came across it by chance looking for something else then was totally surprised to find it in the Woody CD's! It goes great with Mutt. Fast. Thanks again Maurice

Oct. 21, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Frank de Lange

Sebastian Geerken wrote: >Hi, > >I've only taken a glance at it, but made two changes to Frank's >work. The patch is attached, and is to be applied after Frank's patch: >The changes: > > - Fixed a bug in focus.c: Now, spaces are also drawn, between the > words of a multi-word link. Somewhere, it is documented, that you > have to highlight up to strlen(word->content.data.text) + 1, to > highlight also the space. > > - I've modified the page widget to draw the focus-highlighted text > with a border, not inverse, as done with found and selected text. > >Sebastian > > {Have you thought about | Is there} a way to highlight text using a pattern (like the 'gray-out' highlight for images)? I have explicitly not used a line-stile highlight for keyboard focus, because this makes it often hard to see where focus is. Links are sometimes small, no more than a '*' or a subscripted number. A line-style highlight is hard to see in those cases... I do agree that it is necessary to use a different highlight style for focus, search and selection, but the traditional focus highlight ((dotted/dashed) line around word) is not very useful in many cases. This goes even more for people with bad eyesight. 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." ]

Oct. 20, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Frank de Lange

Sebastian Geerken wrote: >Hi, > >I've only taken a glance at it, but made two changes to Frank's >work. The patch is attached, and is to be applied after Frank's patch: >The changes: > > - Fixed a bug in focus.c: Now, spaces are also drawn, between the > words of a multi-word link. Somewhere, it is documented, that you > have to highlight up to strlen(word->content.data.text) + 1, to > highlight also the space. > > Hmmm... that was intentional, so that focused links could be recognized more easily... Same for the next one by the way. Anyway, it would be even better if the focus could be drawn in another pattern or color, so that it is visible even when overlayed with a selection or found highlight. Btw, apart from looking only fleetingly at it, did you try keyboard navigation? If so, any remarks about the functionality itself? 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." ]

Oct. 20, 2003

Re: [Dillo-dev] FLTK

by Melvin Hadasht

[Thanks Indan for your reply] > If > the only reason to switch to GTK2 is to have better fonts support, then > I > would just stick to GTK 1 and use the freetype library directly, > something > along the line of prerendered fonts and use them as small pictures, > whatever is fastest. According to http://www.dillo.org/Notes.html, Gtk+ is seen as a mean to support Unicode, not as a mean to display "nice" fonts. But the issue of font rendering speed is also there and as you suggest, these can be optimized depending on context. > Personally I don't need unicode support, can > understand that there are a lot people that need or want it, but maybe > it's not Dillo's task to support it, maybe a poll on the main website to > ask the users about it? For me CSS support is much more important than > most other features. Personnaly, I'd prefere Unicode support (or more precisely multi languages support), than CSS support. I personnaly do not browse only English web pages, and as the Internet is meant to allow information sharing throughout the world, I think Unicode and multi-language support is important. IMO, more important than CSS support, but I let developers decide which is more important and which is easier to implement and which will be implemented first, as each feature depend not only on user wishes but also on available resources. I think Gtk+2 is a nice library which is meant for ease of use and to fullfill most developers wishes in an easy way. This introduces some more abstraction and generalization in the way its widgets are implemented at the cost of specialized and optimized implementations. On modern hardware (>1Ghz, not like my 266Mhz chip), the slower than gtk1.2 library should still be quite usable (although, I did not test it on fast hardware). For example, the GtkTreeView: it is a very flexible widget and provides many features, but it is not a specialized widget anymore, so it is way slower than GtkCList or GtkCTree (AFAIS, it is not used in Thunderbird). Concerning Pango, it has to analyze each string to decide with which rendering engine the string will be rendered, this implies analyzing each character to determine to which language class it belongs, if there are RightToLeft and LeftToRight words etc... Each language may use a different set of fonts, and each font must be checked for its size. This computation is complex so to achieve fast rendering Pango should be studied carefully and rendering or drawing (on the expose events) algorithms should hand crafted. For example, maybe knowing that the page is in a certain non-unicode encoding, we could spare Pango some of its computation if Pango API allows such approach. So to summarize: I think porting Gtk+2 would need a quite deep knowledge of Pango and Gtk2 drawing pipeline and even more efforts on optimizations, as Dillo is meant to be a fast browser before being feature- rich browser. -- Melvin Hadasht

Oct. 19, 2003

Re: [Dillo-dev] [PATCH] Version 2 of keyboard navigation, solves problem with Tab

by Sebastian Geerken

Hi, I've only taken a glance at it, but made two changes to Frank's work. The patch is attached, and is to be applied after Frank's patch: The changes: - Fixed a bug in focus.c: Now, spaces are also drawn, between the words of a multi-word link. Somewhere, it is documented, that you have to highlight up to strlen(word->content.data.text) + 1, to highlight also the space. - I've modified the page widget to draw the focus-highlighted text with a border, not inverse, as done with found and selected text. Sebastian

Oct. 19, 2003

Re: [Dillo-dev] Re: /. crap

by Eric GAUDET

...tidy... > OK, your response ( and the others ) has convinced me that this was a > bad idea :) > :-) More generally, my point was: there's a lot to do to improve Dillo, let's not waste our time fixing problems that are not supposed to exist in the first place. > I realize this thread comes up periodically, I only mentioned it this > time because it was a way of minimizing the problem outside of the > core, by reusing existing tools (like tidy). Also, it gets tiresome > loading up another browser after a while with large sites, like > slashdot, that can't easily fix their problems. ( That's one downside > of using dillo - once you get used it, it's hard to tolerate anything > else :) > Tidy is actually an excellent idea ... server side :-) This /. guy should give it a try. On the other hand, fixing a broken page client side everytime it's loaded really sounds terrible. About the list of excuses given for not fixing the bug right away, the only real one is the management's priorities. As for the rest, I would just say: - not fixing bugs because some customers rely on them is bad for business; - not fixing bugs beacuse it has a lot of dependencies tell the design is probably wrong; - not fixing bugs because "it's complicated" is really lame; - "why would anybody write a browser from scratch?" why would anybody do anyting? let's all use windos and IE6! Best, EG

Oct. 19, 2003

Re: [Dillo-dev] Re: /. crap

by Stephen Lewis

On Sat, Oct 18, 2003 at 08:19:49PM -0700, Eric GAUDET wrote: > -- En reponse de "Re: [Dillo-dev] Re: /. crap" de Geoff Lane, le > 18-Oct-2003 : > >> I have a suggestion regarding this: > >> While supporting broken HTML isn't really in the project goals, > >> would it be possible to wrap a tool like htmltidy using the dpi? > >> > >> So that dillo itself never even gets delivered broken HTML at all, > >> becauses it's all been pre-processed into something valid... > > > > One of the objections to accepting and attempting to display broken HTML > > is that you have no idea if the browser interpretation of the bad HTML > > matches the intention of the author. <snip> > The only effort we make towards broken html is trying as hard as we can not > to segfault. If a broken page is not rendering properly in Dillo (or any > browser), it's a bug in the page, not a bug in Dillo. Period. OK, your response ( and the others ) has convinced me that this was a bad idea :) I realize this thread comes up periodically, I only mentioned it this time because it was a way of minimizing the problem outside of the core, by reusing existing tools (like tidy). Also, it gets tiresome loading up another browser after a while with large sites, like slashdot, that can't easily fix their problems. ( That's one downside of using dillo - once you get used it, it's hard to tolerate anything else :) -- Stephen Lewis

Oct. 19, 2003

Re: [Dillo-dev] Re: /. crap

by Eric GAUDET

-- En reponse de "Re: [Dillo-dev] Re: /. crap" de Geoff Lane, le 18-Oct-2003 : >> I have a suggestion regarding this: >> While supporting broken HTML isn't really in the project goals, >> would it be possible to wrap a tool like htmltidy using the dpi? >> >> So that dillo itself never even gets delivered broken HTML at all, >> becauses it's all been pre-processed into something valid... > > One of the objections to accepting and attempting to display broken HTML > is that you have no idea if the browser interpretation of the bad HTML > matches the intention of the author. Not only that, but it is also a significant effort to : - detect that the html is broken (it can have thousands of different problems) - pick the right fix for it (the one that most browser will agree on, because there's no standard for rendering broken pages, by definition) - fix it so it displays somewhat properly (meaning, change the internal representation of the page) By "significant effort", I mean we need develpment time to add a lot of non-trivial error recovery code, and also it will slow down the rendering process because it will need some sort of second-pass parsing of the page. That's why Dillo's attitude is to stick to the standard, not because we're standard fanatics: that's the only way to have a bounded and reliable definitoin of what rendering should be. The only effort we make towards broken html is trying as hard as we can not to segfault. If a broken page is not rendering properly in Dillo (or any browser), it's a bug in the page, not a bug in Dillo. Period. Best, Eric ------------------------------------------------------------------------ Eric GAUDET <eric(a)rti-zone.org> Le 18-Oct-2003 a 20:10:05 "Parler pour ne rien dire et ne rien dire pour parler sont les deux principes majeurs et rigoureux de tous ceux qui feraient mieux de la fermer avant de l'ouvrir." ------------------------------------------------------------------------

Oct. 19, 2003