May 2004 - Dillo-dev - lists.mailman3.com

[Dillo-dev]BugTrack
by Jorge Arellano Cid 22 May '04

22 May '04

Hi there! Dillo's bugtrack was just updated so email addresses are mangled with images to protect from SPAM robots. The "submitter" camp was also added, so we can contact the poster for details. Cheers Jorge.-

1 0

[Dillo-dev]javascript links
by Jorge Arellano Cid 22 May '04

22 May '04

Hi there, The CVS is just updated for 0.8.2-pre. The first patch is a tiny handler for javascript links. It's very simple, it will try to make a normal link from a javascript-based href. Please test it and tell me how it works. Cheers Jorge.-

1 0

[Dillo-dev]White space handling
by Sebastian Geerken 21 May '04

21 May '04

Hi! This mail is just to collect what I have found in the specs, and how I understand it. I'll comment Jorge's mails seperately. Sebastian. ---------------------------------------------------------------------- HTML ---- Unfortunately, I do not have the SGML spec at hand, so I only refer to the parts of the HTML spec, which refer to general SGML topics. There is something in chapter 6, although I did not find anything about how #PCDATA (which is used in the DTD for the texts, which are relevant in this context), only about #CDATA: > 6.2 SGML basic types > > The document type definition specifies the syntax of HTML element > content and attribute values using SGML tokens (e.g., PCDATA, CDATA, > NAME, ID, etc.). See [ISO8879] for their full definitions. The > following is a summary of key information: > > * CDATA is a sequence of characters from the document character set > and may include character entities. User agents should interpret > attribute values as follows: > > o Replace character entities with characters, > o Ignore line feeds, > o Replace each carriage return or tab with a single space. > > User agents may ignore leading and trailing white space in CDATA > attribute values (e.g., " myval " may be interpreted as > > "myval"). Authors should not declare attribute values with leading > or trailing white space. > > For some HTML 4 attributes with CDATA attribute values, the > specification imposes further constraints on the set of legal > values for the attribute that may not be expressed by the DTD. About HTML: > 9.1 White space > > [...] > For all HTML elements except PRE, sequences of white space separate > "words" (we use the term "word" here to mean "sequences of non-white > space characters"). When formatting text, user agents should > identify these words and lay them out according to the conventions > of the particular written language (script) and target medium. > [...] This is, what is currently the difference between calls to a_Dw_page_add_text() (which adds a word), and a_Dw_page_add_space(), which adds a "word separation". > B.3.1 Line breaks > SGML (see [ISO8879], section 7.6.1) specifies that a line break > immediately following a start tag must be ignored, as must a line > break immediately before an end tag. This applies to all HTML > elements without exception. > > The following two HTML examples must be rendered identically: > > <P>Thomas is watching TV.</P> > > <P> > Thomas is watching TV. > </P> > > So must the following two examples: > > <A>My favorite Website</A> > > <A> > My favorite Website > </A> Notice this: "This applies to all HTML elements without exception." That is, also for <pre>. But it does not say anything about white spaces in general. XHTML ----- First of all from the XML 1.1 spec: > 2.10 White Space Handling > > In editing XML documents, it is often convenient to use "white > space" (spaces, tabs, and blank lines) to set apart the markup for > greater readability. Such white space is typically not intended for > inclusion in the delivered version of the document. On the other > hand, "significant" white space that should be preserved in the > delivered version is common, for example in poetry and source code. > > An XML processor MUST always pass all characters in a document that > are not markup through to the application. A validating XML > processor MUST also inform the application which of these characters > constitute white space appearing in element content. First of all, we do not have a distinction between the (basic) XML processor, and the application. (In the CSS prototype, this is clearer, and because it is always a good decision to make the implementation structure resemble the structure of the specifications, this should be kept in mind.) How I understand this basicly: It is (in most cases, see below) the task of the application (in this case XHTML) to determine how to deal with whitespaces. Anyway, I did not find anything in the XHTML 1.0 specification, so I believe that the same rules apply, as for HTML 4.01. > A special attribute named xml:space MAY be attached to an element to > signal an intention that in that element, white space should be > preserved by applications. In valid documents, this attribute, like > any other, MUST be declared if it is used. When declared, it MUST be > given as an enumerated type whose values are one or both of > "default" and "preserve". For example: > > <!ATTLIST poem xml:space (default|preserve) 'preserve'> > <!ATTLIST pre xml:space (preserve) #FIXED 'preserve'> > > The value "default" signals that applications' default white-space > processing modes are acceptable for this element; the value > "preserve" indicates the intent that applications preserve all the > white space. This declared intent is considered to apply to all > elements within the content of the element where it is specified, > unless overridden with another instance of the xml:space > attribute. This specification does not give meaning to any value of > xml:space other than "default" and "preserve". It is an error for > other values to be specified; the XML processor MAY report the error > or MAY recover by ignoring the attribute specification or by > reporting the (erroneous) value to the application. Applications may > ignore or reject erroneous values. If you look at the DTDs of XHTML 1.1, you'll find three elements setting this: <style>, <script>, and <pre>. As to the patch: <style> and <script> are currently rather unimportant, while for <pre>, the HTML parser switches into the DILLO_HTML_PARSE_MODE_PRE mode, where white spaces are handled differently. > The root element of any document is considered to have signaled no > intentions as regards application space handling, unless it provides > a value for this attribute or the attribute is declared with a > default value.

