- Dillo-dev - lists.mailman3.com

[Dillo-dev]Content outside table border
by Jorge Arellano Cid June 9, 2004

June 9, 2004

Hi Sebastian, Just found this page: http://www.757.org/~joat/blog/ look at the small calendar! Best Jorge.-

1 0

[Dillo-dev]Some remarks on the UI
by Sebastian Geerken June 6, 2004

June 6, 2004

Hi, several remarks on the UI, which should be fixed IMO. 1. Bug meter: The bug meter button reacts on the "pressed" event, to show the window, but it should react on the "clicked" signal. Popping up a window after a "pressed" signal is usually only done for volatile windows (like menus, or overview windows, like in GIMP, which often vanish again, after releasing the mouse button). Reacting on "pressed" is always a bit problematic, also because the pointer grab initiated with this event can cause side-effects. Furthermore, it should not have a relief, compare to the "Hide Controls" button. 2. The menus behind the "Back" and "Forward" buttons: Consider the following scenario: (i) The user presses button 3 on the "Back" button, and the menu is shown. (ii) He keeps the button pressed, moves to one entry in the menu, and releases the button. Nothing happens. Currently, the menu items only react on "button_press", which is anyway wrong (see above). Furthermore, in this situation, the item should already react on the "release" event, either as described above, or in the way (i) click on menu, (ii) click on menu entry. The current behaviour is that much confusing, that a user may think that it does not work at all. (I did!) (The implementation would become a bit tricky, since button 2 will pop up the page in a new window. Perhaps, I'd even suggest to skip this feature, if a clean solution is not possible.) BTW, it is not very obvious, that there is a menu behind these two buttons. Perhaps there should be, in the icon, a small arrow directed downdwards, or so. 3. Attached is the incomplete code of a new widget, which changes the behaviour of GtkButton: (i) It reacts also on button 2 and 3, this would make multiple functions for one button possible. Actually, this feature should be reserved for very few situation (since it is simply confusing), namely the "Clear URL" button, which may also be used for visiting the URL in the selection buffer. (ii) It provides a function for attaching a menu in a better way, than we have currently, for the "Back" and "Forward" menus, and for the bug meter. Simply copy all files into one directory, call "make", and run "testprg". Look, what happens with different mouse buttons. Comments welcome. Sebastian

2 6

[Dillo-dev]UTF-8
by Jorge Arellano Cid June 4, 2004

June 4, 2004

Hi guys! I just added a small hack to view UTF-8-encoded quotation marks. Yes, it's a mistery to me why someone would want to serve pages in english, encoded in UTF-8 instead of Latin1. ...but you may find some as this one: http://www.seattleweekly.com/features/0422/040602_news_microsoft.php Please let me know if you know of more pages like this one, or if you know the rationale for preferring UTF-8 over latin1 when the latter is enough. Cheers Jorge.-

2 1

[Dillo-dev]very simple question, and many kudos!
by Brian Hechinger June 3, 2004

June 3, 2004

first off, i would like to say that i am completely impressed with dillo's efficiency. i finally found myself to be in the position where i needed to get X11 onto my Toshiba Tecra notebook so that i could use a web browser. it's a 166Mhz with 32M ram, so i asked around what would be the best browser for such a low resource machine, and was told firefox by a few. so i got a copy of firefox. it was so slow, not only was it unusable, it made the rest of my computer unusable. then someone mentioned dillo. so i got it. i have to say, i can't even put my surprise of how fast it was into words. i was floored. this is EXACTLY what i needed. so far, it's perfect for me. the only thing that i have a question about is PgUp and PgDn only moving half a page at a time. is there a way to get them to move a full page? thanks, and keep up the excellent work!! -brian -- "Performing a Google search on the fairly unique name you've chosen weeks ago for a piece of software you're writing, only to discover that the sole occurance of that name is as a pen-name for someone who spends his spare time writing X-rated PowerPuff Girls fan fiction is pretty-much a buzzkill." -- Jonathan Patschke --

5 10

[Dillo-dev][bug] ppc64 crash on right-click / bug tracking system
by Thomas Cort June 3, 2004

June 3, 2004

Hi, I ran into a problem where dillo crashes when I right click on any part of a webpage. A full bug report is below this paragraph. When I went to use the bug tracking system I noticed the "Max 256 chars" notice. Is it possible to get this increased? I couldn't get my bug report into <= 256 characters. Dillo 0.8.1 on GNU/Linux (yellowdog 3.0) ppc64 (Apple G5) configure options: --prefix=/home1/students/tcort To reproduce bug: ssh with X11 forwarding and compression turned on, start dillo, and right click on any part of the webpage. Notes: I don't have local access to this machine, so I don't know if it's an X11 forwarding bug or a ppc64 specific bug. Browsing webpages works fine as long as you don't right click. Using other programs with X11 forwarding from this machine, such as gimp, work fine. Output: tcort@pepsi tcort $ ssh -X -C turing.ubishops.ca tcort(a)turing.ubishops.ca's password: [tcort@turing tcort]$ bin/dillo dillo_dns_init: Here we go! Disabling cookies. Nav_open_url: Url=>about:splash< Gdk-ERROR **: BadWindow (invalid Window parameter) serial 2306 error_code 3 request_code 38 minor_code 0 Gdk-ERROR **: BadAccess (attempt to access private resource denied) serial 2307 error_code 10 request_code 102 minor_code 0 [tcort@turing tcort]$

2 1

[Dillo-dev]https (eg for posting to ps2 bulletin boards)
by robert w hall June 2, 2004

June 2, 2004

Every time I read the playstation2-linux lists I realise how very useful dillo will be when it gets just a little further. How's the short/medium term future of https looking?(*) If an official plugin is in the offing then that's probably what we should all wait for. Otherwise, is the patch from 0.7 resurrectable?? Bob (*You need ssl to post to the ps2 bulletin board) -- robert w hall

3 4

[Dillo-dev]dillo as a debian package ..?
by Jorge Arellano Cid June 1, 2004

June 1, 2004

Hi! It's been a long time since the debian package for Dillo is not updated. Since 0.7.3 to be accurate. :-( I've contacted Phil and, surprisingly, the only reason for them not being made is lack of time. Is here a Debian developer that can take the burden, or help Phil, or at least provide us with an x86 .deb to link to from the download page? It seems important because Debian lingering on 0.7.3 implicitly passes the (wrong) message of the latter versions of dillo not being worth an upgrade. TIA Jorge.- ---------- Forwarded message ---------- From: Jesper Olsen <__lazer __at phreaker__ net__> To: jcid(a)dillo.org Subject: dillo as a debian package ..? hello there .. Is there somewhere around where i can get dillo-0.8.1 as a .deb file?? i can't find it, i've almost looked everywhere :s MaNN, thank you for a wonderful browser .. it runs top stable and fast on my 166mhz .. well, it is a shame that i can't get the new versions of the browser ! DILLO ROCKS!!!!! - lazer

3 5

Re: [Dillo-dev]Some remarks on the UI
by Nicola Girardi June 1, 2004

June 1, 2004

This is what I replied privately to Sebastian: > BTW, it is not very obvious, that there is a menu behind these two > buttons. Perhaps there should be, in the icon, a small arrow > directed downdwards, or so. In fact I didn't ever discovered there was such (useful) menu. :-( > (ii) It provides a function for attaching a menu in a better way, > than we have currently, for the "Back" and "Forward" menus, > and for the bug meter. Another menu I didn't catch, the bug meter menu. :-) > Comments welcome. Very nice. :-)

