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

RFC: Dillo presentation

by furaisanjin＠gmail.com

Hi, 2009/3/5 Jorge Arellano Cid <jcid(a)dillo.org>: > ? ?- Low bandwidth requirement (very important in rural areas) Is there any plan to limit simultaneous HTTP connections? If the page contains lots of pictures, dillo generates simultaneous HTTP connections to fetch them and those occupy certain amount of bandwidth. Regards, furaisanjin

March 5, 2009

RFC: Dillo presentation

by onepoint＠starurchin.org

Many thanks, Jorge! Updated checklist attached. Regards, Jeremy Henty

March 5, 2009

clipping image inputs

by corvid＠lavabit.com

Johannes wrote: > On Wed, Mar 04, 2009 at 08:22:12PM +0000, corvid wrote: > > With > > > > <input type="image" name="name1" src="whatever" > > WIDTH="80" HEIGHT="14" > > alt="name1name1name1name1"> > > <input type="image" name="name2" src="whatever" > > width="9" height="14" > > alt="name2name2name2name2"> > > > > the long alt text doesn't clip. > > It looks like the embed knows that it's 80 pixels wide > > (at least the child widget area stuff in Textblock::drawLine > > seemed to have the right idea), > > but the image thinks it's 188 (in my case). > > > > > > PS I have "white-space: nowrap" pretty much working, > > but I don't know what I'm doing in Textblock very well, > > so it's definitely not going into this release. > > Can you explain the issue your are working on? At least > > <div style="white-space: nowrap">foo bar foo bar foo bar</div> > > seems to work already (the line is not wrapped). First I noticed that the boxes at the bottoms of the pages about web browser stuff in en.wikipedia weren't wrapping (including Dillo's page) because they go <..nowrap>...</span> <span..nowrap>...</span> and it wasn't taking spaceStyle->whiteSpace into account. Not handling its own wikipedia page well is sort of unfortunate. and then I found that if you have a line that goes: some normal text <span ...nowrap>really really long stretch of nowrap</span>, it wouldn't break before the span. There may be other cases as well.

March 5, 2009

clipping image inputs

by Johannes.Hofmann＠gmx.de

On Wed, Mar 04, 2009 at 08:22:12PM +0000, corvid wrote: > With > > <input type="image" name="name1" src="whatever" > WIDTH="80" HEIGHT="14" > alt="name1name1name1name1"> > <input type="image" name="name2" src="whatever" > width="9" height="14" > alt="name2name2name2name2"> > > the long alt text doesn't clip. > It looks like the embed knows that it's 80 pixels wide > (at least the child widget area stuff in Textblock::drawLine > seemed to have the right idea), > but the image thinks it's 188 (in my case). > > > PS I have "white-space: nowrap" pretty much working, > but I don't know what I'm doing in Textblock very well, > so it's definitely not going into this release. Can you explain the issue your are working on? At least <div style="white-space: nowrap">foo bar foo bar foo bar</div> seems to work already (the line is not wrapped). Cheers, Johannes

March 4, 2009

clipping image inputs

by corvid＠lavabit.com

With <input type="image" name="name1" src="whatever" WIDTH="80" HEIGHT="14" alt="name1name1name1name1"> <input type="image" name="name2" src="whatever" width="9" height="14" alt="name2name2name2name2"> the long alt text doesn't clip. It looks like the embed knows that it's 80 pixels wide (at least the child widget area stuff in Textblock::drawLine seemed to have the right idea), but the image thinks it's 188 (in my case). PS I have "white-space: nowrap" pretty much working, but I don't know what I'm doing in Textblock very well, so it's definitely not going into this release.

March 4, 2009

RFC: Dillo presentation

by jcid＠dillo.org

