- Dillo-dev - lists.mailman3.com

What's left to do for dillo-2.1?

by jcid＠dillo.org

On Sat, Jan 31, 2009 at 04:03:11PM +0100, Hofmann Johannes wrote: > On Sat, Jan 31, 2009 at 12:04:32PM -0300, Jorge Arellano Cid wrote: > > On Sat, Jan 31, 2009 at 03:08:20PM +0100, Hofmann Johannes wrote: > > > On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > > > > > > > I get the feeling we are close to releasing dillo-2.1. Do others > > > > agree? What's left to be done? > > > > > > I agree. Of course there is a lot todo regarding CSS conformance, > > > but we won't pass any ACID test soon anyway. > > > I'd like to get the font-size issue on wikipedia.org fixed however - > > > help on that is very welcome :-). > > > > Ah!, and there's the very important issue of the visited link color. > > When coming back to a page, most of the time visited links aren't shown > > as such (i.e. drawn in visited color). > > Do you have an example? CSS allows to specify the visited link > color, so it may just have been set by the author to something > unexpected. http://www.linux.org.uk/Portaloo.cs (but as you said, this one sets to the same color). http://www.lacuarta.cl If you click on a red headline and come back, the color is the same. I don't know what color is visited set to. > Does > > :visited {color: #800080 !important} > > in .dillo/style.css fix the problem? Yes. It always shows the same visited-color, but is much better than without. Personally, I like best something like the old "contrast visited color" ;) -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 31, 2009

Re: Dillo Source code

by jcid＠dillo.org

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 ______________________________________________________________________

Jan. 31, 2009

What's left to do for dillo-2.1?

by Johannes.Hofmann＠gmx.de

On Sat, Jan 31, 2009 at 12:04:32PM -0300, Jorge Arellano Cid wrote: > On Sat, Jan 31, 2009 at 03:08:20PM +0100, Hofmann Johannes wrote: > > On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > > > > > I get the feeling we are close to releasing dillo-2.1. Do others > > > agree? What's left to be done? > > > > I agree. Of course there is a lot todo regarding CSS conformance, > > but we won't pass any ACID test soon anyway. > > I'd like to get the font-size issue on wikipedia.org fixed however - > > help on that is very welcome :-). > > Ah!, and there's the very important issue of the visited link color. > When coming back to a page, most of the time visited links aren't shown > as such (i.e. drawn in visited color). Do you have an example? CSS allows to specify the visited link color, so it may just have been set by the author to something unexpected. Does :visited {color: #800080 !important} in .dillo/style.css fix the problem? Cheers, Johannes

Jan. 31, 2009

What's left to do for dillo-2.1?

by jcid＠dillo.org

On Sat, Jan 31, 2009 at 03:08:20PM +0100, Hofmann Johannes wrote: > On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > > > I get the feeling we are close to releasing dillo-2.1. Do others > > agree? What's left to be done? > > I agree. Of course there is a lot todo regarding CSS conformance, > but we won't pass any ACID test soon anyway. > I'd like to get the font-size issue on wikipedia.org fixed however - > help on that is very welcome :-). Ah!, and there's the very important issue of the visited link color. When coming back to a page, most of the time visited links aren't shown as such (i.e. drawn in visited color). -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 31, 2009

What's left to do for dillo-2.1?

by jcid＠dillo.org

On Sat, Jan 31, 2009 at 03:08:20PM +0100, Hofmann Johannes wrote: > On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > > > I get the feeling we are close to releasing dillo-2.1. Do others > > agree? What's left to be done? > > I agree. Of course there is a lot todo regarding CSS conformance, > but we won't pass any ACID test soon anyway. > I'd like to get the font-size issue on wikipedia.org fixed however - > help on that is very welcome :-). and there's the "minimal_font_size" pref. I may look into this after dicache... -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 31, 2009

What's left to do for dillo-2.1?

by jcid＠dillo.org

On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > I get the feeling we are close to releasing dillo-2.1. Do others > agree? What's left to be done? It looks like the main part is done. The close-tab icon is still missing (Jo?o Ricardo is working on it). I'm yet to push more dicache/image cleanups and to update the respective docs. There're more valgrind issues to look into. It would also be interesting to look at the addblock code; corvid made a prototype based on RE. I have the feeling (i.e. not backed with actual data) that maybe an option to not load resources from sites other than where the page is hosted, would get rid of most of the problems cheaply. Another posibility is to filter by host (dStrncasecmp() against URL_HOST), and maybe also offer RE filtering for more fine tunning (comments encouraged). CSS, we need Johannes green light on this. More stabilizing & testing. After that, custom packages need to be built for Debian, Ubuntu, RedHat... We may be more or less one month away... -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 31, 2009

What's left to do for dillo-2.1?

by Johannes.Hofmann＠gmx.de

On Sat, Jan 31, 2009 at 01:15:07PM +0000, Jeremy Henty wrote: > > I get the feeling we are close to releasing dillo-2.1. Do others > agree? What's left to be done? I agree. Of course there is a lot todo regarding CSS conformance, but we won't pass any ACID test soon anyway. I'd like to get the font-size issue on wikipedia.org fixed however - help on that is very welcome :-). Regards, Johannes

Jan. 31, 2009

What's left to do for dillo-2.1?

by onepoint＠starurchin.org

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

Jan. 31, 2009

CSS branch merged!

by Johannes.Hofmann＠gmx.de

On Sun, Jan 18, 2009 at 09:37:45AM +0100, Hofmann Johannes wrote: > On Sat, Jan 17, 2009 at 11:39:04PM +0000, corvid wrote: > > Johannes wrote: > > > On Sat, Jan 17, 2009 at 10:42:36PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > On Sat, Jan 17, 2009 at 07:17:53PM +0000, corvid wrote: > > > > > > Johannes wrote: > > > > > > > On Sat, Jan 17, 2009 at 04:29:37PM +0000, corvid wrote: > > > > > > > > I wonder whether there's a way to specify something like > > > > > > > > code, tt, pre, samp, kbd {font-family: mono !important} > > > > > > > > * {font-family: sans !important} > > > > > > > > but have sans only for elements not otherwise specified. > > > > > > > > > > > > > > > > > > > > > > According to http://www.w3.org/TR/CSS21/cascade.html#specificity > > > > > > > the first rule should overrule the second one if it matches. > > > > > > > So this should work. > > > > > > > Note, that the specificity stuff is not fully implemented yet, but > > > > > > > it should be sufficient for the example above. > > > > > > > > > > > > Does it work for you? > > > > > > > > > > Yes, I tried: > > > > > > > > > > code, tt, pre, samp, kbd {color: green !important} > > > > > * {color: red !important} > > > > > > > > > > on http://www.dillo.org/CSS.html and it seemed to work ok. > > > > > > > > All red for me. > > > > > > > > I tried reverting to the official tip, even I don't have anything > > > > much except forms code in my tree right now. > > > > Still all red. > > > > > > > > How strange that we would see different behaviour here... > > > > I guess I'll have to dive into the code myself... > > > > > > Please check again with attached patch. > > > > It's working! > > Thanks! Excellent customer service :) > > It's not the proper solution though. > Here's the plan to apply rules according to > http://www.w3.org/TR/CSS21/cascade.html#specificity: > > * For each CssRule compute the specificity according to > http://www.w3.org/TR/CSS21/cascade.html#specificity > > * Store the rules in RuleList sorted by this specificity. > > * In CssStyleSheet::apply() merge-sort the 4 ruleLists with > potentially matching rules and apply them in the order given by > their specificity. > > If anyone feels like implementing it - go ahead :) Just implemented that. Please test. Cheers, Johannes

