May 2009 - Dillo-dev - lists.mailman3.com

repo

by jcid＠dillo.org

Johannes, In patch fd2b0634abe9 there's a long-word splitter, please add a comment on why it's there. IIRC it was discussed in dillo-dev recently but memory is fragile. BTW, there's a warning too: xembed.cc: In member function 'void Xembed::createInternal(uint32_t)': xembed.cc:126: warning: unused variable 'x' TIA. -- Cheers Jorge.-

May 29, 2009

--xid option

by jcid＠dillo.org

On Thu, May 28, 2009 at 12:48:22PM +0000, corvid wrote: > Johannes wrote: > > On Wed, May 27, 2009 at 05:25:15PM -0400, Jorge Arellano Cid wrote: > > > AFAIS the current repo is almost dillo-2.1. I'd freeze here > > > and only accept bug fixes and polish from now. Opinions? > > > > Ok for me. > > A release sounds good. > Of course naturally I think, "I hope my MSG macros count as polishing... > I hope my UTF-8 file.c code counts as polishing..." Send them to me when they're ready. > The auth crash that Tim reported is the one thing clearly in the way. It'd be good to solve this one. > Bits of polish that I see in skimming through my mail is the matter > of the sysconf dir, and of the keybindings changing and the mystery of > KEYS_HIDE_PANELS. And putting together sample style.css and keysrc. Yes. I have other items here, but more on this later. -- Cheers Jorge.-

May 29, 2009

patch: a binding for stop

by jcid＠dillo.org

On Fri, May 29, 2009 at 02:39:04AM +0000, corvid wrote: > > I don't like much Esc for stop, but if that's FFs default, > > it may be better than another (as the Ctrl-x clash you spot). > > Afterall this is what configurable keybindings is suppossed to > > solve so Esc is OK for me as default. > > I'll have to rip out the mysterious HIDE_PANELS in order to > take back Escape which it is using. AFAIS, in the sense of: > What is the purpose of KEYS_HIDE_PANELS when we have KEYS_FULLSCREEN? The idea is to handle the case of a "search text" request on hidden panels. In which case the search panel is temporarily shown, until Esc is pressed. If it can be done with less variables, no problem. Now, Esc is used to: - Close dialog windows - Hide the search panel Please don't rip that functionality. The idea is Esc to stop when there's no search bar. -- Cheers Jorge.-

May 29, 2009

x offset > 64k

by Johannes.Hofmann＠gmx.de

On Thu, May 28, 2009 at 12:36:05PM +0000, corvid wrote: > Johannes wrote: > > On Thu, May 28, 2009 at 03:55:57AM +0000, corvid wrote: > > > I tried looking at a stylesheet, but nothing displayed. > > > It was a one-line document about 7k chars long. > > > > > > It turned out that fltk::getwidth() calls XftTextExtents32() > > > and the width comes back in a short, so it wrapped at 32k. > > > > > > I chopped the line into 1k-long "words", and now I saw > > > text, but once I made a line somewhere over 8k chars long, drawing > > > would wrap and start at the beginning again. Everything looked > > > all right in fltk::drawtext_transformed() as it called > > > XftDrawString32()... > > > > > > I have no idea whether this is something easy to deal with > > > in some way, or a limitation in X... > > > > > > > Oh. This is extremely nasty. Yes, it is a limitation of X. And > > someone (fltk or dillo) needs to workaround it. Fltk2 has 32bit > > coordinate space, but single drawing operations seem still to be > > limited in size, as they are directly mapped to their X > > counterparts. > > The individual drawing requests weren't too big after splitting > them up, so far as I could tell. I was trying > > data = a_Misc_expand_tabs(Start + i - len, len); > while (data->len > 1000) { > char *s = dStrndup(data->str, 1000); > DW2TB(dw)->addText(s, widgetStyle); > dStr_erase(data, 0, 1000); > dFree(s); > } > DW2TB(dw)->addText(data->str, widgetStyle); > > where data had become a Dstr*. That's fltk not checking the coordinates for 16bit overflow before passing it to XftDrawString32(). Of course one could argue that Xft should do that check. We probabely need to do it ourselfes in fltkviewbase.cc by adding checks for coordinates >= USHRT_MAX. But what is our general plan to fix these issues? I'd say in the long run we could try to make all the draw* methods in fltkviewbase.cc work properly with arbitrary int coordinates by breaking them down to equivalent (as far as the visible area is concerned) drawrequests with smaller coordinates. Cheers, Johannes

