- Dillo-dev - lists.mailman3.com

[Patch 3/4] Key bindings

by rogutes＠googlemail.com

corvid (2009-05-03 23:01): > 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? Hello, I'm also wondering why KEYS_HIDE_PANELS is there, since KEYS_FULLSCREEN works fine. It seems to have been merged by Jorge together with the configurable keybindings patch, but I think the functionality was actually proposed by Tim. So I'm bumping this thread and also attaching a small patch, which fixes an omission during the configurable keys merge. The following code was removed from ui.cc, and I think it should be added to keys.cc (currently, no keybindings work if numlock is on): - // We're only interested in some flags - unsigned modifier = event_state() & (SHIFT | CTRL | ALT); And one more question: why are the Button1, Button2, Button3 modifierNames there? And one more suggestion: wouldn't it be more intuitive to have "command = keybinding" instead of "keybinding = command"? Now the keysrc file will look like this: Esc = hide-panels <Ctrl>a = hide-panels , = back Backspace = back . = forward <Shift>Backspace = forward while it could be: hide-panels = Esc hide-panels = <Ctrl>a back = , back = Backspace forward = . forward = <Shift>Backspace -- -- Rogut?s Sparnuotos

May 7, 2009

image memory leak

by onepoint＠starurchin.org

You should note that I have applied this patch: http://starurchin.org/dillo/patch/img_ref.diff.txt I list all my local patches at http://starurchin.org/dillo/valgrind.html . Only img_ref.diff.txt affects how DilloImages are managed. Regards, Jeremy Henty

May 7, 2009

image memory leak

by onepoint＠starurchin.org

On Thu, May 07, 2009 at 11:43:36AM -0400, Jorge Arellano Cid wrote: > Have you found a simplified test-case to reproduce it? Unfortunately no. Here's what I know from good-old printf() debugging. It's definitely the case that sometimes an image callback is called with a freed DilloImage. In fact this happens a lot, much more often than the valgrind logs suggest, so I think it doesn't always cause a bad memory access. Mostly the callback is only called two extra times after the free, but sometimes it is called many more times than that. The only way this could happen is if the DilloImage is put in a DilloWeb and then Cache_client_dequeue() is called without the CCC being shut down. Cache_client_dequeue() is called at various places in cache.c but the whenever the problem appears it turns out that it was called from a_Cache_stop_client(). I have not yet traced the stack further back. I'll do that next and let you know what it shows. Regards, Jeremy Henty

May 7, 2009

Dillo2 + FLTK2 + NxLib running on mips linux

by corvid＠lavabit.com

furaisanjin wrote: > 2009/5/7 corvid <corvid(a)lavabit.com>: > > Wouldn't it be wrong to wrap after most multibyte chars? > > (e.g., if you go to uk.wikipedia.org) > > No, but I thoght some people might concern the cost of utf8decode and > more memory allocation/deallocation due to this patch. Even in English pages it's very common to use some multibyte chars. Spanish, German, etc., of course have accented chars that use two bytes in UTF8. As for whether the code should be optimized or a pref needed, I never tried profiling it. Anyway, it should be moved into Html_process_word...

May 7, 2009

change FLTK scheme for in dillo2

by corvid＠lavabit.com

IL'dar wrote: > Can I change colours of dialogues and scrollbar in dillo2? > I would like to gets something less bright. > Even something like fluid2's -bg option will be ok. Not currently. I would not necessarily be opposed to making ui_fg and ui_bg prefs and adding a bunch of [class]::default_style->[whatever]color() to dillo.cc, although I wouldn't be surprised if we ran into our share of places where fltk hardcodes things to, say, GRAY75.

May 7, 2009

image memory leak

by jcid＠dillo.org

On Sat, Apr 25, 2009 at 01:18:19PM +0100, Jeremy Henty wrote: > 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? Yes, it makes sense to me. Have you found a simplified test-case to reproduce it? Finally now I have some time to investigate this bug. I'll start with the problem Johannes described (large jpeg) because of the test-case. Let's start... -- Cheers Jorge.-

May 7, 2009

Dillo2 + FLTK2 + NxLib running on mips linux

by furaisanjin＠gmail.com

2009/5/7 corvid <corvid(a)lavabit.com>: > Wouldn't it be wrong to wrap after most multibyte chars? > (e.g., if you go to uk.wikipedia.org) No, but I thoght some people might concern the cost of utf8decode and more memory allocation/deallocation due to this patch. Regards, furaisanjin

May 7, 2009

Dillo2 + FLTK2 + NxLib running on mips linux

by corvid＠lavabit.com

furaisanjin wrote: > > ?BTW, ?AFAIR ?the ?patch ?for ?wrapping chinese is "basic". As I > > don't ?know ?anything ?about ?chinese ?it's ?very ?hard for me to > > evaluate. > > I think the patch for Html_write_raw is rather simple than I thought. > If I can give one comment, it's better to treat all multi byte UTF8 > characters in the same way (not only Chinese and Japanese) so that > more people would be happy. If some people don't want to add this > patch for pure ASCII only language, would you able to add prefs > control for multi byte UTF8 character languages? Wouldn't it be wrong to wrap after most multibyte chars? (e.g., if you go to uk.wikipedia.org)

May 7, 2009

Dillo2 + FLTK2 + NxLib running on mips linux

by corvid＠lavabit.com

Jorge wrote: > BTW, AFAIR the patch for wrapping chinese is "basic". As I > don't know anything about chinese it's very hard for me to > evaluate. > > Corvid: is it worth to push this patch to the repo? Hard for me to evaluate, too. To me, it seems like a good thing on the whole... furaisanjin said that doing this makes text in tables too narrow, but I'd imagine that's a smaller matter than the lack of wrapping would be. I think the current patch would fail to work if numeric entities are used to specify characters.

May 7, 2009

Dillo2 + FLTK2 + NxLib running on mips linux

by furaisanjin＠gmail.com

> ?BTW, ?AFAIR ?the ?patch ?for ?wrapping chinese is "basic". As I > don't ?know ?anything ?about ?chinese ?it's ?very ?hard for me to > evaluate. I think the patch for Html_write_raw is rather simple than I thought. If I can give one comment, it's better to treat all multi byte UTF8 characters in the same way (not only Chinese and Japanese) so that more people would be happy. If some people don't want to add this patch for pure ASCII only language, would you able to add prefs control for multi byte UTF8 character languages? Regards, furaisanjin

May 7, 2009