- Dillo-dev - lists.mailman3.com

[Dillo-dev]GTK 1.2 ..?

by R. Tyler Ballance

Is there any reason Dillo is still building against the GTK+ 1.2 libraries as opposed to 2.0 ? I'm not sure what it would break to build against the 2.0 libs, but I would really like to start building against them so I can add the clipboard code that i've had my eye on ;) I don't think the size would grow _that_ much, and I think the benefits would be large from using 2.0. Right now, the only difference I can see would be in the autoconf files, GTK+ 2.0 uses pkg-config to supply the correct cflags and ldflags, while GTK+ 1.2 uses gtk-config. Ideas, suggestions? -R. Tyler Ballance p.s. I'm working through bug #668 which I added last night on my NetBSD laptop right now, woo

March 30, 2005

Re: [Dillo-dev]Refresh patch for 0.8.4

by Brian Hechinger

On Mon, Feb 21, 2005 at 09:19:34AM +0100, Roberto A. Foglietta wrote: > > For this reason I decide to have -r option instead put an option in a > config file because packager could deliver its own default config with > that option activated by default. It could be much more difficult for > the packager to force me using that option by command line, instead. > ;-) this is why my plan was to have an rc file similar to the cookierc file so you can have fine grained control over which sites are allowed to meta-refresh and which ones aren't. IMNSHO, the best solution. ;) -brian -- "Now you know why I got the everliving hell OUT of Windows administration. Knowing it doesn't make it any easier. It's just broken-as-designed."

March 16, 2005

Re: [Dillo-dev]Patch: config option for page increment

by Jorge Arellano Cid

On Mon, Mar 14, 2005 at 02:41:31PM +0100, Alexander Becher wrote: > Hi everyone, Hi! > I have made a small change to dillo-0.8.4, so I can put a line like > > scroll_factor=0.5 > > in my dillorc and get the old behaviour for scrolling a page. > > It would be great if this could be included in the dillo distribution, > so I don't have to patch my source every time I build a new version. > > I know that the current effort is the port to FLTK. If this makes this > patch useless for new versions, I'll try to adapt it once the port to > FLTK is done. Don't worry, most probably there will not be a 0.8.5. Just be sure that once the protoype is available (with scrolling ;) you submit a patch for it. -- Cheers Jorge.-

March 14, 2005

[Dillo-dev]Patch: config option for page increment

by Alexander Becher

Hi everyone, I have made a small change to dillo-0.8.4, so I can put a line like scroll_factor=0.5 in my dillorc and get the old behaviour for scrolling a page. It would be great if this could be included in the dillo distribution, so I don't have to patch my source every time I build a new version. I know that the current effort is the port to FLTK. If this makes this patch useless for new versions, I'll try to adapt it once the port to FLTK is done. Regards Alexander -- PGP key available

March 14, 2005

Re: [Dillo-dev]configure cache size

by Jorge Arellano Cid

On Thu, Mar 10, 2005 at 09:09:39AM +0100, G. Milde wrote: > > Dear developers, > > thanks for dillo. :-) > [...] > > PS: This is a re-post. I sent this mail once, before subscribing and it > seems like it did not get through the moderation process. dillo-dev receives too much SPAM, so the moderation process became: if (!subscribed) reject; -- Cheers Jorge.-

March 14, 2005

Re: [Dillo-dev]configure cache size

by Jorge Arellano Cid

On Sun, Mar 13, 2005 at 02:56:39PM -0500, Livio Soares wrote: > Hi Günter, > > G. Milde writes: > > > > Dear developers, > > [...] > > > What could I do to turn off (or limit) the internal cache? > > No, not in "vanilla" Dillo. > > > Was the cache_size option in the debian package an unofficial patch? I > > would really like to see this patch in the mainstream, as I am short on > > RAM here... > > Yes, this is an unofficial patch. I wrote that patch in 2002-2003. Since then, > my life turned upside down a few times. Right now, I'm just focusing on > avoiding heart attacks from overworking ;-) > > Regardless, there are two relevant posts about the subject: > > The message explaining the internals of the patch: > http://sourceforge.net/mailarchive/message.php?msg_id=1642897 > > The lastest version of the patch: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-January/000073.html > > > I think it last applied cleanly to Dillo 0.7.0 (from early 2003). Of course, I > expect it to not apply cleanly at all today. However, the good part is that the > entire patch was only less than 150 lines of code; it probably would take > someone just a few days to reintegrate it. > > If anyone wants to grab this patch and update it, before you do, please make > sure with Jorge if he is interested. Although _I_ feel that this patch is > extremely important to Dillo, I have no idea why Jorge didn't integrate it in > the first place, at the time (although, I have a hunch he was too busy, and this > was not so high in his priority list...). Hi Livio! Good to see you can respond even at peak work levels! :-) You're right on both things, it _is_ very important, and I did not have the time... Unfortunately this is not rare because I have much more work than I can handle so only the top priorities get a time slice. For instance, now, the official CVS is frozen because Sebastian and I are working with exclusive dedication to the port to FLTK. As soon as we get an interesting prototype, we'll upload the source tree so everyone can play and help with it. Of course, if there's a person with high knowledge on Dillo internals and enough time to review/integrate/QA the patches, I'm more than willing to hear from him! BTW, Livio was my perfect candidate, but he has no time now... -- Cheers Jorge.-

March 14, 2005

Re: [Dillo-dev]configure cache size

by Livio Soares

Hi Günter, G. Milde writes: > > Dear developers, [...] > What could I do to turn off (or limit) the internal cache? No, not in "vanilla" Dillo. > Was the cache_size option in the debian package an unofficial patch? I > would really like to see this patch in the mainstream, as I am short on > RAM here... Yes, this is an unofficial patch. I wrote that patch in 2002-2003. Since then, my life turned upside down a few times. Right now, I'm just focusing on avoiding heart attacks from overworking ;-) Regardless, there are two relevant posts about the subject: The message explaining the internals of the patch: http://sourceforge.net/mailarchive/message.php?msg_id=1642897 The lastest version of the patch: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-January/000073.html I think it last applied cleanly to Dillo 0.7.0 (from early 2003). Of course, I expect it to not apply cleanly at all today. However, the good part is that the entire patch was only less than 150 lines of code; it probably would take someone just a few days to reintegrate it. If anyone wants to grab this patch and update it, before you do, please make sure with Jorge if he is interested. Although _I_ feel that this patch is extremely important to Dillo, I have no idea why Jorge didn't integrate it in the first place, at the time (although, I have a hunch he was too busy, and this was not so high in his priority list...). If you have any questions, please go ahead and ask. Oh, and just for the record, there used to be a "featureful" version of the patch, which had a couple of interesting facilities (viewing the cache contents, and flushing everything from the cache). They were ripped from the newest versions of the patch, but are described here: http://sourceforge.net/mailarchive/message.php?msg_id=1642897 And links to all patches are within the posts I linked here. Good luck, Livio

March 13, 2005

Re: [Dillo-dev]dillo bug : not using the whole space

by Sebastian Geerken

On Tue, Mar 08, Denis BUCHER wrote: > I found another bug or problem in dillo : It doesn't use all the space > provided ! > > For example, let's take a 320x240 screen/window (in full screen mode). > If your content takes more than 305-310 pixels wide, the scrollbars are > appearing, while they only should appear if your content is larger than > "window size less borders", like 316... > > I hope my question is clear and thank anyone would could reply/help me :-) I hope that I mean the same problem: I type "dillo -geometry 615x665 somePicture.png", where "somePicture.png" is 600x600 pixels large. "-geometry 615x665" is just the size, where the viewport should provide space for this image. Initially, the scrollbars are visible, but when I enlarge the window and restore its size again, the scrollbars are not visible anymore, interestingly. There seems to be some bug in Dw_gtk_viewport_calc_size (in dw_gtk_viewport.c), actually, the way as it is supposed to work (initially assume that the scrollbars are not visible) suggests to work it the way you expect. Sebastian

