- Dillo-dev - lists.mailman3.com

[patch]: remove the BW_* flags

by onepoint＠starurchin.org

On Wed, Mar 18, 2009 at 09:26:14AM -0400, Jorge Arellano Cid wrote: > On Fri, Mar 13, 2009 at 05:52:07PM +0000, Jeremy Henty wrote: > > Yes, there is a case for keeping the flags for future development. > > I'd prefer to keep the flags. OK, I'll drop the patch and work on the rest. > > Just so you know, the cleanups I have pending refactor a lot of > > code that calls the dList_* API in convoluted and inefficient > > ways. [...] > [...] > dList API was designed with a minimal working function set in > mind. This keeps the API easy to remmeber and use. I'm sure that's right but there's a lot of repeated code wherever dLists are cleaned up. That makes me think that the current API is a little *too* minimal. > Please try to get some performance numbers, and in the meanwhile > send me a summary of the API changes. I will. Regards, Jeremy Henty

March 19, 2009

[patch]: fix compiler warning in CustShrinkTabPager

by onepoint＠starurchin.org

The CustShrinkTabPager class generates a gcc warning because it has virtual functions but its destructor is not virtual. This patch adds the virtual destructor and stops the warning. NB: there may be a case for rejecting this patch if we're really concerned about the performance of virtual functions (one extra indirection per call). FLTK deliberately avoids virtual destructors whenever possible for just this reason. I seriously doubt that this patch makes any impact on Dillo, but that's just IMHO. Regards, Jeremy Henty

March 18, 2009

[patch] Configurable key bindings

by jcid＠dillo.org

On Mon, Mar 09, 2009 at 04:54:57PM +0100, Tim Nieradzik wrote: > [...] > PS: I would like to port some C files to C++ in order to achieve > more consistency. What is your opinion on this? Please don't. C++ is an unfortunate compromise we had to make to be able to use FLTK2. It has increased complexity, reduced portability and we'd like to confine it to a minimum (in size and features). > Submitting a patch > for each changed file to the list might be a bit inconvenient. That's not the idea. One changeset (which can touch several files) per email is the standard. > Therefore, I am considering creating a repository on FreeHg.org > which only deals with refactoring code. Separate repos. are suggested for major changes (as the CSS branch). -- Cheers Jorge.-

March 18, 2009

Re: Approval

by jcid＠dillo.org