1 0

Re: [Dillo-dev]page increment (was: very simple question, and many kudos!)
by Sebastian Geerken May 31, 2004

May 31, 2004

On Mon, May 31, Brian Hechinger wrote: > On Mon, May 31, 2004 at 03:09:03PM +0200, Sebastian Geerken wrote: > > > > Scrolling half a page is actually standard behaviour of Gtk, look > > e.g. at gtk_layout_size_allocate() (in gtklayout.c), which is more or > > less responsible for this in our case, since our code uses > > GdkAdjustment::page_increment, which is set there. > > hmmmmmm. can't say i care for that behavior. maybe i should whine to the GTK > folks and see if i can either get that changed, or at least get it setup so > there is some way to override it at run/compile time? They won't probably change it, especially since dillo depends on Gtk 1.2, which development has been closed, AFAIK. > > The attached patch "solves" it, but I'm not sure, wether the standard > > behaviour should be overridden. > > how hard would it be to make it a runtime option? something in dillorc? that > way you can have standard behavior and also the option to change its behavior > to satisfy people like me? Actually, it envolves reading Havoc Pennington's essay "Free software and good user interfaces" (http://ometer.com/free-software-ui.html) especially the section "The Question of Preferences", and considering, whether or not this configuration option should be added. Actually, I'd rather like it either having applied or not (not configurable), the others should apply the patch. (Adding the code is BTW rather simple, just look at how other options are handled in "prefs.c".) > how about this. let me know when the CVS tree stablizes and i'll write that > for you. It will probably still take some time, it is a bit more difficult than I thought. Sebastian

1 0

[Dillo-dev]helper applications and their uses
by Randy May 25, 2004

May 25, 2004

Hello, First of all,let me say that i don't know a command-line from a chorus line-my feeble knowlege of Linux consists mainly of downloading Apt and Synaptic for my RH7.3 and FC1 distros,and handling it all from the GUI. Just letting you know that your'e dealing with a novice here. : ) I like the concept behind Dillo,simple and fast.I understand that you might be working on a version for frames later on,which would be even better of course.My question though-without reliance on the usual Mozilla plug-ins(which Galeon,Epiphany and Firefox also use) is there anything I can download as a helper application? Would the full Java,for example,interact at all with Dillo when browsing the Web? Would Realplayer,or Gxine with Real plug-ins(i'm on Gnome,of course). Thanks in Advance, Randy

2 1

[Dillo-dev]Dillo RPM available for Yellow Dog Linux 3.0
by Kelson Vibber May 24, 2004

May 24, 2004

In case anyone's interested, I posted an RPM for Yellow Dog Linux 3.0 over the weekend. The usual place: http://www.hyperborea.org/software/dillo/ -- Kelson Vibber www.hyperborea.org

1 0

[Dillo-dev]0.8.1 text centering error? (fwd)
by Jorge Arellano Cid May 23, 2004

May 23, 2004

---------- Forwarded message ---------- Date: 18 May 2004 04:15:11 PDT From: Gregg <dude(a)scorpiorising.ca> To: Dillo <dillo-dev(a)lists.auriga.wearlab.de> Subject: [Dillo-dev]0.8.1 text centering error? 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 _______________________________________________ Dillo-dev mailing list Dillo-dev(a)lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

1 0

[Dillo-dev]Re: White spaces handling (was: Weird glitch with rendering)
by Jorge Arellano Cid May 23, 2004

May 23, 2004

Hi Sebastian, > Just FYI: I remember from the old discussion, that DwPage originally > collapsed spaces (i.e. calls to a_Dw_page_add_space), and that I > suggested some changes, so that this is not done anymore. Your patch > would reverse this change again. > > The discussion goes attached. I read the whole thread you sent me. BTW, the whole whitespace issue re-started when I found one of the patches you mentioned. I then read the past emails, and started to try to follow. It is not easy to make a clean picture of it though! --This mainly because of the way it used to be handled inside Dillo and because the SPECS seem not definitive in this matter. Here I'll try to cite past emails and comment my current thoughts: > [...] > This is because a_Dw_page_add_space is called twice, and this function > does actually not add a space, but change the current one. I've worked > on two solutions: > > 1. The first patch (underlined-spaces-clean.diff) changes the > behavior of a_Dw_page_add_space, but needs some changes in the > HTML parser, to control better when this function is called, > i.e. to ignore spaces after <A> and before </A>. This one seems the best candidate. With regard to fixing the parser for ignoring these spaces, see my comments below. > 2. The second one (underlined-spaces-kludgy.diff) tries to adjust > spaces, depending on rather hairy conditions. It works already > (if I'm not wrong, it has quite the same results as the code > before, except the bug). This option is no longer valid. As you clearly described: <q> > > > 2. The second one (underlined-spaces-kludgy.diff) tries to adjust > > > spaces, depending on rather hairy conditions. It works already > > > (if I'm not wrong, it has quite the same results as the code > > > before, except the bug). > > As I've now noticed, this will not work for CSS, e.g. the following > code: > > One non-underlined word > > will be displayed: > > One non-underlined word > ---- ----- > > just because this patch lets DwPage assume something about the > document structure (change from non-underline to underline == > beginning of a tag) which it can (and should) not. > </q> Now, > > Despite of the file names, I'm not sure if the changes in the HTML > parser can be done cleanly. So, if you think that this is difficult to > realize, apply the second patch. Especially, there is probably also an > other DwPage function necessary to remove again the last space, when > </A> is read after a space. I believe the parser is not very hard to modify for ignoring the spaces as patch 1.- requires. The problem is that the SPEC is not clear about exactly how these spaces should be collapsed. For instance: > A different case is "Some text". Your patch will make > "Some text" of it, but it should be really be > "Some text." Yes, I agree, "collapsing" here should be: 'Some text' => 'Some text' as you note. but what do we do with this: 'Some text' If we ignore white space after the start tag and before the end tag, it becomes 'Sometext' (with no space at all!) If we "collapse" as the SPEC says should be done, we have two possibilities: 'Some text' (as it was: underline the whitespace) and 'Some text' (move the space out of the tag) AFAICT, the SPEC leaves the choice open, and advices HTML authors against whitespace inside the tags. IMO, always collapsing white space after the start tag and before the end tag is the simplest to implement. Even more, as the SPEC doesn't define what to do in this case, it's an option left to the User Agent: <q source='HTML4.01 SPEC, 9.1'> In order to avoid problems with SGML line break rules and inconsistencies among extant implementations, authors should not rely on user agents to render white space immediately after a start tag or immediately before an end tag. Thus, authors, and in particular authoring tools, should write: We offer free <A>technical support</A> for subscribers. and not: We offer free<A> technical support </A>for subscribers. </q> Now, this solution would also account for the special SGML line break rules: <q source='HTML-4.01 SPEC B.3.1'> 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: Thomas is watching TV. Thomas is watching TV. So must the following two examples: <A>My favorite Website</A> <A> My favorite Website </A> </q> Note that Firebird doesn't follow the SGML line break rules! This is not to say we should follow, but that we may find some buggy pages out there, but at least at this point the SPEC is quite clear. ;) > I'm not completely sure, we should carefully evaluate the specs, I'd > suggest to delay this for the 0.8.2 release. Neither I am sure! :-) At this point I see that applying patch 1, plus making the parser ignore whitespaces after a start tag and before an end tag is a correct solution that can endure a reality test. I'll start coding it. Please let me know your thoughts or any point I'm still missing. Best Jorge.- PS: This work is for 0.8.2.

2 9

[Dillo-dev]BugTrack
by Jorge Arellano Cid May 22, 2004

May 22, 2004

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 May 21, 2004

May 21, 2004

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 May 21, 2004

May 21, 2004

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: > > Thomas is watching TV. > > > Thomas is watching TV. > > > 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 May 21, 2004

May 21, 2004

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 May 19, 2004

May 19, 2004

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 May 18, 2004

May 18, 2004

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 May 15, 2004

May 15, 2004

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 May 15, 2004

May 15, 2004

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 May 14, 2004

May 14, 2004

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 May 14, 2004

May 14, 2004

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

Re: [Dillo-dev]dillo-0.8.1.tar.bz2 final on ps2
by Jorge Arellano Cid May 14, 2004

May 14, 2004

On Fri, 14 May 2004, robert w hall wrote: > works OK on playstation2-linux with a 2.2.21 kernel (from xrhino). > I haven't tried it on the default (sony) 2.2.1 kernel (kids seem to have > deleted it!) - but dimly recollect pthreads is a library not a kernel > feature, (so it shouldn't matter???) POSIX threads is one of "those" complex matters. It depends on several things including the kernel and glibc. To add flavour, Linux comes/came with linux threads, which is close to POSIX but not fully. The New POSIX Threads Library (NPTL) is POSIX compatible, and requires special kernel threading (as of 2.5.36), glibc 2.3 and other bindings (RedHat 9 was going to be the first to provide such environment). Furthermore, there are several different threading libraries among the platforms we support, so go figure! You can read much more than you wanted to know here: http://lwn.net/Articles/10465/ http://people.redhat.com/drepper/nptl-design.pdf As you may have begun to suspect after this short exposition, it's hard to know, and certainly I don't know, whether it will also run with Sony's 2.2.1 kernel! :-) Regards Jorge.-