May 28, 2009

--xid option

by onepoint＠starurchin.org

On Thu, May 28, 2009 at 09:02:41AM +0200, Johannes Hofmann wrote: > On Wed, May 27, 2009 at 05:25:15PM -0400, Jorge Arellano Cid wrote: > > AFAIS the current repo is almost dillo-2.1. I'd freeze here and > > only accept bug fixes and polish from now. Opinions? > > Ok for me. +1. We really want to ship the CSS support (and all the other goodies we have) in a stable release and there are no show-stopping problems. Regards, Jeremy Henty

May 28, 2009

patch: a binding for stop

by jcid＠dillo.org

On Wed, May 27, 2009 at 02:22:57PM +0000, corvid wrote: > > Wondering whether we can come to a decision on this one.. > I don't like much Esc for stop, but if that's FFs default, it may be better than another (as the Ctrl-x clash you spot). Afterall this is what configurable keybindings is suppossed to solve so Esc is OK for me as default. > -------------------------------------- > > > Jeremy wrote: > > On Wed, May 06, 2009 at 11:32:31AM -0400, Jorge Arellano Cid wrote: > > > > > > The other one I can think of as mnemonic is <ctrl>x. What do > > > people think? > > > > That clashes with "Cut". Select some text in the URL window and > > <ctrl>+x will delete it. I think it's not a good idea to grab > > something that (a) already has a conventional action, and (b) already > > performs that conventional action in the GUI. > > > > And while we're talking about conventional use: Dillo is highly > > unconventional when it uses <ctrl>+q to close a tab. Everyone else[1] > > uses <ctrl>+w to close a tab (<ctrl>+<shift>+q to close a window) and > > <ctrl>+q to quit. Which can be annoying when switching between the > > two. > > > > Firefox uses Escape to stop, and arora[2] uses <ctrl>+. . > > > > Regards, > > > > Jeremy Henty > > > > [1] ie. Firefox :-) > > [2] http://code.google.com/p/arora/ - WebKit+Qt-based browser. It > > looks very nice and may supplant Firefox as "the browser to fall back > > to when Dillo can't handle the page". > > -- Cheers Jorge.-

May 28, 2009

--xid option

by corvid＠lavabit.com

Johannes wrote: > On Wed, May 27, 2009 at 05:25:15PM -0400, Jorge Arellano Cid wrote: > > AFAIS the current repo is almost dillo-2.1. I'd freeze here > > and only accept bug fixes and polish from now. Opinions? > > Ok for me. A release sounds good. Of course naturally I think, "I hope my MSG macros count as polishing... I hope my UTF-8 file.c code counts as polishing..." The auth crash that Tim reported is the one thing clearly in the way. Bits of polish that I see in skimming through my mail is the matter of the sysconf dir, and of the keybindings changing and the mystery of KEYS_HIDE_PANELS. And putting together sample style.css and keysrc.

May 28, 2009

x offset > 64k

by corvid＠lavabit.com

Johannes wrote: > On Thu, May 28, 2009 at 03:55:57AM +0000, corvid wrote: > > I tried looking at a stylesheet, but nothing displayed. > > It was a one-line document about 7k chars long. > > > > It turned out that fltk::getwidth() calls XftTextExtents32() > > and the width comes back in a short, so it wrapped at 32k. > > > > I chopped the line into 1k-long "words", and now I saw > > text, but once I made a line somewhere over 8k chars long, drawing > > would wrap and start at the beginning again. Everything looked > > all right in fltk::drawtext_transformed() as it called > > XftDrawString32()... > > > > I have no idea whether this is something easy to deal with > > in some way, or a limitation in X... > > > > Oh. This is extremely nasty. Yes, it is a limitation of X. And > someone (fltk or dillo) needs to workaround it. Fltk2 has 32bit > coordinate space, but single drawing operations seem still to be > limited in size, as they are directly mapped to their X > counterparts. The individual drawing requests weren't too big after splitting them up, so far as I could tell. I was trying data = a_Misc_expand_tabs(Start + i - len, len); while (data->len > 1000) { char *s = dStrndup(data->str, 1000); DW2TB(dw)->addText(s, widgetStyle); dStr_erase(data, 0, 1000); dFree(s); } DW2TB(dw)->addText(data->str, widgetStyle); where data had become a Dstr*.

