- Dillo-dev - lists.mailman3.com

The Dillo web browser and GTK+ (fwd)

by Jorge Arellano Cid

Hi there! Can someone please forward this to gtk-list(a)gnome.org. I sent it once and as I'm not a member it was held for aproval, but it never made its way in. :( If someone here is a member, please send it. If someone knows the answer, better! Thanks a lot Jorge.- ---------- Forwarded message ---------- Date: Tue, 10 Jun 2003 12:38:36 -0400 (CLT) From: Jorge Arellano Cid <jcid(a)softhome.net> To: gtk-list(a)gnome.org Subject: The Dillo web browser and GTK+ Hi! I have two questions: 1) What do I need to do to make the Dillo web browser listed in the GTK+ apps. at www.gtk.org? (Ref: www.dillo.org) 2) Technical: If I have three focusable widgets in a window, pressing TAB/ShiftTAB cycles through them, _BUT_ like this: .-> One -> Two -> Three -> "Nirvana" --. | | '--------------------------------------' (or backwards). And I want it to be: .-> One -> Two -> Three -> --. | | '----------------------------' I have called "Nirvana" a widget(?), that seems to grab the focus (as none of the three widgets has it when at "Nirvana" :) Appended is some example code that illustrates the problem. Thanks in advance Jorge.- PS: Please CC me, as I'm not in the list. ----------------------------------------------------------------- /* focus example. -- GTK+-1.2.x */ #include <gdk/gdk.h> #include <gdk/gdkkeysyms.h> #include <gtk/gtk.h> gint delete_event( GtkWidget *widget, GdkEvent *event, gpointer data ) { return(FALSE); } /* Another callback */ void destroy( GtkWidget *widget, gpointer data ) { gtk_main_quit(); } int main( int argc, char *argv[] ) { GtkWidget *window; GtkWidget *entry; GtkWidget *vbox; gtk_init(&argc, &argv); /* create a new window */ window = gtk_window_new (GTK_WINDOW_TOPLEVEL); GTK_WIDGET_UNSET_FLAGS (window, GTK_CAN_FOCUS); gtk_signal_connect (GTK_OBJECT (window), "delete_event", GTK_SIGNAL_FUNC (delete_event), NULL); gtk_signal_connect (GTK_OBJECT (window), "destroy", GTK_SIGNAL_FUNC (destroy), NULL); /* Create the entries */ vbox = gtk_vbox_new (FALSE, 0); entry = gtk_entry_new(); GTK_WIDGET_SET_FLAGS(entry, GTK_HAS_FOCUS); gtk_widget_set_usize(entry, 140, 0); gtk_entry_set_text(GTK_ENTRY(entry), "One"); gtk_box_pack_start (GTK_BOX (vbox), entry, FALSE, FALSE, 0); gtk_widget_show (entry); entry = gtk_entry_new(); gtk_widget_set_usize(entry, 140, 0); gtk_entry_set_text(GTK_ENTRY(entry), "Two"); gtk_box_pack_start (GTK_BOX (vbox), entry, FALSE, FALSE, 0); gtk_widget_show (entry); entry = gtk_entry_new(); gtk_widget_set_usize(entry, 140, 0); gtk_entry_set_text(GTK_ENTRY(entry), "Three"); gtk_box_pack_start (GTK_BOX (vbox), entry, FALSE, FALSE, 0); gtk_widget_show (entry); gtk_container_add(GTK_CONTAINER (window), vbox); gtk_widget_show (vbox); gtk_widget_show (window); /* Start */ gtk_main (); return(0); } -----------------------------------------------------------------

June 20, 2003

Re: [Dillo-dev] Hangin with high CPU load

by Jorge Arellano Cid

On Fri, 20 Jun 2003, Frédéric Bothamy wrote: > * David McKee <dmckee(a)jlab.org> [2003-06-19 13:46] : > > [...] > > Of late dillo has started getting into a state where all progress stop in > > all open windows, and it sits on the CPU---keeping my load average at 1.0 > > > > [...] > > So, two questions: > > > > -- Has anyone else observed this behavior? > > Not sure if the problem is the same, but I have noticed this behaviour > when I load a big page with an anchor (or is it a reference?) in the > address, eg: > > http://ftp-master.debian.org/testing/update_excuses.html#kdelibs > > (WARNING: 853 Kb). It eventually finishes loading the page but it can > take a HUGE amount of time (several minutes whereas the same page > without '#kdelibs' only takes about 10 to 15 seconds). This is another problem! IIRC Sebastian posted a comment about this sometime ago, but although I searched for, I didn't find the post :( After reviewing it myself (the huge page with anchor problem), I developed a small patch that more or less solves the problem (makes the anchored URL to load two times slower, but it works). -- I'm still working on it. The problem is similar to what we had before incremental rewraping. The anchor (aka. "fragment") code falls inside an exponential algorithm so it dies hogging (unless you have exponential patience!). > I do not think however that this particular problem is specific to Dillo > as I have already seen Mozilla hung with the same test. Most programs don't care much about hogging the CPU, but we do! So this is a BUG in Dillo and we'll try to work it out. Sebastian: Did you post something about this, or is it my mind joking on me? Cheers Jorge.- PS: The search for a way to reproduce the other BUG is still open