Hi Jeremy, On Tue, Mar 03, 2009 at 08:36:59PM +0000, Jeremy Henty wrote: > > I have agreed to give presentation on Dillo to my local Linux Users > Group this Thursday. Naturally I'm leaving it until the last minute > to write anything! :-) I am attaching my crib list of essential points > to cover. > > My aim is to give a very short talk covering > > * project goals > * history (Dillo-1, Dillo-2.0, Dillo-2.1, soon) > * development model > * supported features > * architecture (DPI, Dw) > * future > > I'd very much appreciate any comments people have, particularly if you > think there's anything important I have missed out. This is your > chance to tell me what to tell them. (Just bear in mind that I aim to > be brief, so I can't go into large amounts of detail.) OK, here go mine. > > Dillo > > Fast, light, graphical browser. (stats?) > > No dependencies on heavyweight desktop environments. ... and you can statically link FLTK2. > Used in many lightweight distros. > One of the big names in this niche. > > Aims to democratise data. Data access: - Low HW requirement - Low bandwidth requirement (very important in rural areas) - Encourages standards (very important to be able to display the data). and privacy. > History > > Dillo-1 > C, Gtk-1 > developed internally > Developers attempted to find funding, failed > stalled Not really developed internally. It was always an open project. Some patches didn't get in though. Stalled when we realized GTK1 was a dead end. > Dillo-2 > Ported to FLTK-2 (GTK-2 is too bulky) > Development opened up > Dillo-2.0 This one was developed internally (Sebastian and I), and opened later for all to see. The idea was to attract more developers, and to let it evolve from there (very good documentation for developers was included). You can find a good summary in its splash page: "Our users will surely enjoy this new release as it will give them the same things they're accustomed plus tabbed browsing, antialiasing, different character sets, accepting compressed pages, control over image loading, smaller footprint, fewer dependencies, better table rendering, bugfixes, improved GUI, ... In brief, a better dillo." > > Dillo-2.1 (coming soon) - CSS (fonts and colours) Now we have more developers too! > VCS, originally CVS, now Mercurial > > DPI architecture (so Dillo is really a suite of programs) > - implements https, cookies Future: * It'd be great to have dillo included as a help browser in the main distros (e.g. Debian). Do you remember the times when applications came with a help button that popped information on how to use the program? There were even context-sensitive help buttons. All that vanished with the bloated browser (no time and no memory to launch it, and to find it useful). Those times may be back; dillo can be launched in less than a second and its memory footprint is really small. It provides support for standard HTML documentation with images. An API for context sensitive help is simple to develop (its basically pushing a passed URL). * Improve rendering: especially floating objects and the already good-looking CSS. * Dillo with Framebuffer support. This can be very useful for embedded devices. * Improve functionality so more sites can be used quickly! (we all know the nice feel of a site that can be used with Dillo) -- Cheers Jorge.-

March 4, 2009

Holiday week

by jorl17.8＠gmail.com

S?b, 2009-02-21 ?s 11:47 -0300, Jorge Arellano Cid escreveu: > Hi there, > > I happen to be enjoying a much needed holiday week! :-) > > The plan is to come back around near wednesday 25. > > In the meanwhile, I leave you with the following issues lurking > in my list to be considered. Maybe all of them can be left to the > release after 2.1, but maybe not: > > [ ] https dialog bombing issue. BUG#868 > When enabled, multiple https requests to the same site result > in dialog bombing. The https dpi is disabled by default in > Dillo. Anyway, in Debian, there's a security warning against > dillo for not checking certificates (I don't know what > version of dillo they use, nor why they enable https.) > > [ ] Jump to #anchor doesn't work correctly. > The idle timeout doesn't work reliably (an old bug). > > [ ] Implement @import statement in STYLE element. > > [ ] What will we do with xhtml? FF doesn't validate. BUG#732 > This would be interesting to define. > (already suggested as discussion material in another thread). > > [ ] "-fno-rtti -fno-exceptions" gcc: 64KB less. > Enabling this switches reduces the binary size. > > [ ] dpi for "view page source" (it re-uses search capability). > Waiting since a long time... > > [-] BUG#892 prefs bg_color is not working > Johannes was working on related things... > > [ ] META refresh: "instant client-side redirect". > [ ] META refresh: URL='<URI>' case. > I plan to implement both when I'm back (and to include them > in dillo-2.1). > > BTW, I want to welcome Tim Nieradzik as a new developer and to > tell Joao that the bug in the find-text iterator is not that much > important. Just focus on something more urgent. > I'm glad you had fun! I have been quite away and felt like I had to explain my absence. It's exam period over here, exams coming from every direction and barely any time to program. The iterator bug seems to effectively be a bug in the way iterators treat whitespace, but I'm leaving that for later, right now I will try to use my time to focus on understanding dillo's internals to a deeper degree. Anyway, once I am fully free, I'll be sure to note that here. Good luck everyone, Jo?o P.S: And welcome Tim Nieradzik!

