- Dillo-dev - lists.mailman3.com

image resize

by furaisanjin＠gmail.com

Hi all. I think image resize doesn't work when image was already fetched. This is one example page. http://news.goo.ne.jp This page contains CSS so that repush happens. Images have been fetched already when repush is made. Regards, furaisanjin

May 5, 2009

Amazon shop search code!!! :)

by freya128＠yahoo.com

This one was much easier! A bit long but it allows you to search the amazon shop! :) You can change it to amazon.co.uk or amazon.de etc and it still works. More of a fun thing but kinda groovy. search_url="http://www.amazon.com/s/190-8761482-7673944?ie=UTF8&index=blended&link&fiel…" Amazon renders a bit messy right now tho. love Freya

May 5, 2009

Code for Wikipedia searches

by freya128＠yahoo.com

Hiya! A big thanks to Corvid who helped me loads to get my new dillo compiled and working! I wanted to give a little back, so I did a load of reasearch and finally managed to work out the code to get dillo to do direct wikipedia searches. Just add this to the dillorc file: search_url="http://www.wikipedia.org/wiki/Special:Search?search=%s" It would be good to include it with future dillo releases as it's not easy to find out how to do this! It's lots of fun tho, just enter your keywords and it takes you right to the wikipedia page! :) I'm a bit of a wikipedia fan as you may have noticed. Anyway I know it's not loads but I think it's groovy and adds something to dillo. love Freya

May 5, 2009

Latest Dillo

by corvid＠lavabit.com

Freya wrote: > By the way, the copy link location option doesn't seem to work but maybe you already know that. It's supposed to work, anyway. > It would be great to get wikipedia rendering really well, as there are so many wikipedia pages and it is so useful that it would be good just to have a little browser even if it only worked on wikipedia pages! Theres so much content on there. > > I am having one problem tho and I'm wondering if it is a known thing or something that I have done bad here. The default font seems to render very badly, like the kerning is out or something. The k in book is half missing and it is hard to read what you type into the location bar, and the wikipedia pages are basically unreadable too as they all use this font. Wondering if it is because of the version of the font libraries I'm linking in when I compile or something else? > > Is this a known problem? Various dillorc prefs have changed. If you start dillo from the command line with show_msg set in dillorc, does it complain a lot about unknown prefs and stuff? Instead of vw_fontname and fw_fontname, there's #font_serif="DejaVu Serif" #font_sans_serif="DejaVu Sans" #font_cursive="DejaVu Sans" #font_fantasy="DejaVu Sans" #font_monospace="DejaVu Sans Mono" which you'll see in the current sample dillorc. Everything is supposed to look better nowadays because Johannes has added a lot of CSS code. Speaking of which, you can have a style.css file now. I tried making a sample one (http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-February/006036.html ) a while back.

May 4, 2009

Latest Dillo

by freya128＠yahoo.com

Well I just finally managed to compile dillo from the latest developer source and wow it's really amazing! Check out this page: http://www.indiewire.com That site doesn't work properly in my old OS9 mac running the latest netscape available for OS9 but here on my linux laptop running dillo it is working just fine! Totally usable! I also tried myspace for a giggle and found that was also very usable, at least for reading blogs and comments and stuff. Great! Lots of other sites are also working just fine too! By the way, the copy link location option doesn't seem to work but maybe you already know that. It would be great to get wikipedia rendering really well, as there are so many wikipedia pages and it is so useful that it would be good just to have a little browser even if it only worked on wikipedia pages! Theres so much content on there. I am having one problem tho and I'm wondering if it is a known thing or something that I have done bad here. The default font seems to render very badly, like the kerning is out or something. The k in book is half missing and it is hard to read what you type into the location bar, and the wikipedia pages are basically unreadable too as they all use this font. Wondering if it is because of the version of the font libraries I'm linking in when I compile or something else? Is this a known problem? Anyway I'm still in awe at how well the new code is working! :) Thankyou! love Freya

May 4, 2009

[patch]: more cleanups

by onepoint＠starurchin.org

Three more cleanup patches: 1: Inline Cache_client_make_key() into Cache_client_enqueue(). Why have a separate function just to increment a variable? It's just as clear (and less noisy) to increment a static variable inside Cache_client_enqueue(). 2: The width and height arguments of a_Image_new() do nothing. The function itself ignores them and its callers always set them to 0. Since neither the function or its callers seem to care what these arguments are, why not remove them? 3: a_Web_dispatch_by_type() has a strange convention for its return type, it returns -1 to indicate failure. It's less confusing to use the common convention of a boolean: 1 indicates success and 0 indicates failure. Regards, Jeremy Henty

May 4, 2009

Trying to compile the fltk 2 thing

by livio＠eecg.toronto.edu

Hi, Freya writes: > > It goes a bit funny sadly: > > === making src === > === making images/libjpeg === > === making images/zlib === > === making images/libpng === > === making images === > === making OpenGL === > === making fluid === > Linking fluid2... > /usr/bin/ld: cannot find -lXi > collect2: ld returned 1 exit status > make[1]: *** [fluid2] Error 1 > make: *** [all] Error 2 > > Any idea what I might be doing wrong? > It's a shame there are no packages available for the source as I'm running debian and I suspect things would be easier that way. apt-get install libxi-dev Should fix this particular error. Unfortunately, I have not found an "authoritative" list of dependencies for FLTK2. So, if other errors show up due to missing installed dependencies, you can always go to: http://www.debian.org/distrib/packages#search_contents and look for the missing library. For example, in the above case, if one searches for "libXi.so" they can see the missing 'libxi-dev' package. Good luck, Livio