March 12, 2005

Re: [Dillo-dev]javascript ...

by Sebastian Geerken

On Wed, Mar 09, Lars Segerlund wrote: > I have a theoretical question, as follows. > > What would be needed for Dillo to support javascript ? Of course > it would need a javascript interpreter, but there are also issues > about variables and how to handle stuff like mouseover and such in > the rest of the code. The script interpreter could be a dpi; to handle variables, the dpi should provide the possibility to handle different states (something like a key, which dillo creates for each page, and which helps the dpi to distinguish different states, which have independant sets of variables etc.). Then there are events ('on...' attributes of the HTML tags). There is a document tree already in the CSS prototype (see <http://www.dillo.org/CSS.html>), which provides some signals based on document *elements* (not on dillo widgets anymore), this could be extended. Somehow, these signals need to be connected to the script engine dpi. Also, there needs to be another interface, so that the dpi can access properties of dillo (i.e. HTML DOM). For the XML subset (XML DOM), the document tree in the CSS prototype must be extended a bit. (The planned functionality is not that much less than the functionality needed for a full XML DOM implementation). The rest of HTML DOM is related to the DilloHtmlLB structure. > Is there any possibility that the dpi interface would suffice for > a task like this ? ( what I mean here is if there is a possibility > to somhow use it for this functionality, perhaps 'filtering' the > pages through it or something ? ). > > Basicly I'm curious, and I would like to have a look at if it's > doable. It should be doable, but there are some changes in dillo needed. Sebastian

March 12, 2005

Re: [Dillo-dev]XML browser

by Sebastian Geerken

Hi, first of all, some time ago I planned to extract Dw from dillo, making an own library of it. I've polished it a bit so far, it can be downloaded at <http://www.dillo.org/misc_files/dw-core-0.1.0.tar.gz>. It is nothing "official" yet, but you should be able to play around with it. Notice that this only contains the core of Dw, not the specific widgets. However, it should be possible to copy them, but they need some (trivial) changes, to remove some dependencies from the rest of dillo. Furthermore, I already wrote some widgets, which are neither part of dillo (some kind of tree, a simple text box, and a widget, which may be used to toggle the visibility of another widget), these may be a start if you need something similar. On Tue, Mar 08, dillo-dev(a)moshe.nl wrote: > For some time now i'm looking for an XML browser, witch is simply able to > show XML documents. XML capable browsers that exist today do not suit my > (and others who extencively use XML) needs. Their XML implementation is > based on top of their html implementation, witch makes it incapable of > many standard XML features and also makes them bloated. > During my search I began to cave into the dillo source, and found the > dillo widget system. Witch seems to be a good rendering system for digital > documents, not just html. > > XML parsers already exist (libxml for example), and parsing XML is a lot > easier than parsing html, because it has a much more strict syntax. An XML > browser, maybe more acuratly named an XML viewer, is just as abstract as > XML itself. It has no way to know how a partucular XML document has to be > show'ed. For this purpose XSLT exists, it is able to "translate" any XML > document into another. > Thus creating a XML viewer is limited to being able to render one > particular type of XML document, and having XSLT documents available to > translate the rest. > > Luckily something like glade exists. Glade is an GUI development kit, > using XML to describe the GUI's, and GTX+ to show them. Dillo widgets are > an extention to GTK+, meanig glade can show them. > > Leaving the "problem" to creating the XSLT stylesheets te translate > documents to glade-XML. I'm in no way familiar with glade-XML, but there is at least one problem with this approach: dillo widgets are *not* Gtk+ widgets, instead, from Gtk's point of view, there is only one large widget (GtkDwViewport), Gtk+ itself does not care about the complex dillo widget tree behind. OTOH, coding the rendering yourself should be pretty simple. > The dillo widget is currently inside the dillo source, and only linked > directly to dillo. how posible is it to seperate this, and have dillo > widget inside a .so for example? See above. > As such an XML browser is not really aimed at the same goals als the dillo > project (as far as i've read, correct me if i'm wrong), i'd apriciate the > dillo widget into a seperate library. this way dillo and this XML browser > both can use the same dillo widget system, without forcing me to include > dw vith the XML browser. (and sync them constantly) There are no plans to make dillo use a Dw library, since Dw is changing frequently, so it would be necessary to have a new version of Dw for each release of dillo. However, there is a script within the dw-core tarball, which makes syncing very simple, see README. > I'm still only planning, so i'd like any comments on this idea, as well as > tips and other ideas. maybe you also have comments on the level of > integration dillo and the XML browser can have. Perhaps there may be a (graphical) plugin, which reuses Dw for the rendering (so that your viewer may be ported). I wrote something about this some time ago (it is part of the documentation about the "rendering abstraction"). Anyway, graphical plugins are not to be expected in the near future, there are currently other priorities. Sebastian

March 12, 2005

[Dillo-dev]configure cache size

by G. Milde

Dear developers, thanks for dillo. As I sometimes use a more (or less) feature-rich webbrowser than dillo, I 'outsourced' the caching of web pages (to squid). In a previous Debian package of dillo, I could turn off the internal web cache with cache_size=00 in .dillo/dillorc. With version 0.8.3, I get the error dillorc:23: unexpected string constant "cache_size", expected symbol and every dillo process uses > 5 MiB of memory. What could I do to turn off (or limit) the internal cache? Was the cache_size option in the debian package an unofficial patch? I would really like to see this patch in the mainstream, as I am short on RAM here... PS: This is a re-post. I sent this mail once, before subscribing and it seems like it did not get through the moderation process. Sincerely Günter Milde -- G.Milde web.de

March 10, 2005

Re: [Dillo-dev]javascript ...

by Kelly Price

On Wed, 9 Mar 2005 20:30:22 +0100, Lars Segerlund <lars.segerlund(a)comsys.se> wrote: > I have a theoretical question, as follows. > > What would be needed for Dillo to support javascript ? Of course it would need a javascript interpreter, but there are also issues about variables and how to handle stuff like mouseover and such in the rest of the code. > E-Links allows the use of Mozilla's SpiderMonkey javascript interpiter in other code. It has enough to run JS code but not enough to muck around on pages -- you'll have to write code to make the DOM standard work. I doubt the dpi interface, as I read correctly, was built for dynamic web pages. -- Kelly "STrRedWolf" Price http://strredwolf.furrynet.com

March 9, 2005

[Dillo-dev]javascript ...

by Lars Segerlund

Hi, I have a theoretical question, as follows. What would be needed for Dillo to support javascript ? Of course it would need a javascript interpreter, but there are also issues about variables and how to handle stuff like mouseover and such in the rest of the code. Is there any possibility that the dpi interface would suffice for a task like this ? ( what I mean here is if there is a possibility to somhow use it for this functionality, perhaps 'filtering' the pages through it or something ? ). Basicly I'm curious, and I would like to have a look at if it's doable. / regards, Lars Segerlund.

March 9, 2005

Re: [Dillo-dev]Gmail

by Kelly Price

On Sat, 05 Mar 2005 16:56:45 -0500, Jonathan Gardner <bohemian72(a)gmail.com> wrote: > I hadn't actually tried using Gmail with Dillo before, but I just heard > that Gmail recently implemented a "plain html" version and would thus > work on any browser. That inspired me to try it with Dillo and sure > enough it works. Maybe it always did, but it certainly does now. :-) > I've had to switch on SSL/https just to get to the password prompt, and afterwards, I get stuck. Odd behavior. -- Kelly "STrRedWolf" Price http://strredwolf.furrynet.com

March 9, 2005

Re: [Dillo-dev]Dillo centering elements

by David McKee

Mr. Bucher, On Tue, 8 Mar 2005, Denis BUCHER wrote: > I don't know if I didn't find which HTML tags were supported by dillo, Dillo strives for compliance with documented HTML standards. See the web site for details (there are god links from the FAQ). > or if it is a dillo bug or limitation, but I am totally unable to make > dillo center something on the screen. You could have said (in detail) what you tried. [...some more complaints snipped...] Did you examine the bug metter output for the stuff you tried? WAs it enlightening? > Therefore my question is : How to achieve that (having dillo centering an > image). The short and snippy answer is: with standards compliant html. I have no trouble with:  <pre> <p align="center"> ... </p> </pre> and the like. A longer answer would depend on exactly what you are tring to achieve, but would still send you off to read the standards[1] or some instructions written by someone who had already done so. Then there is the lecture on the foollishness of trying too hard to control the exact appearance of your document. [Yes, CSS style sheets change the lecture to some extent, but they don't apply to dillo.] [1] Try at w3m for an online source. Good luck, -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

March 9, 2005

[Dillo-dev]XML browser

by dillo-dev＠moshe.nl

Hello, For some time now i'm looking for an XML browser, witch is simply able to show XML documents. XML capable browsers that exist today do not suit my (and others who extencively use XML) needs. Their XML implementation is based on top of their html implementation, witch makes it incapable of many standard XML features and also makes them bloated. During my search I began to cave into the dillo source, and found the dillo widget system. Witch seems to be a good rendering system for digital documents, not just html. XML parsers already exist (libxml for example), and parsing XML is a lot easier than parsing html, because it has a much more strict syntax. An XML browser, maybe more acuratly named an XML viewer, is just as abstract as XML itself. It has no way to know how a partucular XML document has to be show'ed. For this purpose XSLT exists, it is able to "translate" any XML document into another. Thus creating a XML viewer is limited to being able to render one particular type of XML document, and having XSLT documents available to translate the rest. Luckily something like glade exists. Glade is an GUI development kit, using XML to describe the GUI's, and GTX+ to show them. Dillo widgets are an extention to GTK+, meanig glade can show them. Leaving the "problem" to creating the XSLT stylesheets te translate documents to glade-XML. The dillo widget is currently inside the dillo source, and only linked directly to dillo. how posible is it to seperate this, and have dillo widget inside a .so for example? As such an XML browser is not really aimed at the same goals als the dillo project (as far as i've read, correct me if i'm wrong), i'd apriciate the dillo widget into a seperate library. this way dillo and this XML browser both can use the same dillo widget system, without forcing me to include dw vith the XML browser. (and sync them constantly) I'm still only planning, so i'd like any comments on this idea, as well as tips and other ideas. maybe you also have comments on the level of integration dillo and the XML browser can have. Greetings, Môshe van der Sterre http://www.moshe.nl/ http://www.coecu.nl/ PS: Needless to say, i'm a little short on time, so my participation in any discussion might be low. PSS: I'll problably license the browser code itself GPL (just as dw), and the XSLT stylesheelts LGPL. As they might be usefull elsewhere. Mvg, Môshe van der Sterre http://www.moshe.nl/ http://www.coecu.nl/ Mvg, Môshe van der Sterre http://www.moshe.nl/ http://www.coecu.nl/

March 8, 2005

[Dillo-dev]dillo bug : not using the whole space

by Denis BUCHER

Hello ! I found another bug or problem in dillo : It doesn't use all the space provided ! For example, let's take a 320x240 screen/window (in full screen mode). If your content takes more than 305-310 pixels wide, the scrollbars are appearing, while they only should appear if your content is larger than "window size less borders", like 316... I hope my question is clear and thank anyone would could reply/help me :-) Denis -- Denis Bucher Horus Digital Solutions Each problem has a solution ______________________________________________________________________ Tél. +41-22-8000625 Fax: +41-22-8000622 www.horus.info

March 8, 2005

[Dillo-dev]Dillo centering elements

by Denis BUCHER

Hello ! I don't know if I didn't find which HTML tags were supported by dillo, or if it is a dillo bug or limitation, but I am totally unable to make dillo center something on the screen. I want to center an image, but centering the table containing the image or centering the contents in the table cell don't work. And I don't even speak about vertical centering. I even tryed with onepixel images, streched with <img width="20"> for example. Doesn't see to work either. Therefore my question is : How to achieve that (having dillo centering an image). Thanks a lot in advance ! Denis -- Denis Bucher Horus Digital Solutions Each problem has a solution ______________________________________________________________________ Tél. +41-22-8000625 Fax: +41-22-8000622 www.horus.info

March 8, 2005

Re: [Dillo-dev]Gmail

by Patrick Shanahan

* Nicolas Kaiser <nikai(a)nikai.net> [03-08-05 08:47]: ... > One thing that doesn't work for me: signing out gives me > > error: redirect loop for http://gmail.google.com/gmail Try copying the 'sign out' url onto the address line and <enter>. I have a similar problem with a heavy with extensions version of firefox. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery

March 8, 2005

Re: [Dillo-dev]Gmail

by Jorge Arellano Cid

On Sat, Mar 05, 2005 at 04:56:45PM -0500, Jonathan Gardner wrote: > I hadn't actually tried using Gmail with Dillo before, but I just heard > that Gmail recently implemented a "plain html" version and would thus > work on any browser. That inspired me to try it with Dillo and sure > enough it works. Maybe it always did, but it certainly does now. :-) Thanks Jonathan. This is very important news. Please test it throughly to be sure it works 100%. If that's confirmed it'd be worth to add a news item in our web site. After all, what could be faster than dillo as web mail? -- Cheers Jorge.-

March 8, 2005

[Dillo-dev][liamfoy sepulcrum org: Dillo, excellent work]

by Jorge Arellano Cid

Hi there, This comments make me happy! -- Cheers Jorge.-

March 8, 2005

Re: [Dillo-dev]Gmail

by Nicolas Kaiser

* Jorge Arellano Cid <jcid(a)dillo.org>: > This is very important news. Please test it throughly to be > sure it works 100%. If that's confirmed it'd be worth to add a > news item in our web site.

March 8, 2005

Re: [Dillo-dev]Gmail

by Riccardo Mottola

Hello, Jorge Arellano Cid wrote: > This is very important news. Please test it throughly to be > sure it works 100%. If that's confirmed it'd be worth to add a > news item in our web site. > > After all, what could be faster than dillo as web mail? I just compiled and packages 0.8.4 for MkLinux so I will use it and testit. But it is the plain version of Gmail that is very well done: it works really smooth with netscape 4.79 and looks good. They must have used skilled designers. Under ns 4.79 I notice the use of Javascript though (looking at the status bar) so I wonder what it really does, it may be that the "plain" version still detects and adatps to the capabilities of the browser. Cheers, R

March 8, 2005

[Dillo-dev]Gmail

by Jonathan Gardner

I hadn't actually tried using Gmail with Dillo before, but I just heard that Gmail recently implemented a "plain html" version and would thus work on any browser. That inspired me to try it with Dillo and sure enough it works. Maybe it always did, but it certainly does now. :-) Jonathan

March 5, 2005

[Dillo-dev]dillo bug : not using the whole space

by Denis BUCHER

Hello ! I found another bug or problem in dillo : It doesn't use all the space provided ! For example, let's take a 320x240 screen/window (in full screen mode). If your content takes more than 305-310 pixels wide, the scrollbars are appearing, while they only should appear if your content is larger than "window size less borders", like 316... I hope my question is clear and thank anyone would could reply/help me :-) Denis -- Denis Bucher Horus Digital Solutions Each problem has a solution ______________________________________________________________________ Tél. +41-22-8000625 Fax: +41-22-8000622 www.horus.info

