- Dillo-dev - lists.mailman3.com

[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