June 2011 - Dillo-dev - lists.mailman3.com

Development schedule for version 1.3

by jcid＠dillo.org

On Sun, Jun 05, 2011 at 08:08:15PM +0000, corvid wrote: > [...] > - Still missing is the -f command line option (used by claws). > > Jorge was waiting for something to do with FLTK before taking action there. Yes, Matt wrote he planned to solve STR2639 for rc7, but it didn't happen so, I'll commit a patch with workarounds. (FWIW, I would have been surprised with such a change at this stage). > - tab titles > > Just cosmetic issues of: They seem too short, the original title of, e.g., > ctab5, is suboptimal, and the ones without a title tag are initially blank. This may be a matter of taste. e.g. Dillo-2.x used "dillo" instead of a blank title, and allowed longer labels. I like the current behaviour with fixed length tabs. YMMV. "ctab<n>" as label is weird, and should be changed. Suggestions? (e.g. tab length, initial string). Keep it simple please ;-) -- Cheers Jorge.-

June 9, 2011

Table::addCell() leak

by jcid＠dillo.org

Hi there, I'm back from a new machine (still tweaking it, but workable!) On Sun, Jun 05, 2011 at 03:09:35AM +0000, corvid wrote: > > http://starurchin.org/dillo/valgrind/10ca58f617a0693638facdb40bcf319af1bdfc… > has a leak at dw/table.cc:323, and I found a way to trigger it: > > <table border=2> > <tr><td>first<td rowspan=2>tall<td>third > <tr><td colspan=2>wide<td>last > </table> > > Jorge, you might remember a little something about tables. Can we > simply check children->get() before putting anything there, or do > we have to fix things somewhere if part of a span is stolen away? Hmmm, fixing it from the HTML parser would be harder as AFAIR it doesn't know much more than adding rows and cells. Corner cases as this should be easier to handle in the dw-table as you suggest. It looks like an overlooked case, or maybe just paying the "leak cost" of it. ;-) You should review the algorithm to make sure the stolen cell will not be missed elsewhere. -- Cheers Jorge.-

June 9, 2011

Development schedule for version 1.3

by corvid＠lavabit.com

I wrote: > Johannes wrote: > > Can you please try attached patch? > > It seems to work ok with xft enabled and also allows to set e.g: > > font_sans_serif="helvetica" without xft. > > Font names in the non-xft case are still a bit odd (e.g. all lower > > case), but I don't think there's much we can do about that. > For non-xft, xlsfonts says that I have, for instance, "new century > schoolbook", but Dillo doesn't list it. I changed it to Fl::set_fonts ("-*-iso10646-1"); to follow the lead of if (!xstarname) { strcpy(buf,"-*-"); strcpy(buf+3,fl_encoding); xstarname = buf; } and now it can find new century schoolbook.

June 8, 2011

Development schedule for version 1.3

by corvid＠lavabit.com

Johannes wrote: > Can you please try attached patch? > It seems to work ok with xft enabled and also allows to set e.g: > font_sans_serif="helvetica" without xft. > Font names in the non-xft case are still a bit odd (e.g. all lower > case), but I don't think there's much we can do about that. It looks like I have to get the capitalization right for the xft case now. I have a tendency to specify the fonts in lowercase. For non-xft, xlsfonts says that I have, for instance, "new century schoolbook", but Dillo doesn't list it.

June 7, 2011

Development schedule for version 1.3

by Johannes.Hofmann＠gmx.de

On Mon, Jun 06, 2011 at 09:26:03PM +0000, corvid wrote: > I wrote: > > Johannes wrote: > > > On Mon, Jun 06, 2011 at 08:04:37PM +0000, corvid wrote: > > > > PS Do you think we should change the Fl::set_fonts ("-*"); > > > > to specify iso10646-1? > > > > > > Wouldn't that exclude non-UTF-8 fonts which might work fine for > > > people not caring about special chars? > > > > I was thinking of the case where you had a latin1 version and a > > utf-8 version of a font, but I don't know the relevant code well > > enough to know what happens. > > The xft version says: > // Also, for now I'm ignoring the "pattern_name" and just getting everything... > > So I guess there's no point in worrying about it. > Can you please try attached patch? It seems to work ok with xft enabled and also allows to set e.g: font_sans_serif="helvetica" without xft. Font names in the non-xft case are still a bit odd (e.g. all lower case), but I don't think there's much we can do about that. Cheers, Johannes

June 7, 2011

Development schedule for version 1.3

by itsme_410＠yahoo.com

Do we have features/bugs for each milestone documented anywhere??http://www.dillo.org/Plans.html is a bit too high level. What comes after 1.3? I doubt fltk 1.3 will be released on Wednesday: they have yet to release their RC7 which was supposed to be June 1, P.S. Are we going to call Dillo with FLTK1.3 as Dillo3? One problem is that on the surface nothing has changed from Dillo2, so users will probably get confused. How about call it dillo2.3? Btw, it is unfathomable to me why weekly fltk2 updates continue to be released......hopefully, fltk1.3 will not be as much of a roadblock in terms of facilitating adoption of dillo as fltk2 was. Recall that since they never hit stable, distros such as Fedora did not go for dillo2 (sticking with dillo 0.8.6).

June 7, 2011

Development schedule for version 1.3

by corvid＠lavabit.com

I wrote: > Johannes wrote: > > On Mon, Jun 06, 2011 at 08:04:37PM +0000, corvid wrote: > > > PS Do you think we should change the Fl::set_fonts ("-*"); > > > to specify iso10646-1? > > > > Wouldn't that exclude non-UTF-8 fonts which might work fine for > > people not caring about special chars? > > I was thinking of the case where you had a latin1 version and a > utf-8 version of a font, but I don't know the relevant code well > enough to know what happens. The xft version says: // Also, for now I'm ignoring the "pattern_name" and just getting everything... So I guess there's no point in worrying about it.

June 6, 2011

Development schedule for version 1.3

by corvid＠lavabit.com

Johannes wrote: > On Mon, Jun 06, 2011 at 08:04:37PM +0000, corvid wrote: > > PS Do you think we should change the Fl::set_fonts ("-*"); > > to specify iso10646-1? > > Wouldn't that exclude non-UTF-8 fonts which might work fine for > people not caring about special chars? I was thinking of the case where you had a latin1 version and a utf-8 version of a font, but I don't know the relevant code well enough to know what happens.

June 6, 2011

Development schedule for version 1.3

by Johannes.Hofmann＠gmx.de

On Mon, Jun 06, 2011 at 08:04:37PM +0000, corvid wrote: > Johannes wrote: > > I just committed something to get the preferred font stuff working > > on fltk-1.3. Please give it a try. > > Does it work for you with xft disabled? > I set font_sans_serif to "helvetica", and got > ** WARNING **: preferred sans-serif font "helvetica" not found. No, doesn't seem to work here either. This is a general problem of the font handling code in fltkplatform.cc and fltk13... I will look into it. > > PS Do you think we should change the Fl::set_fonts ("-*"); > to specify iso10646-1? Wouldn't that exclude non-UTF-8 fonts which might work fine for people not caring about special chars? Cheers, Johannes

June 6, 2011

Development schedule for version 1.3

by corvid＠lavabit.com

Johannes wrote: > I just committed something to get the preferred font stuff working > on fltk-1.3. Please give it a try. Does it work for you with xft disabled? I set font_sans_serif to "helvetica", and got ** WARNING **: preferred sans-serif font "helvetica" not found. PS Do you think we should change the Fl::set_fonts ("-*"); to specify iso10646-1?

June 6, 2011