- Dillo-dev - lists.mailman3.com

patch: changeLinkColor

by Johannes.Hofmann＠gmx.de

On Sun, Sep 28, 2008 at 07:42:14PM +0000, corvid wrote: > Jorge wrote: > > On Sun, Sep 28, 2008 at 05:55:10PM +0000, corvid wrote: > > > Encouraged by the idea that I am going in the right direction, I have > > > made a new one with spaceStyle: > > > > Funny how we were working on the same patch a the same time! > > > > I had an ancient version, and gave it a review. > > The link search is linear inside textblock. A linux gazette page > > showed more than 33000 words to color a link. On bigger pages it may be worst. > > It depends on the structure. For instance our bookmarks uses tables > > and the link is usually found in less than 10 words. > > > > The patch in CVS reduce the 35000 steps to 1500 or so (the > > sorted link list is sparse, so there's a penalty for looking > > for an actual link to compare to). > > > > Please apply the spaceStyle part, and send it to me. > > Do we know that all of the (TEXT -- putting WIDGET aside for the moment) > contents of a link will have the same style? First likely example I could > come up with is how about in a utopian future dillo where tooltips are > implemented and there's an ABBR inside? Oh right. Just think about: <html> <body> <a href="http://slashdot.org">slash<b>dot</b></a> </body> </html> After clicking, the dot is no longer bold. Cheers, Johannes

Sept. 28, 2008

patch: changeLinkColor

by Johannes.Hofmann＠gmx.de

On Sun, Sep 28, 2008 at 02:54:56PM -0400, Jorge Arellano Cid wrote: > On Sun, Sep 28, 2008 at 05:55:10PM +0000, corvid wrote: > > Encouraged by the idea that I am going in the right direction, I have > > made a new one with spaceStyle: > > Funny how we were working on the same patch a the same time! > > I had an ancient version, and gave it a review. > The link search is linear inside textblock. A linux gazette page > showed more than 33000 words to color a link. On bigger pages it may be worst. > It depends on the structure. For instance our bookmarks uses tables > and the link is usually found in less than 10 words. > > The patch in CVS reduce the 35000 steps to 1500 or so (the > sorted link list is sparse, so there's a penalty for looking > for an actual link to compare to). > Not sure I understand this optimization. It is assuming that link numbers are always increasing, right? Can we assume this in dw/*? src/html.cc seems to be implemented currently in way that this is true. But perhaps we could/should reuse link numbers for equal destination urls in the future? Or someone might just choose hashes of the url string as link number. BTW. with both implementations I now see issues with this example: <html> <body> <a href="http://www.dillo.org">dillo</a> <a href="http://slashdot.org">slashdot</a> <a href="http://www.dillo.org">dillo</a> </body> </html> When opening the first link in a new window, it doesn't change color in the original one. When opening it in a tab, the first one changes color. After a reload also the second one changes color. Am I missing something? Cheers, Johannes

Sept. 28, 2008

what crashes remain?

by corvid＠lavabit.com

Jorge wrote: > On Sat, Sep 27, 2008 at 11:15:42PM +0000, corvid wrote: > > Jorge wrote: > > > On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > > > > It's still possible to crash dillo if you click on a remote link and > > > > quickly click on some images to load them. Doesn't crash every time, > > > > but typically within four tries or so. I had assumed it was the same > > > > thing as whatever was wrong with the menu crash, so I'd ignored it. > > > > > > > > If I stick > > > > a_Bw_stop_clients(bw, BW_Img); > > > > in the DilloHtml destructor, I can no longer get it to crash, but > > > > I randomly got a "Cache_process_queue Caught busy!!!" while browsing > > > > earlier today, so there's something wrong with just doing that. > > > > (Assuming it's related; I'm not in the habit of getting that MSG.) > > > > > > That message means big trouble: the event loop stepped over itself... > > > > > > I've tried several different ways but can't get to crash it. > > > > > > Does the attached patch help? > > > > Seems to be working well so far. > > Is there any danger in adding something like > > a_Nav_cancel_expect to a_UIcmd_stop()? > > What's the idea behind it? > > If you want to get rid of empty cache entries from > unsuccesful http connections, it's more complex than that. > BTW, I plan to do that after the release. I'm on page A. I try to go to page B, which seems to be taking a long time to think about resolving or contacting the host or whatever. I hit stop and go back to reading and want to continue loading images. Or if DNS couldn't resolve the hostname, I could hit stop to re-enable loading images.

Sept. 28, 2008

what crashes remain?

by jcid＠dillo.org

On Sat, Sep 27, 2008 at 11:15:42PM +0000, corvid wrote: > Jorge wrote: > > On Sat, Sep 27, 2008 at 05:29:28PM +0000, corvid wrote: > > > It's still possible to crash dillo if you click on a remote link and > > > quickly click on some images to load them. Doesn't crash every time, > > > but typically within four tries or so. I had assumed it was the same > > > thing as whatever was wrong with the menu crash, so I'd ignored it. > > > > > > If I stick > > > a_Bw_stop_clients(bw, BW_Img); > > > in the DilloHtml destructor, I can no longer get it to crash, but > > > I randomly got a "Cache_process_queue Caught busy!!!" while browsing > > > earlier today, so there's something wrong with just doing that. > > > (Assuming it's related; I'm not in the habit of getting that MSG.) > > > > That message means big trouble: the event loop stepped over itself... > > > > I've tried several different ways but can't get to crash it. > > > > Does the attached patch help? > > Seems to be working well so far. > Is there any danger in adding something like > a_Nav_cancel_expect to a_UIcmd_stop()? What's the idea behind it? If you want to get rid of empty cache entries from unsuccesful http connections, it's more complex than that. BTW, I plan to do that after the release. > PS Stop should have a keyboard shortcut, I think. > I long had a reflex of hitting ESC from the netscape/mozilla > days, but of course ESC would be inconsistent for dillo. Could be. Maybe Ctrl-P. Although Stop is not yet doing exactly what it should. -- Cheers Jorge.-

Sept. 28, 2008

patch: changeLinkColor

by corvid＠lavabit.com

I wrote: > The registerName is because html.cc needs to have that working in > order to call changeLinkColor. By the way, in addition to html.cc, instanceOf is used in Textblock::addParbreak(). Perhaps we will see some effect from this.

Sept. 28, 2008

patch: changeLinkColor

by corvid＠lavabit.com

Johannes wrote: > On Sun, Sep 28, 2008 at 06:00:20AM +0000, corvid wrote: > > I just took the 0.8.6 version and replaced everything in it with > > dillo2 versions. (well, then had to add in the widget part) > > The fact that it seems to be working is kind of shocking. > > > > As for whether this is still the right way to do it, I leave this > > matter for the experts. > > Not that I'm an expert, but it looks right to me. It looks like it still needs to change spaceStyle. I wonder why spaceStyle is necessary... something to do with CSS?

Sept. 28, 2008

panel_size=small hides the menubar

by onepoint＠starurchin.org

On Sun, Sep 28, 2008 at 08:27:28AM -0400, Jorge Arellano Cid wrote: > On Sun, Sep 28, 2008 at 12:58:17PM +0100, Jeremy Henty wrote: > > > > If I add "panel_size=small" to ~/.dillo/dillo2rc then the menubar > > disappears! Huh? (~/.dillo/dillo2rc is otherwise identical to > > the default /etc/dill2rc) > > Well, more or less that's the idea with tiny, small and medium. Oh, I see! I was thinking of "the panel" as referring to just the button bar rather than the whole set of controls at the top. It makes more sense now but it's still a little surprising: I would expect a change of size specification to do nothing more than change the size of things, not make some of them disappear. > Whereas it has an inconsistency with the "show_menubar" preference, > that's happily ignored by the code. > > This should be corrected into a consistent and easy to use model. I would say that it would be simpler and more consistent to make "show_menubar" the only thing that determines whether the menubar is shown, and make "panel_size" affect nothing except the sizes of things. *If* there's an opportunity for a more radical change before release, why not move the File menubutton into the button bar (perhaps with a vertical divider to set them apart)? IMHO it's very ugly to have the File button sitting all alone at the top, wasting all that precious vertical whitespace for just one button! (That's why I only just noticed the menubar had gone, I normally turn it off anyway.) Regards, Jeremy Henty

Sept. 28, 2008

panel_size=small hides the menubar

by jcid＠dillo.org

On Sun, Sep 28, 2008 at 12:58:17PM +0100, Jeremy Henty wrote: > > If I add "panel_size=small" to ~/.dillo/dillo2rc then the menubar > disappears! Huh? (~/.dillo/dillo2rc is otherwise identical to the > default /etc/dill2rc) Well, more or less that's the idea with tiny, small and medium. Whereas it has an inconsistency with the "show_menubar" preference, that's happily ignored by the code. This should be corrected into a consistent and easy to use model. -- Cheers Jorge.-

Sept. 28, 2008

panel_size=small hides the menubar

by onepoint＠starurchin.org

If I add "panel_size=small" to ~/.dillo/dillo2rc then the menubar disappears! Huh? (~/.dillo/dillo2rc is otherwise identical to the default /etc/dill2rc) Regards, Jeremy Henty

Sept. 28, 2008

patch: changeLinkColor

by Johannes.Hofmann＠gmx.de

On Sun, Sep 28, 2008 at 06:00:20AM +0000, corvid wrote: > I just took the 0.8.6 version and replaced everything in it with > dillo2 versions. (well, then had to add in the widget part) > The fact that it seems to be working is kind of shocking. > > As for whether this is still the right way to do it, I leave this > matter for the experts. Not that I'm an expert, but it looks right to me. Cheers, Johannes

Sept. 28, 2008