- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev]Task list & priorities

by Brian Hechinger

On Sat, Nov 06, 2004 at 07:11:12PM -0300, Jorge Arellano Cid wrote: > Hi there, Hello!! > > [3] Preferences dpi. > > [3] Handling of configuration data. > > <Sebastian> > I'd regard this as one task (from the user's point of view). Here, I'd > rather focus on designing a solid base rather soon, on which future > extensions may be build on. It is not clear yet, how this will look > like at all, but supposed (as an example), that dillo manages the > configuration data (not a dpi), communication with configuration dpis > should be considered, but made possible later. > > (Except the feature, on which Daniel Fairhead is working.) > > <Jorge> > Configuration data also needs some sync. For instance, dillorc, > cookiesrc, cacherc, <dpis>rc. Maybe having a common format and a > powerful preferences dpi makes sense at this stage. ok, i will take ahold if this one if no-one objects. i would love to see this done, as it makes doing lots of other things much, much simpler in the future, especially the cache thing. since the cache thing is now going to be pretty much on hold until after the CCC study, i need something to do in the mean-time. ;) i don't think it should be too relevant as to if configuration is handled by a dpi or by dillo proper, since it's just a matter of what part things ask to get their configuration data from, as they should never have to look at a config file themselves. it should be fairly trivial to rewrite how things ask for their config. keep in mind i have yet to look at the dpi system at all, so i could be completely wrong with that assumption. i'm assuming that being able to offer a configuration API would allow a layer of abstraction that would hide the internals of how things are actually done as pertaining to aquiring configuration data. i've got a higher priority project currently on my plate, but the way things are looking, it shouldn't be but a couple more days until i'm done with it, at which time i will study the dillo code at great length and evaluate which would be the easier way (for me at least) to handle this. > > [3] Make cookies into a dpi server. > > <Jorge> > Procrastinated from a long time ago. This solves the problem of > only the first Dillo instance (and its child windows) having > cookies enabled. Now that cookies work better (with 302 > redirections) this problem will be more evident. i think it may be to my advantage to tackle this task first, as it will give me a much greater understanding of the dpi structure. that should certainly make a configuration dpi a very simple task to get completed. > > [5] GUI dpi for downloads. > > <Sebastian> i agree 100% with you on this, however....... > <Jorge> i think of such annoying sites as sourceforge that do all sorts of wonky things with the url you send it that wget just doesn't properly grok. while i certainly prefer to copy the url and give it to wget myself, sometimes that just isn't practical. -brian -- IHTFP: I firmly believe that people dumber than me exist solely for my amusement. IHTFP: Okay, maybe not solely for my amusement. Some of them make good cake.

Nov. 7, 2004

[Dillo-dev]Task list & priorities

by Jorge Arellano Cid

Hi there, Here I'm attaching the draft for the priorities list we're working on with Sebastian. Note that [1] Parsing of XML empty tags (e.g <script/> as <script></script>). is already done! and I'm working on the parser to avoid memory leaks with bad HTML, to be able to get the doc tree from parsing (XML well formedness validation and hopefully good for CSS too). Let's name this one as: [1] Orthogonalize the parser (leaks, XML, CSS) And here are a few to add to the list too: [ ] Login messages for the ftp dpi. [ ] Bookmarks dpi "sort" function. [ ] Back/Forward for #anchored links. -- Cheers Jorge.- PS: Please conside all of these works when I'm sending delayed answers :-P

Nov. 6, 2004

Re: [Dillo-dev]Parsing of XML empty tags

by Jorge Arellano Cid