March 4, 2005

[Dillo-dev]Dillo centering elements

by Denis BUCHER

Hello ! I don't know if I didn't find which HTML tags were supported by dillo, or if it is a dillo bug or limitation, but I am totally unable to make dillo center something on the screen. I want to center an image, but centering the table containing the image or centering the contents in the table cell don't work. And I don't even speak about vertical centering. I even tryed with onepixel images, streched with <img width="20"> for example. Doesn't see to work either. Therefore my question is : How to achieve that (having dillo centering an image). Thanks a lot in advance ! Denis -- Denis Bucher Horus Digital Solutions Each problem has a solution ______________________________________________________________________ Tél. +41-22-8000625 Fax: +41-22-8000622 www.horus.info

March 4, 2005

[Dillo-dev]FOSDEM 2005

by Jorge Arellano Cid

Hi there, I'm in Europe these days! At this time FOSDEM 2005 is history, and Dillo was there (embedded track). We had a lot of work with Sebastian and presented Dillo succesfully! The conference was informative and entertaining so people liked it very much. Now I'm in Dortmund and we're working hard with Sebastian on a CVS based prototype with the new Abstraction Layer, so don't expect much emails these days. All the pending work is stalled as we're 100% on this, so patches, extensions, bug-fixes etc will have to wait. Eventually we will come with a renewed Dillo design that provides for stronger basis for the future (think of FLTK, CSS, utf8, text antialiasing, better rendering, etc). -- Cheers Jorge.-

