- Dillo-dev - lists.mailman3.com

Garbage chars added

by Johannes.Hofmann＠gmx.de

On Thu, Oct 23, 2008 at 02:14:24PM -0300, Jorge Arellano Cid wrote: > On Thu, Oct 23, 2008 at 03:41:40PM +0000, corvid wrote: > > Tomas wrote: > > > "corvid" <corvid(a)lavabit.com> wrote: > > > > > > > Tomas wrote: > > > > > What's causing the addition of garbage symbols, like here (comments > > > > > by tr (6th & 8th comment(most visible in 8th))): > > > > > http://www.nezinau.lt/microsoft-lazerines-peles-sugeba-nustebinti#comments > > > > > Backspace? > > > > > > > > Looks like it. > > > > > > > > I pasted a random chunk of text ending in a non-ASCII character into > > > > a textarea with a form submitting as UTF-8. > > > > "mink??" became "mink%C5%A1" in the submitted data, which I believe is > > > > right. Then I pressed backspace in the textarea, leaving "mink", and > > > > submitted again. Now it submits "mink%A1", which is wrong. > > > > Input type=text doesn't seem to have the problem. > > > > Probably something wrong in fltk's TextEditor, then. I'll see if I can > > > > find where it's missing some utf8-awareness. > > > > > > > > > > Hey you were quick to figure that out :) > > > > In fltk/src/TextEditor.cxx, you could try replacing the kf_backspace > > with: > > > > int TextEditor::kf_backspace(int, TextEditor* e) { > > int oldpos = e->insert_position(); > > if (!e->buffer()->selected() && e->move_left()) > > e->buffer()->select(e->insert_position(), oldpos); > > kill_selection(e); > > e->show_insert_position(); > > e->maybe_do_callback(); > > return 1; > > } > > > > Looks like their kf_delete is broken as well... > > It'd be great if an FLTK2 STR with patch is made out of this. > (Johannes knows what's required. Just user/passwd?) Yes, just register at http://fltk.org/login.php Works with dillo :-) Cheers, Johannes

Oct. 23, 2008

dillo in distributions

by akemnade＠tzi.de

Hi, I have looked a bit around. My bitbake files I sent to openembedded are not accepted yet. There are no comments on their tickets yet. The openmoko people have discovered my openmoko package between the debian packages (there was nowhere else a note about them), put a note into their "community update" about it. It is also included in their FDOM distribution and the package is also mirrored on www.opkg.org Greetings Andreas Kemnade

Oct. 23, 2008

Garbage chars added

by sandshrew＠gmail.com

On Thu, 23 Oct 2008 15:41:40 +0000 "corvid" <corvid(a)lavabit.com> wrote: > In fltk/src/TextEditor.cxx, you could try replacing the kf_backspace > with: > > int TextEditor::kf_backspace(int, TextEditor* e) { > int oldpos = e->insert_position(); > if (!e->buffer()->selected() && e->move_left()) > e->buffer()->select(e->insert_position(), oldpos); > kill_selection(e); > e->show_insert_position(); > e->maybe_do_callback(); > return 1; > } > > Looks like their kf_delete is broken as well... > Seems to work now. Maybe you should send them a patch? > Tomas wrote: > > X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.0; i486-pc-linux-gnu) > > Just noticed this. Is claws able to make much use of dillo2? > Jorge put in a special-case workaround for "dillo -l -f -x XID URL" > right before release, but I don't know whether anyone's using it > (or if any claws users even know it's there) With claws I use Gtkhtml2Viewer ( http://www.claws-mail.org/plugin.php?plugin=gtkhtml2 ) -- Brain: an apparatus with which we think we think. - A. Bierce

Oct. 23, 2008

Garbage chars added

by jcid＠dillo.org

On Thu, Oct 23, 2008 at 03:41:40PM +0000, corvid wrote: > Tomas wrote: > > "corvid" <corvid(a)lavabit.com> wrote: > > > > > Tomas wrote: > > > > What's causing the addition of garbage symbols, like here (comments > > > > by tr (6th & 8th comment(most visible in 8th))): > > > > http://www.nezinau.lt/microsoft-lazerines-peles-sugeba-nustebinti#comments > > > > Backspace? > > > > > > Looks like it. > > > > > > I pasted a random chunk of text ending in a non-ASCII character into > > > a textarea with a form submitting as UTF-8. > > > "mink??" became "mink%C5%A1" in the submitted data, which I believe is > > > right. Then I pressed backspace in the textarea, leaving "mink", and > > > submitted again. Now it submits "mink%A1", which is wrong. > > > Input type=text doesn't seem to have the problem. > > > Probably something wrong in fltk's TextEditor, then. I'll see if I can > > > find where it's missing some utf8-awareness. > > > > > > > Hey you were quick to figure that out :) > > In fltk/src/TextEditor.cxx, you could try replacing the kf_backspace > with: > > int TextEditor::kf_backspace(int, TextEditor* e) { > int oldpos = e->insert_position(); > if (!e->buffer()->selected() && e->move_left()) > e->buffer()->select(e->insert_position(), oldpos); > kill_selection(e); > e->show_insert_position(); > e->maybe_do_callback(); > return 1; > } > > Looks like their kf_delete is broken as well... It'd be great if an FLTK2 STR with patch is made out of this. (Johannes knows what's required. Just user/passwd?) -- Cheers Jorge.-

Oct. 23, 2008

claws? (Re: [Dillo-dev] Garbage chars added)

by corvid＠lavabit.com

Tomas wrote: > X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.0; i486-pc-linux-gnu) Just noticed this. Is claws able to make much use of dillo2? Jorge put in a special-case workaround for "dillo -l -f -x XID URL" right before release, but I don't know whether anyone's using it (or if any claws users even know it's there) Hmm...a moment of searching and the first hit I get is http://www.nabble.com/Using-of-Dillo2-td20014194.html which suggests that, no, they don't know.

Oct. 23, 2008

Garbage chars added

by corvid＠lavabit.com

Tomas wrote: > "corvid" <corvid(a)lavabit.com> wrote: > > > Tomas wrote: > > > What's causing the addition of garbage symbols, like here (comments > > > by tr (6th & 8th comment(most visible in 8th))): > > > http://www.nezinau.lt/microsoft-lazerines-peles-sugeba-nustebinti#comments > > > Backspace? > > > > Looks like it. > > > > I pasted a random chunk of text ending in a non-ASCII character into > > a textarea with a form submitting as UTF-8. > > "mink?" became "mink%C5%A1" in the submitted data, which I believe is > > right. Then I pressed backspace in the textarea, leaving "mink", and > > submitted again. Now it submits "mink%A1", which is wrong. > > Input type=text doesn't seem to have the problem. > > Probably something wrong in fltk's TextEditor, then. I'll see if I can > > find where it's missing some utf8-awareness. > > > > Hey you were quick to figure that out :) In fltk/src/TextEditor.cxx, you could try replacing the kf_backspace with: int TextEditor::kf_backspace(int, TextEditor* e) { int oldpos = e->insert_position(); if (!e->buffer()->selected() && e->move_left()) e->buffer()->select(e->insert_position(), oldpos); kill_selection(e); e->show_insert_position(); e->maybe_do_callback(); return 1; } Looks like their kf_delete is broken as well...

Oct. 23, 2008

More love for Dillo2!

by jcid＠dillo.org

On Wed, Oct 22, 2008 at 11:00:11PM +0100, Jeremy Henty wrote: > > Linux Today linked to this: > > TuxArena: Dillo 2.0 Gets Tabbed Browsing > > http://tuxarena.blogspot.com/2008/10/dillo-20-gets-tabbed-browsing.html Good! Link added in "Press" section. -- Cheers Jorge.-

Oct. 23, 2008

Garbage chars added

by sandshrew＠gmail.com

On Thu, 23 Oct 2008 14:43:09 +0000 "corvid" <corvid(a)lavabit.com> wrote: > Tomas wrote: > > What's causing the addition of garbage symbols, like here (comments > > by tr (6th & 8th comment(most visible in 8th))): > > http://www.nezinau.lt/microsoft-lazerines-peles-sugeba-nustebinti#comments > > Backspace? > > Looks like it. > > I pasted a random chunk of text ending in a non-ASCII character into > a textarea with a form submitting as UTF-8. > "mink?" became "mink%C5%A1" in the submitted data, which I believe is > right. Then I pressed backspace in the textarea, leaving "mink", and > submitted again. Now it submits "mink%A1", which is wrong. > Input type=text doesn't seem to have the problem. > Probably something wrong in fltk's TextEditor, then. I'll see if I can > find where it's missing some utf8-awareness. > Hey you were quick to figure that out :) -- Brain: an apparatus with which we think we think. - A. Bierce

Oct. 23, 2008

Garbage chars added

by corvid＠lavabit.com

Tomas wrote: > What's causing the addition of garbage symbols, like here (comments by > tr (6th & 8th comment(most visible in 8th))): > http://www.nezinau.lt/microsoft-lazerines-peles-sugeba-nustebinti#comments > Backspace? Looks like it. I pasted a random chunk of text ending in a non-ASCII character into a textarea with a form submitting as UTF-8. "mink?" became "mink%C5%A1" in the submitted data, which I believe is right. Then I pressed backspace in the textarea, leaving "mink", and submitted again. Now it submits "mink%A1", which is wrong. Input type=text doesn't seem to have the problem. Probably something wrong in fltk's TextEditor, then. I'll see if I can find where it's missing some utf8-awareness.

Oct. 23, 2008

css

by Johannes.Hofmann＠gmx.de

On Wed, Oct 22, 2008 at 10:33:44PM +0000, corvid wrote: > Johannes wrote: > > This approach has some issues. In contrast to > > http://www.dillo.org/CSS.html it would only be possible to apply > > style information that is available when starting parsing of a > > document. However we could start rendering with what style > > information is available and reload once all css files have been > > loaded. > > So is the idea that your method is more lightweight and a > repush() once the CSS arrives looks the same as applying > the CSS on the fly? That's the idea. > > If this is deemed superior, there might be things we could rip out of > dw that were written with the other scheme in mind. > No, I don't think this is superior. However, we need to be able to apply available styles while parsing anyway. So I would start coding that. And maybe this together with the repush thing gives acceptable behaviour already. Cheers, Johannes

Oct. 23, 2008

Garbage chars added

by francis＠daoine.org

On Thu, Oct 23, 2008 at 03:52:56PM +0300, Tomas R wrote: > On Thu, 23 Oct 2008 13:43:04 +0100 > Francis Daly <francis(a)daoine.org> wrote: > > On Thu, Oct 23, 2008 at 02:34:10PM +0300, Tomas R wrote: Hi there, > > > What's causing the addition of garbage symbols, like here (comments > > > by tr (6th & 8th comment(most visible in 8th))): > > > http://www.nezinau.lt/microsoft-lazerines-peles-sugeba-nustebinti#comments > > > Backspace? > > If you're asking "did dillo put it there previously when uploading a > > comment", that's something I can't answer easily -- perhaps capturing > > the network traffic when uploading will show whether it is in dillo's > > output; if so, more investigation will be needed to find why. > > I am asking WHY dillo put them there. The comments containing > garbage symbols were submitted by me with dillo2 and I think I used > Backspace where the garbage chars are added (check the page with some > full blown browser). I've taken a local copy of the html page, modified the form so that it points to a local "echo all input" cgi script, and I do not see any extra characters added. I've pasted in some of the (accented) text from the main page; I've deleted and backspaced and added my own text within dillo; and when I press "Tinka!", I see nothing unusual in the bytes returned by my "echo" script. I presume that means there's nothing unusual in the bytes sent by dillo. Right now, I can't reproduce the problem you're reporting. Can you provide a reproduction recipe? Preferably one that can be run using a local web server, so that we won't be adding unnecessary test comments to someone's live site. The garbage characters on the page aren't all the same character. Presumably either dillo is adding in the rubbish, or is misinterpreting the bytes written in the comment, or else the receiving side is somehow breaking things. When we can see the bytes being sent by dillo, we'll know which half (sender/receiver) is broken. Good luck, f -- Francis Daly francis(a)daoine.org

Oct. 23, 2008

Garbage chars added

by francis＠daoine.org

On Thu, Oct 23, 2008 at 02:34:10PM +0300, Tomas R wrote: > What's causing the addition of garbage symbols, like here (comments by > tr (6th & 8th comment(most visible in 8th))): > http://www.nezinau.lt/microsoft-lazerines-peles-sugeba-nustebinti#comments > Backspace? The page is claimed to be UTF-8, but it contains 6 invalid byte sequences (according to wc). So, there's garbage in the HTML which is interpreted as garbage. Dillo shows it because it is there. If you're asking "did dillo put it there previously when uploading a comment", that's something I can't answer easily -- perhaps capturing the network traffic when uploading will show whether it is in dillo's output; if so, more investigation will be needed to find why. Good luck, f -- Francis Daly francis(a)daoine.org

Oct. 23, 2008

Garbage chars added

by sandshrew＠gmail.com

What's causing the addition of garbage symbols, like here (comments by tr (6th & 8th comment(most visible in 8th))): http://www.nezinau.lt/microsoft-lazerines-peles-sugeba-nustebinti#comments Backspace? -- Brain: an apparatus with which we think we think. - A. Bierce

Oct. 23, 2008

pasting URL

by thomas-forum＠orgis.org

Am Wed, 22 Oct 2008 22:46:52 +0100 schrieb higuita <higuita7(a)yahoo.co.uk>: > you can already paste a URL to the X icon in the urlbar and it > will load... Indeed. Good to know. > the midle click on the body is reserved to dragging the page Now that's funny. I have my middle button configured to emulate scroll wheels when pressed+dragging (EmulateWheel option in Xorg config). This is kindof convenient in all around X11, especiall with a trackpoint or trackball... The funny part is that this Xorg feature hides the middle click + dragging action from dillo -- it gets vertical and horizontal scroll events instead, while the single middle click that could paste the URL (let through by Xorg, because of EmulateWheelclickToo) is blocked from that by dillo, which prepares for movement of the mouse -- which is impossible to get in this config. So an unreachable feature of dillo (dragging) makes a different expected feature (middle-click pasting into window) unreachable. I envision making this configurable in dillo (deactivate dragging to activate pasting)... or recreate the EmulateWheelclickToo behaviour to use the isolated click for the differing action. But that being said -- this is a really minor issue compared to CSS support. Alrighty then, Thomas. PS: As a side note: dillo does not handle the horizontal scroll events:-( This is a more major issue than middle-click pasting, 'cause I got really used to 2D scrolling. I hope FTLK2 doesn't just swallow these.

Oct. 23, 2008

pasting URL

by onepoint＠starurchin.org

On Wed, Oct 22, 2008 at 10:46:52PM +0100, higuita wrote: > you can already paste a URL to the X icon in the urlbar and it > will load... So it does! That's neat! Regards, Jeremy Henty [not the OP, BTW]

Oct. 23, 2008

css

by corvid＠lavabit.com

Johannes wrote: > This approach has some issues. In contrast to > http://www.dillo.org/CSS.html it would only be possible to apply > style information that is available when starting parsing of a > document. However we could start rendering with what style > information is available and reload once all css files have been > loaded. So is the idea that your method is more lightweight and a repush() once the CSS arrives looks the same as applying the CSS on the fly? If this is deemed superior, there might be things we could rip out of dw that were written with the other scheme in mind.

Oct. 23, 2008

More love for Dillo2!

by onepoint＠starurchin.org

Linux Today linked to this: TuxArena: Dillo 2.0 Gets Tabbed Browsing http://tuxarena.blogspot.com/2008/10/dillo-20-gets-tabbed-browsing.html Regards, Jeremy Henty

Oct. 23, 2008

pasting URL

by higuita7＠yahoo.co.uk

Hi On Wed, 22 Oct 2008 21:00:57 +0200, Thomas Orgis <thomas-forum(a)orgis.org> wrote: > I'm wondering if it would be difficult to add a neat little feature > that other browsers usuall implement: > X11 Mouse-mid-click pasting of an url in the body of the dillo window > as a shortcut to x-ing the url field and pasting there, then type enter. you can already paste a URL to the X icon in the urlbar and it will load... the midle click on the body is reserved to dragging the page cya higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946

Oct. 22, 2008

dillo-2.0 compilation failure

by jcid＠dillo.org

On Wed, Oct 22, 2008 at 12:09:10AM +0200, Ben de Groot wrote: > Jorge Arellano Cid wrote: > > On Tue, Oct 21, 2008 at 07:39:51PM +0200, Ben de Groot wrote: > > >> % grep inbuf_t work/dillo-2.0/config.log > >> #define inbuf_t const char > > > > It looks like the test in configure.in detects iconv() in > > a strange way. > > Indeed, something seems to go wrong there. My glibc version is > 2.8_p20080602. > > > What's inconv's signature in your OS? > > extern size_t iconv (iconv_t __cd, char **__restrict __inbuf, > size_t *__restrict __inbytesleft, > char **__restrict __outbuf, > size_t *__restrict __outbytesleft); > > > Just for testing try setting [char] instead of [const char] in > > configure.in:348. Although I don't yet get confirmation on the above test, please test current CVS. There's a try-patch there. If it works, just let me know. -- Cheers Jorge.-

Oct. 22, 2008

[patch]: change the default tab label to "Dillo"

by jcid＠dillo.org

On Wed, Oct 22, 2008 at 04:36:42PM +0200, Johannes Hofmann wrote: > On Tue, Oct 21, 2008 at 09:12:02PM +0000, corvid wrote: > > Jorge wrote: > > > On Mon, Oct 20, 2008 at 12:21:49PM +0100, Jeremy Henty wrote: > > > > > > > > *ahem*, replying to myself. > > > > > > > > > ... I think it looks a little sad when a new tab pops up with the > > > > > pointless label "Label", so I changed it to "Dillo". > > > > > > > > No comments on this? It seems to have vanished without trace. > > > > > > It doesn't seem to make much difference (and we have no > > > comments so far). > > > > > > Although I see one point with the "Label" label ;), > > > it suggests that there goes a label that's yet unset. > > > > I didn't say anything because I didn't care too much, > > but I suppose I like Dillo better than Label. > > Same here. Committed. -- Cheers Jorge.-

Oct. 22, 2008

pasting URL

by thomas-forum＠orgis.org

Hi there, I'm wondering if it would be difficult to add a neat little feature that other browsers usuall implement: X11 Mouse-mid-click pasting of an url in the body of the dillo window as a shortcut to x-ing the url field and pasting there, then type enter. ...or does someone already have a patch handy? ;-) And: Don't let you be distracted from CSS support by this... Alrighty then, Thomas.

Oct. 22, 2008

issues & suggestions

by jcid＠dillo.org

On Sun, Oct 19, 2008 at 06:19:30PM +0300, Tomas R wrote: > > > [...] > > > 2) With the latest dillo2 version (I think this bug was introduced > > > only recently, as I tested dillo2 from cvs not so long ago & it > > > wasn't present) the menu is "teared off" when pressed. Here is a > > > screenshot: > > > http://img410.imageshack.us/img410/5211/dillomenuxu9.png > > > and dillorc I use: > > > http://pastebin.com/f42244f75 > > > > Not a bug but a feature! > > > > The detached menu allows for two things: > > > > 1.- Popup menu working with Alt-F shortcut even when the "File" > > item is hidden. > > 2.- Simpler code and improved panel configuraion flexibility. > Even from dev's perspective it might seem as a feature but from user's > - it's an ugly bug. Please try current CVS. -- Cheers Jorge.-

Oct. 22, 2008

css

by Johannes.Hofmann＠gmx.de

Hi, here comes my proposal to get css support started. Note that I'm new to this stuff so I will probabely simplify things a lot and miss many issues that will have to be addressed later on. * Separate out the style handling from html.cc in a new class StyleEngine (better name welcome). This class will be fed the html tree via a SAX like interface as the document is parsed and will hand out the current Style object. * Initially StyleEngine will be implemented to just mimic the current behaviour of html.cc. So after this step everything should work as currently. * Then we can design the data structures to hold parsed css data and make StyleEngine use these structures which will be statically filled initially. Again dillo should work as it does now. * Next we can implement a css parser that is able to fill the data structures from the last step. Now we should already be able to set a fixed user style sheet. * Hooking up the css parser to automatically load css information as referenced in html pages would be next. * In parallel to all this we would need to make floating objects work in dw/textblock.cc. This approach has some issues. In contrast to http://www.dillo.org/CSS.html it would only be possible to apply style information that is available when starting parsing of a document. However we could start rendering with what style information is available and reload once all css files have been loaded. Currently dillo parses attributes on demand. So we don't have a complete list of attributes and their values. As StyleEngine might access any attribute, we might need to change this. Comments or more advanced plans would be more than welcome! Cheers, Johannes

Oct. 22, 2008

patch: prefs.vw_fontname as fltk ui's default font

by Johannes.Hofmann＠gmx.de

On Wed, Oct 22, 2008 at 04:09:42PM +0000, corvid wrote: > Johannes wrote: > > On Wed, Oct 22, 2008 at 02:27:23PM +0000, corvid wrote: > > > I was changing the font in a few more places that > > > can take arbitrary user text -- and then having > > > to change it for neighbouring things so that > > > the difference isn't too jarring -- and I reached > > > the point where it seemed like it may be best > > > just to change the font for everything. > > > > > > > I like it! > > We could also remove the places where the font has been set already. > > Yeah, I figured I'd rip out the existing ones later in a patch to Jorge > if this one goes over well. (except source, which I'm accustomed to seeing > in a fixed-width font) > > For me, there's no change by default because dejavu sans is my default > sans-serif font in fontconfig and I use it for dillo unless I want to > view Asian characters for some reason. > > > PS: In case someone needs it we could add a ui font option in dillorc > > and default to fw_fontname. > > Why fw? I meant vw...

Oct. 22, 2008

patch: prefs.vw_fontname as fltk ui's default font

by corvid＠lavabit.com

Johannes wrote: > On Wed, Oct 22, 2008 at 02:27:23PM +0000, corvid wrote: > > I was changing the font in a few more places that > > can take arbitrary user text -- and then having > > to change it for neighbouring things so that > > the difference isn't too jarring -- and I reached > > the point where it seemed like it may be best > > just to change the font for everything. > > > > I like it! > We could also remove the places where the font has been set already. Yeah, I figured I'd rip out the existing ones later in a patch to Jorge if this one goes over well. (except source, which I'm accustomed to seeing in a fixed-width font) For me, there's no change by default because dejavu sans is my default sans-serif font in fontconfig and I use it for dillo unless I want to view Asian characters for some reason. > PS: In case someone needs it we could add a ui font option in dillorc > and default to fw_fontname. Why fw?

Oct. 22, 2008

patch: prefs.vw_fontname as fltk ui's default font

by Johannes.Hofmann＠gmx.de

On Wed, Oct 22, 2008 at 02:27:23PM +0000, corvid wrote: > I was changing the font in a few more places that > can take arbitrary user text -- and then having > to change it for neighbouring things so that > the difference isn't too jarring -- and I reached > the point where it seemed like it may be best > just to change the font for everything. > I like it! We could also remove the places where the font has been set already. Cheers, Johannes PS: In case someone needs it we could add a ui font option in dillorc and default to fw_fontname.

Oct. 22, 2008

dillo-2.0 compilation failure

by Johannes.Hofmann＠gmx.de

On Wed, Oct 22, 2008 at 08:44:48AM -0300, Jorge Arellano Cid wrote: > On Wed, Oct 22, 2008 at 12:09:10AM +0200, Ben de Groot wrote: > > Jorge Arellano Cid wrote: > > > On Tue, Oct 21, 2008 at 07:39:51PM +0200, Ben de Groot wrote: > > > > >> % grep inbuf_t work/dillo-2.0/config.log > > >> #define inbuf_t const char > > > > > > It looks like the test in configure.in detects iconv() in > > > a strange way. > > > > Indeed, something seems to go wrong there. My glibc version is > > 2.8_p20080602. > > > > > What's inconv's signature in your OS? > > > > extern size_t iconv (iconv_t __cd, char **__restrict __inbuf, > > size_t *__restrict __inbytesleft, > > char **__restrict __outbuf, > > size_t *__restrict __outbytesleft); > > OK. > > A "char **" not a "const char **". > > > > Just for testing try setting [char] instead of [const char] in > > > configure.in:348. > > > > In our bugtracker another patch was proposed, which makes dillo compile > > for me. https://bugs.gentoo.org/show_bug.cgi?id=242774 > > > > --- src/form.cc 2008-10-21 21:02:31 +0000 > > +++ src/form.cc 2008-10-21 21:02:53 +0000 > > @@ -1240,8 +1240,9 @@ > > int rc = 0; > > Dstr *output; > > const int bufsize = 128; > > - inbuf_t *inPtr; > > - char *buffer, *outPtr; > > + //inbuf_t *inPtr; > > + //char *buffer, *outPtr; > > + char *buffer, *outPtr, *inPtr; > > size_t inLeft, outRoom; > > bool bad_chars = false; > > > > Does this patch look good to you? > > No. > > It seems to be enough for Gentoo, but I'd prefer to detect the > type of inbuf_t correctly in configure.in, so it compiles out of > the box. One could think that using char* for inPtr would work for both cases (char ** and const char ** in the declaration of iconv), but it doesn't: void test(const char **s) {}; int main(int argc, char **argv) { char *s; test(&s); } fails with const.cc: In function 'int main(int, char**)': const.cc:5: error: invalid conversion from 'char**' to 'const char**' const.cc:5: error: initializing argument 1 of 'void test(const char**)' See e.g. http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.17 for the reason why this does not work. Cheers, Johannes

Oct. 22, 2008

[patch]: change the default tab label to "Dillo"

by Johannes.Hofmann＠gmx.de

On Tue, Oct 21, 2008 at 09:12:02PM +0000, corvid wrote: > Jorge wrote: > > On Mon, Oct 20, 2008 at 12:21:49PM +0100, Jeremy Henty wrote: > > > > > > *ahem*, replying to myself. > > > > > > > ... I think it looks a little sad when a new tab pops up with the > > > > pointless label "Label", so I changed it to "Dillo". > > > > > > No comments on this? It seems to have vanished without trace. > > > > It doesn't seem to make much difference (and we have no > > comments so far). > > > > Although I see one point with the "Label" label ;), > > it suggests that there goes a label that's yet unset. > > I didn't say anything because I didn't care too much, > but I suppose I like Dillo better than Label. Same here. Cheers, Johannes

Oct. 22, 2008

patch: prefs.vw_fontname as fltk ui's default font

by corvid＠lavabit.com

I was changing the font in a few more places that can take arbitrary user text -- and then having to change it for neighbouring things so that the difference isn't too jarring -- and I reached the point where it seemed like it may be best just to change the font for everything.

Oct. 22, 2008

dillo-2.0 compilation failure

by jcid＠dillo.org

On Wed, Oct 22, 2008 at 12:09:10AM +0200, Ben de Groot wrote: > Jorge Arellano Cid wrote: > > On Tue, Oct 21, 2008 at 07:39:51PM +0200, Ben de Groot wrote: > > >> % grep inbuf_t work/dillo-2.0/config.log > >> #define inbuf_t const char > > > > It looks like the test in configure.in detects iconv() in > > a strange way. > > Indeed, something seems to go wrong there. My glibc version is > 2.8_p20080602. > > > What's inconv's signature in your OS? > > extern size_t iconv (iconv_t __cd, char **__restrict __inbuf, > size_t *__restrict __inbytesleft, > char **__restrict __outbuf, > size_t *__restrict __outbytesleft); OK. A "char **" not a "const char **". > > Just for testing try setting [char] instead of [const char] in > > configure.in:348. > > In our bugtracker another patch was proposed, which makes dillo compile > for me. https://bugs.gentoo.org/show_bug.cgi?id=242774 > > --- src/form.cc 2008-10-21 21:02:31 +0000 > +++ src/form.cc 2008-10-21 21:02:53 +0000 > @@ -1240,8 +1240,9 @@ > int rc = 0; > Dstr *output; > const int bufsize = 128; > - inbuf_t *inPtr; > - char *buffer, *outPtr; > + //inbuf_t *inPtr; > + //char *buffer, *outPtr; > + char *buffer, *outPtr, *inPtr; > size_t inLeft, outRoom; > bool bad_chars = false; > > Does this patch look good to you? No. It seems to be enough for Gentoo, but I'd prefer to detect the type of inbuf_t correctly in configure.in, so it compiles out of the box. Please try the tweak-test in configure.in. If it works, we'll be sure proper detection will fix the bug. -- Cheers Jorge.-

Oct. 22, 2008

dillo-2.0 compilation failure

by yngwin＠gentoo.org

Jorge Arellano Cid wrote: > On Tue, Oct 21, 2008 at 07:39:51PM +0200, Ben de Groot wrote: >> % grep inbuf_t work/dillo-2.0/config.log >> #define inbuf_t const char > > It looks like the test in configure.in detects iconv() in > a strange way. Indeed, something seems to go wrong there. My glibc version is 2.8_p20080602. > What's inconv's signature in your OS? extern size_t iconv (iconv_t __cd, char **__restrict __inbuf, size_t *__restrict __inbytesleft, char **__restrict __outbuf, size_t *__restrict __outbytesleft); > Just for testing try setting [char] instead of [const char] in > configure.in:348. In our bugtracker another patch was proposed, which makes dillo compile for me. https://bugs.gentoo.org/show_bug.cgi?id=242774 --- src/form.cc 2008-10-21 21:02:31 +0000 +++ src/form.cc 2008-10-21 21:02:53 +0000 @@ -1240,8 +1240,9 @@ int rc = 0; Dstr *output; const int bufsize = 128; - inbuf_t *inPtr; - char *buffer, *outPtr; + //inbuf_t *inPtr; + //char *buffer, *outPtr; + char *buffer, *outPtr, *inPtr; size_t inLeft, outRoom; bool bad_chars = false; Does this patch look good to you? It looks like this issue doesn't pop up with glibc-2.6.1, which is our stable version. But obviously, I'd like it to work on our testing branch as well. Cheers, -- Ben de Groot Gentoo Linux developer (lxde, media, desktop-misc) Gentoo Linux Release Engineering PR liaison __________________________________________________ yngwin(a)gentoo.org http://ben.liveforge.org/ irc://chat.freenode.net/#gentoo-media irc://irc.oftc.net/#lxde __________________________________________________

Oct. 22, 2008

[patch]: change the default tab label to "Dillo"

by corvid＠lavabit.com

Jorge wrote: > On Mon, Oct 20, 2008 at 12:21:49PM +0100, Jeremy Henty wrote: > > > > *ahem*, replying to myself. > > > > > ... I think it looks a little sad when a new tab pops up with the > > > pointless label "Label", so I changed it to "Dillo". > > > > No comments on this? It seems to have vanished without trace. > > It doesn't seem to make much difference (and we have no > comments so far). > > Although I see one point with the "Label" label ;), > it suggests that there goes a label that's yet unset. I didn't say anything because I didn't care too much, but I suppose I like Dillo better than Label. I think what I'd expect as a user is for it to be blank if the page doesn't contain anything yet.

Oct. 21, 2008

dillo-2.0 compilation failure

by jcid＠dillo.org

On Tue, Oct 21, 2008 at 07:39:51PM +0200, Ben de Groot wrote: > corvid wrote: > >> form.cc: In member function ???Dstr* DilloHtmlForm::encodeText(void*, > >> Dstr**)???: > >> form.cc:1261: error: invalid conversion from ???const char**??? to ???char**??? > >> form.cc:1261: error: initializing argument 2 of ???size_t iconv(void*, > >> char**, size_t*, char**, size_t*)??? > > > Did you run configure yourself? What type does inbuf_t have in config.log? > > yes, I ran configure first, with: > ./configure --prefix=/usr --host=i686-pc-linux-gnu > --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share > --sysconfdir=/etc --localstatedir=/var/lib --enable-gif --disable-ipv6 > --enable-jpeg --enable-png --enable-ssl --build=i686-pc-linux-gnu > > > % grep inbuf_t work/dillo-2.0/config.log > #define inbuf_t const char It looks like the test in configure.in detects iconv() in a strange way. What's inconv's signature in your OS? Just for testing try setting [char] instead of [const char] in configure.in:348. -- Cheers Jorge.-

Oct. 21, 2008

[patch]: change the default tab label to "Dillo"

by jcid＠dillo.org

On Mon, Oct 20, 2008 at 12:21:49PM +0100, Jeremy Henty wrote: > > *ahem*, replying to myself. > > > ... I think it looks a little sad when a new tab pops up with the > > pointless label "Label", so I changed it to "Dillo". > > No comments on this? It seems to have vanished without trace. It doesn't seem to make much difference (and we have no comments so far). Although I see one point with the "Label" label ;), it suggests that there goes a label that's yet unset. -- Cheers Jorge.-

Oct. 21, 2008

dillo-2.0 compilation failure

by corvid＠lavabit.com

Ben wrote: > corvid wrote: > >> form.cc: In member function ?Dstr* DilloHtmlForm::encodeText(void*, > >> Dstr**)?: > >> form.cc:1261: error: invalid conversion from ?const char**? to ?char**? > >> form.cc:1261: error: initializing argument 2 of ?size_t iconv(void*, > >> char**, size_t*, char**, size_t*)? > > > Did you run configure yourself? What type does inbuf_t have in config.log? > > yes, I ran configure first, with: > ./configure --prefix=/usr --host=i686-pc-linux-gnu > --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share > --sysconfdir=/etc --localstatedir=/var/lib --enable-gif --disable-ipv6 > --enable-jpeg --enable-png --enable-ssl --build=i686-pc-linux-gnu > > > % grep inbuf_t work/dillo-2.0/config.log > #define inbuf_t const char Hmm... A minute with google teaches me that gentoo people run into problems when system versions of things conflict with portage versions, but then I don't know enough to have any idea whether our config test would be picking up the wrong one for some reason...

Oct. 21, 2008

dillo-2.0 compilation failure

by akemnade＠tzi.de

On Tue, 21 Oct 2008 19:39:51 +0200 Ben de Groot <yngwin(a)gentoo.org> wrote: > corvid wrote: > >> form.cc: In member function ?Dstr* DilloHtmlForm::encodeText(void*, > >> Dstr**)?: > >> form.cc:1261: error: invalid conversion from ?const char**? to ?char**? > >> form.cc:1261: error: initializing argument 2 of ?size_t iconv(void*, > >> char**, size_t*, char**, size_t*)? > > > Did you run configure yourself? What type does inbuf_t have in config.log? > > yes, I ran configure first, with: > ./configure --prefix=/usr --host=i686-pc-linux-gnu > --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share > --sysconfdir=/etc --localstatedir=/var/lib --enable-gif --disable-ipv6 > --enable-jpeg --enable-png --enable-ssl --build=i686-pc-linux-gnu > > > % grep inbuf_t work/dillo-2.0/config.log > #define inbuf_t const char > The iconv test is done with gcc in c-mode, form.cc in c++-mode. The first one might be less strict so the iconv test code in configure.in,configure does not produce errors. But -Wall should be added already to CFLAGS earlier.... Just some guesses. Greetings Andreas Kemnade

Oct. 21, 2008

dillo-2.0 compilation failure

by yngwin＠gentoo.org

corvid wrote: >> form.cc: In member function ?Dstr* DilloHtmlForm::encodeText(void*, >> Dstr**)?: >> form.cc:1261: error: invalid conversion from ?const char**? to ?char**? >> form.cc:1261: error: initializing argument 2 of ?size_t iconv(void*, >> char**, size_t*, char**, size_t*)? > Did you run configure yourself? What type does inbuf_t have in config.log? yes, I ran configure first, with: ./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-gif --disable-ipv6 --enable-jpeg --enable-png --enable-ssl --build=i686-pc-linux-gnu % grep inbuf_t work/dillo-2.0/config.log #define inbuf_t const char -- Ben de Groot Gentoo Linux developer (lxde, media, desktop-misc) Gentoo Linux Release Engineering PR liaison __________________________________________________ yngwin(a)gentoo.org http://ben.liveforge.org/ irc://chat.freenode.net/#gentoo-media irc://irc.oftc.net/#lxde __________________________________________________

Oct. 21, 2008

dillo-2.0 compilation failure

by corvid＠lavabit.com

Ben wrote: > Hi, > > I'm trying to get an ebuild together to get dillo-2.0 into Gentoo Linux' > portage repository. But compilation fails for me with: > > form.cc: In member function ?Dstr* DilloHtmlForm::encodeText(void*, > Dstr**)?: > form.cc:1261: error: invalid conversion from ?const char**? to ?char**? > form.cc:1261: error: initializing argument 2 of ?size_t iconv(void*, > char**, size_t*, char**, size_t*)? > make[3]: *** [form.o] Error 1 > > This is with gcc-4.3.2. If anybody could have a look at this and shed > some light on it (as I'm not a C++ coder myself), I would be grateful. Did you run configure yourself? What type does inbuf_t have in config.log?

Oct. 21, 2008

Heavy load on X

by Johannes.Hofmann＠gmx.de

On Tue, Oct 21, 2008 at 12:19:15PM +0000, corvid wrote: > furaisanjin wrote: > > I find the reason now. I selected this option. > > > > limit_text_width=YES > > > > I missed the comment just above. > > > > # *** NOT HOOKED UP YET *** > > > > So after I set NO on limit_text_width, the problem has disappeared. > > Oh! > You have still found something interesting because I added that > comment _not_ because it was known to break anything, but because > there is not enough limit_text_width code for it to have > much of an observable effect -- that is, I didn't want people to > be disappointed when they set the option and nothing happened. > > (Johannes will know, but...) maybe it's triggering queueResize()s in a loop. void Textblock::setWidth (int width) { /* If limitTextWidth is set to YES, a queue_resize may also be * necessary. */ if (availWidth != width || limitTextWidth) { looks like a candidate... But I have not seen a page where limit_text_width=YES makes a difference anyway. Cheers, Johannes

Oct. 21, 2008

dillo-2.0 compilation failure

by yngwin＠gentoo.org

Hi, I'm trying to get an ebuild together to get dillo-2.0 into Gentoo Linux' portage repository. But compilation fails for me with: form.cc: In member function ?Dstr* DilloHtmlForm::encodeText(void*, Dstr**)?: form.cc:1261: error: invalid conversion from ?const char**? to ?char**? form.cc:1261: error: initializing argument 2 of ?size_t iconv(void*, char**, size_t*, char**, size_t*)? make[3]: *** [form.o] Error 1 This is with gcc-4.3.2. If anybody could have a look at this and shed some light on it (as I'm not a C++ coder myself), I would be grateful. Regards, -- Ben de Groot Gentoo Linux developer (lxde, media, desktop-misc) Gentoo Linux Release Engineering PR liaison __________________________________________________ yngwin(a)gentoo.org http://ben.liveforge.org/ irc://chat.freenode.net/#gentoo-media irc://irc.oftc.net/#lxde __________________________________________________

Oct. 21, 2008

Heavy load on X

by corvid＠lavabit.com

furaisanjin wrote: > I find the reason now. I selected this option. > > limit_text_width=YES > > I missed the comment just above. > > # *** NOT HOOKED UP YET *** > > So after I set NO on limit_text_width, the problem has disappeared. Oh! You have still found something interesting because I added that comment _not_ because it was known to break anything, but because there is not enough limit_text_width code for it to have much of an observable effect -- that is, I didn't want people to be disappointed when they set the option and nothing happened. (Johannes will know, but...) maybe it's triggering queueResize()s in a loop.

Oct. 21, 2008

Heavy load on X

by corvid＠lavabit.com

furaisanjin wrote: > <button type="submit">search</button> Hmm... I wonder whether it has something to do with ComplexButton. Does the following cause the problem as well? <html> <head> <title>test</title> </head> <body> <form action="http://search.itmedia.co.jp/" method="GET"> <input name="img" type="image" src="http://www.dillo.org/main-small.jpg"> </form> </body> </html>

Oct. 21, 2008

Heavy load on X

by furaisanjin＠gmail.com

2008/10/21 Jeremy Henty <onepoint(a)starurchin.org>: > Just guessing, but is your fltk2 using cairo? That's been the cause > of other problems. no, I didn't add any option for fltk2. I find the reason now. I selected this option. limit_text_width=YES I missed the comment just above. # *** NOT HOOKED UP YET *** So after I set NO on limit_text_width, the problem has disappeared. Regards, furaisanjin

Oct. 21, 2008

Heavy load on X

by onepoint＠starurchin.org

On Mon, Oct 20, 2008 at 11:10:09PM +0900, ?$BIwPT;6?M wrote: > Hello all. > > I'm running dillo2 on FreeBSD 6.3. When I visit this page > http://www.itmedia.co.jp/bizid/, somehow Xorg occupies lot of > processing power and value of CPU in top command shows more than > 85%. Does anybody have an idea? What would be the reason? Just guessing, but is your fltk2 using cairo? That's been the cause of other problems. Regards, Jeremy Henty

Oct. 21, 2008

Heavy load on X

by furaisanjin＠gmail.com

Hello all. I was able to strip down the minimum HTML code which caused the problem. <html> <head> <title>test</title> </head> <body> <form action="http://search.itmedia.co.jp/" method="GET"> <button type="submit">search</button> </form> </body> </html> "search" is flicking on the dillo screen and I guess this causes the problem. Regards, furaisanjin

Oct. 21, 2008

Heavy load on X

by christopher.illies＠ki.se

On Tue, Oct 21, 2008 at 10:16:34AM +0000, corvid wrote: > Christopher wrote: > > I don't see that problem, using FreeBSD 7.1-PRERELEASE, but I don't > > get any redering of the japanise fonts in dillo either. This is > > on dillo-2.0. japanese/sazanami-ttf and fltk-2.0.r6305 are installed > > from ports. > > Are you setting vw_fontname and fw_fontname to use sazanami-gothic? Thank you, I was not aware of that. Now I get good rendering of the japanise fonts in both http://www.itmedia.co.jp/bizid/ and http://japan.cnet.com, but I don't see the heavy load on Xorg. > > PS fltk-2.0.r6403 contains various fixes. Yes, I know, but for now I go with what is available in the ports system. Christopher

Oct. 21, 2008

Heavy load on X

by corvid＠lavabit.com

Christopher wrote: > On Mon, Oct 20, 2008 at 06:34:32PM +0200, Johannes Hofmann wrote: > > On Tue, Oct 21, 2008 at 12:02:53AM +0900, ???? wrote: > > > Yes, as long as I see this page, CPU usage is high. I don't do > > > anything else but just see the page. > [...] > > > I used sazanami-gothic to see Japanese. I change font to times then > > > CPU usage became about 67%. > [...] > > > > PS: Anyone else on the list using FreeBSD? > > I don't see that problem, using FreeBSD 7.1-PRERELEASE, but I don't > get any redering of the japanise fonts in dillo either. This is > on dillo-2.0. japanese/sazanami-ttf and fltk-2.0.r6305 are installed > from ports. Are you setting vw_fontname and fw_fontname to use sazanami-gothic? PS fltk-2.0.r6403 contains various fixes.

Oct. 21, 2008

Heavy load on X

by christopher.illies＠ki.se

On Mon, Oct 20, 2008 at 06:34:32PM +0200, Johannes Hofmann wrote: > On Tue, Oct 21, 2008 at 12:02:53AM +0900, ???? wrote: > > Yes, as long as I see this page, CPU usage is high. I don't do > > anything else but just see the page. [...] > > I used sazanami-gothic to see Japanese. I change font to times then > > CPU usage became about 67%. [...] > > PS: Anyone else on the list using FreeBSD? I don't see that problem, using FreeBSD 7.1-PRERELEASE, but I don't get any redering of the japanise fonts in dillo either. This is on dillo-2.0. japanese/sazanami-ttf and fltk-2.0.r6305 are installed from ports. Christopher

Oct. 21, 2008

Heavy load on X

by furaisanjin＠gmail.com

Sorry, I replied to you rather than sent to mailing list. 2008/10/21 Johannes Hofmann <Johannes.Hofmann(a)gmx.de>: > Can you try to run dillo with xtrace as described in > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-September/004911.ht… > (at the end). > xtrace will output a lot. What I'm interested in is the output after > the page has loaded. xtrace output was quite fast and I can't tell when the page is loaded. So I attached a log from start to end. The log file is here http://proxy.f3.ymdb.yahoofs.jp/bc/35859833/bc/log.gz?bcSfR_IBM5W5sefZ I found another page http://japan.cnet.com. This page causes the problem. Regards, furaisanjin

Oct. 21, 2008

patch: a quick and ugly source searcher

by corvid＠lavabit.com

- TextBuffer also has search_backward and a matchCase argument. - show_insert_position() often doesn't want to scroll quite far enough to bring the text into view.

Oct. 21, 2008