March 4, 2009

RFC: Dillo presentation

by onepoint＠starurchin.org

I have agreed to give presentation on Dillo to my local Linux Users Group this Thursday. Naturally I'm leaving it until the last minute to write anything! :-) I am attaching my crib list of essential points to cover. My aim is to give a very short talk covering * project goals * history (Dillo-1, Dillo-2.0, Dillo-2.1, soon) * development model * supported features * architecture (DPI, Dw) * future I'd very much appreciate any comments people have, particularly if you think there's anything important I have missed out. This is your chance to tell me what to tell them. (Just bear in mind that I aim to be brief, so I can't go into large amounts of detail.) Regards, Jeremy Henty

March 3, 2009

Re: css parsing numbers

by Johannes.Hofmann＠gmx.de

On Tue, Mar 03, 2009 at 08:34:09AM -0300, Jorge Arellano Cid wrote: > On Mon, Mar 02, 2009 at 09:54:43PM +0100, Hofmann Johannes wrote: > > On Mon, Mar 02, 2009 at 01:06:52PM -0300, Jorge Arellano Cid wrote: > > > On Sun, Mar 01, 2009 at 12:31:18PM +0100, Hofmann Johannes wrote: > > > > On Sat, Feb 28, 2009 at 12:22:32AM +0100, Hofmann Johannes wrote: > > > > > On Fri, Feb 27, 2009 at 07:06:27PM +0100, Hofmann Johannes wrote: > > > > > > On Fri, Feb 27, 2009 at 03:29:55PM +0000, corvid wrote: > > > > > > > > On Fri, Feb 27, 2009 at 02:26:03PM +0000, corvid wrote: > > > > > > > > > > Committed. I hoped to be able to make that code a bit shorter, but > > > > > > > > > > could not find a reasonable solution... > > > > > > > > > > > > > > > > > > Yeah. In any case, it's just going to get worse/rearranged again > > > > > > > > > for negative numbers... > > > > > > > > > > > > > > > > Exactly. I started my simplification attempts, added negative number > > > > > > > > support - and blew it all up :) > > > > > > > > I'm really considering a flex based scanner now. What do you think? > > > > > > > > > > > > > > I only touched flex very briefly for a class at school long ago, > > > > > > > and I don't remember anything from the experience, but the > > > > > > > idea interests me since it has to be less trouble than trying > > > > > > > to do it by hand... > > > > > > > > > > > > > > > > > > > > > > > This turned out to be easier than expected. Attached patch adds a flex > > > > > based scanner for CSS data. > > > > > It's not optimized or polished but seems to work here. > > > > > > > > To make reviewing easier I created a repo for the flex experiment: > > > > http://freehg.org/u/dillo/flex/ > > > > I think the use of flex makes the code simpler and more > > > > maintainable. For some reason rendering is a bit different, e.g. on > > > > wikipedia.org maybe because negative numbers are supported. > > > > It would be nice if people could test it regarding the performance > > > > impact. > > > > > > > > What do you think. Is it worth to add the flex dependency? > > > > > > I'm a bit worried about the flex dependency. > > > > > > It's being a long time since I saw/used flex/bison/yacc & > > > friends. AFAIR, there was a myriad of slightly incompatible > > > flavours. > > > > > > It may be safer to generate a C-source parser with the tool, > > > and to include it as a source file. > > > > I'm currently checking re2c (http://re2c.org/) as a flex alternative > > and it looks pretty cool. It does not need a lib and produces > > pretty clean C code. So we might ship the generated code in the > > release tarballs. > > > > I'll post a prototype when I'm ready. > > Great. > C code looks like the more portable way to go. > > BTW, quoting from the description of Flex > ('aptitude show flex'): > > <q> > [...] > The behaviour of Flex has undergone a major change since version > 2.5.4a. Flex scanners are now reentrant, and it is now possible > to have multiple scanners in the same program with differing sets > of defaults, and the scanners play nicer with modern C and C++ > compilers. The Flip side is that Flex no longer conforms to the > POSIX lex behaviour, and the scanners require conforming > implementations when flex is used in ANSI C mode. The package > flex-old provides the older behaviour. > </q> > > OTOH, re2c looks like a suitable tool we may use in other areas > too. Go ahead! The re2c version now more or less works (escaped characters are not yet supported). You can find the code at http://freehg.org/u/dillo/flex/ Cheers, Johannes