March 3, 2005

[Dillo-dev]Patch to handle "td width" issues

by sam+dillo＠chaosring.org

It would be nice if we lived in a world without MSIE (Microsoft Internet Explorer) In particular, it would be nice if we lived in a world without MSIE's broken CSS. For example, there is a wonderful CSS attribute, called max-width, that lets a user specify the maximum width for a given element. Should the user have a narrow window (can you say 640x480), the element in question will just become narrower to fit this window. However, MSIE does not have support for this attribute. This is a feature that only 10% of the browsing population can make use of. The workaround looks like this: <table><tr> <td width=700> The content of a web site. </td></tr></table> The way all the mainstream browsers (MSIE, Opera, Konqueror/Safari, and all the Gecko browsers) handle this is as follows: * They consider the <td width=123> to be a suggestion. This is the maximum possible width for the element in question, as long as the table cell does not have any single elements (such as very long words) that are wider. * If the browser window (viewport) is wide enough to fit this element with the suggested width, the width is unchanged. * If the browser window is not wide enough to fit this element, the table cell will be made narrower to accomodate the narrow browser window. Dillo, however, does not support this /de facto/ standard. The following patch gives Dillo support for this standard. This patch doesn't do the rendering the correct way (which is to make sure all such TDs are not wider than the browser viewport window, barring long table elements), but it does make sure that a single table cell will not be wider than the Dillo browser window. This patch does not handle dynamic resizing, but will ensure that the TD hack will render (mostly) correctly in Dillo. - Sam --- dillo-0.8.4.orig/src/dw_gtk_viewport.c 2004-10-21 15:35:00.000000000 -0700 +++ dillo-0.8.4/src/dw_gtk_viewport.c 2005-03-02 19:04:07.954913184 -0800 @@ -56,6 +56,8 @@ static void Dw_gtk_viewport_adj_changed (GtkAdjustment *adj, GtkDwViewport *viewport); +int ext_window_width = -1; + /* * Standard Gtk+ function */ @@ -302,6 +304,7 @@ widget->allocation.height, viewport->depth); viewport->back_width = widget->allocation.width; + ext_window_width = viewport->back_width; viewport->back_height = widget->allocation.height; DEBUG_MSG (1, " Creating new pixmap, size = %d x %d\n", widget->allocation.width, widget->allocation.height); @@ -1165,6 +1168,7 @@ viewport_area.x = gtk_layout_get_hadjustment(layout)->value; viewport_area.y = gtk_layout_get_vadjustment(layout)->value;; viewport_area.width = widget->allocation.width; + ext_window_width = viewport_area.width; viewport_area.height = widget->allocation.height; if (p_Dw_rectangle_intersect (&viewport->draw_areas[i], --- dillo-0.8.4.orig/src/html.c 2005-01-05 13:01:00.000000000 -0800 +++ dillo-0.8.4/src/html.c 2005-03-02 19:25:16.673038712 -0800 @@ -132,6 +132,8 @@ } TagInfo; static const TagInfo Tags[]; +extern int ext_window_width; + /* * Return the line number of the tag being processed by the parser. */ @@ -1837,6 +1839,22 @@ if ((attrbuf = Html_get_attr(html, tag, tagsize, "width"))) { style_attrs.width = Html_parse_length (html, attrbuf); + /* In Netscape 4/MSIE/Gecko there is a complicated algorithm + * that makes sure all of the td widths are no wider than the + * screen; since MSIE 5/6 doesn't have the CSS max_width + * attribute, web designers still use td width=whatever to specify + * a maximum width. The following makes sure a single table cell + * is no wider than the browser window */ + if(DW_STYLE_IS_ABS_LENGTH(style_attrs.width)) { + int wide; + wide = DW_STYLE_ABS_LENGTH_VAL(style_attrs.width); + printf("------------%d %d\n",wide,ext_window_width); + if(wide > ext_window_width - 10 && + ext_window_width > 300) { + wide = ext_window_width - 10; + style_attrs.width = DW_STYLE_CREATE_ABS_LENGTH(wide); + } + } new_style = TRUE; }

March 3, 2005

[Dillo-dev]Frame support

by dominik

hi, does anyone know a patch for current cvs code to enable frame support ? p.s. i saw some older frame-pathces for dillo, what is the problem with it ? -- dominik.holler(a)gmx.net || PGP Key ID: FDEF2A0B

Feb. 27, 2005

[Dillo-dev]Patch for Sun C compiler ()

by Jérémy JUST

Hello, To compile Dillo-0.8.4 with Sun C compiler under Solaris 9, I had to apply the attached patch. It appears that Dillo code uses some GCC features that are not in the C language specifications. With my correction, it compiles and seems to work, but there are still many warnings. I haven't tested my patch with GCC or under another OS. Description of my environment: <<<<< $ /opt/SUNWspro/bin/version Machine hardware: sun4u OS version: 5.9 Processor type: sparc Hardware: SUNW,Netra-T12 The following components are installed on your system: Sun Studio 8 Sun Studio 8 C Compiler Sun Studio 8 C++ Compiler Sun Studio 8 Tools.h++ 7.1 Sun Studio 8 C++ Standard 64-bit Class Library Sun Studio 8 Garbage Collector version of "/opt/SUNWspro/bin/cc": Sun C 5.5 2003/03/12 version of "/opt/SUNWspro/bin/CC": Sun C++ 5.5 2003/03/12 >>>>> Greetings. -- Jérémy JUST <jeremy_just(a)netcourrier.com>

Feb. 25, 2005

Re: [Dillo-dev]pthread troubles on IRIX

by Riccardo Mottola

News: > > I found that I had to modify > dillo_LDFLAGS = -lpthread > > too > > but I get at the end: > -lm > ld32: WARNING 84: /usr/lib32/libpthread.so is not used for resolving any > symbol. > ld32: ERROR 33: Unresolved text symbol "pthread_cancel" -- 1st > referenced by IO/libDio.a(IO.o). > Use linker option -v to see when and which objects, archives and > dsos are loaded. > > so now I am still stuck :( I hacked around this by removing dillo_LDFLAGS and by appending -lpthread to dillo_LDADD. It appears that the linker is order sensitive and that -lpthread was added too early. Now it works! I hope I can find the time to port this browser to motif soon... how is the abstraction going on ? -R

Feb. 22, 2005

[Dillo-dev]pthread troubles on IRIX

by Riccardo Mottola

Hey, I am compiling on irix 6.5 and have this trouble: gcc -I/usr/freeware/include/gtk-1.2 -I/usr/freeware/include/glib-1.2 -I/usr/freeware/lib32/glib/include -g -O2 -D_REENTRANT -D_THREAD_SAFE -Wall -Waggregate-return -L/usr/local/lib -o dillo -pthread chain.o commands.o cache.o capi.o dw.o dw_aligned_page.o dw_bullet.o dw_button.o dw_container.o dw_embed_gtk.o dw_ext_iterator.o dw_gtk_scrolled_frame.o dw_gtk_scrolled_window.o dw_gtk_statuslabel.o dw_gtk_viewport.o dw_hruler.o dw_image.o dw_list_item.o dw_marshal.o dw_page.o dw_style.o dw_table.o dw_table_cell.o dw_tooltip.o dw_widget.o findtext.o selection.o web.o progressbar.o dillo.o bookmark.o dicache.o dns.o gtk_ext_button.o gtk_ext_menu.o gtk_ext_menu_item.o gtk_menu_title.o gif.o jpeg.o png.o html.o image.o misc.o interface.o history.o nav.o plain.o menu.o prefs.o colors.o bitvec.o klist.o strbuf.o url.o cookies.o dpiapi.o IO/libDio.a -L/usr/freeware/lib32 -lgtk -lgdk -lgmodule -lglib -lintl -lXi -lXext -lX11 -lm gcc: unrecognized option `-pthread' ld32: ERROR 33: Unresolved text symbol "pthread_cancel" -- 1st referenced by IO/libDio.a(IO.o). looking in the config.log: configure:6722: checking whether threads work with -pthread configure:6749: gcc -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib -pthread conftest.c >&5 gcc: unrecognized option `-pthread' configure:6755: $? = 0 I tried replacing -pthread with -lpthread in src/Makefile and in src/IO but it must be elsewhere. I found that I had to modify dillo_LDFLAGS = -lpthread too but I get at the end: -lm ld32: WARNING 84: /usr/lib32/libpthread.so is not used for resolving any symbol. ld32: ERROR 33: Unresolved text symbol "pthread_cancel" -- 1st referenced by IO/libDio.a(IO.o). Use linker option -v to see when and which objects, archives and dsos are loaded. so now I am still stuck :( Cheers, Riccardo

Feb. 22, 2005

[Dillo-dev]help on dillo

by �� JeN ��

good day! i would like to ask for your help. i am a computer science student and currently, doing my thesis. i, together with my group mates is implementing a system in linux that enables to add plug-ins (a plug-in can be an application or a functionality of the system) using shared objects. If we are to add, for example, an existing application in our system it has to be in the .so form. Dillo is one of the examples we considered to add in our system. It is also one way of testing if the plug-in function we are implementing really works. Regarding the dillo browser, we tried to make it as a shared object file using the command line "gcc -g -shared -Wl,-soname,dillo.so.0 \-o dillo.so dillo.o -lc" the problem is there are certain methods that cannot be recognized when we run the shared object that is produced using our system. those methods are undefined according to the system. We do not know if the paths of the libraries used by dillo have something to do with the error... or something else. we would like to ask if our way of making a shared object file is correct or applicable to dillo. if not, can u tell us how to make it as a shared object file - the proper way of making a shared object file. Also, can u let us know how to compile dillo manually, without using the make file. if you also have an advice regarding the problem/solution to the problem, we would appreciate it very much. thank you very much, sir. - jen __________________________________ Do you Yahoo!? The all-new My Yahoo! - What will yours do? http://my.yahoo.com

Feb. 22, 2005

Re: [Dillo-dev]Please help me with some data

by Andreas Schweitzer

On Mon, Feb 21, 2005 at 10:31:18PM -0300, Jorge Arellano Cid wrote: > * Comparative wall-clock times for page rendering. > > Wall clock times for rendering a sample page. Have you seen this recent comparison : http://www.howtocreate.co.uk/browserSpeed.html It was on osnews.com ( http://www.osnews.com/story.php?news_id=9694 ) and slashdot ( http://slashdot.org/article.pl?sid=05/02/11/2016227 ) But one competition for dillo - at least in in the embedded market - seems to be konq-e ( http://www.konqueror.org/embedded/ ) which seems to be missing in the compariosn. Cheers, Andreas -- Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Feb. 22, 2005

Re: [Dillo-dev]Another refresh patch

by Horst Gutmann

Horst Gutmann wrote: > Hi everyone :-) > > I also needed some meta-refresh functionality because I use meta-refresh > as an "offline"-alternative for 30x-return codes. Basically I just > wanted to ask how ugly the code is and if I'm at least on the right way :-) > > Currently it simply ignores the delay-value because I don't really need > it for this project. > > MfG, Horst > > Sorry, this time it should at least survive a `patch` :-? I just have one problem with it now: It doesn't work on local addresses. It's trying to resolve the file:// address on the DNS *g* MfG, Horst

Feb. 22, 2005

[Dillo-dev]Another refresh patch

by Horst Gutmann

Hi everyone :-) I also needed some meta-refresh functionality because I use meta-refresh as an "offline"-alternative for 30x-return codes. Basically I just wanted to ask how ugly the code is and if I'm at least on the right way :-) Currently it simply ignores the delay-value because I don't really need it for this project. MfG, Horst