May 28, 2009

x offset > 64k

by Johannes.Hofmann＠gmx.de

On Thu, May 28, 2009 at 03:55:57AM +0000, corvid wrote: > I tried looking at a stylesheet, but nothing displayed. > It was a one-line document about 7k chars long. > > It turned out that fltk::getwidth() calls XftTextExtents32() > and the width comes back in a short, so it wrapped at 32k. > > I chopped the line into 1k-long "words", and now I saw > text, but once I made a line somewhere over 8k chars long, drawing > would wrap and start at the beginning again. Everything looked > all right in fltk::drawtext_transformed() as it called > XftDrawString32()... > > I have no idea whether this is something easy to deal with > in some way, or a limitation in X... > Oh. This is extremely nasty. Yes, it is a limitation of X. And someone (fltk or dillo) needs to workaround it. Fltk2 has 32bit coordinate space, but single drawing operations seem still to be limited in size, as they are directly mapped to their X counterparts. It not only affects text btw: <html> <body> <img src="foo" width="8000" height="20" style="border: 1px solid black" /> </body> </html> Maybe we need to add code to all the drawing operations in dw/fltkviewbase.cc to break up large drawing requests somehow? Cheers, Johannes

May 28, 2009

--xid option

by Johannes.Hofmann＠gmx.de

On Wed, May 27, 2009 at 05:25:15PM -0400, Jorge Arellano Cid wrote: > On Tue, May 26, 2009 at 08:17:53PM +0200, Johannes Hofmann wrote: > > On Tue, May 19, 2009 at 08:24:14PM +0200, Johannes Hofmann wrote: > > > On Tue, May 19, 2009 at 01:34:56PM -0400, Jorge Arellano Cid wrote: > > > > On Mon, May 18, 2009 at 11:14:14PM +0200, Johannes Hofmann wrote: > > > > > On Mon, May 18, 2009 at 01:48:43PM -0400, Jorge Arellano Cid wrote: > > > > > > On Mon, May 18, 2009 at 01:18:11AM +0200, Johannes Hofmann wrote: > > > > > > > Hi, > > > > > > > > > > > > > > attached patch tries to implement the missing --xid option that is > > > > > > > used to embed dillo into the claws mailer. > > > > > > > The right way to do this would probabely be to implement the > > > > > > > complete XEMBED protocol which is also mentioned in > > > > > > > doc/fltk-problems.doc. > > > > > > > However a simple XReparentWindow() seems to work more or less here. > > > > > > > Please test. > > > > > > > > > > > > It seems like you forgot to commit xembed.{hh,cc} to the repo. > > > > > > e.g. hg add xembed.hh xembed.cc > > > > > > > > > > Oh yes. Should be fixed now. > > > > > Btw. I managed to install the claws mail client including the dillo > > > > > plugin and it seems to work fine now with dillo2. That's why I just > > > > > committed the xembed stuff. > > > > > > > > This is very good. > > > > > > > > I'll have to dig for the sylpheed contact to let them know. > > > > Does anybody here know the email? > > > > > > I already contacted them on irc (#claws on freenode). > > > It would be good if this get's some testing as there seems to be > > > some interaction with the WM in use. I now tested it successful > > > on dwm, twm, and fvwm. > > > Also there are probabely more elegant ways to do it, but > > > for now I think it's better than nothing. > > > > More testing showed that the current implementation has severe > > problems. > > The thing is that the window manager that I use (dwm) is one of the > > few non-reparenting WMs. Most others reparent new windows and that > > can create races with the reparentin we do. > > There also seems to be a problem with keyboard events in that case. > > Is there anyone on the list with in-depth X11 knowledge who could > > help with the xembed stuff? > > Not me. > > I've seen new patches in the repo so I assume this is more > or less being improved. Please let me know how it goes. I figured out some more how this is supposed to work with xtrace and the testsocket example from gtk2. For me it now works reliably with claws under kde3. An open issue is that claws eats up all key presses it has defined as hotkeys (including 'p' and 'u'), but the same thing happens when I embed the example plugin from gtk instead of dillo. > > AFAIS the current repo is almost dillo-2.1. I'd freeze here > and only accept bug fixes and polish from now. Opinions? Ok for me. Cheers, Johannes

May 28, 2009