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

experimental patch: Re: dillo2 wrapping Chinese
by corvid＠lavabit.com 06 Jun '09

06 Jun '09

dillo people: It turns out that dillo handles Chinese quite badly because the text doesn't contain whitespace (BUG 827). It looks like Japanese is that way as well. 1) People using East Asian languages: Does this do roughly the right thing? I've read that there are picky rules about certain individual characters, but I just mean in general here. 2) Thoughts on optimization are welcomed. littlebat: For some reason, I was thinking that whitespace was required between words in dillo, but I misremembered. littlebat wrote: > Hi, > Thanks for the work on Dillo. > > I think it isn't a good idea to resolve long chinese line wrapping > problem by inserting space after punctuation mark("?" or "?" or "?", > etc..). > > Here is a "Dillo2 Wrap Long Chinese Line Test" page: > http://www.learndiary.com/en/dillo2-wrap-long-chinese-line-test.htm . > Open it with Firefox or IE, then open it with Dillo2, You will see the > different of wrapping long chinese line between them. > > Note, unlike english, there is no space between Chinese characters. So, > it should be wrapped after any Chinese character which has reached the > end of a line. I don't know the technique detail about this, but, I > think, let the Chinese characters function as (english) commas or > periods is a good idea, so, a new line can be started after any Chinese > charcter which character has reached the end of a line. > > littlebat > > http://www.learndiary.com/en/ > > > corvid wrote: > >Would it make things better or worse than it is now if I inserted a > >space when encountering a "?" or "?" so that dillo would know > >that it can wrap there? If that doesn't show up properly, > >I mean the characters that function as commas and periods. > > > >(I'm trying to think of something simple that will at least help you > > somewhat without having to make big changes right now :) > > I realize that it _should_ be able to wrap after most CJK characters, > > but...) > > > >It could be worse because > >1) Those spaces would still be there if you were copying and pasting > > the text to something else. > >2) If you wanted to search a page for "text?text", you would have to > > enter "text? text" with a space in there.

3 10

FreeHG performance
by onepoint＠starurchin.org 05 Feb '09

05 Feb '09

Am I the only one getting very poor performance from FreeHG ? Quite often I get a 404 Not Found and right now it's hanging. Everyone confirms that Mercurial itself is really fast and I've seen other reports criticising FreeHG's performance. Perhaps we should think about moving host? It's not always easy to find time to devote to Dillo so it's rather aggravating when that time is wasted just waiting for a connection to the server. I'm committed enough to grit my teeth and wait but I can see it putting off would-be contributors. Just a thought, Jeremy Henty

5 14

Bad character coding for www.blisty.cz
by newman.x＠gmail.com 03 Feb '09

03 Feb '09

Hi, I am affraid there ocurred regression in post-dillo-2.0 when compared to dillo-2.0. Look on the www.blisty.cz web page, on the top there's following sence (it's in Czech) "?t?te Britsk? listy speci?ln? upraven? pro va?e mobiln? telefony a PDA" but in current hg tip it's displayed as "?t?te Britsk? listy speci?ln? upraven? pro va?e mobiln? telefony a PDA" and of course, the whole page is displayed like in ISO-8859-1 coding. I noticed this first when the character coding code in post-dillo-2.0 was changed. When the page is saved to disk and opened it works as expected. It appeared that it is somehow related to default dillorc. 1) remove the ~/.dillo directory 2) dillo www.blisty.cz 3) --> PASS 4) quit dillo 5) dillo www.blisty.cz 6) --> FAIL Can anyone, please, have a look at this and say whether is it reproducible and, perhaps, fix it? :) Thanks, -- Regards, Michal Nowak

4 10

What's left to do for dillo-2.1?
by onepoint＠starurchin.org 01 Feb '09

01 Feb '09

I get the feeling we are close to releasing dillo-2.1. Do others agree? What's left to be done? Regards, Jeremy Henty

4 11

CSS branch merged!
by jcid＠dillo.org 31 Jan '09

31 Jan '09

Hi there, The CSS branch was merged back into main! It has been stabilized and we can continue working from this basis towards our next release. I want to thank all of you involved in helping this happen. Having basic CSS support merged in, is quite an achievement! :-) -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

6 29

Window icon
by jcid＠dillo.org 31 Jan '09

31 Jan '09

Hi, Does anyone feel like hooking the small dillo icon to its window? http://fltk.org/newsgroups.php?s18335+gfltk.general+v18348+T1 -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

1 0

Re: Dillo Source code
by jcid＠dillo.org 31 Jan '09