May 4, 2009

patch: punctuation keys

by corvid＠lavabit.com

I'm thinking it might be more natural to be able to put, e.g., "*" instead of "<shift>8" (my keyboard, anyway). This patch is working for the cases I've happened to try, but I am not sure that event_text() will necessarily work for everything. (Last bit of the patch allows binding '<', which is a shifted key for me.) PS <shift>TabKey doesn't work for me, but it wasn't working for me before, either. PPS It would be nice if we could allow multibyte characters.

May 4, 2009

Trying to compile the fltk 2 thing

by freya128＠yahoo.com

It goes a bit funny sadly: === making src === === making images/libjpeg === === making images/zlib === === making images/libpng === === making images === === making OpenGL === === making fluid === Linking fluid2... /usr/bin/ld: cannot find -lXi collect2: ld returned 1 exit status make[1]: *** [fluid2] Error 1 make: *** [all] Error 2 Any idea what I might be doing wrong? It's a shame there are no packages available for the source as I'm running debian and I suspect things would be easier that way. Hope someone can help! :) love Freya

May 4, 2009

[Patch 3/4] Key bindings

by corvid＠lavabit.com

Jorge wrote: > The patch is not 100% complete. For instance there's > a need to provide a default keysrc file in a similar way > that cookiesrc or dillorc (with useful comments). Started looking into making a default keysrc. Some of the bindings in keys.cc are not the same as those in dillo2-help.html. Is that intentional? What is the purpose of KEYS_HIDE_PANELS when we have KEYS_FULLSCREEN?

May 4, 2009

[patch]: fix comment for a_Cache_open_url()

by jcid＠dillo.org

On Sun, May 03, 2009 at 12:12:41AM +0100, Jeremy Henty wrote: > > a_Cache_open_url() never returns 0, so its comment needs fixing. > (Bonus typo fix included too.) :) Committed. -- Cheers Jorge.-

May 3, 2009

[patch]: ensure Cache_client_make_key() returns > 0

by jcid＠dillo.org

On Sat, May 02, 2009 at 11:22:06PM +0100, Jeremy Henty wrote: > > Cache_client_make_key() carefully prevents integer overflow from > making it return a negative value, but it might return 0. This is a > problem because a_Capi_open_url() either calls a_Cache_open_url() and > returns the new client key or else returns 0 to signal that it did not > call a_Cache_open_url(). If Cache_client_make_key() returns 0 then > a_Capi_open_url() will return 0 too, and so its caller will think that > a_Cache_open_url() was not called even though it was. This will stop > the new cache client from being added to the browser window that > is responsible for creating it, which is wrong. Committed. Thanks for the detailed explanation. -- Cheers Jorge.-

May 3, 2009

Style question: cleaning up NULL

by jcid＠dillo.org

On Sun, May 03, 2009 at 05:16:31PM +0100, Jeremy Henty wrote: > > On Sun, May 03, 2009 at 09:35:34AM -0400, Jorge Arellano Cid wrote: > > On Sun, May 03, 2009 at 11:27:14AM +0100, Jeremy Henty wrote: > > > > > > ... a_Url_free() and a_Image_unref() both guard against being > > > passed a NULL argument, yet in several cases the code that calls > > > these functions also checks for a NULL, which is redundant. > > > > In general the API accepts NULL (e.g. dlib), so please remove the > > redundant checks outside it. > > OK, patches attached. Committed! -- Cheers Jorge.-

May 3, 2009

[Patch 3/4] Key bindings

by jcid＠dillo.org

On Sun, May 03, 2009 at 05:51:33PM +0000, corvid wrote: > Jorge wrote: > > A new, rewritten version of the patch was committed. > > Hurray! :) > PS Don't we need something like the following: Committed. -- Cheers Jorge.-

May 3, 2009

[Patch 3/4] Key bindings

by corvid＠lavabit.com

Jorge wrote: > A new, rewritten version of the patch was committed. Hurray! PS Don't we need something like the following:

May 3, 2009

Style question: cleaning up NULL

by onepoint＠starurchin.org

On Sun, May 03, 2009 at 09:35:34AM -0400, Jorge Arellano Cid wrote: > On Sun, May 03, 2009 at 11:27:14AM +0100, Jeremy Henty wrote: > > > > ... a_Url_free() and a_Image_unref() both guard against being > > passed a NULL argument, yet in several cases the code that calls > > these functions also checks for a NULL, which is redundant. > > In general the API accepts NULL (e.g. dlib), so please remove the > redundant checks outside it. OK, patches attached. Regards, Jeremy Henty

May 3, 2009

[Patch 3/4] Key bindings

by jcid＠dillo.org

Hi, A new, rewritten version of the patch was committed. It is O(log n) instead of O(n^3), supports named keys, and multiple keybindings. It supports the traditional key bindings by default, and they can be configured in ~/.dillo/keysrc. e.g. <Ctrl>a = bookmarks F6 = back . = forward <Ctrl>b = back The patch is not 100% complete. For instance there's a need to provide a default keysrc file in a similar way that cookiesrc or dillorc (with useful comments). Please test it and polish where needed. It has had very little testing. Note: O(log n) may be an overkill, but once it was O(n) it was easy to use dlib's sorted list instead of plain list. It can also be used as a template for other sources. -- Cheers Jorge.-

