August 2003 - Dillo-dev - lists.mailman3.com

Rendering problem
by Andrew A. Gill Aug. 28, 2003

Aug. 28, 2003

I've been having a problem with dillo rendering some portions of text. For instance, the Google sponsored links always take up vertical space before the results. Normally, this isn't something that I really care about, but now it's causing slashdot to be rendered as black-on-black text, thus depriving me of my ability to read about the new MD5 sums that the RIAA is using. (bug 493) -- |Andrew A. Gill |I posted to Silent-Tristero and| |<superluser(a)frontiernet.net> |all I got was this stupid sig! | |alt.tv.simpsons CBG-FAQ author | | | (Report all obscene mail to Le Maitre Pots)| |Nothing here yet: <http://www.needsfoodbadly.com> Temporary sig: -- But thanks for everything else.

3 2

Re: Re: dillo / time-controlled reloads
by Jorge Arellano Cid Aug. 28, 2003

Aug. 28, 2003

On Wed, 20 Aug 2003, Melvin Hadasht wrote: > > Hi Jorge & Melvin, > > Hi Henning & Jorge, > > (Is there a reason why this is not on the ML?) The only reason is that I pressed "reply" on a mail sent to my personal address. :-) > > > > > there's one bit missing. there is NO concept at all about time-based > > > > reloads. the meta refresh header would be reasonably close, but even > > > > better would be something like > > > > > > > > dillo -reload-every 60 http://blah/cgi-bin/blubb.cgi > > > > > > > > it should reload that URL every 60 seconds in that case no matter what. > > > > > > I think reloading it if upon display is also a good choice. I > > > mean, let the user browse other pages without reloading the > > > special URL, and reload it when it's back on display and the > > > timeout has been reached. > > I don't see why a browser should reload an URL if it is not currently viewed, but > I'm not a web expert. > > > > > I looked into adding a sigalrm handler an solving it this way, but > > > > then it turned out that is more complicated > > We can use the glib timeout functions for that. Yes, timeouts are simpler. > > Here is how I would implement the feature: > > - an internal Dillo function to mark/unmark a URL with > "reload periodically when viewed", A simple flag, maybe in the DilloUrl or in the cache entry. > it will also create a timeout > callback that will reload the URL if it is currently viewed. A periodiciy of 0 will > stop reloading. For that, I need to take a look on the browser history/cache, too. Don't worry, I can do that easily (I know pretty well the cache). I'd prefer you to focus on the dpi part. I mean, this dpi will end asking dillo to do the job. For instance: <dpi cmd='set_reload_URL' url='...' always='true'> > > - add a "-r, --reload-every" command line option that calls that function. > In fact, when I finish implementing the "(remote-)command" option, it would be > something like: "-c open(URL, refresh=60)" (that is if I finally decide that > supporting commands with more than one argument is worth the work). Hmmm, I think a simple cli switch to tell dillo to listen to the reloads.dpi is enough: dillo -reloads (or something like it) Then, the client communicates with the dpi socket. All this API is what needs to be designed. I'd appreciate you to work on this part. > > > The first duty is to define what is required for a good, > > > general purpose, kind of reloading dpi. The next one is to reduce > > > the features to a minimum working set, then implement! > > parameters: URL, periodicity (seconds), when (visible|always). This is a good start! For instance: fprintf(reloads_dpi_socket, "push http://localhost/someurl visible\n"); may be all the client program needs to know. Of course it could also be something like: fprintf(reloads_dpi_socket, "<dpi cmd='reloads' url='http://localhost/someurl' visible>" * The first example makes more clear that it goes trough reloads.dpi who parses it and then sends a dpip tag to dillo to request the job done. This may also be handy: "<dpi cmd='reloads' url='http://localhost/someurl' stop>" Note that it may be good to integrate the remote control functionality into the same dpi (and maybe call it remote.dpi?). This means adding a simple and useful API for help programs to use. For instance to let them push new URLs into the same instance of dillo (and not having to start a new dillo per requested page). Ex: The client app. asks the remote control dpi whether there's a running instance of dillo. YES -> send new to-be-pushed URL NO -> start "dillo -rc" (remote control) send new to-be-pushed URL Please polish along these lines. Cheers Jorge.-