Feb. 22, 2005

[Dillo-dev]Please help me with some data

by Jorge Arellano Cid

Hi guys, This weeks have taken a hectic pace for me, finishing and taking care of a lot of issues has been the workload of each day. Now almost everything is ready for FOSDEM 2005 and a very long trip. The point: ;) I'm gathering more data to tune and enrich some points of the conference. The skeleton is: Presentation contents: * What's Dillo * Project objectives * Compatibility/Portability Dillo on PDAs: iPAQ, Yopi, Psion (familiar). uclibc * Architecture overview: Parser/Rendering/IO/Plugins * Current state of the project: Supported standards Features HTML bug meter Memory usage: Comparison table with other browsers by VSZ/RSS. CPU usage: Comparative wall-clock times for page rendering. * Near future potential The port to FLTK Antialiased fonts, UTF-8, more speed, smaller footprint, rendering to abstract devices. CSS, XHTML validation, more SSL, ... I need more data on: Memory usage: Comparison table with other browsers by VSZ/RSS. CPU usage: Comparative wall-clock times for page rendering. and uclibc This is: -------- * Comparison table with other browsers by VSZ/RSS.: On the same system, how much VSZ/RSS Dillo uses in comparison with Mozilla, Firefox, Opera, Whatever on startup and on loading a sample page. * Comparative wall-clock times for page rendering. Wall clock times for rendering a sample page. * uclibc I know Dillo has run under ucLibc. I need the system spec, RSS and compared with other browsers that may also work on the environment. That's it. Please post your answers to dillo-dev so everyone can see the collected data. A lot of TIA! -- Cheers Jorge.-

Feb. 22, 2005

Re: [Dillo-dev]testing https plugin gave problems

by Matthias Franz

On Fri, Feb 18, 2005 at 09:21:45AM +0100, Peter Wood wrote: > I tried to test the https plugin by removing line 56 from dpi/https.c, The message you saw is probably not quite accurate. Try to replace the "#undef ENABLE_SSL" with "#define ENABLE_SSL". All the best, -- Matthias Franz

Feb. 21, 2005

Re: [Dillo-dev]Refresh patch for 0.8.4

by Roberto A. Foglietta

Jorge Arellano Cid wrote: > Hi Roberto, > > A meta-refresh patch is small and almost no bloat, so maybe > having it as a 'configure' option for embedded developers that > know what they're doing could be considered. FWIW, I decided not > to make it public long ago because some packagers were just > picking up patches from the net and making them available to > users that were even more unaware than the packager! :-) For this reason I decide to have -r option instead put an option in a config file because packager could deliver its own default config with that option activated by default. It could be much more difficult for the packager to force me using that option by command line, instead. ;-) Users would have option active by default could have an alias dillo = 'dillo -r', but a bona-fide package install should not change users alias. Yes, by the way, it could modify /etc/profile but it could apply a rootkit too... ;-) Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253

Feb. 21, 2005

Re: [Dillo-dev]Refresh patch for 0.8.4

by Jorge Arellano Cid