Hi, On Sun, Mar 15, 2009 at 10:34:53PM +0000, Tim Nieradzik wrote: > Hi Jorge, > > > Please send it to me and I'll send you a dillo.org based URL > > so you can refer to it. > > Unfortunately I had already deleted the mail but here are some > information from my maildrop log that might be useful for you: > > Date: Mon Mar 9 17:00:12 2009 > From: dillo-dev-bounces(a)dillo.org > Subj: Your message to Dillo-dev awaits moderator approval > Size: 1902 Message found and approved. > By the way, I think I have found three bugs in Dillo. Whenever I > visit the site https://oss.gonicus.de/labs/gosa/wiki, it asks me > whether I want to accept the certificate about 10 times (probably > for each picture and CSS file). A way to solve it would be to > remember the selection for all links on this page but this could > become to a big security risk as people could misuse this behaviour > for phishing sites. This is BUG#868 in the tracker. The solution is to turn the https dpi into a server (it's a filter now). This is not complex but takes time. I don't want to delay the next release even more so most probably it will be in the release after dillo-2.1. > The other bug appears on http://urldecode.info/ where no pictures > are displayed. My vague assumption is that Dillo cannot handle > images whose headers contain a "Location" header. Dillo just checks > whether the Content-Length header contains anything (this is why it > works for 0). It seems to me that Dillo downloads the picture > properly but does not show it because it thinks the size is supposed > to be 0. Yes, historically dillo doesn't follow image redirections. Over time this has helped to reduce advertising (most image redirections are advertising). > [...] > A possible solution would be to overwrite all headers by the ones > from the redirected URL ("Location" header). Or would it be better > to delete all available headers when a "Location" headers was found? For "root" URLs, redirection is working, the same/similar method my be re-used for images. The point is whether it's desirable to do it. For instance, with a load_remote_images pref, it would work, but lot's of advertising would pass too. When disabled, sites as the one you cite won't work. If we let the user toggle this pref from "Tools" it would feel clumsy to do it for a favorite site. Now, we may solve all this with URL filtering. Let's say filtering has higher priority, and we have "allow" and "deny" options (just think of hosts not RE by now to discard performance issues). In the above described case I'd choose to set: allow file content = urldecode.info load_image_redirections = NO meaning that when visiting urldecode.info, remote image redirections will be loaded. The API should allow setting this automatically from the tools menu (e.g. "allow remote images" option with a short dialog: Do you want to enable remote image loading permanently for site xxx.yyy.zzz? [Allow] [Cancel]) URL filtering based on regular expressions is expensive in CPU terms, that's why I like the idea of HOST-based filtering. With it you can deny as a general rule and have some allow exceptions. (BTW, as a last resource if all this is not enough, RE support may be added on top). > The third issue (which only occurs in the Hg tree) looks like a > timing bug. When visiting http://www.golem.de/0903/65726.html not > all of the pictures are shown but when reloading the page, they are. > Interestingly, it works perfectly if I save the page to disk and > then view it manually in Dillo. This needs some ivestigation... > When is the final version planned to be released? I'll have more time in April, so probably April. > In my opinion we > should wait a few weeks because Dillo crashes regularly on my > machines (always running the trunk version). This is strange, I very seldom get a dillo crash. Can you post example URLs, more details of your OS/FLTK-version/settings? > Therefore a release > candidate every two would be useful for the users to give feedback > and to report further bugs. After all of the major bugs have been > fixed, we could announce the final version. That's the idea. > Is it planned to include > the key bindings patch into this version? This should not be a big > deal for the users as the configuration files are backward > compatible. No, it's not planned. Now if the patch is simple, clean and straightforward and I can review it before rc1, and behaves well in testing, then it may go in. > What really annoys me is that when Dillo crashes, the CPU usage > climbs onto 100%. The only way I can fix this is to kill all > Dillo-related processes. This way, I lose my tabs. A session-saver > like in Mozilla Firefox would be a useful feature but I am not sure > whether it is worth the "bloatage". AFAIS, one of the main features of Dillo is its stability, so please give us more information on this. > PS: What is the accurate way to find those memory leaks? I remember > Jeremy speaking about Valgrind which he used to create his "crash > reports". Valgrind is cetainly a great tool for the job. -- Cheers Jorge.-

March 18, 2009

Re: patch: media_type pref

by corvid＠lavabit.com

Jorge wrote: > On Mon, Feb 16, 2009 at 05:37:36AM +0000, corvid wrote: > > It makes more sense to have a pref that the user can > > control than for us to guess what they might like > > based on screen size or whatever, I think. > > I hesitate on this. For instance: if media_type is defined to > "handheld" and there's no such remote CSS, at least it should > fallback to "screen". If there is a handheld style sheet available and dillo is running on a handheld, it would be a shame not to use it. I'm hoping that the page author would have the sense to supply something for type "all". > Maybe it's more practical to provide custom stylesheets (as the > current "style.css". e.g. small_screen.css, print.css) and to > allow switching among them from the "Tools" menu. > > What do you think? I think someone using handheld would want to use both the page author's handheld-specific code and a user style suitable for their device. I'll send this to the list in case anyone with experience using such devices with the web has opinions to share.

March 18, 2009

[patch] Configurable key bindings

by tim.nieradzik＠gmx.de

