- Dillo-dev - lists.mailman3.com

Close-tab Button

by jorl17.8＠gmail.com

Greetings to all. As a simple introduction may I say I thank you all for your work on Dillo. Currently, I am trying to implement the Close-Tab button. I've been discussing it with Jorge Arellano Cid and he suggested I 'brought-it' to dillo-dev. FLTK Tabs don't support a close-tab button, as many of you have seen, and the idea was to have a button at the end of the tabs list. For that, I created an fltk::Button widget in CustTabGroup. I position this widget at the end of the tabs list and, then, I add() it to the CustTabGroup's parent() (UI). After that, I set the UI's resizer() to be an InvisibleBox positioned in such a way that it doesn't resize the button itself, but only moves it. Refreshing the button (when changing/adding/closing tabs) is done in the handle() method of the CustTabGroup. Just a second ago I solved one of the problems, which was the fact that tab_height() returned 0 in the constructor and resize() didn't work. I worked around that by constructing the button only in event() if tab_height()>0 and it hasn't been constructed yet. This way we can use the correct height for the button. It may not seem reliable to do so many things in handle(). Any suggestions? It is functional, only you can say if it fully suits Dillo's needs though. Unfortunately, there are some problems: The first one is the most-relevant one. When the list of tabs grows it can go over the button. I have been trying to fix this, but I can't seem to do it. A possible way could (maybe) be to 'trick' the pager into thinking it has less space left to draw the tabs, and that could possibly be achieved using update_positions(), although I am having some problems with that. The second problem is a minor one, but annoying. I believe when CSS rendering is triggered, the render area flickers and that is normal. However, the way I implemented this (probably because of it being in handle()) makes the Button also flash. Thanks, Jo?o

Feb. 1, 2009

CSS branch merged!

by Johannes.Hofmann＠gmx.de

On Sat, Jan 31, 2009 at 06:15:50PM -0300, Jorge Arellano Cid wrote: > On Fri, Jan 30, 2009 at 10:35:18PM +0100, Hofmann Johannes wrote: > > 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. > > I don't know what to test but there're > rendering differences with this page: > > http://www.thefreedictionary.com/unneeded > > (comparing with 83d840739a0e as tip) > > HTH. Well, rendering differences are the point here :) For example on cnn.com you can now read the "Home" white on red background, which was red on red before. Thanks for testing, Johannes

Jan. 31, 2009

Bad character coding for www.blisty.cz

by newman.x＠gmail.com

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

Jan. 31, 2009

Window icon

by jcid＠dillo.org

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 ______________________________________________________________________

Jan. 31, 2009

CSS branch merged!

by jcid＠dillo.org

On Fri, Jan 30, 2009 at 10:35:18PM +0100, Hofmann Johannes wrote: > 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. I don't know what to test but there're rendering differences with this page: http://www.thefreedictionary.com/unneeded (comparing with 83d840739a0e as tip) HTH. -- 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 06:53:47PM +0100, Hofmann Johannes wrote: > On Sat, Jan 31, 2009 at 02:38:47PM -0300, Jorge Arellano Cid wrote: > > 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. > > Yes, that's expected. They set the color for visited links. > firefox also shows them in red. > > > > > > 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" ;) > > That's problematic. I don't know how to express this in CSS and > hacking this around CSS seems ugly. > Maybe adding some special dillo specific CSS extension would be > possible. > But before doing that we should make sure that it really can't be > done with standard CSS. Also we should check what other browsers do. Yes. In its current state: :visited {color: #800080 !important} is enough for a release. Maybe in the future we can modify the custom dillo stylesheet with a computed visited color, on-the-fly for each page. Is that possible? -- 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 02:38:47PM -0300, Jorge Arellano Cid wrote: > 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. Yes, that's expected. They set the color for visited links. firefox also shows them in red. > > > 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" ;) That's problematic. I don't know how to express this in CSS and hacking this around CSS seems ugly. Maybe adding some special dillo specific CSS extension would be possible. But before doing that we should make sure that it really can't be done with standard CSS. Also we should check what other browsers do. Cheers, Johannes

Jan. 31, 2009

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