- Dillo-dev - lists.mailman3.com

[Patch 3/4] Key bindings

by Johannes.Hofmann＠gmx.de

On Thu, May 07, 2009 at 06:02:08PM +0000, corvid wrote: > Rogut?s wrote: > > And one more suggestion: wouldn't it be more intuitive to have > > "command = keybinding" instead of "keybinding = command"? > > *agrees* Well in muttrc you have e.g: bind pager <Down> next-line So it's rather "keybinding = command". Perhaps the '=' is a bit confusing. Cheers, Johannes

May 7, 2009

Re: Dillo2 + FLTK2 + NxLib running on mips linux

by stevegigijoe＠yahoo.com.tw

>On Thu, May 07, 2009 at 02:07:22AM +0800, ???? ?i wrote:=0A>> Hello All=0A= >>=0A>> One years ago I had tried dillo + fltk + nxlib and unsuccessful.=0A= >> Today, the dillo2 works. I'm so happy.=0A>>=0A>> Also I have record my b= uilding progress in my blog=0A>>http://tw.myblog.yahoo.com/stevegigijoe/art= icle?mid=3D138&prev=3D-1&next=3D137=0A>>=0A>> Thank you all.=0A=0A> Good! = =0A> Do you have a screenshot?=0A=0AScreenshot=0A=0A=0Ahttp://f23.yahoofs.= com/myper/824eoFyBBBKXGuU1zjFOFp3xJAY-/blog/ap_F23_20090506105626866.jpg?TT= AeMBKBHJ2Wr2zc=0A=0Ahttp://f23.yahoofs.com/myper/824eoFyBBBKXGuU1zjFOFp3xJA= Y-/blog/ap_F23_20090506092752201.jpg?TTAeMBKBlaX8P12A=0A=0Ahttp://f23.yahoo= fs.com/myper/824eoFyBBBKXGuU1zjFOFp3xJAY-/blog/ap_F23_20090506111231234.jpg= ?TTAeMBKB7IcMpZy_=0A=0ASteve=0A=0A=0A ________________________________= ______________________________________________________________________=0A= =A5I=B6O=A4~=AEe=B6q=B5L=A4W=AD=AD=A1HYahoo!=A9_=BC=AF=B9q=A4l=ABH=BDc2.0= =A7K=B6O=B5=B9=A7A=A1A=ABH=A5=F3=A5=C3=BB=B7=A4=A3=A5=B2=A7R=A1I http://tw.= mg0.mail.yahoo.com/dc/landing

May 7, 2009

[Patch 3/4] Key bindings

by rogutes＠googlemail.com

Re-sending, because the patch was missing some spaces. 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

BUMP: Re: [Dillo-dev] [patch]: more cleanups

by onepoint＠starurchin.org