1 0

[Dillo-dev]pre release
by Frank W McCormick May 13, 2004

May 13, 2004

Hi all Compiled and running the pre on Linux 2.4.24. No problems yet, but one thing that's been bothering me since Dillo was given DL capabilities....right clicking on a direct link gives you the DL but were it not for the eth0 indicator in ICEWM I wouldn't have any indication that DL was going ahead. Is this normal ? -- -------------- Frank McCormick Montreal --------------

2 1

[Dillo-dev]Re: null byte in HTML
by Jorge Arellano Cid May 13, 2004

May 13, 2004

---------- Forwarded message ---------- Date: Thu, 13 May 2004 12:33:13 +0300 (EEST) From: Jukka K. Korpela <jkorpela(a)cs.tut.fi> To: Jorge Arellano Cid <jcid(a)dillo.org> Subject: Re: Is the null byte allowed in HTML? On Wed, 12 May 2004, Jorge Arellano Cid wrote: > I can't yet found whether the null byte character is allowed in > HTML. Can you shed some light on this? It is not. You could use http://validator.w3.org to check for disallowed characters (it reports "non SGML character number 0"), but the ultimate reference is a) for HTML 4, the SGML declaration http://www.w3.org/TR/html4/sgml/sgmldecl.html where UNUSED effectively means 'disallowed' b) for XHTML, the XML specification, see http://www.w3.org/TR/REC-xml/#charsets which say, among other things, that all characters below 9 (HT) are disallowed. Thanks for a good question - I'm just finalizing a book on XHTML (in Finnish, sorry) and I realized that I had forgotten to discuss the character issue in sufficient detail. (I just realized that various generators may produce data with control characters.) -- Jukka "Yucca" Korpela, http://www.cs.tut.fi/~jkorpela/

2 1

[Dillo-dev]null byte in HTML
by Jorge Arellano Cid May 12, 2004

May 12, 2004

Hi there! Does anyone know whether a null-byte ('\0') is allowed inside HTML or SGML or XML? Cheers Jorge.-

1 0

[Dillo-dev]download problem on OpenBSD
by Riccardo Mottola May 11, 2004

May 11, 2004

