- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] Compatibility Patch

by Andreas Schweitzer

Hi, > This time i have a little patch for urls with white spaces, it > converts them to correct characters (%20), it works well, just > download the nav.diff.gz from my site and copy it to dillo/src > directory: I would say we should appreciate the effort, but this issue came up before - long time ago, so you can't know about it. But read, e.g. these threads : http://sourceforge.net/mailarchive/message.php?msg_id=1148257 http://sourceforge.net/mailarchive/message.php?msg_id=1167938 However, I would like to raise an issue here : I agree to stick to correct HTML. But isn't it worth only if the offending webmaster notices that his page is broken, instead of the surfer noticing it ? Or - actually, the user may not even know, why exactly the link is not working. I agree, that there are more important things to do than making nice looking popus that say "Dear user, the web page you are visiting is broken because of ..." so that the user can complain to the webmaster. But for the long run this could be considered. And only as long as dillo can easily detect errors, of course. In this case, would it make sense to adjust the Browser ID to include a messgage along the lines of : "Webmaster, you have a malformed URL in a page of yours." ? Just some thoughts, which probably won't make it before dillo is much more mature. Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Oct. 24, 2003

Compatibility Patch

by Carlos Daniel Ruvalcaba Valenzuela

Hi everyone. This time i have a little patch for urls with white spaces, it converts them to correct characters (%20), it works well, just download the nav.diff.gz from my site and copy it to dillo/src directory: $ gunzip nav.diff.gz $ patch nav.c nav.diff Answare yes to the question that patchs mades to you. My Web: http://earth.prohosting.com/wbuffer Cheers Carlos Daniel Ruvalcaba

Oct. 24, 2003

Re: [Dillo-dev] FLTK

by Jorge Arellano Cid

Hi there! Just to add more information about FLTK: http://mail.gnu.org/archive/html/texmacs-dev/2003-02/msg00073.html Very informative. Cheers Jorge.-

Oct. 23, 2003

Re: [Dillo-dev] Can't find dpidrc

by Nigel Wilkinson

Thanks everyone Nigel

Oct. 23, 2003

Re: [Dillo-dev] FLTK

by Jorge Arellano Cid

Hi there! After the previous answers from Michael Sweet (forwarded to this list), Sebastian rose a key question: > GtkLayout is mainly there to overcome the limited size of X > windows. When I started to develop Dw, I first tried to get a similar > result by writing anything myself, but finally gave it up. Look at the > Gtk+ documentation, GtkLayout does some weird things which may not be > possible with FLTK. Once again, here're the answers. Cheers Jorge.- PS note: Fl_Help_View is a widget for basic HTML rendering. ---------- Forwarded message ---------- Date: Wed, 22 Oct 2003 16:03:52 -0400 From: Michael Sweet <mike(a)easysw.com> To: Jorge Arellano Cid <jcid(a)dillo.org> Subject: Re: FLTK and Dillo Jorge Arellano Cid wrote: > ... > One interesting concern raised by Sebastian is about a way to > overcome the limited-window-size problem of X windows (GTK+ uses > GtkLayout to overcome it). I know FLTK runs on WIN32 so it should > have no problems with large windows, but I couldn't find any > formal doc stating it. This is an issue for us because of large > scrolled html pages (or should I say books?). Are you referring to the 16-bit coordinate issues? If so, those are also present on WIN32... FLTK 1.1.x uses 16-bit integers for coordinates, so to support views larger than 16-bits you'll need to do a little work yourself. For example, Fl_Help_View offsets the X,Y values by the current scroll position and does gross clipping of blocks to support really long HTML files. FLTK 2.x uses 32-bit integers for coordinates and doesn't have this limitation. It will also be providing device classes to support X11, PostScript, PDF, etc. rendering in a device- independent way. >>> 2.- Unicode, UTF-8. >>> This was the main reason for considering GTK2. Is FLTK ready >>> to render Unicode characters? >> >>The patched version is, and FLTK 2.0 will fully embrace UTF-8. > > > Do you mean current FLTK 2.0 CVS does not have the patch yet? AFAIK, 2.0 doesn't have it yet. Bill Spitzak is probably a better person to talk to on that issue, as I've been sticking to maintaining 1.1.x (lack of time on my part - too many other projects! :) > If so, can it be patched or should we use 1.1.4 + utf-8 patch? > > In other words, which version should we start testing with? > What's your advice to structure it (i.e on which widgets should > we base HTML rendering)? Use 1.1.4 + UTF-8 patch; 2.0 is still in a state of flux, and until we have the new device classes in place there may still be some API changes. If you write to 1.1.x now, the 1.x compatibility headers in 2.0 should be enough to support your apps with either release. You'll probably want to subclass Fl_Group and use the existing Fl_Scrollbar classes to provide your scrollbars. The Fl_Help_View widget might serve as a guide for your porting effort, as it supports a limited subset of HTML and does all of the scrolling, linking, etc. stuff. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com