31 Jan '09

Hi Jo?o, On Fri, Jan 30, 2009 at 09:38:18PM +0000, Jo?o Ricardo Louren?o wrote: > > > > I have never worked with tabs in FLTK, but I've been browsing the > > > documentation and have been trying to understand them. As for the > > > button, I've nearly got it, the only problem is finding a way to prevent > > > tabs from going over the button and that doesn't seem to be happening. > > > An alternative would be to have the button in the 'tool-bar' or limit > > > the number of tabs (doesn't seem nice right?). I'm trying to figure out > > > pagers to set some kind of limit... > > > > The button outside the tab-labels area would be confusing... > > > > > One other problem seems to be the fact that the button keeps resizing, > > > that's probably bad FLTK coding on my side, let's hope I can figure it > > > out. > > > > FLTK-2.0 widgets have a handle() method that handles events. > > They also have a draw() method that draws the widget. My first > > idea was to draw the button in the draw() method of the pager, > > and to hook its functionality in the handle() method. > > This is the way I'd explore. > > > > The canonical way would be to try to add a child button widget > > in the pager. It may not be possible though. > > Yes, I did try to think of adding a button widget in the pager, though > digging with the pager itself is quite a mess I'm trying to work out. > For now, I'm trying to move my hackish code into CustTabGroup and the > problem is that I can't seem to get the tab height... > > What I am doing (for now, which still suffers from the resizing bug, > since I did not touch pagers) is adding an fltk::Button, positioning it > correctly and making it visible. In order to have it visible I add() it > to the parent of a CustTabGroup instance (a UI, I believe), and this UI > is the one that resizes it, I should figure out a way of preventing > that. Is there another way of making it visible, not having it resize? > It's something I never dug before. I don't know why it is resizing. FLTK2 widgets need an explicit resize() call to enable it. Although there're exceptions. If you add it with a fixed size int the UI that should be it. > Adding a child button widget in the pager seems difficult in the 'real' > meaning of the word 'add'. As a pager isn't a group that seems > difficult, unless I do not use a widget but draw() it myself and then > handle() it correctly. Yes, the second option is where I'd start. There's the fltk.general forum for question like this: http://fltk.org/newsgroups.php?gfltk.general+T I haven't tried there yet and it would be interseting to know their advice. > > On to another issue. > > > > Browsing the code I noticed: > // WORKAROUND: limit the number of tabs because of a fltk bug > if (ui->tabs()->children() >= 127) > > And, then, browsing the FLTK code I found: > > static int p[128]; > ... > void TabGroup::draw() { > ... > int w[128]; > ... //code using w and p... > > I guess the problem is p being limited to 128...Probably fixing this > issue has been discussed earlier, but a hipothesis would be overriding > Fltk's code for TabGroup, anyway, that doesn't seem nice. Maybe we could > ask the FLTK people to change it, if they agreed with it. Having more > than 127 tabs open seems impossible but we never know. FLTK2 is beong stalled for some time now. The team is focused on the 1.3.x branch. I wouldn't expect a patch unless we send it to them. At some point in the future we may be switching to 1.3.x. (they seem to want to develop a compatibility layer for FLTK-2.0, so ATM it's better to wait). I'd focus on the close-tab issue. ;) -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

1 0

Still leaking CSS values
by onepoint＠starurchin.org 30 Jan '09

30 Jan '09

The "0123456789" value in the stylesheet leaks. Test case and valgrind log attached. Regards, Jeremy Henty

2 2

<ol>'s leak the labels of their items
by onepoint＠starurchin.org 29 Jan '09

29 Jan '09

Valgrind reports that <ol>s leak the labels of their items: each of the first 9 <li>s leaks 3 bytes, then they leak 4 bytes per <li> etc. The leaked memory is created by the line list_item->initWithText (dStrdup(buf), wordStyle); in Html_tag_open_li (in src/html.cc). The dStrdup()ed memory is never freed. I think that the problem is that the TextBlock destructor only deletes the content of a word if the content type is WIDGET or ANCHOR, whereas it should also handle the case when the content type is TEXT. Perhaps initWithText() should copy the string argument itself with new[] so that ~TextBlock could safely delete[] it? The only two references to initWithText() are in html.cc and one of the widget tests, so this would be an easy change. Regards, Jeremy Henty

3 20

dw::Image objects leak their mapKey
by onepoint＠starurchin.org 29 Jan '09

29 Jan '09

This shows up under valgrind as a leak when the HTML includes an <img usemap="...">. Patch attached. Regards, Jeremy Henty

2 3