Hello, using pre2 I went to sourceforge do download a file. On the mirror page I selected one and clicked on the "here" message for the non-stadard refresh which gives a direct link to the file (I could use it for d/l with wget). Clicking on it brought up a file location requester, I selected my home directory and gave ok. Dillo crashed with: Nav_open_url: Url=>http://prdownloads.sourceforge.net/ayttm/ayttm-0.4.6.tar.gz?use_mirror=hean…< Connecting to 66.35.250.217 Nav_open_url: Url=>http://heanet.dl.sourceforge.net/sourceforge/ayttm/ayttm-0.4.6.tar.gz< Dns_server [0]: heanet.dl.sourceforge.net is 0x721cb8 Connecting to 193.1.219.87 HTTP warning: Unhandled MIME type: <application/x-gzip> dpi.c:71: a_Dpi_rd_dpi_socket_dir: fopen : No such file or directory - /home/multix/.dillo/dpi_socket_dir debug_msg - init_sockdir: The dpi_socket_dir file does not exist dpid started Riccardo

2 2

Re: [Dillo-dev]dillo interface and motif, athena etc
by Riccardo Mottola May 11, 2004

May 11, 2004

david feldman wrote: > > I think your questions are very good, I hope you get good answer! > unfortunately there was no follow up. I wonder if anyone else beside you was interested. -R

2 1

[Dillo-dev]BUG#522
by Jorge Arellano Cid May 10, 2004

May 10, 2004

Hi, Can anyone reproduce BUG#522? 522 Impact: soft error At: run time Type: crash Comments: Url=>http://www.rti-zone.org/dillo/Html.testsuite/jorge/c2.html< Gdk-ERROR **: BadValue (integer parameter out of range for operation) serial 4689 error_code 2 request_code 45 minor_code 0 HTReproduce: debian unstable WorkedBy: nobody Cheers Jorge.-

2 1

Re: [Dillo-dev]BUG#522
by Jorge Arellano Cid May 10, 2004

May 10, 2004

On Mon, 10 May 2004, Riccardo Mottola wrote: > Jorge Arellano Cid wrote: > > > > Hi, > > > > Can anyone reproduce BUG#522? > > [...] > > No I cannot reproduce it on solaris. > > I compiled dillo on Solaris, UltraSparc too (alyazs solaris 2.6, gcc > 3.3) You might add this to the compatibility list too. So we have: Solaris 2.6, gcc 3.3, Sparc v8 processor (=32bit) Solaris 2.6, gcc 3.3, UltraSparc (64bit?) What SunOS do they report? Cheers Jorge.-

1 0

[Dillo-dev]dillo-0.8.1-pre2.tar.bz2
by Jorge Arellano Cid May 10, 2004

May 10, 2004

Hi there! It took a long time, but finally, dillo-0.8.1-pre2.tar.bz2 is ready for download. The problem was that the patch for the problem of left-clicking an unhandled MIME type involved changes, inside the cache module, that were not trivial. I pondered the situation carefully trying to decide whether to make the patch and delay the next release, or leave it for 0.8.2. After studying the situation and developing a patch, important changes were made in the cache (for instance all the cached URLs use new code now, and the main scheduler was also changed, and the posibility of deleting an active URL-transfer was made possible). After all that, it only remained to offer a download dialog for the aborted transfer, and as the patch was already major, I went ahead and the result was one of those improvements you can't leave out. What does it do? well, now you can left-click on any URL; if it happens to be of an unhandled MIME type, the transfer is aborted, and a download dialog appears to offer the possibility of saving the resource locally. Simple and clean. Now you can click carelessly on those fake-download links from SF until you reach the real source ;). The tradeoff: the possibility of labelling this release as "beta stable" is not as clear as before. This tarball requires plenty of testing, so please download it and give it a hard time! Any use of the browser serves, specially testing the new download feature and multiple windows at the same time. Get it from: http://www.dillo.org/download/dillo-0.8.1-pre2.tar.bz2 and report back to dillo-dev. Cheers Jorge.- PS: Kudos are also welcome! ;)

3 6

[Dillo-dev]compile problems on AIX + gcc
by Riccardo Mottola May 7, 2004

May 7, 2004

Hello, I'm trying to compile 0.8.1-pre1 on AIX 4.1 : One never knows, maybe som4e progress was made :) I had still to use CFLAGS="-lpthreads" to have configure pthread working at configure. I notice the following warnings gcc -DHAVE_CONFIG_H -I. -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/u sr/local/include -I/usr/local/include/gtk-1.2 -I/usr/local/include/glib-1.2 -I/u sr/local/lib/glib/include -lpthreads -D_REENTRANT -D_THREAD_SAFE -Wall -Waggreg ate-return -c `test -f 'dw_bullet.c' || echo './'`dw_bullet.c gcc: -lpthreads: linker input file unused since linking not done should I have used LDFLAGS or something else? isn't there a more elegant solution to work around this pthread regnition problem? like a configure option? Cheers, Riccardo

1 0

[Dillo-dev]Re: about gtk on solaris 2.6
by Jorge Arellano Cid May 6, 2004

May 6, 2004