On Fri, Nov 05, 2004 at 05:57:16PM +0100, Matthias Franz wrote: > On Fri, Nov 05, 2004 at 10:11:21AM -0300, Jorge Arellano Cid wrote: > > Now the parser recognizes: </x>, <x /> and <x/>. (committed) > > Maybe one should do this only in w3c_plus_heuristics mode (or in > a future XML mode), for two reasons: > > Firstly, the slash "/" has a special meaning in SGML, hence in HTML, > as a so-called NET-enabling start tag. Essentially, this means that > > <x/content/ > > is equivalent to > > <x>content</x> > > (This is one of the weird features of HTML that almost no browser > supports, see http://www.cs.tut.fi/~jkorpela/html/empty.html .) > Therefore, parsing <x/> or <x /> as <x></x> makes Dillo manifestly > non-HTML-conforming. Don't worry, Dillo will never be SGML compliant! ;) Being HTML compliant (and therefore SGML compliant) involves having an SGML parser, which is too big and complex for Dillo to have. > Secondly, if I understand the HTML compatibility guidelines of Appendix C > of the XHTML 1.0 spec correctly, they suggest to use <x /> only for elements > which have no close tag in HTML, like <hr> or <br> for instance. For others, > one should use an explicit end tag. This means that one can ignore an "/" > at the end of a tag for all XHTML documents which follow these guidelines. > (But note that according to the first point these guidelines are not > compatible with SGML.) Yes, this is a known issue. Even more, "<br/>" is valid XML, notwithstanding the compatibility recommendation of writing it as "<br />". And there's the HTML "<a href=http://foo.org/>" type of tag (for instance with google). --note the final "/>". So, as usual, I tried to code a solution that accounts for most of the cases with a view to better usability. BTW, now I'm very advanced in studying a way to modify the parser to be able to generate the document tree from the tags. Basically by being more orthogonal at pushing ans popping tags. This will also serve to cut memory leaks with bad HTML. -- Cheers Jorge.-

Nov. 6, 2004

Re: [Dillo-dev]Parsing of XML empty tags

by Matthias Franz

On Fri, Nov 05, 2004 at 10:11:21AM -0300, Jorge Arellano Cid wrote: > Now the parser recognizes: </x>, <x /> and <x/>. (committed) Maybe one should do this only in w3c_plus_heuristics mode (or in a future XML mode), for two reasons: Firstly, the slash "/" has a special meaning in SGML, hence in HTML, as a so-called NET-enabling start tag. Essentially, this means that <x/content/ is equivalent to <x>content</x> (This is one of the weird features of HTML that almost no browser supports, see http://www.cs.tut.fi/~jkorpela/html/empty.html .) Therefore, parsing <x/> or <x /> as <x></x> makes Dillo manifestly non-HTML-conforming. Secondly, if I understand the HTML compatibility guidelines of Appendix C of the XHTML 1.0 spec correctly, they suggest to use <x /> only for elements which have no close tag in HTML, like <hr> or <br> for instance. For others, one should use an explicit end tag. This means that one can ignore an "/" at the end of a tag for all XHTML documents which follow these guidelines. (But note that according to the first point these guidelines are not compatible with SGML.) All the best, -- Matthias Franz Section de Mathématiques, Université de Genève, Suisse

Nov. 5, 2004

Re: [Dillo-dev]Parsing of XML empty tags (e.g <script/> as <script></script>).

by Brian Hechinger

On Thu, Nov 04, 2004 at 07:28:16PM -0300, Jorge Arellano Cid wrote: > Topic change (cache control): > > Brian: Take a look at BUG#161, Madis worked on the same problem > long ago. Some ideas may be saved... I'm not saying the patch is > wrong, I just happened to notice this entry while skimming. ok, i've got a copy. i'm going to put this on hold until a decision is made for configuration stuffs however, since i would like to get that written first before i continue with cache control. -brian -- IHTFP: I firmly believe that people dumber than me exist solely for my amusement. IHTFP: Okay, maybe not solely for my amusement. Some of them make good cake.

Nov. 5, 2004

Re: [Dillo-dev]Parsing of XML empty tags (e.g <script/> as <script></script>).

by Jorge Arellano Cid

On Thu, Nov 04, 2004 at 07:28:16PM -0300, Jorge Arellano Cid wrote: > Hi there, > > Well, the priorities list draft had this one with top priority > (among others): > > <q> > [1] Parsing of XML empty tags (e.g <script/> as <script></script>). > </q> > > [...] > Unto the bug, it's BUG#514 and seems also #587. It needs some > testing. As a matter of fact I had to fix the patch because google's answer links were not being rendered. Now the parser recognizes: </x>, <x /> and <x/>. (committed) -- Cheers Jorge.-

Nov. 5, 2004

[Dillo-dev]dpi menu and inteface hadling question

by Diego Sáenz

I have made some proof of concept about dpi menu handling with a patch that add a dpi command that add a toolbar item/button and some test commands. ¿must i continue with menus or must i wait for fltk port and universal ccc implementation? The attached files are the b2ziped patch and a b2ziped and tared directory tree with some test files. Look at the second attachment for the dpi command. To test use the patch (works from cvs 2004-09-18 to current cvs), uncompres the directory in a /home/SOME_USER/.dillo/dpi/ directory, run the patched dillo and put dpi:/dpitest/ in the location bar. Then you can use the buttons that apear in the toolbar. Please if you have any suggestion reply and say it. I am open to change even command name :) If dillo suported onevent and css or javascript all the dillo interface could be a html page with an iframe(or something like that) that contain the site viewed. An external dpi or program could modify the interface page to add buttons or menu items when dpis ask for it and say to dillo to refresh interface page. I think this is the way that less code add to dillo but it is imposible for now and waste a few mem. DarkSpirit/Diego Saenz PD: sorry for my english

Nov. 4, 2004

[Dillo-dev]Parsing of XML empty tags (e.g <script/> as <script></script>).

by Jorge Arellano Cid

Hi there, Well, the priorities list draft had this one with top priority (among others): <q> [1] Parsing of XML empty tags (e.g <script/> as <script></script>). </q> I'll post the priorities draft tomorrow for you to read, probably before Sebastian has a chance to review it... Unto the bug, it's BUG#514 and seems also #587. It needs some testing. Thorben: Do you have a test page for #587? --- Topic change (cache control): Brian: Take a look at BUG#161, Madis worked on the same problem long ago. Some ideas may be saved... I'm not saying the patch is wrong, I just happened to notice this entry while skimming. -- Cheers Jorge.-

Nov. 4, 2004

Re: [Dillo-dev]Memory leak bug

by Jorge Arellano Cid

On Wed, Nov 03, 2004 at 09:32:15AM +0100, Roberto A. Foglietta wrote: > Roberto A. Foglietta wrote: > >Hi, > > > > I didn't find memory leak bug but I have to say this: waiting html page > >load complete doesn't help. > > > > I have done a patch which after first load doesn't show images BUT I > >lost it because I didn't care it... But when I saw my logs I see that > >patch fixed memory leak. Even if memory leak has nothing to do with > >images because trivial pages has no images. Probably 4kb is a structure > >not data. > > > > Thinking memory leak is generated by losing a structure instead data > >could explain why has fixed size (4kb for each reload) and probably why > >it happen only during a reload. In reload some data is cached but > >structures a created and destroyed... probably not all of them. > > > > Unfortunately it's time I have to find another browser to use it in my > >project. Sorry. > > Suggest: > > http://valgrind.kde.org/overview.html Yes, I haven't used it in a long time. Good to remember. After upgrading to valgrind-2.2.0, and testing, it detected two minor leaks in Dillo (fixed now in CVS), but these were not the cause for the "reload" leak. After that, I got no more leak errors detected inside Dillo (while testing a trivial page with 12 reloads) with: valgrind --tool=addrcheck --leak-check=yes ./dillo /tmp Interesting to note is this one in GTK+: ==9413== ==9413== ==9413== 2816 bytes in 36 blocks are definitely lost in loss record 47 of 54 ==9413== at 0x34148F1D: calloc (in /usr/lib/valgrind/vgpreload_addrcheck.so) ==9413== by 0x34343F2A: g_malloc0 (in /usr/lib/libglib-1.2.so.0.0.10) ==9413== by 0x342C12AA: gtk_type_new (in /usr/lib/libgtk-1.2.so.0.9.1) ==9413== by 0x34284C27: gtk_pixmap_new (in /usr/lib/libgtk-1.2.so.0.9.1) ==9413== -- Cheers Jorge.-

Nov. 3, 2004

Re: [Dillo-dev]Memory leak bug

by Roberto A. Foglietta

Roberto A. Foglietta wrote: > Hi, > > I didn't find memory leak bug but I have to say this: waiting html page > load complete doesn't help. > > I have done a patch which after first load doesn't show images BUT I > lost it because I didn't care it... But when I saw my logs I see that > patch fixed memory leak. Even if memory leak has nothing to do with > images because trivial pages has no images. Probably 4kb is a structure > not data. > > Thinking memory leak is generated by losing a structure instead data > could explain why has fixed size (4kb for each reload) and probably why > it happen only during a reload. In reload some data is cached but > structures a created and destroyed... probably not all of them. > > Unfortunately it's time I have to find another browser to use it in my > project. Sorry. Suggest: http://valgrind.kde.org/overview.html 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

Nov. 3, 2004