June 20, 2003

Re: [Dillo-dev] Hangin with high CPU load

by Frédéric Bothamy

* David McKee <dmckee(a)jlab.org> [2003-06-19 13:46] : > Folks, > I've been using dillo for a number of months now, and it has become my > first choice browser--I switch to mozilla or opera only when I have to > java, javascript, http/1.1 authentication, ssl and the like. > > > > Of late dillo has started getting into a state where all progress stop in > all open windows, and it sits on the CPU---keeping my load average at 1.0 > > Sometimes it recovers after a while, sometime I get fed up and close all > windows at the WM manager level. Stopping all the active windows doesn't > cure it, nor does closing them. I haven't tried using the `Exit Dillo' > menu item, but I'll do so on the next occurrence. > > This has been with the CVS version(s) over the last few weeks. Two > systems, one running redhat 6.2 (I know, I know...), the other Debian > GNU/Linux 3.0r1. > > > > So, two questions: > > -- Has anyone else observed this behavior? Not sure if the problem is the same, but I have noticed this behaviour when I load a big page with an anchor (or is it a reference?) in the address, eg: http://ftp-master.debian.org/testing/update_excuses.html#kdelibs (WARNING: 853 Kb). It eventually finishes loading the page but it can take a HUGE amount of time (several minutes whereas the same page without '#kdelibs' only takes about 10 to 15 seconds). I do not think however that this particular problem is specific to Dillo as I have already seen Mozilla hung with the same test. HTH Fred

June 20, 2003

Re: [Dillo-dev] Hangin with high CPU load

by Stephen Lewis

