- Dillo-dev - lists.mailman3.com

[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