1 0

[Dillo-dev]Tabs/Frames/Kbnav
by Jorge Arellano Cid 21 May '04

21 May '04

Hi, Now that dillo 0.8.1 is done, I want to clarify what happened with the Tabs/Frames/KeybNav patch. Sometime has passed since, but at the time we decided to not stir an already ungrateful situation. Here I'm forwarding a couple of emails that should be enough to do it (dillo-dev archives holds the rest). Sincerely Jorge.- -------------------------------------------------------------------------- From akemnade(a)informatik.uni-bremen.de Mon May 17 08:44:51 2004 Date: Sat, 27 Mar 2004 14:25:31 +0100 From: Andreas Kemnade <akemnade(a)informatik.uni-bremen.de> To: Sebastian Geerken <s.geerken(a)ping.de> Cc: jcid(a)dillo.org Subject: Re: [Dillo-dev]Frame support in CVS Hi Sebastian, Hi Jorge, On Sun, 7 Mar 2004 22:14:49 +0100 Sebastian Geerken <s.geerken(a)ping.de> wrote: > Hi Andreas. > > (I'm writing this in English to make forwarding etc. simpler.) > > Jorge and I would indeed like to incorporate Frank's work into the > main trunk, but unfortunately Frank refused to clean up the code, and > finally, he quit the project, and plans to make an own version of > dillo. I've a mail of 8 Jan, which I can forward you, if you are > interested. > Please send me that mail. Ok, perhaps I was not deep enough in the archives. I just did not find any statement about what has to be done with the patch. I think other readers of dillo-dev do not know about that, too. Perhaps it would be better if that was more clarified but I also understand that you do not want to repeat yourself too often. > If you want to commit some work, you may clean up the patch, > especially split it up into several parts. Most important, there are > three parts: DilloDoc (which I'd like to be renamed), frames, and > tabs. They are of course related, but it would be handy to have single > patches for them (because of the over-linear correlation of patch size > and review time). > Most the time I was just happy to be able to apply the frames patch. I was not forced to look at the code. But with the massive conflicts the patch produces when I applied it to 0.8 I really had to start to look at the patch. Sometimes being not a maintainer has really big advances... If I checked the patch size before fixing the conflicts I guess I would have given up. I have never noticed before how big the patch was. If splitting does not work, then there is something really wrong with the code. So let's divide and conquer. I think an important part is to remove nice (but not very important) features from the patch which can be added separetely later on. I think I can find time in the next month to split and clean up the frame patch. Greetings Andreas Kemnade -------------------------------------------------------------------------- From s.geerken(a)ping.de Mon May 17 08:44:37 2004 Date: Sat, 10 Jan 2004 13:04:11 +0100 From: Sebastian Geerken <s.geerken(a)ping.de> To: Jorge Arellano Cid <jcid(a)dillo.org> Subject: Fwd: Re: Notes on keyboard navigation FYI. [ Part 2: "Included Message" ] Date: Thu, 08 Jan 2004 22:31:10 +0100 From: Frank de Lange <frank(a)unternet.org> To: Sebastian Geerken <s.geerken(a)ping.de> Subject: Re: Notes on keyboard navigation Sebastian Geerken wrote: >Hi Frank. > >First of all, a happy new year! > >Several notes on keyboard navigation: > >1. Jorge and I decided, that we do not immediately support keyboard > configuration, also because it is rather unclear what widget > toolkit will be used in the future. So the version of keyboard > navigation, which will be integrated the first time, should have > hard-coded keys. > >2. Some days ago, I committed some changes to iterators, you may be > interested in. There is some description within doc/Dw.txt, section > "Anchors and Scrolling", subsection "Scrolling". Especially, > scrolling has now two dimensions, there is a new scrolling > position, DW_[HV]POS_INTO_VIEW, and DwIterator::scroll_to has been > replaced by the more general DwIterator::get_allocation. > >3. I noticed some performance problems with stress tests, I'm not sure > they play a role in real life. Anyway, you wrote on the list that > you are already working on in. > >Sebastian > > Happy new year as well... and thanks for the notice. For keyboard navigation to work in a sensible way x coördinate support is useful... so useful that I had already implemented it. The performance problems have been solved in my tree as well, as I have stated in my last message to the list. They are caused by the use of g_list_search_custom to find the focusable in focus.c. Using a hash table solved this. But... I have decided to discontinue support to the Dillo project as of the 'infringer' message to the list, so I will no longer post or update patches to Dillo. Instead, I am working on a new browser which should fill the same niche as Dillo (small, fast, enough features for most sites so it can be used as main browser). Starting point for this is my patched version of Dillo, with additional changes: - dpi and dpid and related things are gone (DONE) - library plugins for everything dpi did, and more (mime decoders, schemes, etc) (DONE) - ccc is on the way out, to be replaced by something less convoluted and more general (WORK IN PROGRESS) - DOM support with new xml parser (WORK IN PROGRESS) The project currently uses GTK+ as toolkit, but might switch to something else (FLTK is a candidate). A side goal for this project is to be developer-friendly. Patches are welcome, they will get their own space on the site (which will be on savannah, which is still not completely recovered from the break-in yet... hence the delay). I may post a short notice to the list if/when the project is up and ready for testing. Good luck with Dillo. 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." ]

3 2

[Dillo-dev]Re: White spaces handling (was: Weird glitch with rendering)
by Jorge Arellano Cid 19 May '04

19 May '04

Hi Sebastian, One thing that puzzles me about the patch that collapses whitespace at the parser level, is that some tables no longer are centered! For instance: http://www.dillo.org/stats/ http://www.dillo.org/stats/usage_200405.html Cheers Jorge.-

1 0

[Dillo-dev]0.8.1 text centering error?
by Gregg 18 May '04

18 May '04

Hello, I have compiled and run Dillo 0.8.1 flawlessly on Debian woody. However, I notice the browser "centering text" that wasn't on 0.8.0 and earlier. Example: http://www.cknw.com - my daily news, now shows the headlines as centred. Is this supposed to be? Thanks, -- Gregg

1 0

[Dillo-dev]dillo-0.8.1 was officialy released.
by Jorge Arellano Cid 15 May '04

15 May '04

Hi folks, The new dillo-0.8.1 is just released now, waiting to appear on the freshmeat front page. It's been a long road 'til here, so please let me thank all of you that have participated in dillo-dev. Now, let's party! ;-) Jorge.-

1 0

Re: [Dillo-dev]dillo-0.8.1.tar.bz2 final
by Jorge Arellano Cid 15 May '04

15 May '04

Hi there, Has anyone tested on *BSD yet? and Solaris? Cheers Jorge.-

3 2

Re: [Dillo-dev]dillo-0.8.1.tar.bz2 final
by Jorge Arellano Cid 14 May '04

14 May '04

On Fri, 14 May 2004, Maarten Sander wrote: > Hi, > > > It's a simple test, if you have a working dillo binary after > > 'make', it's OK. That's all. > > > > Please don't be shy and report success on your platform. If > > nobody reports problems before Kelson is done (or Saturday), it > > will be released. ;-) > > Well, it works overhere :) > > I've just compiled and used Dillo on my Fedore Core 1 (Athlon-)machine. > It's updated with all the latest and greatest (*cough*) packages from > Dag, ATrpms, etc. GCC is 3.3.2, glibc 2.3.2, GTK 1.2.10. During > ./configure it gave a big warning that it could not find libpng-config, > but it detected png.h after that and compiled without problems. libpng is not easy to detect, maybe the Fedora team decided to go back to the simple header/library pair to avoid problems. Don't worry. You have a quite current GNU/Linux. Can you tell whether Dillo was linked against NPTL? Cheers Jorge.-

2 2

[Dillo-dev]dillo-0.8.1.tar.bz2 final
by Jorge Arellano Cid 14 May '04

14 May '04

Hi there, It's being a long period of testing. As I don't want to delay the next release anymore, the final tarball is there, ready for download! It is not yet announced, probably on Staurday, after Kelson is ready with the RPMs. The final tarball is not exactly the same as "pre2", it comes with a few fixes: - A fix on iterartors (on a very rare critical warning). - A fix to gray up the stop button on downloads (1 line fix). - A new link in the splash, magazines section. - A fix on pthreads detection code. The last one _NEEDS_ testing, on every machine! I may have said only on non Linux-based ones, but the bug was detected on an old libc5 based GNU/Linux! It should work because it more or less leaves the settings as they were before, but with the enhancement of not linking pthread to every binary. It's a simple test, if you have a working dillo binary after 'make', it's OK. That's all. Please don't be shy and report success on your platform. If nobody reports problems before Kelson is done (or Saturday), it will be released. ;-) Good Luck! Jorge.- PS: Please note that this release shifts the state from alpha to "very stable beta". PS2: http://www.dillo.org/download/dillo-0.8.1.tar.bz2

2 3