Hi Roberto, Sorry for not having had the time to answer this. I'm more than busy finishing all the details of my trip to FOSDEM 2005. I'll post a detailed answer before I depart If I have the time. Meta-refresh causes problems to regular users. It can also be easily abused (for instance auto reloading advertising), it is troublesome for people that have set connect on demand. It's a big problem for consumers with dialups or ISPs that collect cash on a per KB or MB basis. When on limited bandwith it consumes scarce resources. There's also a great incentive to abuse meta-refresh for sites that get their revenues on a per-click basis for advertising. There's a security problem too. A meta refresh is taken as it was a click from the user, so it can be taken advantage off in a way it'd be unwise to describe in a public forum. ;) AFAIK, there's no standard that specifies what meta-refresh does and how. So it must be implemented "by ear". OTOH, I can perfectly understand its uses on an embedded scenery. As a matter of fact I developed this a couple of years ago for a company needing it for an embedded app. A meta-refresh patch is small and almost no bloat, so maybe having it as a 'configure' option for embedded developers that know what they're doing could be considered. FWIW, I decided not to make it public long ago because some packagers were just picking up patches from the net and making them available to users that were even more unaware than the packager! :-) More interesting facts and concerns can be found in the W3C's original thread: http://lists.w3.org/Archives/Public/www-html/2000Feb/thread.html#232 After considering all these facts (and maybe more), a good solution may come. -- Cheers Jorge.- PS: I ended writing the detailed answer. :)

Feb. 19, 2005

Re: [Dillo-dev]Refresh patch for 0.8.4

by Scott Scriven

* Roberto A. Foglietta <roberto.foglietta(a)sad.it> wrote: > >As for meta-refresh, I suppose it could be included without > >causing much trouble, on two conditions: It should retain its > >current "warn the user instead of refreshing" behavior, if the > >refresh goes to a different page. Also, it should let the > >user specify a minimum refresh time that the page cannot > >override. This would allow it to follow W3C standards, and > >not bother users. > > Since the first patch I published the refresh meta tag has to > be activated by '-r' option or it doesn't work and show the > warning as usual. If you use the '-r' option so dillo behave > like every bloat mozilla/firefox/opera/ie etc. etc. > > The option could *not* be save in the /etc/.dillorc but has to > be put on the command line. Scott, do you thing this is > sufficent? An option have to be activated by the user so I > suppose he/she has to know what that option will be. If I want > to be bothered, may I choose it? ;-) It seems to me like something which should be in the config file instead of the command line. I also don't think it should follow refresh links to other pages; it's annoying and the W3C recommends not doing so. A single config option could work; something like "min_refresh_time=5" would enable the feature, and prevent it from reloading more than once every 5 seconds. Or, set the value to -1 to disable the feature and revert to previous behavior. As a command-line option, I'd probably never use it. I don't want dillo to refresh automatically to a different page, ever, so I wouldn't turn the feature on most of the time. But I don't usually know in advance when I'll view a page which refreshes itself, so the feature wouldn't be enabled when I want it. I'm just a regular dillo user, though, so I don't get to decide which patches are accepted. :) -- Scott

Feb. 18, 2005

Re: [Dillo-dev]Refresh patch for 0.8.4

by Roberto A. Foglietta

Scott Scriven wrote: [cut] > As for meta-refresh, I suppose it could be included without > causing much trouble, on two conditions: It should retain its > current "warn the user instead of refreshing" behavior, if the > refresh goes to a different page. Also, it should let the user > specify a minimum refresh time that the page cannot override. > This would allow it to follow W3C standards, and not bother users. Since the first patch I published the refresh meta tag has to be activated by '-r' option or it doesn't work and show the warning as usual. If you use the '-r' option so dillo behave like every bloat mozilla/firefox/opera/ie etc. etc. The option could *not* be save in the /etc/.dillorc but has to be put on the command line. Scott, do you thing this is sufficent? An option have to be activated by the user so I suppose he/she has to know what that option will be. If I want to be bothered, may I choose it? ;-) Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253

Feb. 18, 2005

Re: [Dillo-dev]Refresh patch for 0.8.4

by Scott Scriven

* Kelly Price <strredwolf(a)gmail.com> wrote: > Heya. New here. Glad someone's working on Dillo. Hope it > comes full-featured like Firefox is with less than half the > bloat! > > I'm attaching a fixed patch for 0.8.4 that allows meta-http > refreshes. This is quite common with web chats (including > Tag-Board). I've test-compiled and ran it, and so far so good. > > The next thing we'll need is the frames/iframes code now! I don't know about anyone else, but much of the reason I use dillo is because it does *not* do things like frames, meta-refresh, GIF animations, and Flash ads. It is very small, very fast, and implements useful browser functions without all the flashy cruft a lot of annoying sites use. If you want firefox, then use firefox. As for meta-refresh, I suppose it could be included without causing much trouble, on two conditions: It should retain its current "warn the user instead of refreshing" behavior, if the refresh goes to a different page. Also, it should let the user specify a minimum refresh time that the page cannot override. This would allow it to follow W3C standards, and not bother users. -- Scott

Feb. 18, 2005

[Dillo-dev]testing https plugin gave problems

by Peter Wood

Hi First, thanks to all for a great browser! The following applies to dillo-0.8.4 on linux with glibc2. I tried to test the https plugin by removing line 56 from dpi/https.c, as suggested. However, the linker complained about unresolved symbols when I recompiled. I solved that problem by changing the order of LIBSSL_LIBS in configure.in to "-lssl -lcrypto". Dillo then recompiled fine, however I still get the default message about the prototype plugin for https being disabled. Is there something else I should do. Regards, Peter

Feb. 18, 2005

[Dillo-dev]dillo-0.8.4 ported to ipaq familiar-X11

by Michael Kropfberger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone! familiar comes with dillo-0.6.6 which is even older than old, so I've cross-compiled dillo-0.8.4 with some extra patches: * when started in fullscreen, no toggle-button is visible * no cursor is visible, when the mouse is over the dillo window * the great mime-type patch for external viewers (from <http://www-fourier.ujf-grenoble.fr/~franz/dillo/>) * it reloads all urls (cache disabled for url rewriting, since it ignores the according meta tags) since dillo still is based on gtk+-1.2, this is a little bloated, especially because now there are extra X11-fonts needed... yes, I know, familiar comes with dillo-0.6.6 ported to gtk2 and uses built-in pango fonts, but this was too much work for me now :) I've also packaged a very tiny XFree86-font selection, so it really becomes usable... grab it here: http://www-itec.uni-klu.ac.at/~mike/ipaq/xfonts-tiny-0.1.tar.gz for fast installation on your familiar-0.8 ipaq, grab the font .ipk at: http://www-itec.uni-klu.ac.at/~mike/ipaq/xfonts-tiny_0.1-r0_all.ipk and the dillo .ipk at: http://www-itec.uni-klu.ac.at/~mike/ipaq/dillo_0.8.4-r0_arm.ipk for the OpenEmbedded maintainers, here are the needed bitbake .bb files: http://www-itec.uni-klu.ac.at/~mike/ipaq/my-new-dillo-oe.tgz I hope you all like it! greets, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCE4gxw6IyDgGSsNIRAsl0AJ4kIbSuaU+OUAAtZmtk5/Fbo2V97ACfTnP3 A3xWwswJSz9wiqIpaqrqc5s= =Aj25 -----END PGP SIGNATURE-----

Feb. 16, 2005

[Dillo-dev]FOSDEM 2005

by Jorge Arellano Cid

Hi there, Good news here! After a lot of careful diligencies and a lot of work, it is official now. Dillo will be presented at FOSDEM 2005 (Feb 26, 27). I'll go to Belgium and give a conference at FOSDEM's embedded track. This is very good news for the project because some contacts can be made with a view to fund the future of the project, Dillo will gain more exposure in Europe, and because I'll also meet with Sebastian in Germany and we'll work together on some pending issues and the future of Dillo. This effort has brought a pile of work on my side, and given its importance, I assigned top priority to it and that's the reason for me being silent on the list in the past weeks. I'll try to briefly answer some pending threads, but as I'm not at home now and having still much to do (prepare the conference, trip, lots of emails, schedule, expenditures, etc.), please don't expect much feedback from me these days. For those of you living in Europe, and that think it may be interesting to meet, or have a contact opportunity in your country that may thrive, please let me know. This is a very long distance trip to make to miss the opportunity of taking chances. Ah, if you have some for fun or for pleasure ideas, those will be considered too! :-) Especially near the end of this trip. -- Best wishes. Jorge.-

