- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev]Task list & priorities

by Jorge Arellano Cid

Hi Brian, Please keep this thread on dillo-dev. On Tue, Nov 09, 2004 at 08:12:50AM -0500, Brian Hechinger wrote: > On Mon, Nov 08, 2004 at 06:15:59PM -0300, Jorge Arellano Cid wrote: > > > > Great! > > Now we have a man in charge of it. > > i would be honored. > > > str = a_Prefs_get("font_factor"); > > if (str) > > ff = strtol(str); > > g_free(str); > > i've read all your email, and it looks like mostly enough to get me started, > but i just had this thought: > > if the dpi reads all the rc files in, we're going to have to be able to > specify which rc file we want to get our config from. we need to > implement a system of scope for the rc files. i don't want the cookie > module asking if it has permission to authorize a site to use cookies > by getting it's config from the cacherc which has an identical format. > > what do you think is the best way to go about doing that? make the rc > filename a requirement in the call? > > str = a_Prefs_get("font_factor", "dillorc"); This is a good idea to start with. > > and then in the dpi just have the rc files as a linked list with an entry for > the filename to do a strcmp() on? Maybe, but remember that cookiesrc has another format. It's not a variable/value pairs list, but a list of instances of the same abstract variable (to name it somehow ;). This also needs some thought. > > also, i still need to read about dpis of course, but are they long running > processes? Dpi servers, YES. Dpi filters come and go per request. > the way i'm thinking is that we don't want the rc files read > every time a preference is needed, so the first instance of dillo will start > the config dpi running, and it will continue to run until there are no more > instances of dillo running. does this sound reasonable? Yes. In fact, that's what the bookmarks dpi server does. You don't even have to worry about launching a dpi, that's the dpid job. It's done automatically. -- Cheers Jorge.-

Nov. 9, 2004

Re: [Dillo-dev]Toolkit & dillo

by Riccardo Mottola

Hello, Lars Segerlund wrote: > > There has been a lot of talk about toolkits and dillo, and I had a small idea. What about using lesstif ( Motif ) for dillo ? It's fairly small ( you can bring only the widgets you need ) and if done with some care a statically linked dillo would not be bloated. You immediately would have a supporter! a tester and partially a coder too. > I can have a look at it, but I would like the general opinion first, ( I would even give Xt a shot :-) that way it would be FAST & SMALL ). Well, Xt is pretty extreme, maybe Xaw in case then. Anyway rememebr that most graphic part in Xm is just passed over to Xt calls. I have already proposed and welcomed a motif port. Lately I am coding a bit on my IRC application written in it and am always surprised by the speed and the cleaniness of the result GTK doesn't even get close. But Motif is tricky, do something wrong and you end with a segfault. It is quite low-level sometimes and tied to X11 quite a bit. Even if I learned quite a deal of Motif, doing a port of dillo myself would be out of reach. But I could probably help. Also I have various OSs with different Motif implementations, from 1.1 to 2.1. It's great for testing. My desperation for motif was so great that I went up to digging out mMosaic! and the last beta of it is interesting. It is so fast in the interface (menus, scrolling etc) although the parser is often inferior to dillo. I never coded a single line of Athena though. VIM supports athena, motif, gtk and lately QT even. It would be nice to be able to accomplish this in dillo too! -R

Nov. 9, 2004

[Dillo-dev]Toolkit & dillo

by Lars Segerlund

There has been a lot of talk about toolkits and dillo, and I had a small idea. What about using lesstif ( Motif ) for dillo ? It's fairly small ( you can bring only the widgets you need ) and if done with some care a statically linked dillo would not be bloated. I can have a look at it, but I would like the general opinion first, ( I would even give Xt a shot :-) that way it would be FAST & SMALL ). regards, Lars Segerlund.

Nov. 9, 2004

Re: [Dillo-dev]Task list & priorities

by Jorge Arellano Cid

Hi Brian, On Sat, Nov 06, 2004 at 11:44:48PM -0500, Brian Hechinger wrote: > 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. ;) Great! Now we have a man in charge of it. > > 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. There's at least one big advantage of having the preferences done in a dpi server instead of Dillo (but some more come to mind :). If you have two instances of Dillo which one is in charge of preferences? If you have a dpi running, and the user exits from Dillo what happens with preferences. If there're two Dillos running we'd need to provide for Dillo to Dillo communcation. How do we handoff preferences from an old Dillo that exits to a newer instance? etc. On the plus side, a Dpi server solves those problems. The issue with this approach is how to communicate with Dillo, but we already have the dpi protocol (dpip). Which is flexible and extensible and can make this communication happen (for instance as the "chat" command in bookmarks). The rc files could all reside in ~/.dillo/ and there would be no race conditions on them (as now with cookies). For instance a simple approach (and simplicity is an asset) is something like: str = a_Prefs_get("font_factor"); if (str) ff = strtol(str); g_free(str); a_Prefs_get() could do it task by sending a dpi command: <dpi cmd='get_preference' name='font_factor'> the answer can arrive packed like this: <dpi cmd='answer' to_cmd='get_preference' name='font_factor' value='1.25'> and recovering "value" with a_Misc_get_attr_value() is trivial! > 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. Sure. > > 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. Read doc/Dpid.txt. It's a good introduction. You can also have a look at Cfg.txt inside: http://www.dillo.org/misc_files/cfg-test-0.0.3.tar.gz but this is more advanced than what we need now. Anyway it may show some light of things we may require in the future. Sebastian can provide more feedback on that part although I'd regard that as part 2. > > > > [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. I'd advice to try to use the 'chat' command for this task, and asking me when in trouble. Getting inside the CCC at this stage is not a good idea. > > > > [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. This is very simple, but needs some time. For instance, adding login information messages to the FTP dpi is a matter of calling dup2 on stderr, and dup2 into a pipe for stdout, that way the former stderr can be parsed, the pertinent 'send_status_message' commands sent into the pipe, followed by the actual data. The same applies for downloads, and there's a prototype. -- Cheers Jorge.-

Nov. 8, 2004

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