March 3, 2009

Re: css parsing numbers

by jcid＠dillo.org

On Mon, Mar 02, 2009 at 09:54:43PM +0100, Hofmann Johannes wrote: > On Mon, Mar 02, 2009 at 01:06:52PM -0300, Jorge Arellano Cid wrote: > > On Sun, Mar 01, 2009 at 12:31:18PM +0100, Hofmann Johannes wrote: > > > On Sat, Feb 28, 2009 at 12:22:32AM +0100, Hofmann Johannes wrote: > > > > On Fri, Feb 27, 2009 at 07:06:27PM +0100, Hofmann Johannes wrote: > > > > > On Fri, Feb 27, 2009 at 03:29:55PM +0000, corvid wrote: > > > > > > > On Fri, Feb 27, 2009 at 02:26:03PM +0000, corvid wrote: > > > > > > > > > Committed. I hoped to be able to make that code a bit shorter, but > > > > > > > > > could not find a reasonable solution... > > > > > > > > > > > > > > > > Yeah. In any case, it's just going to get worse/rearranged again > > > > > > > > for negative numbers... > > > > > > > > > > > > > > Exactly. I started my simplification attempts, added negative number > > > > > > > support - and blew it all up :) > > > > > > > I'm really considering a flex based scanner now. What do you think? > > > > > > > > > > > > I only touched flex very briefly for a class at school long ago, > > > > > > and I don't remember anything from the experience, but the > > > > > > idea interests me since it has to be less trouble than trying > > > > > > to do it by hand... > > > > > > > > > > > > > > > > > > > This turned out to be easier than expected. Attached patch adds a flex > > > > based scanner for CSS data. > > > > It's not optimized or polished but seems to work here. > > > > > > To make reviewing easier I created a repo for the flex experiment: > > > http://freehg.org/u/dillo/flex/ > > > I think the use of flex makes the code simpler and more > > > maintainable. For some reason rendering is a bit different, e.g. on > > > wikipedia.org maybe because negative numbers are supported. > > > It would be nice if people could test it regarding the performance > > > impact. > > > > > > What do you think. Is it worth to add the flex dependency? > > > > I'm a bit worried about the flex dependency. > > > > It's being a long time since I saw/used flex/bison/yacc & > > friends. AFAIR, there was a myriad of slightly incompatible > > flavours. > > > > It may be safer to generate a C-source parser with the tool, > > and to include it as a source file. > > I'm currently checking re2c (http://re2c.org/) as a flex alternative > and it looks pretty cool. It does not need a lib and produces > pretty clean C code. So we might ship the generated code in the > release tarballs. > > I'll post a prototype when I'm ready. Great. C code looks like the more portable way to go. BTW, quoting from the description of Flex ('aptitude show flex'): <q> [...] The behaviour of Flex has undergone a major change since version 2.5.4a. Flex scanners are now reentrant, and it is now possible to have multiple scanners in the same program with differing sets of defaults, and the scanners play nicer with modern C and C++ compilers. The Flip side is that Flex no longer conforms to the POSIX lex behaviour, and the scanners require conforming implementations when flex is used in ANSI C mode. The package flex-old provides the older behaviour. </q> OTOH, re2c looks like a suitable tool we may use in other areas too. Go ahead! -- Cheers Jorge.-

March 3, 2009