- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] A short potpourri

by johannes leimbach

> Again, it can be done. If you're a developer, > look at the code for selections (to know how to get > the word under the mouse pointer), then look at how > bookmarks are added (to learn how to send a dpi > command) and then read the dpi docs, to bind your dpi. > > HTH > Jorge.- Or you just go and download stardict from http://stardict.sourceforge.net/, select your word and have a nice translation without even recompiling dillo :) -- < bye > \ oO)-. /__ _\ \ \( | \__|\ | ' '--'

Oct. 22, 2003

Re: [Dillo-dev] Re: Thanks

by Maurice McCarthy

Many thanks to Johann and Gregg for the tips. I can compile and patch, if its not too difficult (Thanks to studying the LFS course) but I'm not up to speed with CVS yet. Just bought O'Reilly's Linux in a Nutshell and have the Linux SA Handbook on order. So I'll give it all a go. Yipee Maurice ----------------- If you think Google's fast Google with a Dillo!

Oct. 22, 2003

Re: [Dillo-dev] A short potpourri

by Jorge Arellano Cid

Hi Eythan, > > I have read that people use dillo to read > documents, long documents, and perhaps whole > books, or chapters... In such cases there comes > a time when a use of a dictionary is a must. Is > it possible to have a dpi that will allow for the > running of any shell command on a highlighted > portion of the screen? It can be done. > In this example running > a dictionary on a word? The output of the > command would go into a new tab, or window or > split of the current window, horizontally or > vertically, depending on the key-binding. I'd make the dpi have its own window and let dillo grab the word from the mouse pointer position before asking the dpi for the word. All with a keyboard shortcut; very practical! Again, it can be done. If you're a developer, look at the code for selections (to know how to get the word under the mouse pointer), then look at how bookmarks are added (to learn how to send a dpi command) and then read the dpi docs, to bind your dpi. HTH Jorge.-

Oct. 21, 2003

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