May 3, 2009

Style question: cleaning up NULL

by jcid＠dillo.org

On Sun, May 03, 2009 at 11:27:14AM +0100, Jeremy Henty wrote: > > I've noticed that a_Url_free() and a_Image_unref() both guard against > being passed a NULL argument, yet in several cases the code that calls > these functions also checks for a NULL, which is redundant. I think > that if the API officially accepts NULL then code that calls the API > shouldn't be checking for it. Conversely, if the API does not accept > NULL then its implementation shouldn't be checking for it. So I would > suggest we remove the redundancy by eliminating the NULL check from > either the callers or the API implementation. Thoughts? I'll provide > patches if people agree and decide whether or not these APIs should > support NULL. In general the API accepts NULL (e.g. dlib), so please remove the redundant checks outside it. -- Cheers Jorge.-

May 3, 2009

Style question: cleaning up NULL

by onepoint＠starurchin.org

I've noticed that a_Url_free() and a_Image_unref() both guard against being passed a NULL argument, yet in several cases the code that calls these functions also checks for a NULL, which is redundant. I think that if the API officially accepts NULL then code that calls the API shouldn't be checking for it. Conversely, if the API does not accept NULL then its implementation shouldn't be checking for it. So I would suggest we remove the redundancy by eliminating the NULL check from either the callers or the API implementation. Thoughts? I'll provide patches if people agree and decide whether or not these APIs should support NULL. Regards, Jeremy Henty

May 3, 2009

[patch]: fix comment for a_Cache_open_url()

by onepoint＠starurchin.org

a_Cache_open_url() never returns 0, so its comment needs fixing. (Bonus typo fix included too.) Regards, Jeremy Henty

May 3, 2009

[patch]: ensure Cache_client_make_key() returns > 0

by onepoint＠starurchin.org

Cache_client_make_key() carefully prevents integer overflow from making it return a negative value, but it might return 0. This is a problem because a_Capi_open_url() either calls a_Cache_open_url() and returns the new client key or else returns 0 to signal that it did not call a_Cache_open_url(). If Cache_client_make_key() returns 0 then a_Capi_open_url() will return 0 too, and so its caller will think that a_Cache_open_url() was not called even though it was. This will stop the new cache client from being added to the browser window that is responsible for creating it, which is wrong. Regards, Jeremy Henty

May 3, 2009

[patch]: fix comment to a_Html_image_new()

by onepoint＠starurchin.org

On Fri, May 01, 2009 at 01:52:31PM +0000, corvid wrote: > (I thought the line was "Does what it says on the tin.") Yes it is, but I avoid using such phrases in case it causes confusion. But if you'd like me to be more colloquial, I will! :-) Regards, Jeremy Henty

May 2, 2009

[patch]: fix comment to a_Html_image_new()

by corvid＠lavabit.com

Jeremy wrote: > Does what the subject says. (I think this is my fault: I proposed > taking out the "add" argument and renaming the function but forgot the > revise the comment.) Committed. (I thought the line was "Does what it says on the tin.")

May 1, 2009

[patch]: fix comment to a_Html_image_new()

by onepoint＠starurchin.org

Does what the subject says. (I think this is my fault: I proposed taking out the "add" argument and renaming the function but forgot the revise the comment.) Regards, Jeremy Henty

May 1, 2009

[Patch 2/4] Refactoring src/prefs.c and src/dir.c

by jcid＠dillo.org

Hi Tim, On Tue, Apr 21, 2009 at 03:48:49PM +0000, Tim Nieradzik wrote: > > The patch has a strange comment WRT equal signs: > > > > + // parse the value > > + i = 0; > > + while (*p) { > > + // skip all spaces and equal signs > > + if (!isspace(*p)) { > > + value[i++] = *p; > > + } > > + > > + p++; > > + } > > + > > + value[i] = '\0'; > > > > So either the implementation or the comment is wrong... > > The comment is wrong, I am sorry. If you look a few lines above, you > will see that we have already checked whether the current character > is an equal sign. > > In a previous implementation I used to have an additional check > there but removed it later as we do not want to skip any equal signs > within values. Equal signs are very common in search URLs so > skipping them could have led to many problems. > > I guess I just forgot to adjust the comment accordingly after having > changed this part. > > > If the required job is basically the same, I can keep the current > > function (maybe returning the new termination codes) and continue > > integrating the patchset. > > Yes, that is probably best. OK, a new patch for this was just committed. Several changes/fixes were made. Of the top of my head: - Remove multiple return points inside functions - Comments accuracy - Keep source code file margin < 80 cols. - Identation style in dillo uses 3 spaces. (and there was wrong indentation too). - FIxed a memory leak. Tim: please make a diff between a tree with the original patch and what was committed to get a detailed view of the changes. I'll continue integrating from here. -- Cheers Jorge.-

April 28, 2009

towards a dillo-2.1 release

by jcid＠dillo.org