Feb. 11, 2005

Re: [Dillo-dev]Refresh patch for 0.8.4

by Roberto A. Foglietta

Kelson Vibber wrote: > Madis Janson wrote: > >> This is only my opinion, which may be wrong (I am only contributed few >> patches to Dillo), but I think the reason for no answer is that strict >> standards compliance is one of the goals of the Dillo project and the >> w3c html standard discourages the usage of meta tag for refresh. >> >> http://www.w3.org/TR/html401/struct/global.html#idx-meta_data-2 > > > Actually, that document only discourages using meta refresh for > *forwarding*, as there are better, more accessible ways to do it (i.e. > 302 Moved and similar responses). It says nothing negative about using > a meta http-equiv tag to *refresh* the page. > > "Note. Some user agents support the use of META to refresh the current > page after a specified number of seconds, with the option of replacing > it by a different URI. Authors should not use this technique to forward > users to different pages, as this makes the page inaccessible to some > users. Instead, automatic page forwarding should be done using > server-side redirects." > I hope this could make change your minds about including my patch in dillo project. I remember you that patch doesn't modify standard dillo behaviure but simple add -r flags which allow refresh tag to act. :-) If I have to modify something in the patch to make it accepted feel free to suggest me. Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253 diff -pru dillo-0.8.4/src/browser.h dillo-0.8.4-refresh/src/browser.h --- dillo-0.8.4/src/browser.h 2004-10-20 21:09:51.000000000 +0200 +++ dillo-0.8.4-refresh/src/browser.h 2005-01-17 14:39:34.000000000 +0100 @@ -139,6 +139,12 @@ struct _BrowserWindow /* The id for the idle function that sets button sensitivity. */ guint sens_idle_id; + + /* RAF, 2004-10-26: usefull to refresh tag */ + guint timeout; + guint delay; + guint idle_id; + DilloUrl *refresh_url; }; diff -pru dillo-0.8.4/src/cache.c dillo-0.8.4-refresh/src/cache.c --- dillo-0.8.4/src/cache.c 2004-12-24 16:22:53.000000000 +0100 +++ dillo-0.8.4-refresh/src/cache.c 2005-01-17 14:51:58.000000000 +0100 @@ -906,6 +906,12 @@ static void Cache_process_queue(CacheDat DEBUG_MSG(1, "QueueSize ====> %d\n", g_slist_length(ClientQueue)); } +/* RAF, 2004-10-28 */ +gint a_Cache_queue_size(void) +{ + return g_slist_length(ClientQueue); +} + /* * Callback function for Cache_delayed_process_queue. */ diff -pru dillo-0.8.4/src/cache.h dillo-0.8.4-refresh/src/cache.h --- dillo-0.8.4/src/cache.h 2004-12-23 19:55:07.000000000 +0100 +++ dillo-0.8.4-refresh/src/cache.h 2005-01-17 14:52:16.000000000 +0100 @@ -50,6 +50,7 @@ struct _CacheClient { /* * Function prototypes */ +gint a_Cache_queue_size(void); //RAF, 2004-10-28 void a_Cache_init(void); gint a_Cache_open_url(void *Web, CA_Callback_t Call, void *CbData); gint a_Cache_get_buf(const DilloUrl *Url, gchar **PBuf, gint *BufSize); diff -pru dillo-0.8.4/src/dillo.c dillo-0.8.4-refresh/src/dillo.c --- dillo-0.8.4/src/dillo.c 2005-01-06 13:14:39.000000000 +0100 +++ dillo-0.8.4-refresh/src/dillo.c 2005-01-17 13:55:23.000000000 +0100 @@ -70,6 +70,7 @@ enum { DILLO_CLI_LOCAL = 1 << 5, DILLO_CLI_GEOMETRY = 1 << 6, DILLO_CLI_DBG_RENDERING = 1 << 7, + DILLO_CLI_REFRESH = 1 << 8, //RAF-2004-10-27 DILLO_CLI_ERROR = 1 << 15 }; @@ -82,6 +83,9 @@ enum { */ gboolean dillo_dbg_rendering = FALSE; +/* RAF, 2004-10-27: adding command line option to allow refresh */ +gboolean dillo_refresh = FALSE; + /* * Forward declarations */ @@ -114,6 +118,9 @@ static CLI_options Options[] = { 0, DILLO_CLI_DBG_RENDERING, " -D, --debug-rendering Draw additionaly several lines in a web page,\n" " representing its structure. For debugging. "}, + /* RAF 2004-10-27: command line option add */ + {"-r", "-refresh", 0, DILLO_CLI_REFRESH, + " -r, -refresh Allow meta refresh working as webmaster decided."}, {NULL, NULL, 0, 0, NULL} }; @@ -249,6 +256,10 @@ gint main(int argc, char *argv[]) case DILLO_CLI_DBG_RENDERING: dillo_dbg_rendering = TRUE; break; + /* RAF, 2004-10-27: adding command line option for meta refresh */ + case DILLO_CLI_REFRESH: + dillo_refresh = TRUE; + break; case DILLO_CLI_GEOMETRY: if (a_Misc_parse_geometry(opt_argv[0], &xpos, &ypos, &width, &height)) break; diff -pru dillo-0.8.4/src/dillo.h dillo-0.8.4-refresh/src/dillo.h --- dillo-0.8.4/src/dillo.h 2004-05-22 00:13:07.000000000 +0200 +++ dillo-0.8.4-refresh/src/dillo.h 2005-01-17 13:53:23.000000000 +0100 @@ -6,4 +6,7 @@ extern gboolean dillo_dbg_rendering; +/* RAF, 2004-10-27: adding command line option to allow refresh */ +extern gboolean dillo_refresh; + #endif /* __DILLO_H__ */ diff -pru dillo-0.8.4/src/html.c dillo-0.8.4-refresh/src/html.c --- dillo-0.8.4/src/html.c 2005-01-05 22:01:00.000000000 +0100 +++ dillo-0.8.4-refresh/src/html.c 2005-01-17 14:52:58.000000000 +0100 @@ -3150,6 +3150,56 @@ static void Html_tag_close_form(DilloHtm * is a hackish way to put the message. A much cleaner approach is to * build a custom widget for it. */ + + /* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * + * WORKING ON SUPPORTING DEPRECATED META REFRESH + * Roberto A. Foglietta <roberto.foglietta(a)sad.it> + * + * Actually I'm working for a local public transport company in which + * I have to to develop a new way to display time table and information + * to people. Using Dillo into embedded linux system allow my collegues + * to change graphical display just editing php code in the server BUT + * this kind of information have to stay up-to-date. Commit a refresh + * from server is, in this case, the best solution I can immagine. + * So supporting meta refresh tag makes Dillo good for embedded client + * systems. This is the main reason because I developed this web-deprecated + * but very-useful-in-embedded function. In addition to this pratical + * consideration I think people use free software to be free, so it makes + * sense give them the freedoom to choose also deprecated functions. + * Obviously to respect Dillo's team decision to do not allow refresh + * as default policy I make it optional by setting a flag from command + * line + */ + +void refresh_true_callback(gpointer client_data) { + BrowserWindow *bw = client_data; + + if(bw->timeout) { + gtk_timeout_remove(bw->timeout); + bw->timeout = 0; + } + + a_Commands_open_link_callback(NULL, client_data); +} + +void refresh_callback(gpointer client_data) { + BrowserWindow *bw = client_data; + + if(a_Cache_queue_size()) { + return; + } + + MSG("a_Cache_queue_size: %d\n", a_Cache_queue_size()); + + if(bw->idle_id) { + gtk_idle_remove(bw->idle_id); + bw->idle_id = 0; + } + + bw->timeout = gtk_timeout_add((guint32)bw->delay*1000, + (GtkFunction)refresh_true_callback, (gpointer)(bw)); +} + static void Html_tag_open_meta(DilloHtml *html, char *tag, gint tagsize) { const gchar *meta_template = @@ -3161,7 +3211,7 @@ static void Html_tag_open_meta(DilloHtml " <a href='%s'>here</a>%s</td></tr></table><br>\n"; const gchar *equiv, *content; - gchar *html_msg, delay_str[64]; + gchar *ptr, *html_msg, delay_str[64]; gint delay; /* only valid inside HEAD */ @@ -3173,7 +3223,34 @@ static void Html_tag_open_meta(DilloHtml if ((equiv = Html_get_attr(html, tag, tagsize, "http-equiv")) && !g_strcasecmp(equiv, "refresh") && (content = Html_get_attr(html, tag, tagsize, "content"))) { + } else { + return; + } + + /* check for delay */ + delay = strtol(content, &ptr, 0); + if(ptr) ptr = (gchar *)content; + + if(*ptr) { + /* todo: fix this to parse "URL =" & friends (HTML spec) */ + /* RAF, 2004-10-25: DONE, I suppose... */ + if (strstr(ptr, "URL") || strstr(ptr, "url") || strstr(ptr, "Url")) { + ptr = strstr(ptr, "="); + while (*(++ptr) == ' ' && *ptr != '>'); /* skip URL= & friends */ + if(*ptr == '>') *ptr = 0; /* doesn't exist any URL= */ + } else { + *ptr = 0; /* doesn't exist any URL= */ + } + } + + if(!*ptr && !delay) { + return; + } else { + g_print("meta refresh: start with refresh %sallowed\n", (dillo_refresh) ? "" : "not "); + g_print("meta refresh: delay -> %d, url -> %s\n", delay, (*ptr) ? ptr : "none"); + } + if(!dillo_refresh) { /* Get delay, if present, and make a message with it */ if ((delay = strtol(content, NULL, 0))) g_snprintf(delay_str, 64, " after %d second%s.", @@ -3196,6 +3273,33 @@ static void Html_tag_open_meta(DilloHtml html->InFlags = SaveFlags; } g_free(html_msg); + } else { + //if(html->bw->refresh_url) + a_Url_free(html->bw->refresh_url); + + if(*ptr) { + html->bw->refresh_url = a_Url_new(ptr, NULL, 0, 0, 0); + a_Url_set_flags(html->bw->refresh_url, URL_FLAGS(html->bw->refresh_url) | URL_E2EReload); + a_Menu_popup_set_url(html->bw, html->bw->refresh_url); + } else { + html->bw->refresh_url = a_History_get_url(NAV_TOP(html->bw)); + a_Url_set_flags(html->bw->refresh_url, URL_FLAGS(html->bw->refresh_url) | URL_E2EReload); + a_Url_set_flags(html->bw->refresh_url, URL_FLAGS(html->bw->refresh_url) & ~URL_SpamSafe); + a_Menu_popup_set_url(html->bw, html->bw->refresh_url); + html->bw->refresh_url = NULL; + } + + /* RAF, 2004-10-25: Use a timeout to refresh the page automatically */ + if(delay) { + //html->bw->timeout = gtk_timeout_add((guint32)delay*1000, + // (GtkFunction)refresh_callback, (gpointer)(html->bw)); + html->bw->delay = delay; + html->bw->idle_id = gtk_idle_add((GtkFunction)refresh_callback, (gpointer)(html->bw)); + } else { + html->bw->timeout = 0; + html->bw->delay = 0; + refresh_callback(html->bw); + } } } diff -pru dillo-0.8.4/src/interface.c dillo-0.8.4-refresh/src/interface.c --- dillo-0.8.4/src/interface.c 2004-12-29 14:26:48.000000000 +0100 +++ dillo-0.8.4-refresh/src/interface.c 2005-01-17 14:46:41.000000000 +0100 @@ -1127,6 +1127,12 @@ a_Interface_browser_window_new(gint widt bw->viewsource_window = NULL; bw->pagebugs_window = NULL; + /* RAF, 2004-10-26: null value for time out */ + bw->timeout = 0; + bw->delay = 0; + bw->idle_id = 0; + bw->refresh_url = NULL; + /* now that the bw is made, let's customize it.. */ Interface_browser_window_customize(bw); diff -pru dillo-0.8.4/src/nav.c dillo-0.8.4-refresh/src/nav.c --- dillo-0.8.4/src/nav.c 2004-12-16 20:02:21.000000000 +0100 +++ dillo-0.8.4-refresh/src/nav.c 2005-01-17 14:43:20.000000000 +0100 @@ -55,6 +55,9 @@ void a_Nav_free(BrowserWindow *bw) { a_Nav_cancel_expect(bw); g_free(bw->nav_stack); + + /* RAF, 2004-10-27: free the url redirection */ + a_Url_free(bw->refresh_url); } @@ -156,6 +159,11 @@ static void Nav_open_url(BrowserWindow * gboolean ForceReload = (URL_FLAGS(url) & URL_E2EReload); MSG("Nav_open_url: Url=>%s<\n", URL_STR_(url)); + /* RAF, 2004-10-28: switch off reload timeout */ + if(bw->timeout) { + gtk_timeout_remove(bw->timeout); + bw->timeout = 0; + } /* Get the url of the current page */ if ( a_Nav_stack_ptr(bw) != -1 )