2 1

Re: [PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads)
by Melvin Hadasht Aug. 27, 2003

Aug. 27, 2003

[Please, as this thread is on the ML, do not mail me personnaly (nor CC me). I'm subscribed to the list and will respond when I have time and when I have something to respond.] Hi, > ok, dillo never reloads the images, not even on manual reloads - still > showing days old stats. > you think that is fixeable soon, for some value of "soon"? I don't always have time for Dillo. Maybe this weekend, maybe the next. Concerning the reload time, I should be able to fix it when I have time. Concerning the cached images, I will need more time. Concerning the "void" input driver, is the coredump due to my patch? -- Melvin Hadasht

3 2

tab and frames in webmail
by �޽�� Aug. 27, 2003

Aug. 27, 2003

hi, Frank de Lange: I apply you dillo tab frame patch,and it seem very cool. But when I go to the www.163.com and www.163.net, I found I can't go into my mailbox.It only says that "This page uses frames, but your browser doesn't support them."And the statusbar shows "Contacting host", for ever. In windows IE I can see the soursecode of that page as following: <html><head> <title>网易邮件系统</title> <meta http-equiv="Content-Type" content="text/html; charset=gb2312"> </head> <frameset frameborder=NO rows=80,* border=0 framespacing=0> <frame name="2" src="/newtop.htm" target=contents scrolling=NO marginwidth=0 marginheight=0 frameborder=NO > <frameset border=0 cols=160,* framespacing=0 marginheight=0 marginwidth=0 frameborder=NO> <frame name="folder" src="/cgi/ldapapp?funcid=simplefdr&sid=DBTpkvElTAQAKUwf" target=rtop marginwidth=0 marginheight=0 frameborder=NO scrolling=yes>  <frame name="main" src="/cgi/ldapapp?funcid=foldmain&sid=DBTpkvElTAQAKUwf" target=rbottom marginwidth=0 marginheight=0 scrolling=AUTO frameborder=NO> </frameset> </frameset> <noframes> <body bgcolor="#FFFFFF"><p>This page uses frames, but your browser doesn't support them.</p> </body></noframes> </html> What's wrong? best reguards 　　　　　　　　Jewen_Luo(a)163.com 　　　　　　　　　　2003-08-27

1 0

[lmettler@lamlaw.com: Re: A few remarks on your site layout...]
by Frank de Lange Aug. 26, 2003

Aug. 26, 2003

----- Forwarded message from Lewis Mettler <lmettler(a)lamlaw.com> ----- >Thanks for the corrected index.html page for my site. > >You are correct. Some of those tags did appear to be out of place. > >I first wrote that page 5-6 years ago using a program from Corel. It is >not surprising that it was put up incorrectly. Most likely I was trying >several different formats and then stopped screwing with it. I noticed >it still had the NT label embedded. I have not used NT for many years. > >In any event, I edited the version you provided to replace the NT >reference and updated a few of the tags. > >Thanks again. > >And, good fortune with the Dillo browser. > >Let me know if my site now formats correctly using Dillo. Well, it seems to... If only all sites responded as quickly... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

1 0

libc dependency in 0.8.0pre (bug 487)
by David McKee Aug. 26, 2003

Aug. 26, 2003

Folks, Updated my CVS at home (Debian 3.0) to 0.8.0pre the other day, and I like what I see. When I tried to do the same at work today (Redhat 6.2), I had problems building. Dpid uses mkdtemp() which was introduced in glibc 2.1.9. However, ./configure has no problems with my glibc 2.1.3. Submitted as bug 487. This constitutes a change from the 0.7 days when (according to the Compatibility web page) any glibc2 would do. Introducing (by hand) a definition of mkdtemp() I found on the web solved all my problems. Browsing the source suggests that you are not in the habit of carrying around lot of little libc bits---and the associated preprocessor code munging---for systems with variant or insufficient libc's. That is fine. It keeps the code base small and simple, but perhaps ./configure should look out for these things. So does this mean some previously working libc's are now going to be excluded, that more conditional compilation stuff will need to go in, or that dpid needs some work to increase it's universal compatibility? -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

3 4

On-line demonstration against software patents in Europe
by Frank de Lange Aug. 26, 2003

Aug. 26, 2003

Hi'all, As you might know, the European Parliament will vote on software patents in the EU on the 1st of september 2003. I have added a notice to my patch page (http://www.geocities.com/ikbenfrank) about this. Maybe the main Dillo page can do the same? For more info on this issue, go to http://swpat.ffii.org Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

1 0

Frameset & lanlaw.org
by Frank de Lange Aug. 26, 2003

Aug. 26, 2003

I just noticed that my current version of the tab+frame patch still has problems with sites like lamlaw.com, which put body content outside of frameset content. Even though this is against the spec, I've changed my current version of the patch so it displays the right (frameset) content for sites like this. BTW, lamlaw.com is really weird... The sequence of tags is html - head - frameset - /frameset - noframes - /head - body - /body - /noframes - /frameset - /html. So, it has frameset inside head (wrong), /head inside noframes, an extra /frameset, etc. The document claims to be html-4.0-transitional. Sure. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

1 0

finger plugin
by Andreas Schweitzer Aug. 22, 2003

Aug. 22, 2003

Hi, as promised in a previous mail. Here is the still quite rough finger dpi intended for interested developers : http://www.hs.uni-hamburg.de/~stcd102/dillo/ http://www.hs.uni-hamburg.de/~stcd102/dillo/adpi-0.1.tar.gz It's configure.in is essentially dillo's configure.in :-) you could actually just put finger.c in the ./dpi/ subdirectory of dillo and adjust Makefile.am accordingly. but now I have an actual distribution :-) In the tarball is also what I call so far a library ... well, or at least the routines that have been re-used over and over. Lastly, there is also an experiment : a term plugin, which lets you call arbitrary programs from within dillo (read the source, though !) Installation: just copy the created .dpi files to ~/.dillo/ and edit ~/.dillo/dpidrc (as long as this file exists), then go to dpi:/finger/ If you want dillo to actually recognize the finger URL you will have to edit src/IO/Url.c and sr/capi.c. Search for the string "ftp" inside these two files and duplicate the relevant part for the finger protocol. Or await how dillo evolves :-) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

1 0

[PATCH] version 9 of tab+frame patch, frame support 'complete' (?)
by Frank de Lange Aug. 22, 2003

Aug. 22, 2003

Hi'all, The next version (9) of my tab patch is ready (see bottom of this message for download instructions). Frameset support is now almost complete, manual resize has been added, targeted link functionality has been improved, most frame-related attributes actually work, try it I'd say... Frameset (and iframe) support is enabled by default, it can be disabled using the configure option --enable-xhtml-dtd=strict. You can also use --enable-xhtml-dtd=transitional, which will give you iframe but no frameset support. The default option, --enable-xhtml-dtd=frameset, gives both iframe and frameset support. As usual, tab support can be disabled using --disable-tabs. Other new features (since the last version): - CTRL-U pops up the view source window - CTRL-B bookmarks the current page - CTRL-S pops up save page window New preferences frame_blank_in_tab=([NO]/YES): show frames with "_blank" target in new tab (instead of new window) (read the Browser_Frames.txt and Browser_Tabs.txt documents (in the doc/ directory) and the dillorc file for more info on tab- and frame-related preferences (after applying the patch, of course...)) Of course, the patch also fixes some bugs (and possibly introduces new ones). More on frame/iframe support ============================ Frameset support is based on a new widget (GtkFrameset) which implements <frameset> as specified in xhtml-dtd-frameset. This widget is not Dillo-specific, so it can in theory be used in any GTK program. It is a pure GTK widget, not rooted in Dw. It does not provide any special support for Dw-specific features (eg. the full-screen-off-button is not displayed in the widget). I might make a special version for Dillo after the GTK-version has been debugged sufficiently. What works: - loading (nested) framesets, displaying frames at their appropriate location and appropriate size, including margin width/height and scrolling. - loading (nested) iframes, displaying iframes at their appropriate location and with (mostly) appropriate size and alignment. - manual frame resize (row, column or both at the same time (drag border crossing - this does not work between nested framesets) - all frame-related menu options (in the popup menu). Frame menus can be accessed using the 'This Frame...' button in the popup menu, nested framesets have their own 'This Frameset...' menu. This way, Dillo allows you to limit actions to a subset of a framed document, eg. you can search for text in just one frame/iframe/frameset. Top-level menu options usually refer to the whole document (the frameset). An exception to this is the 'Jump To' option, which refers to the frame in which the menu was opened (question: should this contain the anchors for all frames?). Use the 'Show only this Frame' option in the Frame Options menu to get a full-page view of a frame. Same for 'Show only this Frameset'. What does not work yet: - the full_screen_off_button is not shown in frame documents. Use double-click instead to toggle the full screen setting... - the frameborder attribute works, but dw_gtk_scrolled_frame always draws a (focus) shadow around itself - even with the border size is set to 0. This makes it impossible to draw frames seamlessly. Tabs, Frames and browser bloat ============================== version: 0.8.0-pre patch: dillo-20030821-tabs.patch.gz unpatched: 285536 bytes patched, no tabs, no frames: 290444 bytes patched, with tabs, no frames: 298092 bytes patched, no tabs, with frames: 307116 bytes patched, with tabs, with frames: 314892 bytes version: 0.7.3 patch: dillo-0.7.3-20030821-tabs.patch.gz unpatched: 284416 bytes patched, no tabs, no frames: 289708 bytes patched, with tabs, no frames: 297324 bytes patched, no tabs, with frames: 305708 bytes patched, with tabs, with frames: 313452 bytes (gcc 3.2.2, binutils 2.13.90.0.18, CFLAGS "-Os") Judge for yourself if the features are worth their weight in bytes... Download instructions ===================== There are now two versions of the patch, one for Dillo 0.7.3 (release) and one for Dillo 0.8.0-pre (CVS). Make sure to download the correct version for the Dillo source you want to patch! If you patch the CVS source, do not forget to run ./autogen.sh after applying the patch. The CVS patch is made against 20030820 CVS, while the 0.7.3 patch is made against Dillo-0.7.3.tar.bz2 (the source tarball on the main Dillo website). Both versions of the patch can be downloaded from the usual (ad-happy, but...) Geocities site: http://www.geocities.com/ikbenfrank/ More specifically for both versions: Dillo 0.8.0-pre (CVS) ===================== http://www.geocities.com/ikbenfrank/dillo-20030821-tabs.patch.gz size: 66661 bytes (gzipped, as downloaded) 281416 bytes (uncompressed) md5sum: 6afb73d97d3db88c629726cef100f604 (gzipped, as downloaded) c3b6ee3095d4b230a78cf836516e0023 (uncompressed) Dillo 0.7.3 (release) ===================== http://www.geocities.com/ikbenfrank/dillo-0.7.3-20030821-tabs.patch.gz size: 93929 bytes (gzipped, as downloaded) 399156 bytes (uncompressed) md5sum: 0363c9ad9f94df9b1bca23e5489e5c5e (gzipped, as downloaded) 8fca8c49a01cd6a6103661720eb8d60d (uncompressed) As always, check the site for the most recent version: That's all for now, Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

2 1