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@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
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.-
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@unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]
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
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@lists.auriga.wearlab.de http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev
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.
participants (4)
-
Frank de Lange -
Jens Arm -
Jorge Arellano Cid -
Sebastian Geerken