What is the verdict on these? My stack of local patches is getting uncomfortably long, so decisions either way are welcome so I can shrink it. Regards, Jeremy Henty On Mon, May 04, 2009 at 06:59:34AM +0100, Jeremy Henty wrote: > > 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 > diff -r 817ab0ff08a1 -r c671a697420f src/cache.c > --- a/src/cache.c Sat May 02 22:57:36 2009 +0100 > +++ b/src/cache.c Sat May 02 23:27:14 2009 +0100 > @@ -136,18 +136,6 @@ > /* Client operations ------------------------------------------------------ */ > > /* > - * Make a unique primary-key for cache clients > - */ > -static int Cache_client_make_key(void) > -{ > - static int ClientKey = 0; /* Provide a primary key for each client */ > - > - if (++ClientKey <= 0) > - ClientKey = 1; > - return ClientKey; > -} > - > -/* > * Add a client to ClientQueue. > * - Every client-field is just a reference (except 'Web'). > * - Return a unique number for identifying the client. > @@ -155,11 +143,13 @@ > static int Cache_client_enqueue(const DilloUrl *Url, DilloWeb *Web, > CA_Callback_t Callback, void *CbData) > { > - int ClientKey; > + static int ClientKey = 0; /* Provide a primary key for each client */ > CacheClient_t *NewClient; > > + if (++ClientKey <= 0) > + ClientKey = 1; > + > NewClient = dNew(CacheClient_t, 1); > - ClientKey = Cache_client_make_key(); > NewClient->Key = ClientKey; > NewClient->Url = Url; > NewClient->Version = 0; > diff -r 4ab60f74c46b src/dicache.c > --- a/src/dicache.c Sun May 03 15:29:42 2009 +0100 > +++ b/src/dicache.c Sun May 03 15:32:34 2009 +0100 > @@ -398,7 +398,7 @@ > dReturn_val_if_fail(MimeType && Ptr, NULL); > > if (!web->Image) > - web->Image = a_Image_new(0, 0, NULL, web->bgColor); > + web->Image = a_Image_new(NULL, web->bgColor); > > /* Add an extra reference to the Image (for dicache usage) */ > a_Image_ref(web->Image); > diff -r 4ab60f74c46b src/html.cc > --- a/src/html.cc Sun May 03 15:29:42 2009 +0100 > +++ b/src/html.cc Sun May 03 15:32:34 2009 +0100 > @@ -2062,7 +2062,7 @@ > html->styleEngine->setNonCssHints(&props); > > /* Add a new image widget to this page */ > - Image = a_Image_new(0, 0, alt_ptr, 0); > + Image = a_Image_new(alt_ptr, 0); > if (DW2TB(html->dw)->getBgColor()) > Image->bg_color = DW2TB(html->dw)->getBgColor()->getColor(); > > diff -r 4ab60f74c46b src/image.cc > --- a/src/image.cc Sun May 03 15:29:42 2009 +0100 > +++ b/src/image.cc Sun May 03 15:32:34 2009 +0100 > @@ -33,10 +33,7 @@ > /* > * Create and initialize a new image structure. > */ > -DilloImage *a_Image_new(int width, > - int height, > - const char *alt_text, > - int32_t bg_color) > +DilloImage *a_Image_new(const char *alt_text, int32_t bg_color) > { > DilloImage *Image; > > diff -r 4ab60f74c46b src/image.hh > --- a/src/image.hh Sun May 03 15:29:42 2009 +0100 > +++ b/src/image.hh Sun May 03 15:32:34 2009 +0100 > @@ -50,8 +50,7 @@ > /* > * Function prototypes > */ > -DilloImage *a_Image_new(int width, int height, > - const char *alt_text, int32_t bg_color); > +DilloImage *a_Image_new(const char *alt_text, int32_t bg_color); > void a_Image_ref(DilloImage *Image); > void a_Image_unref(DilloImage *Image); > > diff -r 02d822ae435a src/cache.c > --- a/src/cache.c Sat May 02 23:38:41 2009 +0100 > +++ b/src/cache.c Sat May 02 23:42:40 2009 +0100 > @@ -1112,7 +1112,7 @@ > const char *curr_type = Cache_current_content_type(entry); > st = a_Web_dispatch_by_type(curr_type, ClientWeb, > &Client->Callback, &Client->CbData); > - if (st == -1) { > + if (!st) { > /* MIME type is not viewable */ > if (ClientWeb->flags & WEB_RootUrl) { > MSG("Content-Type '%s' not viewable.\n", curr_type); > diff -r 02d822ae435a src/web.cc > --- a/src/web.cc Sat May 02 23:38:41 2009 +0100 > +++ b/src/web.cc Sat May 02 23:42:40 2009 +0100 > @@ -47,8 +47,8 @@ > * Given the MIME content type, and a fd to read it from, > * this function connects the proper MIME viewer to it. > * Return value: > - * 1 on success (and Call and Data properly set). > - * -1 for unhandled MIME types (and Call and Data untouched). > + * 1 on success (and Call and Data properly set). > + * 0 for unhandled MIME types (and Call and Data untouched). > */ > int a_Web_dispatch_by_type (const char *Type, DilloWeb *Web, > CA_Callback_t *Call, void **Data) > @@ -57,7 +57,7 @@ > > _MSG("a_Web_dispatch_by_type\n"); > > - dReturn_val_if_fail(Web->bw != NULL, -1); > + dReturn_val_if_fail(Web->bw != NULL, 0); > > // get the Layout object from the bw structure. > Layout *layout = (Layout*)Web->bw->render_layout; > @@ -71,8 +71,8 @@ > Web->bgColor= styleEngine.backgroundStyle()->backgroundColor->getColor(); > > dw = (Widget*) a_Mime_set_viewer(Type, Web, Call, Data); > - if (dw == NULL) > - return -1; > + if (!dw) > + return 0; > > dw->setStyle (styleEngine.style ()); > > @@ -100,7 +100,7 @@ > if (!dw) { > MSG_HTTP("unhandled MIME type: \"%s\"\n", Type); > } > - return (dw ? 1 : -1); > + return dw ? 1 : 0; > } > > > diff -r 02d822ae435a src/web.hh > --- a/src/web.hh Sat May 02 23:38:41 2009 +0100 > +++ b/src/web.hh Sat May 02 23:42:40 2009 +0100 > @@ -38,7 +38,7 @@ > int a_Web_valid(DilloWeb *web); > void a_Web_free (DilloWeb*); > int a_Web_dispatch_by_type (const char *Type, DilloWeb *web, > - CA_Callback_t *Call, void **Data); > + CA_Callback_t *Call, void **Data); > > #ifdef __cplusplus > } > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

May 7, 2009

[Patch 3/4] Key bindings

by corvid＠lavabit.com

Rogut?s wrote: > And one more suggestion: wouldn't it be more intuitive to have > "command = keybinding" instead of "keybinding = command"? *agrees*

May 7, 2009

[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