- 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

Re: [Dillo-dev] Tabbed version of Dillo, remarks

by Sebastian Geerken

On Tue, Jun 17, Frank de Lange wrote: > One last thing before I go to sleep... > > As already stated in the documentation (doc/DilloDoc.txt, but who reads > documentation anyway?), the tabbed version of Dillo sometimes (to be > specific, when loading a tab in the background) produces Gdk_CRITICAL > messages on stderr. Like these: > > Gdk-CRITICAL **: file gdkwindow.c: line 1274 (gdk_window_set_cursor): > assertion `window != NULL' failed. > > These messages come from deep within dw_widget (line 706), and seem to > be caused by an error/a bug in the widget. What seems to happen is that > the widget tries to reset the cursor for a non-existing window > (gdk_window_set_cursor (GTK_LAYOUT(viewport)->bin_window, NULL while the > viewport does not yes have a bin_window defined). > > Sebastian, any input on this? The only thing I can guess now is that the viewport has not been realized now, which is necessary before a DwWidget is added. You may have to enforce this explicitly by gtk_widget_realize. BTW, you can call any Gtk+ program with the "--g-fatal-warnings" option, this will cause the program to abort, so you can get a backtrace in gdb. Sebastian

June 19, 2003

Re: [Dillo-dev] Tabbed version of Dillo

by Sebastian Geerken

On Sun, Jun 08, Frank de Lange wrote: > Sebastian, maybe dw_gtk_scrolled_window needs a method to remove the > gadget? I re-use the BrowserWindow's full_screen_off_button gadget in > all tabs (reparenting it when needed), but I have to forcibly NULLify > the window->gadget attribute to be able to add a new gadget to a > dw_gtk_scrolled_window. It is not 'right' to mess with interal widget > structures... or am I missing something? The code does not seem to > provide a way to remove the gadget once it has been defined. GtkContainer::remove is implemented for GtkDwScrolledWindow (by Dw_gtk_scrolled_window_remove), so you should be able to destroy, unparent etc. the gadget, the GtkDwScrolledWindow will properly "forget" it. I haven't yet tested this, though. Sebastian

June 19, 2003

Re: [Dillo-dev] transient find-dialog

by Jorge Arellano Cid

On Wed, 18 Jun 2003, Andreas Zwinkau wrote: > Hi > > I use ion as my window manager and i found that the find-dialog is not > marked 'transient', but a normal window. This is not a good behaviour in > my eyes, i have to configure ion manually to treat it as transient. > > I must admit i do not fully know, what transient means, but it seems bad > to me to have to configure such things myself. Would you mind reading dillorc? Jorge.-

June 18, 2003

Re: [Dillo-dev] [RFC] Plans for next version of tab patch

by Sebastian Geerken

On Tue, Jun 17, Jorge Arellano Cid wrote: > [...] > Technically, what interests me more about the patch is the > separation of interface code out of document code. > > Now Sebastian is working on another separation; for CSS (it > also involves several files), so I think it is better to keep > both works separated until our re-structuring of the parser is > well defined. I haven't looked yet at the patch yet (I'll do in the next days), but just FYI an overview of the changes: I'll go a bit beyond the changes suggested in <http://www.dillo.org/CSS.html>. Those changes will introduce a new structure named DocDocument, which represents the document in a DOM-like way, and is put as a layer between the HTML parser and Dw (which currently interact closely). See the document mentioned above for motivations and details. Some weeks ago, I decided to restructure also the HTML parser, with two goals in mind: 1. The file html.c is quite large, and it is quite self-evident to split it into three parts: general parsing and tokenizing, handling HTML specific stuff, and the link block, which contains links, forms etc. 2. It would be interesting to make the general parsing code reusable for handling other XML based documents, and even to render XML documents in a way described by CSS. So far, there will be something like the following design: - DilloHtml is replaced by two structures, SgmlParser, and HtmlParser, where the latter is inherited from the first. (I'm not sure the latter one is actually needed, but it is possible to add additional data and code to the base structure). Despite of the name, I do not intend to implement a fully functional SGML parser, it has a quite general interface, but this interface is actually incorrectly implemented, just as correct as it is needed for HTML. (IMO, this is reasonable, more that vice versa ;-) - DilloHtmlLB either remains in its current form, and there will be a new structure SgmlDoc, or SgmlDoc will also be a generalization of DilloHtmlLB. SgmlDoc will refer to the document tree, as well as to the structures needed to represent style sheets, it will exists as long as currently DilloHtmlLB exists. Accesses to DocDocument will be done mostly by the SGML base, while the HTML specific stuff will access the HTML link block, as well as something currently represented by BrowserWindow (what should be changed). Perhaps, there may be changes in the future, e.g. for MathML, there must be other drawing functions in the document tree, so this may be hidden by some kind of interface, but I do not bother about this, because this should be simple to change. Sebastian PS: Sorry for posting an empty reply.

June 18, 2003

Re: [Dillo-dev] [RFC] Plans for next version of tab patch

by Sebastian Geerken

On Tue, Jun 17, Jorge Arellano Cid wrote: > > Hi Frank, > > On Tue, 17 Jun 2003, Frank de Lange wrote: > > > Hej! > > > > Now that the first release of my tab patch is 'out there', I'd like to > > give a short overview of my plans for the next version of this patch. > > If geocities stops working just let me know, or ask Andreas who > mirrored the patch... > > > I > > do not know when I'll be able to release this next version, as I'm busy > > this week, followed by a trip to the UK (back the 13th of juli), but I > > will try to make it relatively soon... > > No problem. > > > Some time ago (maybe a lot), Arvind told me he had developed a > "tabs" patch for dillo: > > http://www.dillo.org/test/dillo_tabs.png > > He had to work on it some more, then he got very busy, and I > haven't heard of it in a long time... > > Technically, what interests me more about the patch is the > separation of interface code out of document code. > > Now Sebastian is working on another separation; for CSS (it > also involves several files), so I think it is better to keep > both works separated until our re-structuring of the parser is > well defined. > > I'd advise you to choose a date from CVS and improve the patch > against it (not trying to catch up with current); that way the > patch can be polished without too much hassle and with the > feedback of interested developers. > > Then, when the time to merge comes, it will be stable, clean > and polished. > > Personally, I can't look at it right now (because of the above > mentioned reasons, plus I'm dedicated to the dillo plugins > extensions). > > NOTE: We have advanced a lot with Ferdi on dpid, so it will > soon be integrated and commited. > > ... it has come a tradition (or better, our way of development) > to test a lot the patches before commiting them in. That way, the > CVS keeps stable, the code clean, and we can keep up with the > ideal of always releasing a better Dillo than the former. > > As you noticed, the patch generated a lot of feedback. I hope > patches start to come just as bug notes! ;) > > > > [...] > > > > Jorge, let me know if/when you plan to commit the patch to CVS > > (read above) > > Last, but not the least, I also think that tabbing is a > function that should/must be done by the WM. I always try to find > "the right place" to put a patch, and IMO it belongs to the WM. > > Now, as these days only a few WMs come with good tabs support, > and as the patch seems small, it should pose no major trouble to > eventually commit it. > > > Welcome aboard! > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

June 18, 2003

Re: [Dillo-dev] </Anti-Tab>

by Andreas Zwinkau

I see your arguments and understand them. The last i wanted was to offend somebody or downgrade Franks work. This patch is something many people wish and so they should get it. Sorry, if i started something, which runs out of order. The problem is not Dillos it is one of the society. We see the most popular window managers/desktop environments Gnome, KDE, OS X, Windows. These dominate the market and everybody else has to adobt and live with it. If these programs have their faults the programs under them have to build around them, while it would be better to change the source of the problems itself. I seems like the HTML problem. Browser do not show everything as they should, so webdesigner use HTML4.01 transitional and <font> to show pages in older browsers as well. Leaving tabbing to the window manager is like leaving layout to CSS. The difference is that the major browsers support it. This world has problems and faults, so we must improvise. I see browser-tabbing as improvising for the people, who like the eye candy of the major window managers. Please don't take this as provocation, activate your browser tabbing and be happy. I deactivate it and i'm happy as well. 'nough said mfg Andreas Zwinkau | web: andi.dasstellenwirinsinternet.de | mail: andi(a)buxach.de | jabber: beza1e1(a)amessage.de

June 18, 2003

transient find-dialog

by Andreas Zwinkau

Hi I use ion as my window manager and i found that the find-dialog is not marked 'transient', but a normal window. This is not a good behaviour in my eyes, i have to configure ion manually to treat it as transient. I must admit i do not fully know, what transient means, but it seems bad to me to have to configure such things myself. mfg Andreas Zwinkau | web: andi.dasstellenwirinsinternet.de | mail: andi(a)buxach.de | jabber: beza1e1(a)amessage.de

June 18, 2003

Re: [Dillo-dev] Location entry shortcuts

by Johan Hovold

Thanks for your reply! On Wed, Jun 18, 2003 at 01:12:08PM +0200, Melvin Hadasht wrote: > >When I tried > > to connect it to the main window, a backspace in a form (or in the > > location bar) would trigger "back". Why is this? > > This is because it is an event rather than a signal. And events can be > transferred to the parent widget if the event handler returns FALSE. So if the > (key) event handler in the entry (location bar) returns FALSE, the event is > forwarded to the other (key) event handlers of the same widget and then to its > parent (the main window). To avoid this, once you handled the event, you can > stop the event transmission by making your event handler return TRUE. See GTK > tutorial about the events handling. I figured that out (see below), but thanks anyway. > > Why doesn't the > > the current key_press_handler receive signals when entering text in a > > form? > > This is related to above. The default entry key event handler returns TRUE. > So I guess you added a key event handler to the entry and made it return FALSE, > am I right? I'm afraid not. I haven't added any event handlers to the location entry (nor to any text widgets for html forms). What I would like to have is a "global" handler, to handle any key presses not handled by a text widgets default handler (like function keys etc...) What I can't figure out is why a key press event is forwarded from a text widgets default handler (e.g. a form) to a handler connected to the main window (bw->main_window), but it is NOT forwarded to a handler connected to the main document window (GTBIN(bw->docwin)->child). Could it be that the main window handler somehow gets called before the text widgets default handler? To reproduce this just connect the current key press handler to bw->main_window instead of docwin->child. Then, entering backspace in an html form will trigger "back". Johan Hovold

June 18, 2003

Re: [Dillo-dev] Location entry shortcuts

by Melvin Hadasht

Hi Johan, on Wed, 18 Jun 2003 12:06 +0200, Johan Hovold wrote: >When I tried > to connect it to the main window, a backspace in a form (or in the > location bar) would trigger "back". Why is this? This is because it is an event rather than a signal. And events can be transferred to the parent widget if the event handler returns FALSE. So if the (key) event handler in the entry (location bar) returns FALSE, the event is forwarded to the other (key) event handlers of the same widget and then to its parent (the main window). To avoid this, once you handled the event, you can stop the event transmission by making your event handler return TRUE. See GTK tutorial about the events handling. > Why doesn't the > the current key_press_handler receive signals when entering text in a > form? This is related to above. The default entry key event handler returns TRUE. So I guess you added a key event handler to the entry and made it return FALSE, am I right? Adiu (Corsican: Farewell) -- Melvin Hadasht

June 18, 2003

Location entry shortcuts

by Johan Hovold

Hi! First I'd like to say thank you to every developer of dillo. For a long time I've been looking for a small and fast browser, and the recent development of opera has made this need even more acute. I've been working on a few improvements to dillos interface, which I will submit shortly, but there one thing I could use some advice on. I'm not a great fan of extensive mouse usage and would therefore like to have a shortcut to focus the location entry. In Mozilla and Opera ctrl-l and F8 respectively, focuses the location entry and selects its contents. Is this the way to go for dillo? Or is it better with one accelerator for location entry "grab_focus" (just focus) and one for the clear button "clicked" (clear and focus). I you prefer the first variant; should this shortcut also be available from within the location entry (one could instead use ctrl-a, ctrl-k), or just when the main document window has focus? The reason for the last question is that the current key_press_handler which handles backspace and '/' is connected to the main document window, and hence doesn't receive signals from the location entry. When I tried to connect it to the main window, a backspace in a form (or in the location bar) would trigger "back". Why is this? Why doesn't the the current key_press_handler receive signals when entering text in a form? Johan Hovold

June 18, 2003

Re: [Dillo-dev] Anti-Tab

by Jyri Jokinen

On Tue, Jun 17, 2003 at 07:29:54 -0700, Chris Palmer wrote: I won't even start to comment on all of it, mainly because this is going off-topic and it would make a really long message. > Let's pretend mainstream window managers like Window Maker, KWM and > Gnome WM Of The Week all supported tabs. How would Dillo tell the window > manager to attach the new window to an existing tab group? Afaik there > is no general protocol for this. I'm pretty sure ICCCM has nothing to > say on this topic. You really haven't looked in to how tabbing window managers work, have you? If so, imho, you are in no place to make comments about the subject. Making it a simple and short story: Clients/windows can be identified by many means, and the window manager can be instructed to group all the windows that match those criterias. > See above. If the toolkit used for both the application and the window > manager were the same, and the toolkit had a general mechanism for tabs, > it would be pretty easy. But not all window managers are implemented in > Gtk, so a protocol is needed. I must be a pure looney for having a working tabbing window manager without such a protocol then. Guess I've just imagined it all for several years now. -- shared, don't bother to answer, i know you didn't get it

June 18, 2003

Re: [Dillo-dev] [RFC] Plans for next version of tab patch

by Jens Arm

Hi If I try to add a bookmark in the tabbed dillo version I get a SegFault: [tux@tux tux]$ dillo Setting locale to C... dillo_dns_init: Here we go! Disabling cookies. Nav_open_url: Url=>about:splash< Nav_open_url: Url=>http://www.dillo.org/< Dns_server [0]: www.dillo.org is 0x810f158 Connecting to 134.102.206.165 Dpi_parse_token: [<dpi cmd='chat' msg='Hi browser'>] Segmentation fault Jens

June 18, 2003

Re: [Dillo-dev] [RFC] Plans for next version of tab patch

by Frank de Lange

Yeah, I'll try to find a good CVS drop to update against (possibly the 0.7.3 release, if that comes relatively soon) and tune the patch to that. <rant mode='puritan'> On the issue of 'tabbing being a feature of the WM, not the app' lots of words have been spoken, maybe wasted. That is one of the reasons I made the whole tab feature optional, so those who take different views can have tabs while the rest can ./configure --disable-tabs and use a tabbed WM. I personally think that a feature which is wanted by many should be implemented, unless is really breaks something bad - security, interoperability, bloat, etc. Tabs do not break anything (if they do, it is a bug, file it or fix it), many people want them, and - most importantly - the VAST majority of WM's does NOT offer tab features. So, currenty, for most people, to get tabs you more or less HAVE to put them in the browser. The WM's which do offer tabs are not really suitable for everyone yet. Once they are - or once the 'main' window managers adopt a good tabbing feature - yes, tabs should probably move to the WM unless there is a compelling reason to have them in the app (I do not know of such a reason). As long as they are not it would be senseless puritanism to NOT put tabs in the browser as an OPTION. Spoken by a user of the Ion WM... </rant> As stated before, I might not have much time the next few weeks, but will try to keep things going anyway. After the 13th of july I expect to have more time... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

June 18, 2003

Re: [Dillo-dev] Anti-Tab

by Chris Palmer

Jyri Jokinen writes: > "Everybody" doesn't want tabs inbrowser. That's a fact. Look around you. Mere semantics, as Kelson Vibber noted. > There are a lot of window managers other than PWM that support window > tabbing - one of the best is Pekwm, wich i've been using for surfing > with dillo for an eternity now. Waimea and Fluxbox are also getting > there slowly, but their implementations lack usability at the moment. Three obscure window managers, and of those, only one is usable enough even for a motivated expert user like yourself. Let's pretend mainstream window managers like Window Maker, KWM and Gnome WM Of The Week all supported tabs. How would Dillo tell the window manager to attach the new window to an existing tab group? Afaik there is no general protocol for this. I'm pretty sure ICCCM has nothing to say on this topic. > Having tab support in a window manager is flexiple. Much more flexiple > then they can ever get in a, lets say browser, without writing a > complete internal window manager. If the functionality doesn't exist, you have to create it. It didn't exist, and Frank created it. Are you going to create a protocol for tabbing in window managers, and convince all the wm developers to adopt it? Are you going to help them implement it? > > It would not be easy to use since the toolkit (Gtk) is not tightly > > integrated with the window manager > > How should this be of any importance? Please enlighten me, who wonder > in the dark. See above. If the toolkit used for both the application and the window manager were the same, and the toolkit had a general mechanism for tabs, it would be pretty easy. But not all window managers are implemented in Gtk, so a protocol is needed. > I care to object on the plea of ease of use. This far all the tabbin > browsers i have tried have been overly complicated to use compared to > the way pekwm handles it. It's a simple Ctrl-T in Phoenix and Command-T in Camino to create new tabbed windows. Ctrl-W/Command-W closes them. You can drag links to the tabs to cause that link to load in the indicated tab. That's pretty simple. Of course, your window manager will trap or ignore those keystrokes, making that very simple mechanism impossible. The window manager will have to support all of the several possible drag-and-drop protocols applications might use. Oops! > And the sheer fact that i can rebind my keys and mouse clicks with the > window manager but not with the browsers is enough to convince me of > ease of use. Hacking configuration files is not my idea of great ease of use. Software usability is acheived in part by defining and adhering to a user interaction policy. The X Window System and related projects have always eschewed policy setting; instead, only a mechanism is provided. (In some cases, not even a mechanism was provided: window management itself was an afterthought, as was drag-and-drop.) That leaves application developers "free" to devise their own wacky schemes, all different. The inevitable result is pain for users. > There are many great window manager projects developed, The very idea of a window manager as a distinct entity is stupid, from a usability point of view. There aren't 200 window managers for Mac OS, Mac OS X, Windows, PalmOS or BeOS. The makers of those products were trying to make something people could use. > and i do hope you take attleast that one back. After all, dillo once > was a petty crappy piece of software (and still is for an untrained > eye), but it has potential. Just like many of those window manager > projects, which you seem to doom as a byproduct to make a wery pointed > point. My point is simply this: For Dillo to succeed, it must meet the needs of users. Web browser users tend to open many documents at a time, and surf between them. They need a way to manage the clutter, and Frank has provided that in a manner similar to that used in other web browsers. Users also need HTTPS, which has also generously been provided. As of right now (I just updated CVS), HTTPS support is not in the source tree. > Closing word, The fact that dillo now could and probably will have > tabbing support is absolutely great. The fact that the work put into > it might get us closer to having frame support is absolutely great. > The fact that I can toggle it off at compilr time is absolutely great. > People being more or less out of order in a mailing list about a > matter like this is _not_great_. I agree! Everyone should be sending Frank cases of beer, not yelling at him for adding "bloat" or saying "That's great, but we prefer to do it in a way that is pretty much impossible to implement, so no thanks."

June 18, 2003

RE: [Dillo-dev] [RFC] Plans for next version of tab patch

by Eric Gaudet

> I'd advise you to choose a date from CVS and improve the patch > against it (not trying to catch up with current); that way the > patch can be polished without too much hassle and with the > feedback of interested developers. > I recommend we tag cvs for such things, to get an easy reference, or better yet, we branch, so merging is easy.

June 17, 2003

Re: [Dillo-dev] [RFC] Plans for next version of tab patch

by Jorge Arellano Cid

Hi Frank, On Tue, 17 Jun 2003, Frank de Lange wrote: > Hej! > > Now that the first release of my tab patch is 'out there', I'd like to > give a short overview of my plans for the next version of this patch. If geocities stops working just let me know, or ask Andreas who mirrored the patch... > I > do not know when I'll be able to release this next version, as I'm busy > this week, followed by a trip to the UK (back the 13th of juli), but I > will try to make it relatively soon... No problem. Some time ago (maybe a lot), Arvind told me he had developed a "tabs" patch for dillo: http://www.dillo.org/test/dillo_tabs.png He had to work on it some more, then he got very busy, and I haven't heard of it in a long time... Technically, what interests me more about the patch is the separation of interface code out of document code. Now Sebastian is working on another separation; for CSS (it also involves several files), so I think it is better to keep both works separated until our re-structuring of the parser is well defined. I'd advise you to choose a date from CVS and improve the patch against it (not trying to catch up with current); that way the patch can be polished without too much hassle and with the feedback of interested developers. Then, when the time to merge comes, it will be stable, clean and polished. Personally, I can't look at it right now (because of the above mentioned reasons, plus I'm dedicated to the dillo plugins extensions). NOTE: We have advanced a lot with Ferdi on dpid, so it will soon be integrated and commited. ... it has come a tradition (or better, our way of development) to test a lot the patches before commiting them in. That way, the CVS keeps stable, the code clean, and we can keep up with the ideal of always releasing a better Dillo than the former. As you noticed, the patch generated a lot of feedback. I hope patches start to come just as bug notes! ;) > [...] > > Jorge, let me know if/when you plan to commit the patch to CVS (read above) Last, but not the least, I also think that tabbing is a function that should/must be done by the WM. I always try to find "the right place" to put a patch, and IMO it belongs to the WM. Now, as these days only a few WMs come with good tabs support, and as the patch seems small, it should pose no major trouble to eventually commit it. Welcome aboard! Jorge.-

June 17, 2003

Re: [Dillo-dev] Anti-Tab

by Frank de Lange

Andreas Zwinkau wrote: > I just want to throw in, that tabbing may be a bloat-feature. Just > because every modern browser has it and everybody wants it, i needn't to > be necessary. I watched a similar discussion some time ago and a wise > argument convinced me, that tabbing is not a task for a browser. > > Before you call me loony, listen. > Tabbing is about handling different windows, but handling windows is > nothing a browser should do. Leave to the programs, which are made for > especially that: Window Managers! Tabbing should not be implemented in a > browser, but in the window manager. > > Sorry, if KDE and Gnome don't support it (i think, am i wrong?) > > Just my 2ct ;) Have a look at the numbers I included on the 'bloat' caused by tabs. You can find this information in the doc/Browser_Tabs.txt file: CFLAGS ------------------------------------------------------------------------- tabs | -g -g stripped -O2 -O2 stripped -Os -Os stripped ........|---------------------------------------------------------------- enabled | 3558892 390204 384453 316444 359821 291868 | disabled| 3468465 381916 374382 308188 350454 284316 | (before)| 3332856 377920 373773 308000 349141 283424 Versions and settings --------------------- gcc: 3.2.2 binutils:2.13.90.0.18 In other words, tabs add all of 7552 bytes to Dillo, on a total size of 291868 bytes. Now please tell me if this is bloat. Also, remember that tabbing window managers are not for everyone. And tabbing is OPTIONAL. Use the --disable-tabs option and there will be no tab code in you binary. So what is the problem again? Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

June 17, 2003

Re: [Dillo-dev] Anti-Tab

by Kelson Vibber

At 10:43 AM 6/17/2003, Jyri Jokinen wrote: > > When it comes to software, "everybody wants it" is a really, really > > good sign that the feature is necessary. > >"Everybody" doesn't want tabs inbrowser. That's a fact. Look around you. That's just semantics. Perhaps not "everybody," but certainly many people love using tabs with their web browsers. Tabs were the main "killer feature" for Mozilla 1.0 (every review of Mozilla for months talked about them), and were requested immediately upon the announcement of Safari. Tabbed browsing (of some sort) is extremely popular. The main disagreement is over where to put the code. > > Implementing it in the application is the best way to do it, given the > > realities of the X Window System. > >As someone pretty happily using a tabbing window manager - could I get >closer information on this, thank you. I don't mean to put words in anyone's mouth, but the way I read this was that the "realities" of X are that there are many different window managers out there, and that the most popular ones do *not* handle tabs themselves. When KWM, Metacity (or whatever Gnome is using by then), and other WMs shipped by default feature well-done tabbed windowing, then putting the code in the browser will be redundant. But for now, they don't, and the best way to handle everyone who wants this for their web browser - assuming it doesn't triple the size of the code (and this doesn't appear to) - is to go ahead and put the code in the browser. Kelson Vibber SpeedGate Communications <www.speed.net>

June 17, 2003

Re: [Dillo-dev] Suggestion for a next dillo version

by Kelson Vibber

At 03:16 AM 6/16/2003, Manuel Serrano wrote: >I was wondering if it could be possible to have an automatic >hidden bar such as in many window manager (fluxbox, kde, gnone, >...). That is the navigation bar is automatically hidden until the >mouse fly over the very top lines. Whether it's technically feasible or not, I don't think this would be very usable, except perhaps in full-screen mode (by which I mean having the dillo window taking up the entire screen, with no title bar at the top). The activation area for one of these has to be narrow, or else you use up the space you gained by hiding it. And having a narrow area - say, the size of a window border - only works if you (a) are doing something that requires precision anyway, like resizing a window, or (b) can't miss it. The reason auto-hide and auto-show works for window managers is that they are at the edge of the screen, and there's nowhere else for the mouse cursor to go. You don't have to worry about hitting an exact area, you just send it in that direction and the toolbar appears. This is true for KDE, Gnome, Windows, Mac OS X, and so on. Putting this in a window would mean hitting something like a 5-pixel wide border, then hitting the toolbar buttons - essentially making it a drop-down menu that's hard to reach and extends horizontally instead of vertically. IMO, it would be more usable to take it a step further and make it an actual drop-down menu, with an activation area the size of the "show controls" button. (I'm not sure how the URL control would fit into this, though.) The exception would be if this were aimed at a true full-screen mode, in which case you gain the same advantages that window managers have by stopping at the edge of the screen. Kelson Vibber www.hyperborea.org

June 17, 2003

Re: [Dillo-dev] IFRAME element stub

by Jorge Arellano Cid

On Sat, 14 Jun 2003, Stephen Lewis wrote: > On Wed, 11 Jun 2003 11:32:22 -0400 (CLT) > Jorge Arellano Cid <jcid(a)softhome.net> wrote: > > > > > Nikita, > > > > > Hi all Dillo developers ! > > > > > > There is a very small patch to support IFRAME HTML element. It does > > > nothing except handling IFRAME via FRAME handler so special IFAME > > > attributes(width and height) are not handled but this patch is > > > suitable for current temporary solution (as we do not have real > > > frame support for now). > > > > Done! > > Just a comment about this - I'm using a recent CVS version some time > after this was integrated, and it causes some display issues with a lot > of sites. In particular, sites that use narrow IFRAMEs for ads in a > table(e.g. http://www.osnews.com, http://arstechnica.com/ ). The > displayed URL seems to force the column width to be much, much wider > than it normally would, making these websites look very bad (very wide > column with ads, very narrow column with actual text :/ ) > > It's great having this patch apart from the display issues it causes. > Would it be possible to make the displayed URL wrap? > [...] > I just wanted to make sure it hadn't > slipped through unnoticed. Of course, if I'd actually read your Well, I noticed the problem shortly after commiting, but as I'm working hevily in dpid (with Ferdi) I didn't have the time to address it. > As an aside, it was quite an eye-opener viewing websites with this > patch, I discovered many sites which I had thought to be free from > advertising were in fact saturated with it > - they were having about as > much effect on me using Dillo as all of those pop up/under ads I hear > about all the time ;) Dillo helps a lot with advertising filtering. Also, popups don't show because of no javascript support. Yes, it was an "eye opener" to see those instrumentations. After some thought I decided to name the link "IFRAME" (the destination shows on the status bar). The patch is now in the CVS. There may still be some problems (if IFRAME is used as a web bug; i.e. invisible IFRAME for spying). I think it will be very interesting to browse and "see" what comes down the line. Another goodie of this approach is that you can search for the "IFRAME" word, and locate them. Cheers Jorge.-

June 17, 2003

Re: [Dillo-dev] Anti-Tab

by Jyri Jokinen

On Tue, Jun 17, 2003 at 09:04:12 -0700, Chris Palmer wrote: > Bloat is when you embed a flight simulator into a spreadsheet program. > Tabs do not bloat Dillo. I agree on this. If tabbing takes us closer to frames, they are ok. Otherwise, i couldn't more disagree with your views. > When it comes to software, "everybody wants it" is a really, really > good sign that the feature is necessary. "Everybody" doesn't want tabs inbrowser. That's a fact. Look around you. > Maybe the feature could be implemented in the window manager, but not > everybody uses PWM, or wants to. There are a lot of window managers other than PWM that support window tabbing - one of the best is Pekwm, wich i've been using for surfing with dillo for an eternity now. Waimea and Fluxbox are also getting there slowly, but their implementations lack usability at the moment. Having tab support in a window manager is flexiple. Much more flexiple then they can ever get in a, lets say browser, without writing a complete internal window manager. Simple tabbing support built into a browser can however be wery usefull in certain situations, and an implmentation like the one in question is a wery good exmple of a well made job. > It would not be easy to use since the toolkit (Gtk) is not tightly > integrated with the window manager How should this be of any importance? Please enlighten me, who wonder in the dark. I care to object on the plea of ease of use. This far all the tabbin browsers i have tried have been overly complicated to use compared to the way pekwm handles it. And the sheer fact that i can rebind my keys and mouse clicks with the window manager but not with the browsers is enough to convince me of ease of use. > (any of 600 crappy things on Freshmeat). There are many great window manager projects developed, and i do hope you take attleast that one back. After all, dillo once was a petty crappy piece of software (and still is for an untrained eye), but it has potential. Just like many of those window manager projects, which you seem to doom as a byproduct to make a wery pointed point. > Implementing it in the application is the best way to do it, given the > realities of the X Window System. As someone pretty happily using a tabbing window manager - could I get closer information on this, thank you. Closing word, The fact that dillo now could and probably will have tabbing support is absolutely great. The fact that the work put into it might get us closer to having frame support is absolutely great. The fact that I can toggle it off at compilr time is absolutely great. People being more or less out of order in a mailing list about a matter like this is _not_great_. Please get your acts together. I've used to expecting quality posts in this list. -- shared, sorry for feeding it, it just looked so wery hungry

June 17, 2003

Re: [Dillo-dev] [PATCH] Tabbed version of Dillo, now available on geocities

by Phil Pennock

On 2003-06-17 at 10:44 +0200, Frank de Lange wrote: > On Tue, Jun 17, 2003 at 10:10:22AM +0200, Andreas Schweitzer wrote: > > - On my FreeBSD 4.8 system with gcc version 2.95.4 I need > > to move one line to make it compile like : > > Yeah, the code needs some cleanup still. I'll go through it for the next patch, > and try it on FreeBSD as well. That particular problem wasn't caused by FreeBSD. It's because the code made use of a C99 feature, allowing variables to be declared anywhere, not just at the head of a function. If you're using gcc 3.<something>, then you can use "gcc -std=c89" to ensure conformance to the older standard. It _should_ highlight issues like this one. HTH, -- 2001: Blogging invented. Promises to change the way people bore strangers with banal anecdotes about their pets. <http://www.thelemon.net/issues/timeline.php>

June 17, 2003

Re: [Dillo-dev] Anti-Tab

by Chris Palmer

Andreas Zwinkau writes: > I just want to throw in, that tabbing may be a bloat-feature. Just > because every modern browser has it and everybody wants it, i needn't to > be necessary. Bloat is when you embed a flight simulator into a spreadsheet program. Tabs do not bloat Dillo. When it comes to software, "everybody wants it" is a really, really good sign that the feature is necessary. Maybe the feature could be implemented in the window manager, but not everybody uses PWM, or wants to. It would not be easy to use since the toolkit (Gtk) is not tightly integrated with the window manager (any of 600 crappy things on Freshmeat). Implementing it in the application is the best way to do it, given the realities of the X Window System. Thank you, Frank! Tabbing is great.

June 17, 2003

Re: [Dillo-dev] Anti-Tab

by Andreas Schweitzer

On Tue, Jun 17, 2003 at 02:46:04PM +0200, Andreas Zwinkau wrote: > I just want to throw in, that tabbing may be a bloat-feature. Just > because every modern browser has it and everybody wants it, i needn't to > be necessary. I watched a similar discussion some time ago and a wise > argument convinced me, that tabbing is not a task for a browser. I really don't mind if tabs are out of dillo. And in the end I will agree, that having tabs is something that is not needed. However, in this case, as I said in some time ago, it looks like the coding design can easily be used to implement frames. I haven't looked at the code yet, though. But if the implemented division of browser window and interface is done as I think it is done, then frames are a natural consequence to code. That is the main reason why I am that interested in this patch. Btw, I think the binary increased by only 10kB on my machine. Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

June 17, 2003

dillo tabbed version

by linux seaq

HI, everybody just reporting a succesful compilation of tabbed dillo. 'til now its working flawlessly. Thanks a lot for it.

June 17, 2003

Re: [Dillo-dev] Anti-Tab

by Madis Janson

On Tue, 17 Jun 2003, Andreas Zwinkau wrote: > I just want to throw in, that tabbing may be a bloat-feature. Just > because every modern browser has it and everybody wants it, i needn't to > be necessary. I watched a similar discussion some time ago and a wise > argument convinced me, that tabbing is not a task for a browser. > > Before you call me loony, listen. > Tabbing is about handling different windows, but handling windows is > nothing a browser should do. Leave to the programs, which are made for > especially that: Window Managers! Tabbing should not be implemented in a > browser, but in the window manager. > > Sorry, if KDE and Gnome don't support it (i think, am i wrong?) > > Just my 2ct ;) > I think, thats why we have the configure options :)

June 17, 2003

Anti-Tab

by Andreas Zwinkau

I just want to throw in, that tabbing may be a bloat-feature. Just because every modern browser has it and everybody wants it, i needn't to be necessary. I watched a similar discussion some time ago and a wise argument convinced me, that tabbing is not a task for a browser. Before you call me loony, listen. Tabbing is about handling different windows, but handling windows is nothing a browser should do. Leave to the programs, which are made for especially that: Window Managers! Tabbing should not be implemented in a browser, but in the window manager. Sorry, if KDE and Gnome don't support it (i think, am i wrong?) Just my 2ct ;) mfg Andreas Zwinkau | web: andi.dasstellenwirinsinternet.de | mail: andi(a)buxach.de | jabber: beza1e1(a)amessage.de

June 17, 2003

tabbed patch crashes when adding bookmark

by Madis Janson

when a_Interface_msg is called. (gdb) bt #0 0x4019752d in gtk_type_check_object_cast () from /usr/lib/libgtk-1.2.so.0 #1 0x08073c05 in a_Interface_msg (bw=0x80a1268, format=0x8278f10 "Hi browser") at interface.c:763 #2 0x08056eab in a_Capi_ccc (Op=2, Branch=138708789, Dir=1, Info=0x80ff670, Data1=0x8278f10, Data2=0x8448730) at capi.c:330 #3 0x08054b2e in a_Chain_fcb (Op=2, Info=0xa, Data1=0x8278f10, Data2=0x8448730) at chain.c:95 #4 0x0807bf64 in Dpi_parse_token (conn=0x82b6fa8) at dpi.c:272 #5 0x0807bfa1 in Dpi_process_io (Op=4, Data1=0xa, conn=0x82b6fa8) at dpi.c:296 #6 0x08054b2e in a_Chain_fcb (Op=2, Info=0xa, Data1=0x823ebd8, Data2=0x0) at chain.c:95 #7 0x0807c9da in IO_read (io=0x823ebd8) at IO.c:420 #8 0x0807cabd in IO_callback (src=0x8120910, cond=G_IO_IN, data=0x617) at IO.c:504 #9 0x40217a56 in g_io_add_watch () from /usr/lib/libglib-1.2.so.0 #10 0x4021903d in g_get_current_time () from /usr/lib/libglib-1.2.so.0 #11 0x402194f4 in g_get_current_time () from /usr/lib/libglib-1.2.so.0 #12 0x40219724 in g_main_run () from /usr/lib/libglib-1.2.so.0 #13 0x4013fc3f in gtk_main () from /usr/lib/libgtk-1.2.so.0 #14 0x08067215 in main (argc=1, argv=0xbffffb04) at dillo.c:298 Bandaid fix seems to be commenting out code, which causes calling a_Interface_msg in dpi code (a_Interface_msg call in a_Capi_ccc and send_status_msg branch in Dpi_parse_token).

June 17, 2003

Re: [Dillo-dev] [RFC] Plans for next version of tab patch

by Jens Arm

Hi The dillo-tab-version is fine work !!! > There might be more, or less. Let me know. Opening new tab instead of window when middle-clicking on a link. Would be nice ;) Perhaps this should be an option in the config-file where this is choosable? Jens

June 17, 2003

[RFC] Plans for next version of tab patch

by Frank de Lange

Hej! Now that the first release of my tab patch is 'out there', I'd like to give a short overview of my plans for the next version of this patch. I do not know when I'll be able to release this next version, as I'm busy this week, followed by a trip to the UK (back the 13th of juli), but I will try to make it relatively soon... Anyway, some plans: Architecture ------------ - further separate interface code out of document code (interface messages currently go directly to the interface, some mediation might be necessary) Functionality ------------- - focus tab contents on tab switch (so key navigation works correctly without having to first click in the tab pane) - focus location bar on switch to empty tab/new tab - new empty tab should show/focus, even when 'tab load in background' is set - after tab delete, switch to NEXT tab instead of PREVIOUS (like mozilla) Coding ------ - clean up code organisation (declarations before g_return/comments) Bugs ---- - full screen off widget does not show after tab switch in full screen (probably hidden, it IS reparented) There might be more, or less. Let me know. Jorge, let me know if/when you plan to commit the patch to CVS Sebastian, do you have any suggestions as to why dw_widget tries to set the cursor on a non-existing bin_window in the mouse event code? See my earlier message on the Gdk-CRITICAL messages which sometimes appear when opening a document in a tab in the background... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

June 17, 2003

Re: [Dillo-dev] [PATCH] Tabbed version of Dillo, now available on geocities

by Frank de Lange

On Tue, Jun 17, 2003 at 10:10:22AM +0200, Andreas Schweitzer wrote: > Hi, > > > I put my patch for a tabbed version of Dillo on a geocities page, so if > > you are quick you might be able to download it before Yahoo? shuts it > > down because the site has exceeded its puny transfer allowance. > > I put it as a mirror on > http://www.hs.uni-hamburg.de/~stcd102/dillo-20030615-tabs.patch.gz > > md5 of the ungzipped version is : > MD5 (dillo-20030615-tabs.patch) = 430aa3489ab88e3fec5486786c7d7648 > > Maybe Frank should double check that. I just downloaded your mirrored copy, the uncompressed patch is identical to the one I distributed. Good. > A few notes : > - on first inspection it works ;-) I hope it also works on more than first inspection. It does for me... > - On my FreeBSD 4.8 system with gcc version 2.95.4 I need > to move one line to make it compile like : Yeah, the code needs some cleanup still. I'll go through it for the next patch, and try it on FreeBSD as well. > - and last : the patches against configure and one Makefile.in won't apply, > but this can be ignored if I do another ./autogen.sh; ./configure step after > patching. I will exclude the 'generated' files in the next patch. > Now, on to finding some time to playing with it :-) ... hmmmm .... frames .... Try the tabs first I'd say, and give some feedback on the design of DilloDoc... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

June 17, 2003

Re: [Dillo-dev] [PATCH] Tabbed version of Dillo, now available on geocities

by Andreas Schweitzer

Hi, > I put my patch for a tabbed version of Dillo on a geocities page, so if > you are quick you might be able to download it before Yahoo? shuts it > down because the site has exceeded its puny transfer allowance. I put it as a mirror on http://www.hs.uni-hamburg.de/~stcd102/dillo-20030615-tabs.patch.gz md5 of the ungzipped version is : MD5 (dillo-20030615-tabs.patch) = 430aa3489ab88e3fec5486786c7d7648 Maybe Frank should double check that. A few notes : - on first inspection it works ;-) - On my FreeBSD 4.8 system with gcc version 2.95.4 I need to move one line to make it compile like : $ diff -c tab.c.frank tab.c.new *** tab.c.frank Tue Jun 17 10:01:42 2003 --- tab.c.new Tue Jun 17 10:03:30 2003 *************** *** 304,309 **** --- 304,311 ---- void a_Tab_visibility_update(BrowserWindow *bw) { + gboolean hide_tabs; + g_return_if_fail(bw != NULL); /* this gets called in the tab switching code, which in turn gets called when *************** *** 313,320 **** */ if(!GTK_IS_CONTAINER(bw->container)) return; - - gboolean hide_tabs; /* HIDE tab bar IF * - there is only one tab left AND the preference tab_bar_show_single_tab --- 315,320 ---- - and last : the patches against configure and one Makefile.in won't apply, but this can be ignored if I do another ./autogen.sh; ./configure step after patching. Now, on to finding some time to playing with it :-) ... hmmmm .... frames .... Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

June 17, 2003

Re: [Dillo-dev] [PATCH] Tabbed version of Dillo

by Frank de Lange

TheStar wrote: > An "unofficial" screenshot of a tabbed dillo would be nice - perhaps a site: > "Unofficial */HaCkEd/* Screenshots"? > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev Screenshot on the patch website (geocities, so start your ad-blockers...) http://www.geocities.com/ikbenfrank/ Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

June 17, 2003

Re: [Dillo-dev] [PATCH] Tabbed version of Dillo

by TheStar

An "unofficial" screenshot of a tabbed dillo would be nice - perhaps a site: "Unofficial */HaCkEd/* Screenshots"?

June 17, 2003

Re: [Dillo-dev] [PATCH] Tabbed version of Dillo

by Frank de Lange

Frank de Lange wrote: > Frank de Lange wrote: > >> Raphael Barabas wrote: >> >>> On Tue, Jun 17, 2003 at 12:43:30AM +0200, Frank de Lange wrote: >>> >>>> You decide. >>> >>> >>> >>> >>> i love it. it's just what i've been waiting for. >>> i know, i know. tabbing should be done by the window manager. but >>> until every window manager (or at least, my favorite) has implemented >>> tabbing, i will enjoy this patch. browsing the web is the only thing >>> where i really want tabbing anyway. >>> >>> oh, and i just noticed it segfaults when i middle-click a link. :) >> >> >> >> Hm, yeah it does. Did not used to do that. Must have messed something >> up somewhere. Well, that is why I sent the patch around of course... >> >> Will look into that when I am less sleepy... >> >> Cheers//Frank > > > I see what has gone wrong, I missed a small piece of the patch. Will > include it in a new version tomorrow... If you want to fix it by hand, > just change line 257 of html.c from: > > - a_Commands_open_link_nw_callback(NULL, lb->dd); > + a_Commands_open_link_nw_callback(NULL, lb->dd->bw); > > and it should work again. > > Sorry for the inconvenience... > > Cheers//Frank I fixed the patch on the geocities website: http://www.geocities.com/ikbenfrank/dillo-20030615-tabs.patch.gz So, anyone who got the patch in the first hour or so after release, please get it again... It missed a small, but essential part... The md5sum of the new, fixed patch is a72edfd6c6fe3fab5153df9bde760985, it is 42305 bytes. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

June 17, 2003

Re: [Dillo-dev] [PATCH] Tabbed version of Dillo

by Frank de Lange

Frank de Lange wrote: > Raphael Barabas wrote: > >> On Tue, Jun 17, 2003 at 12:43:30AM +0200, Frank de Lange wrote: >> >>> You decide. >> >> >> >> i love it. it's just what i've been waiting for. >> i know, i know. tabbing should be done by the window manager. but >> until every window manager (or at least, my favorite) has implemented >> tabbing, i will enjoy this patch. browsing the web is the only thing >> where i really want tabbing anyway. >> >> oh, and i just noticed it segfaults when i middle-click a link. :) > > > Hm, yeah it does. Did not used to do that. Must have messed something up > somewhere. Well, that is why I sent the patch around of course... > > Will look into that when I am less sleepy... > > Cheers//Frank I see what has gone wrong, I missed a small piece of the patch. Will include it in a new version tomorrow... If you want to fix it by hand, just change line 257 of html.c from: - a_Commands_open_link_nw_callback(NULL, lb->dd); + a_Commands_open_link_nw_callback(NULL, lb->dd->bw); and it should work again. Sorry for the inconvenience... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

June 17, 2003

Re: [Dillo-dev] [PATCH] Tabbed version of Dillo, now available on geocities

by Frank de Lange

Todd Slater wrote: > On Tue, 17 Jun 2003 02:07:20 +0200 > Frank de Lange <frank(a)unternet.org> wrote: > > >>Todd Slater wrote: > > >>>This is great, Frank! How does one apply the patch? >>>Todd >> >>First, take a chicken... >> >>Well, no, skip the chicken, get the CVS version of Dillo instead (see >>the Dillo website for how to do this). Go to the base directory >>(/usr/src/dillo-cvs/dillo or something like that), and apply the patch >>using something like zcat name_of_gzipped_patch_file|patch -p1. If >>everything went allright, you now have a patched version of Dillo. >> >>So: >> get CVS version of Dillo >> get patch >> cd /to/where/you/put/dillo >> zcat /where/you/put/dillo-20030615-tabs.patch.gz | patch -p1 >> >> ./autogen.sh (this rebuilds the auto*tools files) >> ./configure (with the usual options like --prefix=, etc) >> (if you want to DISABLE tabs, use --disable-tabs after configure) >> make >> su -c 'make uninstall && make install' >> >>But, err, you already knew that, or you would not be subscribed to a >>developers list, right? >> >>It is late, I should sleep now. >> >>Go'Natt//Frank > > > I was looking forward to the chicken! > > I thought that's what I was supposed to do; however, I get this: > > [todd@clevername dillo]$ zcat ../dillo-20030615-tabs.patch.gz | patch > -p1 > patching file ChangeLog > can't find file to patch at input line 21 > Perhaps you used the wrong -p or --strip option? > The text leading up to this was: > -------------------------- > |diff -pruN dillo/configure dillot/configure > |--- dillo/configure 2003-05-26 14:08:02.000000000 +0200 > |+++ dillot/configure 2003-06-13 19:38:12.000000000 +0200 > -------------------------- > File to patch: > > Do I need to specify the file, or is something else wrong? > > BTW, I'm in the dillo directory when I do this, not the src directory. > Correct? > > Sorry for being such a bonehead! > > Todd You need to run ./autogen.sh on the CVS version of Dillo first (this creates the configure file, and other files), or just skip this file (and the others it might complain about). I might remove the 'generated' files from the next version of the patch - which will result in people asking why they do not get the new configure options (because they forgot to run ./autogen.sh after applying the patch...) Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

June 17, 2003

Re: [Dillo-dev] [PATCH] Tabbed version of Dillo

by Frank de Lange

Raphael Barabas wrote: > On Tue, Jun 17, 2003 at 12:43:30AM +0200, Frank de Lange wrote: > >>You decide. > > > i love it. it's just what i've been waiting for. > > i know, i know. tabbing should be done by the window manager. but > until every window manager (or at least, my favorite) has implemented > tabbing, i will enjoy this patch. browsing the web is the only thing > where i really want tabbing anyway. > > oh, and i just noticed it segfaults when i middle-click a link. :) Hm, yeah it does. Did not used to do that. Must have messed something up somewhere. Well, that is why I sent the patch around of course... Will look into that when I am less sleepy... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

June 17, 2003

Re: [Dillo-dev] [PATCH] Tabbed version of Dillo

by Raphael Barabas

On Tue, Jun 17, 2003 at 12:43:30AM +0200, Frank de Lange wrote: > You decide. i love it. it's just what i've been waiting for. i know, i know. tabbing should be done by the window manager. but until every window manager (or at least, my favorite) has implemented tabbing, i will enjoy this patch. browsing the web is the only thing where i really want tabbing anyway. oh, and i just noticed it segfaults when i middle-click a link. :) thanks, raphael

June 17, 2003

Tabbed version of Dillo, remarks

by Frank de Lange

One last thing before I go to sleep... As already stated in the documentation (doc/DilloDoc.txt, but who reads documentation anyway?), the tabbed version of Dillo sometimes (to be specific, when loading a tab in the background) produces Gdk_CRITICAL messages on stderr. Like these: Gdk-CRITICAL **: file gdkwindow.c: line 1274 (gdk_window_set_cursor): assertion `window != NULL' failed. These messages come from deep within dw_widget (line 706), and seem to be caused by an error/a bug in the widget. What seems to happen is that the widget tries to reset the cursor for a non-existing window (gdk_window_set_cursor (GTK_LAYOUT(viewport)->bin_window, NULL while the viewport does not yes have a bin_window defined). Sebastian, any input on this? Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

June 17, 2003