On Mon, Apr 27, 2009 at 09:10:03PM +0000, corvid wrote: > Jorge wrote: > > On Mon, Apr 20, 2009 at 10:46:49PM +0000, corvid wrote: > > > The dicache changes broke scaled multiscan images. > > > I don't think FltkImgbuf::newScan() gets called anymore. > > > > You're right. Can you look at it? > > > > BTW: FltkImgbuf::newScan() can be issued by adding a call to > > a_Image_new_scan(). > > I think this is all that's needed: > Committed. -- Cheers Jorge.-

April 28, 2009

Image callback race condition

by onepoint＠starurchin.org

On Sun, Apr 26, 2009 at 11:23:07AM +0200, Hofmann Johannes wrote: > On Sun, Apr 26, 2009 at 08:56:15AM +0100, Jeremy Henty wrote: > > > > I am logging the creation and destruction of DilloImage structures > > (patches attached) and I have confirmed that sometimes the image > > callbacks run after the Image is freed. > > This might make sense: > > DilloJpeg sometimes outlives the corresponding DilloImage. If the > a_Jpeg_callback is called and it accesses the pointer to DilloImage > we get the invalid reads, and if there is no callback anymore we > have the leak. OK, I'll try tracing the Dillo{Png,Jpeg,Gif} structures too. Regards, Jeremy Henty

April 28, 2009

towards a dillo-2.1 release

by corvid＠lavabit.com

Jorge wrote: > On Mon, Apr 20, 2009 at 10:46:49PM +0000, corvid wrote: > > The dicache changes broke scaled multiscan images. > > I don't think FltkImgbuf::newScan() gets called anymore. > > You're right. Can you look at it? > > BTW: FltkImgbuf::newScan() can be issued by adding a call to > a_Image_new_scan(). I think this is all that's needed:

April 27, 2009

Image callback race condition

by Johannes.Hofmann＠gmx.de

On Sun, Apr 26, 2009 at 08:56:15AM +0100, Jeremy Henty wrote: > > I am logging the creation and destruction of DilloImage structures > (patches attached) and I have confirmed that sometimes the image > callbacks run after the Image is freed. Here's a typical example: > > $ grep '^Image: 0x4687db8: ' ../../Log/log_2009-04-25_21-48-48.txt > Image: 0x4687db8: new > Image: 0x4687db8: ref: a_Jpeg_callback > Image: 0x4687db8: free > Image: 0x4687db8: ref: a_Jpeg_callback > Image: 0x4687db8: ref: a_Jpeg_callback This might make sense: DilloJpeg sometimes outlives the corresponding DilloImage. If the a_Jpeg_callback is called and it accesses the pointer to DilloImage we get the invalid reads, and if there is no callback anymore we have the leak. Cheers, Johannes

April 26, 2009

Image callback race condition

by onepoint＠starurchin.org

I am logging the creation and destruction of DilloImage structures (patches attached) and I have confirmed that sometimes the image callbacks run after the Image is freed. Here's a typical example: $ grep '^Image: 0x4687db8: ' ../../Log/log_2009-04-25_21-48-48.txt Image: 0x4687db8: new Image: 0x4687db8: ref: a_Jpeg_callback Image: 0x4687db8: free Image: 0x4687db8: ref: a_Jpeg_callback Image: 0x4687db8: ref: a_Jpeg_callback So how can I track down this race condition? Regards, Jeremy Henty PS: I am still running corvid's img-ref patch (also attached for reference).

April 26, 2009

Dillo documentation online

by onepoint＠starurchin.org

There's a tarball of the Dillo documentation at http://starurchin.org/dillo/dillo-docs.tar.gz Alternatively, download the link called "Documentation" at http://starurchin.org/dillo/ It will be updated every night, although it will only be as current as my local HG repo (which I update most days). Regards, Jeremy Henty

April 25, 2009

image memory leak

by onepoint＠starurchin.org

On Fri, Apr 24, 2009 at 06:20:20PM +0200, Hofmann Johannes wrote: > On Thu, Apr 23, 2009 at 09:36:23PM +0100, Jeremy Henty wrote: > > > > On Thu, Apr 23, 2009 at 06:01:56PM +0200, Hofmann Johannes wrote: > > > > > It turns out that memory related to aborted images is not released. > > > > What about the other way round, ie. memory being released and > > then accessed? If you check the invalid read errors at the > > valgrind logs page[1] for the past few days you will see they are > > all due to reading freed image memory. Is this another aspect of > > the same thing, or something else? > > I'd say it's something different. It's always a read of size 4, > isn't it? I guess that's just one uninitialized pointer. I don't think that it's uninitialized pointers. If it were then you would expect valgrind to complain that the address had never been malloced or freed. That's not what we see. Eg. look at the first instance of 'Jpeg_write: Invalid read of size 4'[1]. The freed memory is a DilloImage structure. The line that does the invalid read is reading ... a member of a DilloImage structure! The same is true for the errors from dw::core::Widget::getLayout() , Png_datarow_callback and Png_datainfo_callback . In every case the pointer refers to a malloced structure of the right type. The problem is that the structure has since been freed. I think it's pretty clear that the problem is not uninitialised pointers, it's that the code is using pointers after freeing them. It's probably significant that these errors all come from within image callbacks (a_Jpeg_callback and a_Png_callback). It looks like a race condition to me: callbacks are running after the image has been freed. Does that make sense? Regards, Jeremy Henty [1] http://starurchin.singularity/dillo/valgrind/91efbf6a9f7430ca10f371db76030c…

April 25, 2009

image memory leak

