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
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()
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.-
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
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.-
On Sat, Oct 27, 2007 at 08:13:11PM +0200, Matthias Franz wrote:
- 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.
The following patch fixes this. (It's not against the latest version of fltk, but the relevant file hasn't changed since.) ### start patch ### --- fltk-2.0.x-r5917/src/compose.cxx 2006-06-25 08:11:31.000000000 +0200 +++ fltk-new/src/compose.cxx 2007-11-08 07:38:01.000000000 +0100 @@ -345,19 +345,8 @@ bool fltk::compose(int& del) { for (const char *p = compose_pairs; *p; p += 2) if (p[0] == ascii || p[1] == ascii) { compose_state = ascii; - // prefer the single-character versions: - if (p[1] == ' ') { - int code = (p-compose_pairs)/2+0xA0; - // convert code to utf8: - e_text = textbuffer; - textbuffer[0] = 0xc0 | code>>6; - textbuffer[1] = 0x80 | (code & 0x3f); - textbuffer[2] = 0; - plen = e_length = 2; - return true; - } + return true; } - if (compose_state != 1) return true; #if 0 // The right-hand ctrl and any letter "quotes" the control character: @@ -386,6 +375,24 @@ bool fltk::compose(int& del) { } } + // prefer the single-character versions: + if (ascii == ' ') { + e_text = textbuffer; + if (c1 & 0x80) { + // convert c1 to utf8: + textbuffer[0] = 0xc0 | c1>>6; + textbuffer[1] = 0x80 | (c1 & 0x3f); + textbuffer[2] = 0; + plen = e_length = 2; + } else { + textbuffer[0] = c1; + textbuffer[1] = 0; + plen = e_length = 1; + } + compose_state = 0; + return true; + } + } #if USE_X11 ### end patch ###
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.
I'm getting more and more convinced of this opinion. Why does one specify key mapping in XKB files if each application processes them on its own? BTW, I've noticed another bug in fltk compose key processing: I use the Windoze menu key for composing. Although it has the right keysym (0xff20), it is ignored, probably because it is also considered to be a META key, and these keys are handled by fltk in a special way. I'll send an email to fltk-bugs as well. Cheers, -- Matthias Franz
participants (3)
-
jcid＠dillo.org -
matthias.franz＠ujf-grenoble.fr -
place＠gobigwest.com