- Dillo-dev - lists.mailman3.com

Re: unused parameter warning in http.c
by jcid＠dillo.org Feb. 1, 2009

Feb. 1, 2009

On Sat, Jan 31, 2009 at 10:09:28PM +0000, corvid wrote: > surprised me until I remembered that you turned on -W. > I didn't realize that plain C doesn't allow the name > to be left off in those cases. > > What is the usual trick for this? The manpage talks > about an 'unused' attribute, but that sounds like a gcc-ism. In the past, for C, I've used these couple: 1.- Add a dummy test for the unused var. 2.- Remove the parameter from the function and cast it to match. -- 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

[Patch]: fix URL leak in Html_tag_open_link()
by onepoint＠starurchin.org Feb. 1, 2009

Feb. 1, 2009

If Html_tag_open_link() gets a link that it decides not to use because of the media attribute, it returns without freeing the URL object it just created. The fix is to postpone creating the URL until after all the checks that might cause the function to return. Patch and test case attached. Regards, Jeremy Henty

1 1

CSS branch merged!
by jcid＠dillo.org Jan. 31, 2009

Jan. 31, 2009

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 Jan. 31, 2009

Jan. 31, 2009

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 Jan. 31, 2009

Jan. 31, 2009

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 Jan. 30, 2009

Jan. 30, 2009

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 Jan. 29, 2009

Jan. 29, 2009

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 Jan. 29, 2009

Jan. 29, 2009

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

2 3

Tools button committed
by jcid＠dillo.org Jan. 27, 2009

Jan. 27, 2009

Hi, The tools button changeset was just committed. Please notice the options are global. It's quite useful as is and making per bw options seems not worth. Go check! :-) -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

2 2

Re: new font preferences
by Johannes.Hofmann＠gmx.de Jan. 26, 2009

Jan. 26, 2009

On Mon, Jan 26, 2009 at 04:58:55PM -0300, Jorge Arellano Cid wrote: > On Mon, Jan 26, 2009 at 07:14:08PM +0100, Hofmann Johannes wrote: > > Hi Jorge, > > > > do you have an opinion on the (incompatible) changes to the font > > preferences as proposed in > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2009-January/005746.html > > > > I'd like to commit this if you agree. > > Oh yes, feel free to commit. Committed. > Just let dillo-dev know how to upgrade our custom dillorc! :-) > > At this point you're the most knowledgeable in font handling and > CSS, thus some basic explanation of settings/usage would be welcomed too. >From the checking comment: CSS 2.1 uses the following predefined font names: 'serif', 'sans-serif', 'cursive', 'fantasy', 'monospace'. Add preferences so that the user can set real font names for these. Basically the new "font_sans_serif" option is what "vw_fontame" used to be and "font_monospace" is equivalent to "fw_fontname". The other two options are new. http://www.w3.org/TR/CSS21/fonts.html#generic-font-families has some more information including font examples. Cheers, Johannes

1 0