March 2009 - Dillo-dev - lists.mailman3.com

Re: patch: media_type pref

by Johannes.Hofmann＠gmx.de

On Wed, Mar 18, 2009 at 02:25:55PM +0000, corvid wrote: > 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". Agreed. I think we should first add an option to switch to "handheld" and only apply "handheld" and "all" media styles. Later we can decide whether we want a fallback to "screen". > > > 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. Yes, that's the general idea in CSS. We might add a menu item to make it easy for the user to switch between several user stylesheets. But I would only do this if someone really needs/wants it. > > I'll send this to the list in case anyone with experience using > such devices with the web has opinions to share. Unfortunately not me yet :( Cheers, Johannes

March 19, 2009

[patch]: fix compiler warning in CustShrinkTabPager

by onepoint＠starurchin.org

On Thu, Mar 19, 2009 at 08:20:35AM -0400, Jorge Arellano Cid wrote: > On Wed, Mar 18, 2009 at 09:03:18PM +0000, Jeremy Henty wrote: > > > > The CustShrinkTabPager class generates a gcc warning because it > > has virtual functions but its destructor is not virtual. > > What warning do you get? uicmd.cc:68: warning: 'class CustShrinkTabPager' has virtual functions but non-virtual destructor > What version of gcc are you using? 4.1.2 > I'm using gcc version 4.3.2, which is silent on this. Yes, a bit of Googling confirms that this warning disappeared. An unusual case of gcc becoming more permissive in later versions! The issue appears to be that your destructor must be virtual if you are ever going to delete an object of a derived class via a pointer to the base type, otherwise your object won't get properly cleaned up. My gcc seems to be assuming that this is going to happen, since the class has virtual functions. It looks as though your gcc is smart enough to see that we don't actually do this. I'm finding mixed opinions as to what is the right behaviour, but if the latest gcc is happy then it's probably best to take no action. Sorry for the noise. (Time to upgrade again, I think.) Regards, Jeremy Henty

March 19, 2009

sessions [was: Approval]

by rogutes＠googlemail.com

Jorge Arellano Cid (2009-03-18 10:36): > On Sun, Mar 15, 2009 at 10:34:53PM +0000, Tim Nieradzik wrote: <...> > > 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. Even if dillo is stable, it can crash. Xorg can crash too, or power could be lost, all of which leads to lost sessions. And since dillo has tabs, one session can contain a lot of information. Thus, even if one of the main features is stability, it would still be good to know what the developers think about session saving... Keeping history, contents of forms, i.e. the whole browsing state like Firefox does is not necessary, but a list of opened URLs could be kept in a file, which would be removed on clean exit, no? -- -- Rogut?s Sparnuotos

March 19, 2009

[patch]: fix compiler warning in CustShrinkTabPager

by jcid＠dillo.org

On Wed, Mar 18, 2009 at 09:03:18PM +0000, Jeremy Henty wrote: > > 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. What warning do you get? What version of gcc are you using? I'm using gcc version 4.3.2, which is silent on this. -- Cheers Jorge.-

March 19, 2009

[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