by Johannes.Hofmann＠gmx.de

On Thu, Apr 23, 2009 at 09:36:23PM +0100, Jeremy Henty wrote: > > On Thu, Apr 23, 2009 at 06:01:56PM +0200, Hofmann Johannes wrote: > > > It turns out that memory related to aborted images is not released. > > What about the other way round, ie. memory being released and then > accessed? If you check the invalid read errors at the valgrind logs > page[1] for the past few days you will see they are all due to reading > freed image memory. Is this another aspect of the same thing, or > something else? I'd say it's something different. It's always a read of size 4, isn't it? I guess that's just one uninitialized pointer. Cheers, Johannes

April 24, 2009

image memory leak

by onepoint＠starurchin.org

On Thu, Apr 23, 2009 at 06:01:56PM +0200, Hofmann Johannes wrote: > It turns out that memory related to aborted images is not released. What about the other way round, ie. memory being released and then accessed? If you check the invalid read errors at the valgrind logs page[1] for the past few days you will see they are all due to reading freed image memory. Is this another aspect of the same thing, or something else? > I tried to figure out, why the first cache client is not getting > aborted properly but the cache related code is quite complex... > Does anyone know how this should work? No, I found that part of the code rather brainbending I'm afraid. Regards, Jeremy Henty [1] http://starurchin.org/dillo/valgrind.html

April 23, 2009

image memory leak

by Johannes.Hofmann＠gmx.de

Hi, I did some more tests regarding that image related memory leak, Jeremy reported some time ago. It turns out that memory related to aborted images is not released. With CSS and the related repushs this seems to happen frequently. But I can also trigger it without CSS by hitting Ctrl-R while loading a large image. Attached diagnostic patch shows the issue. Load a page with a single large JPEG image and hit Ctrl-R while it is loading. In that case only the second instance of DilloJpeg is deleted. I tried to figure out, why the first cache client is not getting aborted properly but the cache related code is quite complex... Does anyone know how this should work? Cheers, Johannes

April 23, 2009

patch: a_Capi_get_flags and following redirection

by corvid＠lavabit.com

When an image on a page wouldn't load due to redirection, I would isolate the image, and often notice that message about Content-Length not matching message body. The reason is in a_Capi_open_url(), where reload is set by checking a_Capi_get_flags() for CAPI_IsCached. It follows the redirection, determines the Location URL isn't cached, and makes another HTTP request for the original URL. The cache entry data for that URL ends up containing the body from the first request with the header and body from the second request appended to it. Ah, but sometimes we want to follow redirection for get_flags. - the download check in capi - the load_stylesheet check in html.cc, assuming that we want to make that work with redirection at some point. - load_now for images in html.cc and the rest don't really matter too terribly much either way. So, unable to think of anything nice or clever, I added an argument to get_flags specifying whether redirection should be followed.

April 23, 2009

towards a dillo-2.1 release

by jcid＠dillo.org

Hi Devid, On Wed, Apr 22, 2009 at 03:05:37PM +0200, Devid Antonio Filoni wrote: > Hi, > I can work on point 4. Good! Although packages are to be provided after the final release is ready, you should start testing the packages now. Just put them somewhere (based on current repo) and let the list know for people to check they work OK. If you don't have a server to upload them, we can host them in dillo.org/test. > > Devid Antonio Filoni > > On Mon, Apr 20, 2009 at 11:10 PM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > Hi there, > > > > ?It'd ?be ?very good if we can complete these points for the 2.1 > > release. Listed in no particular order: > > > > ?1.- Dw documentation: online and as tarball. > > ? ? ?We ?have ?good docs. but to generate them there's a need to > > ? ? ?have: doxygen, graphviz, dot, latex and friends. That's why > > ? ? ?having it online and as a tarball is a good idea. > > ?2.- Mapcity segfault > > ? ? ?In www.mapcity.cl playing with the "Tipo Calle" while the > > ? ? ?page ?is ?loading ?makes dillo segfault. If "Remote CSS" is > > ? ? ?disabled, it doesn't happen (also OK in dillo-2.0). > > ?3.- New web site design > > ? ? ?We have a new banner and after finding a good color palette > > ? ? ?it may be ready to renew the site before 2.1 is announced. > > ?4.- Debian/Ubuntu packages (after 2.1 final is ready) > > ?5.- Update "8 years" page (it's nine) > > ? ? ?Yes, I should have done it already... > > ?6.- Configurable key bindings. > > ? ? ?I'm reviewing this with Tim. Hopefully it will make it into > > ? ? ?the 2.1 release. > > ?7.- Memory usage statistics > > ? ? ?Scott has posted some data on this, in another thread. I'll > > ? ? ?answer there. -- Cheers Jorge.-

April 22, 2009

towards a dillo-2.1 release

by devidfil＠gmail.com