On Thu, 19 Jun 2003 13:46:02 -0400 (EDT) David McKee <dmckee(a)jlab.org> wrote: > Of late dillo has started getting into a state where all progress stop > in all open windows, and it sits on the CPU---keeping my load average > at 1.0 > > Sometimes it recovers after a while, sometime I get fed up and close > all windows at the WM manager level. Stopping all the active windows > doesn't cure it, nor does closing them. I haven't tried using the > `Exit Dillo' menu item, but I'll do so on the next occurrence. I have had a the same sort of problem - about the only consistency I can see behind it is that I can only remember it happening when I hit reload on an page that seems to have stalled part-way through. However, it doesn't *always* do it. Are you using a proxy server? I am, and from what I can remember when it does this, the reload (often, but not always) doesn't actually start over, so I suspect that my proxy server still has an open connection (which has stalled) and just resends what it's got so far. The 100% cpu usage ends when(if) the reload completes, and I(think) it also ends when the connection times out. Next time it happens, I'll try to get something more concrete. -- Stephen Lewis slewis(a)paradise.net.nz

June 19, 2003

Re: [Dillo-dev] Hangin with high CPU load

by Jorge Arellano Cid

Hi ya! Just forgot to mention that the patch is not in CVS. Please play a while to find the way to reproduce it! Cheers Jorge.- PS: Did I suggest finding a way to... :-)

June 19, 2003

Re: [Dillo-dev] Hangin with high CPU load

by Jorge Arellano Cid

On Thu, 19 Jun 2003, David McKee wrote: > [...] > Of late dillo has started getting into a state where all progress stop in > all open windows, and it sits on the CPU---keeping my load average at 1.0 > [...] > N.B. I seems to happen most when I have opened several links in new > windows in rapid succession. I just developed a "blind patch" by checking the IO code for exception handling (as suggested in my previous email). After giving the new code a hard time playing with simultaneous connections, it seems to work OK. The real test, of course, is to prove it against a reliable way to reproduce the problem. Can you guys work on finding a way to reproduce the bug please? Cheers Jorge.-

June 19, 2003

Re: [Dillo-dev] transient find-dialog

by Andreas Zwinkau

> Would you mind reading dillorc? Shame on me, seems i don't bring anything to this mailing list :( Thanks for not getting impolite to such a stupid question. Keep working on this great browser :) mfg Andreas Zwinkau | web: andi.dasstellenwirinsinternet.de | mail: andi(a)buxach.de | jabber: beza1e1(a)amessage.de

June 19, 2003

Re: [Dillo-dev] Hangin with high CPU load

by Jorge Arellano Cid

On Thu, 19 Jun 2003, David McKee wrote: > Folks, > I've been using dillo for a number of months now, and it has become my > first choice browser--I switch to mozilla or opera only when I have to > java, javascript, http/1.1 authentication, ssl and the like. That's the idea! > Of late dillo has started getting into a state where all progress stop in > all open windows, and it sits on the CPU---keeping my load average at 1.0 > > Sometimes it recovers after a while, sometime I get fed up and close all > windows at the WM manager level. Stopping all the active windows doesn't > cure it, nor does closing them. I haven't tried using the `Exit Dillo' > menu item, but I'll do so on the next occurrence. Closing the Dillo instance "solves" it. > > This has been with the CVS version(s) over the last few weeks. Two > systems, one running redhat 6.2 (I know, I know...), the other Debian > GNU/Linux 3.0r1. > > > > So, two questions: > > -- Has anyone else observed this behavior? Yes, I've noticed, and have been on it a few times, but I still don't know how to reproduce it reliably (I haven't devoted much time to it though). > -- Can anyone suggest a good way to diagnose the problem so I can submit a > decent bug report? As things stand my understanding is horribly vague. Well I think it has to do with a socket connection in an "exceptional" state of some class (every image in a page, and the page itself, open socket connections). Attaching GDB to the hogging Dillo instance inmediatly stops the problem (and "cont" resumes :-), the interesting thing is that you can't break the code into a function inside Dillo. It seems to get trapped in a busy wait between GTK+ and the kernel signals. * Sometimes de-attaching GDB magically solves the problem. !? > N.B. I seems to happen most when I have opened several links in new > windows in rapid succession. Finding a reliable way to reproduce the problem is KEY to solving it. If you can do that it'd be of great help! I'd try to bring the socket connection into exceptional conditions, and refine from there to find the bug. For instance, what happens when the connection is aborted just before the remote server is contacted? Or maybe what if it is aborted after the remote server is contacted but before Dillo gets notified? It sounds more complex than it is. Just try to find a busy server and play hard on it! Start with the sites you were visiting. I'll check the code for exception handling. Any help is highly appreciated. Cheers Jorge.-

June 19, 2003

Hangin with high CPU load

by David McKee

Folks, I've been using dillo for a number of months now, and it has become my first choice browser--I switch to mozilla or opera only when I have to java, javascript, http/1.1 authentication, ssl and the like. Of late dillo has started getting into a state where all progress stop in all open windows, and it sits on the CPU---keeping my load average at 1.0 Sometimes it recovers after a while, sometime I get fed up and close all windows at the WM manager level. Stopping all the active windows doesn't cure it, nor does closing them. I haven't tried using the `Exit Dillo' menu item, but I'll do so on the next occurrence. This has been with the CVS version(s) over the last few weeks. Two systems, one running redhat 6.2 (I know, I know...), the other Debian GNU/Linux 3.0r1. So, two questions: -- Has anyone else observed this behavior? -- Can anyone suggest a good way to diagnose the problem so I can submit a decent bug report? As things stand my understanding is horribly vague. N.B. I seems to happen most when I have opened several links in new windows in rapid succession. Thanks, -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

June 19, 2003

Re: [Dillo] Charset representation patch

by Jorge Arellano Cid

On Wed, 18 Jun 2003, Nikita V. Borodikhin wrote: > Hello, Jorge ! > > Jorge, I'm sorry for annoying you but can you say anything about > the future of this charset representation patch also posted to > dillo-dev list at Mon, 9 Jun 2003 17:40:24 +0700 ? > > Some time after that (2003/06/12 20:51:00) you add 0x2022 code > to UCStolatin1 handler so this patch differs from mailing list one > in one line. This is at least my third answer to this not high priority issue. From my previous response, still this concern remains unanswered: > (I wrote) > > Finally, I can't see (yet) how having this entitites character > representation helps when using another character set (as with > the russian encoding workaround), unless you first convert the > regular HTML character encoding into the current locale! > Certainly a hairy problem, and one of the main reasons for GTK+2 > design decision of using UCS instead of the current locale as its > internal representation. Now, considering that the default dillo uses Latin1, after reviewing the patch, I found 38% of the big representations table is useless... (and there are other things). > I know you are now hard-working but this patch is not too big > to review... Yes, it is not too big to read, but the work behind integrating a patch is certainly bigger than the patch itself. Most of the time it involves reviewing some RFCs, the internal working structure of the browser in that matter, performance issues, impact, internal standards, future, an so on. IMHO, this is not my duty to do, but the patch sender's, and when I see it was done losely, certainly it discourages me from working on it. If it regards a matter with low priority, then I have one more reason... Now, considering that I have excellent patches in the queue to review (with versions, research, README, Documentation, explanations...), I feel really guilty for dedicating much time to other stuff, but I hope this explanation serves everyone. > Once more sorry. I'm also sorry. Jorge.-

June 19, 2003