Feb. 10, 2005

Re: [Dillo-dev]support for video streams

by Daniel Lord

Hi, On Thu, 10 Feb 2005, Michael Kropfberger wrote: > On Wednesday 09 February 2005 19:48, Bjoern Brill wrote: > > http for which you can provide a working mailcap entry. I hope that this > > patch will be merged in the not-too-distant future. > > this patch is perfect! I also hope, it will make it's way into the CVS! just want to say that this patch suids my needs too ;) Greetings Daniel -- We've all heard that a million monkeys banging on a million typewriters will eventually reproduce the entire works of Shakespeare. Now, thanks to the Internet, we know this is not true.

Feb. 10, 2005

Re: [Dillo-dev]Memory leak bug (was dillo-0.8.3)

by Roberto A. Foglietta

Jorge Arellano Cid wrote: > Hi there, > > Do you remember this 4KB memory leak mail-thread? > sorry I read this mail just by now. > At least after the pthread bug interim patch (CVS) it doesn't > leak anymore in my system. And there's this gentle side effect of > Dillo using less than 1/5 memory than before! thank you. :-) Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253

Feb. 10, 2005

Re: [Dillo-dev]support for video streams

by Michael Kropfberger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 09 February 2005 19:48, Bjoern Brill wrote: > http for which you can provide a working mailcap entry. I hope that this > patch will be merged in the not-too-distant future. this patch is perfect! I also hope, it will make it's way into the CVS! for dillo, there should also be a simpler way to add mime-types at least detected by file extensions... right now I eg. hacked the dpi/file.c to understand video.mp4 as mimetype video/mp4 in File_ext(const char *filename) greets, Mike - -- < When in doubt, THINK! > <----------------------------------------------------------------------> < DI Dr. Michael Kropfberger A-9073 Viktring, Kindergartenstr. 14/6 > < +43(650)6996000 michael _A T_ kropfberger.com http://www.kropfberger.com > <----------------------------------------------------------------------> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCC0SHw6IyDgGSsNIRAhkNAKCux1biazvVk/jwGnj2/oq52bIp0ACeMMTc NN6xvYyYhrbo9XLT1j6yLYs= =9RGu -----END PGP SIGNATURE-----

Feb. 10, 2005