- Dillo-dev - lists.mailman3.com

Crashes on OpenBSD

by Christian.Kellermann＠nefkom.net

Skipped content of type multipart/mixed

Oct. 29, 2007

some more bugs

by jcid＠dillo.org

On Mon, Oct 29, 2007 at 06:02:22PM +0100, Matthias Franz wrote: > On Sat, Oct 27, 2007 at 08:13:11PM +0200, Matthias Franz wrote: > > - Pressing "@" anytime quits Dillo immediately. > > (I guess that was made on purpose during development.) > > On my (German) keyboard I have to press AltGr + "q" to get "@". > Alt + "q" quits dillo as well. (I didn't know that before.) > Could that be an unintended interference? Fixed in CVS! I have a keyboard with '@' in the same key combination, now quit is restricted to LeftAltKey. -- Cheers Jorge.-

Oct. 29, 2007

some more bugs

by matthias.franz＠ujf-grenoble.fr

On Sat, Oct 27, 2007 at 08:13:11PM +0200, Matthias Franz wrote: > - Pressing "@" anytime quits Dillo immediately. > (I guess that was made on purpose during development.) On my (German) keyboard I have to press AltGr + "q" to get "@". Alt + "q" quits dillo as well. (I didn't know that before.) Could that be an unintended interference? -- Matthias Franz

Oct. 29, 2007

Re: yet another patch: forms. activateReceiver

by jcid＠dillo.org

Hi, After a rescue operation (and re-trainning of my bogofilter), there were this emails/patches in the SPAM bin: place (5.6K) patch: just the not-hooked-up image menu place (6.8K) patch: image loading toggle button + preference place (4.2K) patch: plain page menu place (2.6K) yet another patch: forms. activateReceiver All of them were commited with only minor changes. > I assumed I was going to have to _understand_ forms or resources, and here > I find out that all I have to do is hook A to B. At least to make the forms > I use regularly work... I wonder whether you guys left the easy stuff for > whoever comes along just so that it would be easy for them to feel rewarded > for their efforts... :-) We were trying with Sebastian to check that FLTK2, was providing everything we needed to complete the port. Thus, if something worked, but needed lots of hooks thorough the code, only the first one was made (and the rest left for the future), so we could advance to the next case. In the case of forms, while I was porting the html parser the resources for forms were not yet developed, so I had to comment and skip some hooks to make it compile. Later I started joining some dots... > I didn't patch the rc to mention the preference, though. I did. > A slavish copy of linkblock, which, since there certainly weren't any links > involved, ended up named 'eventdata'... In general, do you plan to make the rest of the patches (e.g. hook the image menu, the image loading toggle), or want some help here? BTW, with regard to the linkblock (and my past comments on it), I can try to check how it looks without linkblock, and decide what to make of it afterwards while you work on the part II of the above patches. Just let me know. -- Cheers Jorge.-

Oct. 29, 2007

some more bugs

by jcid＠dillo.org

On Sat, Oct 27, 2007 at 07:12:57PM +0000, place wrote: > Matthias Franz wrote: > > > - The tag <hr> does not produce a horizontal line, but only a small dot. > > My tree has (once again) become far too hacked up for me to generate proper > patches, but the line will be the proper width if you add > > style_attrs.width = Html_parse_length (html, width_ptr); > > to Html_tag_open_hr() Done! -- Cheers Jorge.-

Oct. 28, 2007

some more bugs

by place＠gobigwest.com

Matthias Franz wrote: > - The tag <hr> does not produce a horizontal line, but only a small dot. My tree has (once again) become far too hacked up for me to generate proper patches, but the line will be the proper width if you add style_attrs.width = Html_parse_length (html, width_ptr); to Html_tag_open_hr()

Oct. 27, 2007

some more bugs

by matthias.franz＠ujf-grenoble.fr

Hi everybody, here are some more bugs I've discovered. (I'm sorry that testing usually leads to postings about problems ... Thanks to all who have volunteered to fix them so far!) - The tag <hr> does not produce a horizontal line, but only a small dot. - Pressing "@" anytime quits Dillo immediately. (I guess that was made on purpose during development.) - The bookmark page looks very funny. The columns for the sections and the bookmarks are much to narrow and together use only about one third of the window width. - A problem which is already present in the fltk2 program test/input: Pressing a dead key and then a letter (e.g., "^" and "o") works fine. Pressing a dead key followed by space only sometimes gives the accent (as it should) and sometimes just a space. What you get seems to be random; it changes even while the program is running. I understand that fltk2 processes dead keys on its own. For us, it would probably be easier if the keyboard was used in a "cooked" mode based on the X keyboard settings. Cheers, -- Matthias Franz

Oct. 27, 2007

Test (for posting problems), please ignore

by onepoint＠starurchin.org

Lets see if Jorge has has fixed whatever it was that stopped my posts getting through... Jeremy Henty

Oct. 27, 2007

Re: new browser windows slower than first one

by Johannes.Hofmann＠gmx.de

On Thu, Oct 25, 2007 at 05:34:30PM -0300, Jorge Arellano Cid wrote: > On Thu, Oct 25, 2007 at 07:42:30PM +0000, place wrote: > > I think my biggest problem is that I can't read a page until it's finished > > downloading because it's spending the whole time redrawing, redrawing, > > redrawing. > > For me it's no problem to comment clear_double_buffer() in ui.cc, as long > as we remember to fix the excess of redrawing. I don't mind either, it's just one line anyway. And I think that dillo1 also has frequent redraws but they are not as apparent as the rendering is done to a pixmap and the result is copied. Can others please add the following debug messages to see how often dillo1 rerenders a certain page compared to dillo2 on their machines? dillo1: --- dillo-0.8.6/src/dw_gtk_viewport.c.orig 2007-10-25 22:36:44 +0200 +++ dillo-0.8.6/src/dw_gtk_viewport.c 2007-10-23 19:52:02 +0200 @@ -333,6 +333,7 @@ static void Dw_gtk_viewport_paint (GtkWi /* Widgets draw in backing pixmap. */ p_Dw_widget_draw (viewport->child, &intersection, event); /* Copy backing pixmap into window. */ +fprintf(stderr, "====> DRAW ======\n"); gdk_draw_pixmap (layout->bin_window, widget->style->black_gc, viewport->back_pixmap, area->x, area->y, area->x, area->y, area->width, area->height); dillo2: diff -r 31fd33cfb784 dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Wed Oct 24 22:25:25 2007 +0200 +++ b/dw/fltkviewbase.cc Thu Oct 25 22:51:11 2007 +0200 @@ -50,6 +50,7 @@ FltkViewBase::~FltkViewBase () void FltkViewBase::draw () { +fprintf(stderr, "====> DRAW ======\n"); Group::draw (); ::fltk::Rectangle rect (x(), y(), w(), h()); Johannes

Oct. 25, 2007

Re: new browser windows slower than first one

by jcid＠dillo.org

On Thu, Oct 25, 2007 at 07:42:30PM +0000, place wrote: > I think my biggest problem is that I can't read a page until it's finished > downloading because it's spending the whole time redrawing, redrawing, > redrawing. For me it's no problem to comment clear_double_buffer() in ui.cc, as long as we remember to fix the excess of redrawing. -- Cheers Jorge.-

Oct. 25, 2007