- Dillo-dev - lists.mailman3.com

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