Riccardo, On Thu, 6 May 2004, Riccardo Mottola wrote: > > Hey Jorge, > > just a quick precisation. On the box where i have the old 0.7.3 dillo > which gives GTK errors, I have GIMP installed and that one works fine, I > have edited quite some images. > > SO I suspect it is something in the way dillo calls GTK that could > trigger the error, before saying GTK is bugged on that platform totally. There may be some good news for you: Try this patch: diff -pru dillo/src/dillo.c dillo-0.8.0/src/dillo.c --- dillo/src/dillo.c 2004-04-21 16:47:34.000000000 -0400 +++ dillo-0.8.0/src/dillo.c 2004-05-06 11:11:31.000000000 -0400 @@ -216,6 +216,8 @@ gint main(int argc, char *argv[]) /* Initialize GUI and parse GTK related args */ gtk_init(&argc, &argv); gdk_rgb_init(); + gtk_widget_set_default_colormap (gdk_rgb_get_cmap()); + gtk_widget_set_default_visual (gdk_rgb_get_visual()); /* Handle command line options */ while ((opt_flg = Dillo_get_opt(Options, argc, argv, &opt_argv, &idx))) { It fixes the colormap and visual detection/settings on some systems. The documentation is a bit vague about this calls, they are deprecated now, formerly suggested as initialization for most cases and removed from theGTK+2.0 API (with compatibility defines). If you're lucky, it may help with AIX too. Please test it and report. Note: The patch is in CVS now, but use a "pre1" patched tarball for the test. That asserts the use of the same configure script. Cheers Jorge.-

1 0

[Dillo-dev]downloads and pre2
by Jorge Arellano Cid May 6, 2004

May 6, 2004

On Tue, 4 May 2004, Yves de Champlain wrote: > Hi > [...] > Everything works fine except for this : > > av_open_url: Url=>http://ftp.gnu.org/gnu/ddd/ddd-3.2.1.tar.gz< > Connecting to 199.232.41.7 > warning: Unhandled MIME type: <application/x-tar> > > ** CRITICAL **: file web.c: line 57 (a_Web_dispatch_by_type): assertion > `dw != NULL' failed. > > Of course, this does not start any download but after this, > I still get messages in the shell but I will > not have those from wget once I do "save link as" > like I have if I do "save link as" before. Effectively, a left click on a non-dillo-viewable MIME type URL triggers this error message. The code inside dillo assigns it to a "null-client" which means it continues to download but it's "ignored". This has some side effects, one of them is the transfer not being aborted (so it continues wasting bandwidth and memory). It also keeps a cache entry, so when a dpi download is requested it hits and gets fed from the cache! (not from a dpi). That's clearly a bug. This days I've been reviewing the code with a view to patch it, but it seems that a full patch (aborting the transfer, cleaning the cache entry, stopping the clients and offering a download dialog) may be too complex to debug in this pre-release testing stage. Aborting the download (which would allow for the later dpi download) looks simpler. I'm currently working on this. That, plus the two patches in CVS seem to round "pre2" and most probably become 0.8.1. Cheers Jorge.-

1 0

[Dillo-dev]dillo-0.8.1-pre1.tar.bz2
by Jorge Arellano Cid May 6, 2004

May 6, 2004

Hi there, It took a long time to prepare the pre1 tarball for the next release. Mainly because complex problems were discovered in the last minute. For instance, a race condition in the dpi chain that produced segfaults (it took three days to find and fix), and several problems with the downloads server (it had troubles when saving unnamed pages as "index.html" when the file already existed, it was also not renaming those pages, etc). The "pre1" tarball can be found at: http://www.dillo.org/download/dillo-0.8.1-pre1.tar.bz2 When testing it, please pay special attention to the new detection routine for socklen_t (at ./configure time), and give the downloads server a hard test. Feedback is very important now, because I want to remove the "alpha software" label from dillo and name it as stable (beta). Thanks in advance Jorge.-

3 11

[Dillo-dev]CVS renamed ?
by Jens Arm May 5, 2004

May 5, 2004

Hi If I try to do a CVS checkout I get: [tux@tux dillo]$ cvs -z9 update -dP /sfhome/cvs/dillo: no such repository What happend ? Jens

2 1

[Dillo-dev]libpng-1.2.4 detection
by Jorge Arellano Cid May 4, 2004

May 4, 2004

Hi, Is anyone here using libpng-1.2.4? Rubén sent me a bug report and effectively we were not detecting libpng-1.2.4 right (this only happens with 1.2.4). A patch for this is in CVS, and it will appear in "pre2". I'll keep expecting more feedback from "pre1" because the png lib detection is the only change so far (it's minor and doesn't affect the work of the browser, just compilation). If anyone is using libpng-1.2.4, please let me know. Cheers Jorge.-

2 1

[Dillo-dev]GTK FLTK and other Render
by shuishuila May 3, 2004

May 3, 2004

Hi, dillo-dev， I want to port dillo to set-top box as menu(OSD). But it don't have X11,GTK. How many work need to do if I have to write widget myself? I think it's a pity that dillo combine tightly with glib/gtk, so it is hard to port to X,FrameBuffer,DirectFB etc. If dillo have it's own widget and event handle, it is a excellent broswer for embedded system. Regards, 　　　　　　　　shuishuila 　　　　　　　　shuishuila(a)hotmail.com 　　　　　　　　　　2004-04-30

2 1

Re: Re: [Dillo-dev]GTK FLTK and other Render
by shuishuila May 3, 2004

May 3, 2004

Hi,Jorge, Thank you for your reply. FLTK need X, so I need to port microwindows at least. Why no let dillo's render engine more scalable? And I think that few desktop system have FLTK. Regards, shuishuila(a)hotmail.com 　　　　　　　　　　2004-05-03 ======= 2004-05-02 10:41:00 You Wrote：======= >On Fri, 30 Apr 2004, shuishuila wrote: > >> Hi, dillo-dev， > > Hi. > >> >> I want to port dillo to set-top box as menu(OSD). But it don't have >> X11,GTK. How many work need to do if I have to write widget myself? > > That's a lot of work, but... > >> >> I think it's a pity that dillo combine tightly with glib/gtk, so it >> is hard to port to X,FrameBuffer,DirectFB etc. >> >> If dillo have it's own widget and event handle, it is a excellent >> broswer for embedded system. > > We're almost done with a plan to port Dillo to FLTK. > > You can read about it in our mailing list archives. Start here: > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-April/001882.html > > > If you have FLTK knowledge and are willing to help us doing the >port it'd be great. > > Cheers > Jorge.- = = = = = = = = = = = = = = = = = = = =

1 0

[Dillo-dev]is anyone planning to add SpiderMonkey (JavaScript-C) Engine to Dillo?
by Miernik May 1, 2004

May 1, 2004

Is any work going on to add SpiderMonkey (JavaScript-C) Engine to Dillo? http://www.mozilla.org/js/spidermonkey/ I once saw a post of somebody who planned to do something like that, but heard of no progress later. I would be very interested in such implementation. -- Miernik _________________________ xmpp:miernik@amessage.info ___________________/__ tel: +48888299997 __/ mailto:miernik@ctnet.pl http://www.miernik.ctnet.pl/

1 0

[Dillo-dev]dillo interface and motif, athena etc
by Riccardo Mottola May 1, 2004

May 1, 2004

Hello. I have never looked at dillo's source code directly, so I am asking some general questions here I have always liked dillo's speed and use of system resources because it brings back the fun of browsing and works on older workstations too, as every browser should. But I never liked dillo's interface too much. I'd like to make it a proper interface, more like other browsers have, taking inspiration for example from Mosaic's bar and bookmarks, from chimera's simplicity, from HotJava cutsomization, etc. Also, I dislike GTK: they are slow and don't work well on 256 color screens. I would use Motif for writing the interface with having an eye on LessTif of course. Motif/Lesstif is extremely fast and works like a charm on my old 20Mhz IBM RS6k witha 256 color card. Also, most free OS users have one of the either installed too, to run stuff like the excellent NEdit. Being able to install dillo on AIX, Solaris, IRIX, HP-UX without having to install an additional toolkit would just be nice. Athena is also present everywhere, but let's say it is a bit primitve. Of course, super-fast :) So I ask: how much of dillo's code is GTK dependent and how difficult would it be to port it to another toolkit? I have quite little experience with toolkits and since I don't know GTK it seems impossible to me alone. One of the nicest things, IMHO, would be a toolkit-independent dillo. Have a look at what the excellet GVIM does or at what amaya does (or, at least, did). Choose your toolkit! I don't know how they structured their code and their graphic drawing, but it would be interesting to investigate. -Riccardo