Hi, I can work on point 4. Devid Antonio Filoni On Mon, Apr 20, 2009 at 11:10 PM, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Hi there, > > ?It'd ?be ?very good if we can complete these points for the 2.1 > release. Listed in no particular order: > > ?1.- Dw documentation: online and as tarball. > ? ? ?We ?have ?good docs. but to generate them there's a need to > ? ? ?have: doxygen, graphviz, dot, latex and friends. That's why > ? ? ?having it online and as a tarball is a good idea. > ?2.- Mapcity segfault > ? ? ?In www.mapcity.cl playing with the "Tipo Calle" while the > ? ? ?page ?is ?loading ?makes dillo segfault. If "Remote CSS" is > ? ? ?disabled, it doesn't happen (also OK in dillo-2.0). > ?3.- New web site design > ? ? ?We have a new banner and after finding a good color palette > ? ? ?it may be ready to renew the site before 2.1 is announced. > ?4.- Debian/Ubuntu packages (after 2.1 final is ready) > ?5.- Update "8 years" page (it's nine) > ? ? ?Yes, I should have done it already... > ?6.- Configurable key bindings. > ? ? ?I'm reviewing this with Tim. Hopefully it will make it into > ? ? ?the 2.1 release. > ?7.- Memory usage statistics > ? ? ?Scott has posted some data on this, in another thread. I'll > ? ? ?answer there. > > > ?I'd be working on 5, 6 and 3. > ?Volunteers please assign yourselves to the pending points. > > ?BTW, ?if ?you ?have important points to add to the list, please > say so. > > ?Of course any segfaults or regressions have high priority too. > > ?TIA. > > -- > ?Cheers > ?Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

April 22, 2009

towards a dillo-2.1 release

by Johannes.Hofmann＠gmx.de

On Tue, Apr 21, 2009 at 11:06:09AM -0400, Jorge Arellano Cid wrote: > On Tue, Apr 21, 2009 at 09:01:46AM +0200, Hofmann Johannes wrote: > > On Tue, Apr 21, 2009 at 07:48:11AM +0200, Hofmann Johannes wrote: > > > On Mon, Apr 20, 2009 at 05:10:41PM -0400, Jorge Arellano Cid wrote: > > > > Hi there, > > > > > > > > It'd be very good if we can complete these points for the 2.1 > > > > release. Listed in no particular order: > > > > > > > > 1.- Dw documentation: online and as tarball. > > > > We have good docs. but to generate them there's a need to > > > > have: doxygen, graphviz, dot, latex and friends. That's why > > > > having it online and as a tarball is a good idea. > > > > 2.- Mapcity segfault > > > > In www.mapcity.cl playing with the "Tipo Calle" while the > > > > page is loading makes dillo segfault. If "Remote CSS" is > > > > disabled, it doesn't happen (also OK in dillo-2.0). > > > > 3.- New web site design > > > > We have a new banner and after finding a good color palette > > > > it may be ready to renew the site before 2.1 is announced. > > > > 4.- Debian/Ubuntu packages (after 2.1 final is ready) > > > > 5.- Update "8 years" page (it's nine) > > > > Yes, I should have done it already... > > > > 6.- Configurable key bindings. > > > > I'm reviewing this with Tim. Hopefully it will make it into > > > > the 2.1 release. > > > > 7.- Memory usage statistics > > > > Scott has posted some data on this, in another thread. I'll > > > > answer there. > > > > > > > > > > > > I'd be working on 5, 6 and 3. > > > > Volunteers please assign yourselves to the pending points. > > > > > > I will check 2. > > > > Ok, I can reproduce it now with > > > > trickle -d 15 dillo > > > > trickle (http://monkey.org/~marius/pages/?page=trickle) is really > > cool for debugging! > > > > The problem is the repush caused by the arriving CSS stylesheet. It > > deletes all form widgets and recreates them later. > > I guess I can fix the segfault somehow, but there is a fundamental > > problem if the user starts to fill in a form and then the repush > > deletes all his data :( > > > > I currently see these options: > > > > 1. Disable forms while CSS stylesheets are pending. > > 2. Disable the repush once the user started to fill in forms. > > 3. Save form data in memory and restore it after repush. > > This could also be used to restore form data when going back to a > > forms page. > > > > Opinions? > > To implement what we had with dillo1: This is, inactive forms > until the full form is loaded. Adding the restriction of pending > stylesheets too (like in 1). Ok, I just commited a fix. Please test carefully as there might be negative sideeffects like permanentely deactivated forms if a stylesheet fails to load. Cheers, Johannes

April 22, 2009

towards a dillo-2.1 release

by jcid＠dillo.org

On Tue, Apr 21, 2009 at 08:03:57PM +0000, corvid wrote: > Jorge wrote: > > Please check and comment. > > > The next release, dillo-2.1, scheduled for middle 2009 will provide basic CSS > > support, and the usual bugfixes and cleanups. > > Auth deserves mention, I think. > And I'd add "new features" or "improvements" in front of > "bugfixes and cleanups", since we have added various new > little things as well. Please go ahead. -- Cheers Jorge.-

April 21, 2009

towards a dillo-2.1 release

by corvid＠lavabit.com

Jorge wrote: > Please check and comment. > The next release, dillo-2.1, scheduled for middle 2009 will provide basic CSS > support, and the usual bugfixes and cleanups. Auth deserves mention, I think. And I'd add "new features" or "improvements" in front of "bugfixes and cleanups", since we have added various new little things as well.

April 21, 2009

towards a dillo-2.1 release

by jcid＠dillo.org

On Mon, Apr 20, 2009 at 05:10:41PM -0400, Jorge Arellano Cid wrote: > Hi there, > > It'd be very good if we can complete these points for the 2.1 > release. Listed in no particular order: > > 1.- Dw documentation: online and as tarball. > We have good docs. but to generate them there's a need to > have: doxygen, graphviz, dot, latex and friends. That's why > having it online and as a tarball is a good idea. > 2.- Mapcity segfault > In www.mapcity.cl playing with the "Tipo Calle" while the > page is loading makes dillo segfault. If "Remote CSS" is > disabled, it doesn't happen (also OK in dillo-2.0). > 3.- New web site design > We have a new banner and after finding a good color palette > it may be ready to renew the site before 2.1 is announced. > 4.- Debian/Ubuntu packages (after 2.1 final is ready) > 5.- Update "8 years" page (it's nine) > Yes, I should have done it already... > 6.- Configurable key bindings. > I'm reviewing this with Tim. Hopefully it will make it into > the 2.1 release. > 7.- Memory usage statistics > Scott has posted some data on this, in another thread. I'll > answer there. > > > I'd be working on 5, 6 and 3. 5 is done. BTW, there's a good potential link for "memory usage" when the collected data makes its way into a web page. Please check and comment. -- Cheers Jorge.-

April 21, 2009

towards a dillo-2.1 release

by corvid＠lavabit.com

Jorge wrote: > On Mon, Apr 20, 2009 at 10:46:49PM +0000, corvid wrote: > > Jorge wrote: > > > Of course any segfaults or regressions have high priority too. > > > > The dicache changes broke scaled multiscan images. > > I don't think FltkImgbuf::newScan() gets called anymore. > > You're right. Can you look at it? > > BTW: FltkImgbuf::newScan() can be issued by adding a call to > a_Image_new_scan(). All right. PS I was glad to hear that the website will get a new banner.

April 21, 2009

[Patch 2/4] Refactoring src/prefs.c and src/dir.c

by tim.nieradzik＠gmx.de

> The patch has a strange comment WRT equal signs: > > + // parse the value > + i = 0; > + while (*p) { > + // skip all spaces and equal signs > + if (!isspace(*p)) { > + value[i++] = *p; > + } > + > + p++; > + } > + > + value[i] = '\0'; > > So either the implementation or the comment is wrong... The comment is wrong, I am sorry. If you look a few lines above, you will see that we have already checked whether the current character is an equal sign. In a previous implementation I used to have an additional check there but removed it later as we do not want to skip any equal signs within values. Equal signs are very common in search URLs so skipping them could have led to many problems. I guess I just forgot to adjust the comment accordingly after having changed this part. > If the required job is basically the same, I can keep the current > function (maybe returning the new termination codes) and continue > integrating the patchset. Yes, that is probably best. --Tim

April 21, 2009

[Patch 2/4] Refactoring src/prefs.c and src/dir.c

by jcid＠dillo.org

On Mon, Apr 20, 2009 at 06:44:16PM +0000, Tim Nieradzik wrote: > > What's the main point of dParser_parse_rc_line()? > > The main difference to the current implementation is that equal > signs are interpreted as separator. The current implementation also does that. The patch has a strange comment WRT equal signs: + // parse the value + i = 0; + while (*p) { + // skip all spaces and equal signs + if (!isspace(*p)) { + value[i++] = *p; + } + + p++; + } + + value[i] = '\0'; So either the implementation or the comment is wrong... > > Besides, it requires that ``line'', ``name'' and ``value'' are > initialised with a specific length (in dpid/dpid.c it is set to > 1024). The major advantage is that corrupt files (with very long > lines) would not congest the RAM since we abort after 1024 > characters. This is very unlikely though. > > > The comment says it extracts type, name and value, but it doesn't > > extract type. > > Sorry, I had forgotten to update the description. In a previous > version of my patch there has been a ``type'' attribute. As > proposed, I removed it later on. Since then this function does > basically the same job as dParser_get_rc_pair(). If the required job is basically the same, I can keep the current function (maybe returning the new termination codes) and continue integrating the patchset. Otherwise, what is exactly the new function supposed to do differently? -- Cheers Jorge.-

April 21, 2009

towards a dillo-2.1 release

by jcid＠dillo.org

On Mon, Apr 20, 2009 at 10:46:49PM +0000, corvid wrote: > Jorge wrote: > > Of course any segfaults or regressions have high priority too. > > The dicache changes broke scaled multiscan images. > I don't think FltkImgbuf::newScan() gets called anymore. You're right. Can you look at it? BTW: FltkImgbuf::newScan() can be issued by adding a call to a_Image_new_scan(). -- Cheers Jorge.-

April 21, 2009

towards a dillo-2.1 release

by jcid＠dillo.org

On Tue, Apr 21, 2009 at 09:01:46AM +0200, Hofmann Johannes wrote: > On Tue, Apr 21, 2009 at 07:48:11AM +0200, Hofmann Johannes wrote: > > On Mon, Apr 20, 2009 at 05:10:41PM -0400, Jorge Arellano Cid wrote: > > > Hi there, > > > > > > It'd be very good if we can complete these points for the 2.1 > > > release. Listed in no particular order: > > > > > > 1.- Dw documentation: online and as tarball. > > > We have good docs. but to generate them there's a need to > > > have: doxygen, graphviz, dot, latex and friends. That's why > > > having it online and as a tarball is a good idea. > > > 2.- Mapcity segfault > > > In www.mapcity.cl playing with the "Tipo Calle" while the > > > page is loading makes dillo segfault. If "Remote CSS" is > > > disabled, it doesn't happen (also OK in dillo-2.0). > > > 3.- New web site design > > > We have a new banner and after finding a good color palette > > > it may be ready to renew the site before 2.1 is announced. > > > 4.- Debian/Ubuntu packages (after 2.1 final is ready) > > > 5.- Update "8 years" page (it's nine) > > > Yes, I should have done it already... > > > 6.- Configurable key bindings. > > > I'm reviewing this with Tim. Hopefully it will make it into > > > the 2.1 release. > > > 7.- Memory usage statistics > > > Scott has posted some data on this, in another thread. I'll > > > answer there. > > > > > > > > > I'd be working on 5, 6 and 3. > > > Volunteers please assign yourselves to the pending points. > > > > I will check 2. > > Ok, I can reproduce it now with > > trickle -d 15 dillo > > trickle (http://monkey.org/~marius/pages/?page=trickle) is really > cool for debugging! > > The problem is the repush caused by the arriving CSS stylesheet. It > deletes all form widgets and recreates them later. > I guess I can fix the segfault somehow, but there is a fundamental > problem if the user starts to fill in a form and then the repush > deletes all his data :( > > I currently see these options: > > 1. Disable forms while CSS stylesheets are pending. > 2. Disable the repush once the user started to fill in forms. > 3. Save form data in memory and restore it after repush. > This could also be used to restore form data when going back to a > forms page. > > Opinions? To implement what we had with dillo1: This is, inactive forms until the full form is loaded. Adding the restriction of pending stylesheets too (like in 1). This can solve the problem easily, and work even better when we add a maximum-simultaneous-connections to the server parameter in the future. -- Cheers Jorge.-

April 21, 2009

towards a dillo-2.1 release

by Johannes.Hofmann＠gmx.de

On Tue, Apr 21, 2009 at 07:48:11AM +0200, Hofmann Johannes wrote: > On Mon, Apr 20, 2009 at 05:10:41PM -0400, Jorge Arellano Cid wrote: > > Hi there, > > > > It'd be very good if we can complete these points for the 2.1 > > release. Listed in no particular order: > > > > 1.- Dw documentation: online and as tarball. > > We have good docs. but to generate them there's a need to > > have: doxygen, graphviz, dot, latex and friends. That's why > > having it online and as a tarball is a good idea. > > 2.- Mapcity segfault > > In www.mapcity.cl playing with the "Tipo Calle" while the > > page is loading makes dillo segfault. If "Remote CSS" is > > disabled, it doesn't happen (also OK in dillo-2.0). > > 3.- New web site design > > We have a new banner and after finding a good color palette > > it may be ready to renew the site before 2.1 is announced. > > 4.- Debian/Ubuntu packages (after 2.1 final is ready) > > 5.- Update "8 years" page (it's nine) > > Yes, I should have done it already... > > 6.- Configurable key bindings. > > I'm reviewing this with Tim. Hopefully it will make it into > > the 2.1 release. > > 7.- Memory usage statistics > > Scott has posted some data on this, in another thread. I'll > > answer there. > > > > > > I'd be working on 5, 6 and 3. > > Volunteers please assign yourselves to the pending points. > > I will check 2. Ok, I can reproduce it now with trickle -d 15 dillo trickle (http://monkey.org/~marius/pages/?page=trickle) is really cool for debugging! The problem is the repush caused by the arriving CSS stylesheet. It deletes all form widgets and recreates them later. I guess I can fix the segfault somehow, but there is a fundamental problem if the user starts to fill in a form and then the repush deletes all his data :( I currently see these options: 1. Disable forms while CSS stylesheets are pending. 2. Disable the repush once the user started to fill in forms. 3. Save form data in memory and restore it after repush. This could also be used to restore form data when going back to a forms page. Opinions? Cheers, Johannes

April 21, 2009

towards a dillo-2.1 release

by Johannes.Hofmann＠gmx.de

On Mon, Apr 20, 2009 at 05:10:41PM -0400, Jorge Arellano Cid wrote: > Hi there, > > It'd be very good if we can complete these points for the 2.1 > release. Listed in no particular order: > > 1.- Dw documentation: online and as tarball. > We have good docs. but to generate them there's a need to > have: doxygen, graphviz, dot, latex and friends. That's why > having it online and as a tarball is a good idea. > 2.- Mapcity segfault > In www.mapcity.cl playing with the "Tipo Calle" while the > page is loading makes dillo segfault. If "Remote CSS" is > disabled, it doesn't happen (also OK in dillo-2.0). > 3.- New web site design > We have a new banner and after finding a good color palette > it may be ready to renew the site before 2.1 is announced. > 4.- Debian/Ubuntu packages (after 2.1 final is ready) > 5.- Update "8 years" page (it's nine) > Yes, I should have done it already... > 6.- Configurable key bindings. > I'm reviewing this with Tim. Hopefully it will make it into > the 2.1 release. > 7.- Memory usage statistics > Scott has posted some data on this, in another thread. I'll > answer there. > > > I'd be working on 5, 6 and 3. > Volunteers please assign yourselves to the pending points. I will check 2. Cheers, Johannes

April 21, 2009

towards a dillo-2.1 release

by corvid＠lavabit.com

Jorge wrote: > Of course any segfaults or regressions have high priority too. The dicache changes broke scaled multiscan images. I don't think FltkImgbuf::newScan() gets called anymore.

April 21, 2009