- Dillo-dev - lists.mailman3.com

[bug]: more CSS margin problems

by Johannes.Hofmann＠gmx.de

On Sat, Mar 21, 2009 at 06:54:30AM +0000, Jeremy Henty wrote: > > This looks like a horizontal version of the previous problem I > reported. The online example is > > http://rest-client.heroku.com/rdoc/fr_class_index.html > > The text that sticks out of the left of the coloured area is dead: you > can't select it or click it, and if you drag another window over it > slowly from from left to right then it doesn't redisplay properly. > Minimal example attached. It seems that dw/* is not designed to handle overlapping widgets. Maybe we should just disable negative margins for now. Or at least ensure that only margins overlap but not widget contents. Other ideas? Cheers, Johannes

March 21, 2009

[bug]: more CSS margin problems

by onepoint＠starurchin.org

This looks like a horizontal version of the previous problem I reported. The online example is http://rest-client.heroku.com/rdoc/fr_class_index.html The text that sticks out of the left of the coloured area is dead: you can't select it or click it, and if you drag another window over it slowly from from left to right then it doesn't redisplay properly. Minimal example attached. Regards, Jeremy Henty

March 21, 2009

bookmark dpi - cleanups

by 4winter＠informatik.uni-hamburg.de

Skipped content of type multipart/mixed

March 20, 2009

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