Oct. 23, 2003

CSS

by Sebastian Geerken

Hi! At <http://www.dillo.org/CSS.html>, you'll find an updated version of a document I posted quite a while ago. What this text describes, is partly implemented (mainly to test the critical aspects of the design), I may soon make a tarball public, after some cleanups. The further development is unclear, since some parts have been rewritten, incremental development is difficult, and several general tests are necessary (performance, functionality etc). Sebastian

Oct. 23, 2003

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

by Sebastian Geerken

On Mon, Oct 20, Frank de Lange wrote: > Sebastian Geerken wrote: > > - 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... You should have commented in the code :-) > 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. [other posting] > {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. I would at least leave the traditional line, for reasons of consistence. Perhaps the link may be also highlighted, in a lighter color than the background color (and lightgray for white etc., look at Dw_style_color_create, which is used for shaded colors for borders)? This would make it unconfusable with text selections. [first posting] > Btw, apart from looking only fleetingly at it, did you try keyboard > navigation? If so, any remarks about the functionality itself? I like it, it's, aside from some glitches, quite what I meant with "geometrical navigation". The standard keys are worth to discuss, e.g. Alt-Tab is used by many window managers, and generally, I expect key combinations with the Alt modifier more at the level of windows. (IMO, no modifiers should be used for link navigation, conflicts with other functions have to be resolved somehow.) Sebastian

Oct. 23, 2003

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

by Jorge Arellano Cid

On Mon, 20 Oct 2003, Frank de Lange wrote: > 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 Use of innuendo or sarcasm will not help to get some feedback on this mailing list... Jorge.-

Oct. 23, 2003

Re: [Dillo-dev] Can't find dpidrc

by ferdif＠optusnet.com.au

On Wed, Oct 22, 2003 at 11:49:56PM +0100, Nigel Wilkinson wrote: > Hi folks > > I've just built dillo-0.8.0-pre from the CVS but when I try to use bookmarks it can't fimd dpidrc either in /usr/lib/dillo/dpi or in the ~/.dillo/dpi directory (and its right, they aren't there. Where is it or what is the format so that I can create it. If you simply ran ./configure then do echo dpi_dir=/usr/local/lib/dillo/dpi > ~/.dillo/dpidrc If you ran something like ./configure --prefix=somepath then do echo dpidrc=somepath/lib/dillo/dpi > ~/.dillo/dpidrc I'll fix this in my next patch. Cheers Ferdi

Oct. 23, 2003

Re: [Dillo-dev] localhost

by Thorben Thuermer

On Sun, 19 Oct 2003 03:33:04 +0200 Ivo <ivop(a)euronet.nl> wrote: > Hi all, > > I noticed the following behaviour, with 0.7.3 and also with the current CVS > (just checked out the latest version an hour ago). When I type the > following at the location bar: > > localhost Connects to my webserver (prepends http://) > http://localhost:2317/ It connects to my geneweb server > localhost:2317 It fails, saying ERROR: unsupported protocol > > Is this normal and expected behaviour, or considered a bug? Opera, for > example, prepends http:// and all works like expected. this is 'exected'. if the URL already contains a ':', dillo will assume the part before it is the protocol... after all, if you enter "localhost:2317", you clearly want to connect to host 2317 (0.0.9.13) using the 'localhost' protocol. > --Ivo Thorben

Oct. 23, 2003