- Dillo-dev - lists.mailman3.com

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

by akemnade＠tzi.de

Hi, On Tue, 24 Feb 2009 20:21:52 +0100 Detlef Riekenberg <wine.dev(a)web.de> 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. > > ...$hd id http://hg.dillo.org/dillo > abort: cannot look up remote revision; remote repository does not > support the 'lookup' capability! > $ hg id http://hg.dillo.org/dillo f4d5923de127 Greetings Andreas Kemnade

March 20, 2009

[bug]: CSS strangeness: disappearing text

by Johannes.Hofmann＠gmx.de

On Fri, Mar 20, 2009 at 05:50:49AM +0000, Jeremy Henty wrote: > > Something funny is happening with this URL > > http://marcofrasca.wordpress.com/2009/03/18/updated-paper/ > > In Dillo, all of the first paragraph except for the last line has > disappeared. Also, if you click and drag around that line you can > make it disappear too. It reappears as soon as you drag the window > anywhere. > > I have stripped this down to a minimal example (attached). Both lines > of the style file have to be present to get the effect. > Interestingly, in Firefox this example also only shows the bottom line > of the paragraph, but it puts it right at the top of the screen. So > it looks as though Dillo sort of understands that most of the > paragraph is invisible, but does not put it in the right place? uh, that one is hard... It has to do with how Textblock places child widgets. It seems that reverting fa7a0bd75ff1 fixes this specific issue, but that causes a lot of other glitches e.g. on google.com. I'll see if I can find a fix. Regards, Johannes

March 20, 2009

[bug]: CSS strangeness: disappearing text

by onepoint＠starurchin.org

Something funny is happening with this URL http://marcofrasca.wordpress.com/2009/03/18/updated-paper/ In Dillo, all of the first paragraph except for the last line has disappeared. Also, if you click and drag around that line you can make it disappear too. It reappears as soon as you drag the window anywhere. I have stripped this down to a minimal example (attached). Both lines of the style file have to be present to get the effect. Interestingly, in Firefox this example also only shows the bottom line of the paragraph, but it puts it right at the top of the screen. So it looks as though Dillo sort of understands that most of the paragraph is invisible, but does not put it in the right place? Regards, Jeremy Henty

March 20, 2009

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