Jan. 30, 2009

FreeHG performance

by jcid＠dillo.org

Hi Andreas, On Fri, Jan 30, 2009 at 05:24:56PM +0100, Andreas Kemnade wrote: > Hi Jorge, > > On Fri, 30 Jan 2009 12:22:46 -0300 > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > On Fri, Jan 30, 2009 at 01:21:47PM +0000, Jeremy Henty wrote: > > > > > > 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, > > > > Yes, I've also had trouble with it, and when normal it's slower > > than our Wearlab's CVS. > > > > A couple of days ago (while developoing/reviewing patches) I > > digged a bit on it and it seems that bitbucket is much faster. We > > can try bitbucket while we find a long term solution (e.g. FSF's > > savannah is offering Mercurial and Git repos, but the applying > > process may take some time). > > > > At some point in time we should move out from the Wearlab, as > > it may be closed soon. Currently we need webserver/CGI/python > > shell accounts and a DCVS (Hg or Git). CGI is quite useful, but > > we may use another bugtracker too. > > > The server which actually hosts the dillo debian and openmoko > packages should be an alternative. > At least performance and bandwidth should be no problem. Maybe moving > hg there is a starting point. Does this server belong to the Wearlab? If not, what's its expected lifespan? Or are you suggesting it as an interim solution for mercurial hosting? -- Cheers Jorge.- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

Jan. 30, 2009