1 0

[Dillo-dev]Test for socklen_t in configure.in
by Jorge Arellano Cid April 30, 2004

April 30, 2004

Hi there, Our configure.in is in need of a test for socklen_t. I thought this one could be a good one: dnl ------------------- dnl Check for socklen_t dnl ------------------- dnl AC_MSG_CHECKING(for socklen_t) AC_TRY_COMPILE([#include <sys/types.h> #include <sys/socket.h> socklen_t x; ], [], [AC_MSG_RESULT(yes)], [ AC_TRY_COMPILE([#include <sys/types.h> #include <sys/socket.h> int accept(int, struct sockaddr *, size_t *); ], [], [ AC_MSG_RESULT(size_t) AC_DEFINE(socklen_t, size_t)], [ AC_MSG_RESULT(int) AC_DEFINE(socklen_t, int)])]) but my autoheader complains... Can someone please complete the patch, I'm currently chasing a segfault bug I found... TIA Jorge.-

2 3

[Dillo-dev]Preparing the 0.8.1 release
by Jorge Arellano Cid April 28, 2004

April 28, 2004

Hi guys, 0.8.1 is getting closer every day. It will feature what's currently in the CVS (basically the improved HTML bug detection and rendering). I'd love to be able to switch this dillo version from alpha to beta stable, but for that there's a lot of testing required. That is, the new parser (going to lots of sites and asserting there're no crashes), and the recently found problems with puppy linux and downloading and FTP (has anyone experienced trouble with these dillo plugins on their systems?). Please test our current CVS hardly, and tell us how it did. Thanks to Jim, who was the first one to send some feesback: > Wow! I can see a big improvement, lots of sites that rendered readably, > but 'iffy', are now much clearer and cleaner. Cheers Jorge.-

10 16

[Dillo-dev]what should do after the window is scrolled?
by Lei Jin April 27, 2004

April 27, 2004

After the window is scrolled, should the new contents of the window be redrawed by the code written by human? Can we output the whole contents to a place, then when the window is scrolled, we only need to updated the visible rectangle parameter? --------------------------------- Do You Yahoo!? 惠普TT游戏剧，玩游戏，中大奖！

1 0

[Dillo-dev]install-dpi-local missing?
by Livio Baldini Soares April 26, 2004

April 26, 2004

Hello everyone, Long time no see, I know, I know... My life has been a (wonderful) big roller-coaster for the last 1 to 2 years, and it seems that the remainder of this year will be the same. Anyways, just wanted to try to report that reading the README file, one gets the impression that an "install-dpi-local" script should exist to install the dpis in your ~/.dillo/ directory for you. I have googled for it, and tried searching in the CVS ATTIC with no success. Things are working for me just fine, because I know how/where to copy the dpi files, but I can imagine that some of our users might be frustated, or require additional assistance. So, before releasing 0.8.1 it might be a good idea to fix the README, explaining what is needed for a "local" install, or even better, resurrect the install-dpi-local script. best regards to all! Livio

2 1

[Dillo-dev]About porting Dillo to FLTK.
by Jorge Arellano Cid April 24, 2004

April 24, 2004

Hi there, We've had long email threads (between our core developers and some FLTK core devs.) dicussing about how the port of dillo to FLTK could be done. We've explored different paths (in abstract) and posting all the threads to dillo-dev would add more to confussion than clarity because each one was explored as it were the chosen one. For simplicity and to keep all the developers in dillo-dev well informed (and certainly inviting the interested ones to take part in the process), I prepared this recapitulation about the more relevant issues. It's a long document with a lot of information. Cheers Jorge.- PS: Previous background on this topic can be found at dillo-dev's archives: http://www.dillo.org/search-dillo-dev.html. For instance: search for "FLTK" by "jcid" sorted by "Relevance". This will not only bring my posts but also the ones from Michael Sweet that I forwarded to dillo-dev. ---------------------------------------------------------------- > [Sebastian] > Furthermore, I have plans to extract at least the core of Dw, and make > an own library of it. The package is already finished, I'm just > polishing another package, which uses Dw. (This is "rtfl", the program > for which the macros in "debug.h" are for.) > > Perhaps it is at least possible, to make Dw itself independent of the > widget toolkit (Gtk/FLTK), ... > [Sebastian] > Dw can be rather simply extracted, and probably it is the best to > start with a testbed. I've attached a test program (I searched > for it somewhere in the mailing list, therefore the french > identifiers :-), you have to build dillo first, to run > it. Perhaps it is simpler to include it into the dillo tarball > itself. > [Sebastian] > Another aspect is portability: When using other toolkits than Gtk, > GtkDwViewport may be replaced. > > For archieving this, the following new design will be sufficient: > > +--------------------+ 1 * +-------------------+ > | DwRenderingContext |---------->| DwRenderingWindow | > +--------------------+ +-------------------+ > 1 ^ | 1 > | | > viewport | | child (the top-level DwWidget) > | | > * | V 0..1 > +----------+ 0..1 > | DwWidget |--. parent > +----------+ | > * | | > `-------' > (children) > [Sebastian] > As for the actual porting, I'm currently working on two topics, which > should make porting simpler, since they reduce the Gtk/Gdk specific > stuff into single modules: > > 1. I'm currently changing the design of image handling as I > described in doc/DwImage.txt in the tarball, section "Future > Extensions". As I've seen now, this is also necessary for > topic 2. > > 2. After this, I'll implement the ideas I wrote before (abstraction > of the actual drawing), in the best case, it should be a simple > matter to write a replacement for the viewport, plus some > changes in dw_style.[ch]. (Dependance of the GtkObject model not > yet considered.) > [Matt] > Abstraction is definitely the best thing to do here. I am pretty sure > we can cross reference between the a-layer and whatever FLTK has to > offer. Spontaneously I see the need for buttons and input fields, line, > box, text and image drawing, image scaling and the dreaded 16-bit vs. > 32-bit coordinates. > > [Jorge] > > Once again, I'd wish to know how a seasoned FLTK developer > > foresees the merging path (from their point of view). With regard > > to Dw, you're the authoritative source! ;) > > [Matt] > At this point - if you guys are still interested - I guess I should > take an extensive tour through the Dw code and see, which parts map > directly onto FLTK, and which parts would need modifications or even > rewriting. ------------------ 32 bit coordinates ------------------ > [Jorge] > > Hi Michael, > > We have been extensively discussing how to port Dillo to FLTK > with Mattias M. and Sebastian. One of the key points is how to > provide for a widget that overcomes the problem of 16 bit > coordinates (GtkLayout currently solves this). > > In a formar email you told me that FLTK2.0 had 32 bit > coordinates, but suggested me to use 1.2.x release that would > also come with 32 bit coordinates. > > Matt was somewhat surprised by this... > [Matt] > I talked to Mike. He changed the coordinates to 32 bit in his local > version already. So in short, fltk 1.2 will have 32 bit coordinates. > Versions 1.1 and 1.0 will not be changed anymore, however 1.2 should > become the standard as soon as we release it, since it is source code > compatible to 1.1. > [Matt] > I went through the current CVS code yesterday, and it seems like we had > a mixup between 1.1 and 1.2. Not a biggie, but I re-merged with a > previous CVS version. The current CVS is now fully 32 bit. tested and > working. > [Jorge] > So we have to use 1.2.x CVS, but which docs are recommended for it? > > [Matt] > The 1.2 cvs contains the full 1.1 documentation and is beeing corrected > to reflect 1.2 changes and additions. I am in the process of adding > doxygen style comments to all fltk classes and methods (95% done), so > simply running the command 'doxygen' will create a second, more > 'techie' documentation in docs/html/index.html. ------- Signals ------- > [Jorge] > Appart from that, the 32 bit issue and the signals (perhaps > solved with Fl_Signal). > [Sebastian] > As for signals: This should be rather simple to re-implement. I just > hacked a prototype of very simple framework for signals, which can be > downloaded at <http://www.dillo.org/misc_files/signals-0.0.1.tar.gz>. > It lacks events returning boolean (which we need), and some more > features (which we do not need), but shows that signals aren't really > a problem. ------- Plugins ------- >> OK, there's no plugin API in FLTK. > > Do you mean what GtkPlug/GtkSocket does? There protocol has been (or > is currently?) standardized at freedesktop.org, if an implemtation is > possible (and why should it not?), this is certainly a candidate for > merging into FLTK. > > > [Matt] > > Yeah, I talked to Bill, and we decided that we will create an Fl > > utility library that offers cross platform access to files and sockets, > > provides threads and locks, and also some standardised plugin > > interface. We will be smarter this time and write it in FLTK2 with an > > FLTK1 compatibility layer... . ------------------------------ About how to approach the port ------------------------------ > > >> [Sebastian] > > >> I'm more > > >> than ever convinced that this was the right decision, especially since > > >> then, incremental resizing has been added, what would have been very > > >> difficult in Gtk. Furthermore, this shows the benefit of having an own > > >> widget set, which can be infinitively changed to our needs. > > > > > > [Jorge] > > > In that case, it seems that the path to go is to port Dw to > > > FLTK, and maybe get rid of some widgets (as DwImage) when they > > > can be replaced by an FLTK embedded one. > > > > > > In anycase, Matt is better qualified than me to comment on > > > this. > > > > [Matt] > > All images in FLTK can be resized at any point. > > > > I understand that you prefer to have your own widget set, and I surely > > don't want to convince you different (because we wanted the same thing > > and that's why we wrote FLTK in the first place). However, should you > > decide to go with FLTK, then all the source code is available to you, > > so you can do the same modifications that you would do in your code. If > > those changes (or additions) are useful for the FLTK toolkit, I'll be > > happy to do them for you (ah, that's where the benefit is for you). > > [Jorge] > This is a very interesting collaboration scenery. I believe we > could start as Sebastian suggests, and merge those features you > see could benefit FLTK. (as for images, and maybe the "complex > resize" widget using size hints to name two). > > [Sebastian] > To make this clear again: What we currently have is an own widget > toolkit within Gtk, i.e. Dw widgets, from which the page is build, are > not Gtk widgets, but instead, for Gtk, a tree of Dw widgets is a just > _one_ huge Gtk widget. (With the exception of Gtk widgets embedded > into Dw.) > > I'd like to stick with the same design (with FLTK instead of Gtk), > also on the long run. For this, there are rather few requirements for > the GUI toolkit, mainly only the 32 bit issue. Integrating both > toolkits, in the way that Dw widgets will become FLTK widgets, will > however make things generally more complicated, we will have a hybrid > which has to deal with both rendering HTML (and other) documents on > one hand and GUIs on the other hand. The duplicate code in the current > design (like event handling), is rather minimal, but integrating would > mean one of the following possibilities: > > 1. Making FLTK as abstract as possible: This would make Dw as > complex as it is now, but instead add an unneccessary > dependency, where the development of dillo will often have to > deal with the limits which any GUI toolkit has. > > 2. Incorperating stuff from Dw into FLTK: This would IMO a very bad > decision of the FLTK team. Dw was designed for rendering > documents etc., and its layout mechanism has several ad hoc > features (size hints, width extremes, incremental resizing), > which should not be in a toolkit for GUIs. Actually, the design > is quite ugly at some points. > > Furthermore, the design often changes, some historical examples: > > - Dw widgets had baselines from the beginning, but they were > fist used much later. (I was indeed hesitating at the > beginning.) > - Tables made it neccessary to introduce width extremes. > (Very ad hoc: Why not height extremes? Because texts are -- > in most languages -- written horizontally, and then > vertically split into lines.) > > - Also with tables (although noticed some time later), it > became clear that the current resizing mechanism was > inefficient and had to be extended. (Notice that Dw > requires that several resizes per second must be handled, > much more what is neededfor GUIs.) > > These were certainly not the last changes, e.g. for CSS, we will > have some other requirements, which are yet not specified. Also, > this shows that most requirements are not obvious before they > are first needed. > > If FLTK wants to adopt Dw features, it will be neccecary to > change FLTK often, and since it is not part of dillo, the > development of dillo will be slowed down, until new FLTK > releases. > > 3. We move stuff from Dw into our own version of FLTK: This would > probably the worst possible desicion, we would fork FLTK and > have to maintain it, also the parts which deal with pure GUI > aspects. > > Dw will work fine with FLTK in the way analogue to the current way, > and the problems with this split are really not as dramatic as Jorge > describes it. The FLTK developers should not make the mistake to take > just one (probably rather prominent) project and change their work so > that it just fits within it. And dillo should keep it dependencies as > low as neccessary. ------------ Porting Plan ------------ > [Sebastian] > I'd suggest the following: > > 1. Finish the planned abstractions. The general idea is to have the > Gtk/FLTK specific code in small modules, which may be rewritten in > a simple way. > > 2. Extract Dw from dillo, and write a test program for several aspects > of Dw. > > 3. Rewrite those modules mentioned in 1, and adjust the test > program. This step will still make Gtk necessary, because of the > Gtk object model, but UI control, event handling etc. will be done > by FLTK. > > AFAIS, the affected modules are the new GtkDwViewport, ImgBuf, and > DwStyle. The abstraction in step 1 may taken a bit more extreme, by > splitting up the latter two into toolkit-dependant and -independant > parts, we'll see. The dillo widgets themselves should not be > modified, if this is really necessary, this is a fault of the said > abstraction. > > After this, we will have a version of Dw, which works with FLTK. The > next step is to see how the parts we take from Gtk (object model with > signals) and GLib (several utilities) can be replaced, so that we can > get rid of the Gtk dependencies. Another topic it the port of the > actual UI; AFAIS, there should be no major problems. Appendix -------- -------------- About printing -------------- > > [Jorge] > > Is printing lost because the widget tree is not native FLTK, or > > is it assured by using FLTK's drawing primitives? > > [Sebastian] > Some remarks on this. First, we still have a "native" FLTK widget, > just that we have one large, complex FLTK widget (which complexity is > manages by Dw), instead of multiple smaller and simpler FLTK > widgets. The reimplementation of the viewport should use FLTK methods > for drawing, so there is no problem at all. > > Second, the abstraction described above should make this possible with > any toolkit, it should be simple to write a printing "viewport". > > Third, printing will anyway become more complex, for several > reasons. For one reason, I quote myself from a mail I sent Jorge, this > may also be interesting for Matt: > > <q> > I'm very sceptical about the idea to use the current rendering for > printing, for two reasons: First, the current rendering is designed > for dealing with viewports, not for pages. Pages are in some ways > different, e.g. you must break pages (instead of having one page of > unlimited height), and you cannot widen the page, you must break a > word, when it does not fit into the line, while it is more > reasonable to let the user scroll to the right, when this is > possible. (Furthermore, from a typographic point of view, dillo's > typesetting quality is sufficient for screen rendering, but rather > poor for printing, especially page breaking cannot be done as > simply as line breaking.) > > Second, most of the complexity has its roots in the requirement of > incremental rendering, which is neither needed, nor desired for > printing. Actually, it makes use for printing more complicated and > inefficient. (Although one rendering iteration has a nearly > constant time, it is as a whole still slower than a simple > non-iterative run.) > > [...] > </q> > > Furthermore, even if we would use Dw for printing (with ugly page > breaks etc.), we would need another widget tree, with the same content > of the current one, but with a state, which is different, e.g. the > top-level available width, which is the window width for the screen, > but the standard paper width for the printer.

1 0

Re: [Dillo-dev]Can't start dpid
by Barry Kauler April 24, 2004

April 24, 2004

> > the problem is dpid won't start in my custom Puppy Linux > > distro. Jorge, Thanks for the feedback. Now that I have dillorc file, dpid does load, but it still isn't working. If I start dillo from the commandline, and enter a url https://www.paypal.com, nothing at all happens in the browser, no error msg even. I get this output from dillo on the stdout/errout: Nav_open_url: Url=>https://www.paypal.com< url_str = https://www.paypal.com Dpi_parse_token: [<dpi cmd='answer' to_cmd='open_url' msg='nothing sent...'>] Dpi: [Dpi_process_io] IOClose The paypal site is working, I just checked with Mozilla. If I right-click on a link to a file on a webpage and choose to "Save link as...", the destination choice window comes up, but after pressing OK button, the stdout/errout is this: ERROR: [Dpi_get_token] Can't find token start ERROR: [Dpi_get_token] Can't find token start ERROR: [Dpi_get_token] Can't find token start ERROR: [Dpi_get_token] Can't find token start Dpi: [Dpi_process_io] IOClose So, I celebrated too soon! Do these messages mean anything much to you? Any suggestion what I should try next? Regards, Barry Kauler

1 1

[Dillo-dev]FTP
by Pete April 23, 2004

April 23, 2004

Morning all, Seeing as someone has mentioned 'FTP', I thought I would get in here. I cant seem to FTP with dillo. If I type is ftp://ftp.somewhere.com it will just hang there. If I type in ftp.somewhere.com it will take me to http://ftp.somewhere.com. So tell me, how do you FTP with Dillo? I am using CVS build. Thanks, -- Pete http://milneweb.com http://nomorevirus.com

1 0

Re: [Dillo-dev]About proxy authorization && password storing
by Jorge Arellano Cid April 23, 2004

April 23, 2004

On Fri, 23 Apr 2004, Ivan Daniluk wrote: > > [...] > > - renamed a_Http_use_proxy_passwd() to a_Http_set_proxy_passwd(). > > - Made the password not visible when typed. > > - Added a commented entry for "http_proxyuser" in dillorc. > > > > This patch is now in CVS, but is not tested because I don't > > have a proxy at hand! :-) > I've tested - it seems to be ok. Good. > And one correction from Francis Daly: > ------------------------------------------- > > From: "Francis Daly" <francis(a)daoine.org> > > To: "Ivan Daniluk" <Ivan.Daniluk(a)ucl.com.ua> > > > > On Thu, Apr 08, 2004 at 06:49:45PM +0300, Ivan Daniluk wrote: > > Hi there, > > One small thing: > > > + static const char *base64_hex = "ABCDEFGHIJKLMNOPQRSTUVWXYZ" > > > + "abcdefghijklmnopqrstuvwxyz" > > > + "0123456789._"; > > > > RFC 2068 (HTTP/1.1) defers to RFC 2045 (MIME), which uses "+/" as the > > final two elements, instead of "._". > > > > RFC 1945 (HTTP/1.0) defers to RFC 1521 (MIME, obsoleted by 2045) which > > uses the same. Done! > PS. I've sent a letter to Madis, but have got no reply yet. Yes, he's under too much work now (we were working on the SSL plugin and he had to stop because of his duties). Please allow him some time. BTW, we have a new SSL dpi prototype (not for the next release though). More on this later. I'll send a recapitualtion about the FLTK port first... Cheers Jorge.-

1 0