Here is an updated version of the patch. It aims to be fully backward compatible. You do not need to change anything in your dillorc (put the key bindings into ~/.dillo/keysrc). Changes: - Ported src/dir\.[ch] to C++ (now called src/paths\.(cc|hh)). - Split src/prefs.c (parser is now in src/prefsparser.c). - Changed method names in src/dillo.cc to use camel case. - Added meta-modifier and function keys F10-F12. - Key bindings are to be defined in keysrc (previously dillorc). - Fixed some inconsistent white spaces. - Shortened some license headers. - Minor code cleanups such as using "TODO:" instead of "\todo". - Removed a_Prefs_freeall because it was not used anywhere. PS: I would like to port some C files to C++ in order to achieve more consistency. What is your opinion on this? Submitting a patch for each changed file to the list might be a bit inconvenient. Therefore, I am considering creating a repository on FreeHg.org which only deals with refactoring code. --Tim

March 18, 2009

[patch]: remove the BW_* flags

by jcid＠dillo.org

Hi, On Fri, Mar 13, 2009 at 05:52:07PM +0000, Jeremy Henty wrote: > On Fri, Mar 13, 2009 at 08:40:45AM -0300, Jorge Arellano Cid wrote: > > > Anyway I reviewed the patch back then, and remembered that the > > current interface was meant for flexibility to experiment. > > Yes, there is a case for keeping the flags for future development. I > just wanted to point that they are currently redundant and we could > remove them if we wanted. I'd prefer to keep the flags. > > I have to give it a second review. Anyway, if there're more cleanups > > pending on this patch, it may be worth accepting them > > Just so you know, the cleanups I have pending refactor a lot of code > that calls the dList_* API in convoluted and inefficient ways. (Most > stuff that call dList_remove() are like this.) You get cleaner and > more efficient code by defining new dList_remove_* and dList_free_* > functions, because that lets you replace lots of convoluted code paths > that call dList_remove(), dList_nth_data() etc. with single API calls. dList API was designed with a minimal working function set in mind. This keeps the API easy to remmeber and use. Now, if there's a measurable performance gain with the added functions it may be worth adding them. > One function that gets refactored is a_Bw_stop_clients(), which is why > submitting the cleanup patches is waiting on the decision about the > BM_Flags patch. It won't be hard to fix the cleanup patches if the > BM_Flags patch does not go in, but until the decision is made I don't > know whether or not to do that. Please try to get some performance numbers, and in the meanwhile send me a summary of the API changes. -- Cheers Jorge.-

March 18, 2009

[patch]: fix comment for DLWin::del()

by jcid＠dillo.org

On Wed, Mar 18, 2009 at 06:27:17AM +0000, Jeremy Henty wrote: > > > The comment for DLWin::del() was copied and pasted from > > DLWin::new(), but never corrected! > > And here's the patch. D'oh! Committed. -- Cheers Jorge.-

March 18, 2009

Re: Ohloh does not accept http://hg.dillo.org/dillo as Enlistment for the Dillo browser.

by akemnade＠tzi.de

Hi, On Tue, 17 Mar 2009 20:41:19 +0100 Detlef Riekenberg <wine.dev(a)web.de> wrote: > On Di, 2009-02-24 at 20:21 +0100, Detlef Riekenberg wrote: > > Hi. > > Thanks for working on Dillo. > > > > I tried to update the Dillo Project Page on Ohloh, > > but the the repository failed on the id command. > > > > ...$ hg id http://hg.dillo.org/dillo > > abort: cannot look up remote revision; remote repository does not > > support the 'lookup' capability! > > > > Which Mercurial version is used to serve dillo? > > Ohloh still can't accept the current dillo repository, because "hg id" > failed: > hg id http://hg.dillo.org/dillo > > Any Ideas, who can fix the repository configuration? > I have not updated the server yet (I'll to it at the weekend). I qoute myself: It is Mercurial Distributed SCM (version 0.9.1) Thats the version coming with debian etch. The id command works differently in the newer versions. I plan to upgrade at the end of march at the latest to the just-released stable. Greetings Andreas Kemnade

March 18, 2009

[patch]: fix comment for DLWin::del()

by onepoint＠starurchin.org

> The comment for DLWin::del() was copied and pasted from > DLWin::new(), but never corrected! And here's the patch. D'oh! Jeremy Henty

March 18, 2009