- Dillo-dev - lists.mailman3.com

Browser tabs vs. window manager tabs, again (Was: [Dillo-dev] Proposal: United Dillo)

by Jyri Jokinen

On Mon, Nov 24, 2003 at 12:12:49PM +0100, Stephan Goetter wrote: > > I said "browser tabs". Window manager level window grouping is ok, > > and renders browser tabs useless. That was/is the point. This stuff is on the way of becoming off topic to the list, please try to keep it attleast somewhat Dillo related if you reply (or reply off list). > I'm using fluxbox as well and still do use dillo-tabs heavily. Why? I don't know. Because you are using a window manager with a bad implementation of the concept of window grouping? > With Frank's patch I do just open one window per news-site and every > message in a new sub-tab. My open window-tabs still get clear i.e. <20 > instead of having 50 mixed. This by no means is impossible with window manager window grouping. Instead of having to nest windows, why don't you open a new group for different news sites? Also, can you move browser tabs around your browser windows, that are all around your viewports and workspaces, when it becomes necessary? About nesting - when is there enough? How deep do you want to dive, and when does it become unusable? Next you want subtabs to your web broser so you can "group what you are doing" better and better. Never did you consider of just opening different windows for those groups. > So the can-be-done-with-window-manager-as-well argument doesn't really > exist for me. I don't undestand why you insist using a window manager that doesn't do what you want, and you have to rely on application based extensions to do those things instead. Thus, there is code dublication and implementations that differ from application to application, multiplied configuration process needed for every application - oh, and probably twice the bugs too. This situation really can't be for the good of anyone. I'm somewhat sorry to see Dillo go tabs, even it serves some of the project goals (even those who are using a window manager they really don't want to use and can't change it for a reason or another have the bliss of tabs). I bet we get a kitchen sink too at some point for the same reasons (even those with no kitchen sink can see a kitchen sink). But I do think I've said this enough times allready. Please reply off the list if you have additional questions or points to make. -- shared, pekwm people

Nov. 24, 2003

Re: [Dillo-dev] gcc 2.95 doesn't know about -Wno-unused-parameter

by Jorge Arellano Cid

On Sun, 23 Nov 2003, David McKee wrote: > Jorge, > I suppose you're getting tired of hearing about my ancient Redhat > system, but my gcc doesn't believe in -Wno-unused-parameters, preferning > "-Wno-unused". > > Easy enough to fix by hand. -Wno-unused is a different thing: it eliminates all the "unused" type warnings. That's not the desired effect (`info gcc` for details). If you add a simple way to test whether gcc accepts the warning option, in configure.in, it'd be ok. > Perhaps I should look nto configure in my copious spare time. Cheers Jorge.-

Nov. 24, 2003

[PATCH] Version 16 of tab/frame/kbnav/etc patch is ready

by Frank de Lange

Hi'all, The next version (16) of my tab/frame/keyboard navigation patch is ready (see bottom of this message for download instructions). This is mainly a bug-fix and CVS resync release. For an overview of the new features in this release, see the posting I made to the list on version 15. Fixed bugs ---------- keyboard navigation - erroneously highlighted link after leaving a form element, was caused by wrong function call order in focus_next_link. Fixed. keywords - problem with keywords separated by more than one space is fixed. Keywords can now be separated by any whitespace character, including newlines (but don't forget that you still have to enclose the whole keywords string in double quotes for the parser to recognize it!). splash screem - the splash screen is now installed in $(datadir)/dillo/dillo.html CVS date/time ============= The patch is made against CVS as it was on 20031124@13:18 GMT. It should apply against CVS as it was on 20031121(a)21.33 GMT and later. For those who can not or do not want to use CVS, a snapshot can be found here: http://www.geocities.com/ikbenfrank/dillo-200311241318.tar.gz Tabs, Frames and browser bloat ============================== version: 0.8.0-pre patch: dillo-20031124-tabs.patch.gz unpatched: 297204 bytes patched: 333460 bytes (gcc 3.2.2, binutils 2.13.90.0.18, CFLAGS "-Os") Download instructions ===================== The patch is made against 20031124@13:18 GMT CVS. Do not forget to run ./autogen.sh after applying the patch. You can find the patch on the usual (ad-happy, use an ad-blocking proxy or sane browser) site: http://www.geocities.com/ikbenfrank/ More specifically: Dillo 0.8.0-pre (CVS) ===================== http://www.geocities.com/ikbenfrank/dillo-20031124-tabs.patch.gz size: 117192 bytes (gzipped, as downloaded) 531247 bytes (uncompressed) md5sum: 387f4dd85ead27de04d6527cc71504f5 (gzipped, as downloaded) 23ef8335f885d5657c75c7e9e0e18a3c (uncompressed) As always, check the site for the most recent version 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." ] -- 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." ]

Nov. 24, 2003

[PATCH] Version 5 of kbnav patch is ready

by Frank de Lange

Hi'all, The next version (5) of my keyboard navigation patch is ready. See the end of this message for download instructions. Do note that the tab/frame patch already contains this functionality, so there is no need (and no way) to apply this patch on top of that or the other way around. This release does not add any new features, it is mainly a bug fix and CVS resync release. For more info on what this patch does, see the doc/Keyboard_Navigation.txt document (after applying the patch, naturally...) Fixed bugs ---------- - erroneously highlighted link after leaving a form element, was caused by wrong function call order in focus_next_link. Fixed. CVS date/time ============= The patch is made against CVS as it was on 20031124@13:18 GMT. It should apply against CVS as it was on 20031121(a)21.33 GMT and later. For those who can not or do not want to use CVS, a snapshot can be found here: http://www.geocities.com/ikbenfrank/dillo-200311241318.tar.gz Download instructions ===================== There is currently only one version of the patch, made against 2003124@13:18GMT CVS. As always, have a look at the patch website (http://www.geocities.com/ikbenfrank/) for the latest version of the patch. This patch does NOT apply on top of the tab/frame patch, and the tab/frame patch does not apply on top of this one! The tab/frame patch already contains this functionality, so it is not needed. http://www.geocities.com/ikbenfrank/dillo-200311241458-kbnav.patch.gz size: 30633 bytes (gzipped, as downloaded) 152984 bytes (uncompressed) md5sum: 0ed60695cab750669f3d50c201bdf217 (gzipped, as downloaded) 20aeb6b96e551cd8f4fa65ac5d74ef9e (uncompressed) 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." ]

Nov. 24, 2003

RPM Latest Frame tabs patch with basic authentication:

by Ronald W. Henderson

Folks: Could someone direct me to a location that has a RPM built with the latest Frame and Tabs patch but also basic authenitcation code. I find dillo as an excellent browser but the lack of basic authentication as a standard built in feature limits my use. Today, many networking Vendor's support a web interface for administation of their product and typically require basic authentication for login. I would like to use dillo as my browser for administration purposes. I appreciate your support on this excellent browser! ---Ron Henderson

Nov. 24, 2003

Re: [Dillo-dev] [PATCH] Version 15 of tab/frame/kbnav/etc patch, now with keywords and more...

by Frank de Lange

Paul Pelzl wrote: > Now that I look at the problem again, I appear to have misdiagnosed it. > >It looks like the problem is with multiple spaces between keywords, not >with newlines. I've attached an example that causes a segfault after >entering any URL in the location bar. > >keywords = "s:http://www.google.com/search?q=%s ~:file:~" > > OK, solved this one as well. g_strsplit creates an empty string when two or more consecutive split-characters are encountered (quite reasonable behaviour, but not what I want for keywords) and the keywords processing code was not prepared for empty keywords (this in constrast to keywords with empty URLs which were handled OK). Is fixed in my code now, I'll release a new version of the patch with all recent fixes, made against the most recent version of CVS today or tomorrow. 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." ]

Nov. 24, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Stephan Goetter

Am Thu, Nov 20, 2003 at 10:59:47PM +0200 schrieb Jyri Jokinen und sprach: > On Thu, Nov 20, 2003 at 08:48:56PM +0100, Indan Zupancic wrote: > > > > I think it's the stupidest idea since browser tabs. (*) > > Thanks for your (honest and to the point) oppinion, but really, 50 windows > > open, and you hate tabs? > > I said "browser tabs". Window manager level window grouping is ok, > and renders browser tabs useless. That was/is the point. > > I don't like seeing code duplication, and certainly not somewhere it > doesn't belong. Web browsers should help the user with web browsing, > window managers with window managing. > I'm using fluxbox as well and still do use dillo-tabs heavily. Why? If you want to read 30 news messages in a seperate window (fast open- and closeable) I would have 30 additional window-manager tabs. With Frank's patch I do just open one window per news-site and every message in a new sub-tab. My open window-tabs still get clear i.e. <20 instead of having 50 mixed. So the can-be-done-with-window-manager-as-well argument doesn't really exist for me. Stephan

Nov. 24, 2003

gcc 2.95 doesn't know about -Wno-unused-parameter

by David McKee

Jorge, I suppose you're getting tired of hearing about my ancient Redhat system, but my gcc doesn't believe in -Wno-unused-parameters, preferning "-Wno-unused". Easy enough to fix by hand. Perhaps I should look nto configure in my copious spare time. Thanks, -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

Nov. 24, 2003

Re: [Dillo-dev] [PATCH] Version 15 of tab/frame/kbnav/etc patch, now with keywords and more...

by Frank de Lange

Paul Pelzl wrote: >On Fri, Nov 21, 2003 at 04:46:31PM +0100, Frank de Lange wrote: > > >>The next version (15) of my tab/frame/keyboard navigation patch is >>ready (see bottom of this message for download instructions). >> >> > >I've got a couple of early bugs to report: > >1) when using kbnav to move from a link to an entry box in a form, the > most recently selected link is not properly deselected. Example: > google.com. > > OK, solved this one. It was not related to the reported rendering problem with Dw (which still exists), but to the new focus_in/focus_out handling code which unhighlights a focused link when the viewport loses focus, and highlights it when it regains focus. Fix will be included in next patch... Thanks for the bug report! 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." ]

Nov. 23, 2003

Re: [Dillo-dev] Sigh... CVS out of sync 5 minutes after I upload my patches

by Indan Zupancic

> From now on I will always include the CVS code on which the patch was > based to get around these irritating synchronisation problems. > > Indan, if you want to update your HTTPS patch, may I suggest you use > this source code tarball instead of current Dillo CVS? This way we are > less dependent on the state of CVS... I use the -D option in my install script, and I rewrote the thing so I could just give the date at the top and it will download and install the correct CVS and patches, but now that won't work... To make matters worse, I also updated my https code to the current CVS (which didn't change for two days..). I would appreciate it a lot if you make a patch against the current state of CVS and give the file the usual name. I use FILE1="dillo-${YEAR}${MONTH}${DAY}-tabs.patch.gz" in my script, so it's very easy to update when there's a new version. I could add hours and minutes, but I'd rather leave those out, and when you make a updated version, I also don't have to "downdate" my code/patch. Another possibility is that you make a link named dillo-$DATE-tabs.patch.gz where DATE is the date of the Dillo CVS version that works with your patch, and points to the dillo-$RELEASE_DATE-tabs.patch.gz file. You don't have to host the Dillo source you used, not for me anyway, I won't use it, all I need to know is the date of the CVS you used, and sometimes the time too ;-). I think the install script causes more exposure, because it makes it very easy to get a patched Dillo; people don't even have to know what CVS is. The new https patch will be out soon, maybe even today, so you may expect a new installer soon. Greetings, Indan

Nov. 23, 2003

Re: [Dillo-dev] Sigh... CVS out of sync 5 minutes after I upload my patches

by Frank de Lange

Indan Zupancic wrote: >>It is as if the devil plays with it... 5 minutes after I upload my >>latest patches, CVS gets updated and the patch does not apply anymore. >> >> > >Oh so funny. :) > >I saw you updated your patch today, and the first thing I thought was: Why >didn't Frank say that he used the CVS version of yesterday, because CVS >didn't change for two days, and _if_ CVS would be updated today, there >will be problems. > > That is what the website is for. The name on the patch is the date it is released, the CVS date is the last date CVS is changed. The patch is always based on CVS for the release date (right before I release a patch I update CVS and reconcile any differences, if the differences are big I delay the patch to test the changes), but CVS is not always updated on that day (as you noticed). FYI, the CVS date/time I give is the date/time stamp for the src/ directory. Using CVS features is nice, but have you noticed how many (or few...) people even know how to get source from CVS in the first place? I want the patch to get exposure to as many people as possible, and including the source on which it is based is one way of doing that. Another way would be to release a patched source tree, but I prefer the patch + clean approach. >Could you reply to the CVS offer from Trent Jarvi and say what you think >about a CVS branch? See: > >http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-November/001470.html > > I noticed that posting, have been busy lately hence did not post reply. As there are only two active patch developers at this moment I think we do not need a CVS branch. It should be possible to synchronise releases for two patches. Of course, having a branch on the main Dillo CVS or elsewhere would not hurt, and I do not oppose it. I just think we can do without it for the moment. 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." ]

Nov. 23, 2003

Re: [Dillo-dev] [PATCH] Version 15 of tab/frame/kbnav/etc patch, now with keywords and more...

by Frank de Lange

Paul Pelzl wrote: >On Fri, Nov 21, 2003 at 04:46:31PM +0100, Frank de Lange wrote: > > >>The next version (15) of my tab/frame/keyboard navigation patch is >>ready (see bottom of this message for download instructions). >> >> > >I've got a couple of early bugs to report: > >1) when using kbnav to move from a link to an entry box in a form, the > most recently selected link is not properly deselected. Example: > google.com. > > If this is what I think it is, it actually seems to be a widget bug. I've discussed this with Sebastian before. Relevant part of discussion plus link to bug description: >Another corner case (to be tried with the new patch): >> >> - highlight a link which is followed by an embedded GTK+ widget, >> so that the embedded widget is just outside the visible part of the >> document. >> - move focus to the embedded widget. The widget scrolls into view and >> is focused, >> as it should. >> - but... the link still appeats highlighted. This even though the >> unhighlight >> function is called. >> - cover the 'highlighted' link with another window. When it is >> uncovered, the >> highlight is gone - as it should. >> >> It appears the page is not redrawn correctly when focus is handed over >> to an embedded GTK+ widget. > > I'm not sure, but I assume that this is the another symptom of a known bug (#202). More on this bug at http://www.geocrawler.com/archives/3/702/2002/3/50/8045756/ It might be something else though (I've noticed this many times, and just thought of it as the described widget bug) so I'll have a look at it. >2) the "keywords" user pref is apparently not read in a robust manner. > If I separate keywords by a newline instead of a space, I can > generate a segfault upon typing any URL in the location bar. > Hmmm, I'll have a look at that... 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." ]

Nov. 23, 2003

Re: [Dillo-dev] Confused

by Indan Zupancic

Hi, > Can someone tell me where to download a source with the https, tab patches > without having to track down what and or where to patch? Or send me a > copy:) thanks Currently I have a sort of installer that downloads Dillo, the tabs and https patches, and applies them, Can get it from: http://www.xs4all.nl/~dorinek/dillo/install-dillo.sh But it isn't finished yet, nor up to date (Frank has a newer tabs+frames patch). I have a better installer, but I need to get my https patch working first. It stopped working after I changed it a bit :(. There is a weird bug that I can't seem to find, will hopefully fix it today and then update my https patch and the installer. Greetings, Indan

Nov. 23, 2003

Confused

by Donald McKnight

Can someone tell me where to download a source with the https, tab patches without having to track down what and or where to patch? Or send me a copy:) thanks Thanks Donald ----- Original Message ----- From: "Indan Zupancic" <indan(a)nul.nu> To: <dillo-dev(a)dillo.org> Sent: Saturday, November 22, 2003 10:18 AM Subject: [Dillo-dev] [patch] Cleanup of IO.c > Hi, > > Just cleaned IO.c up, so nothing fundamental changed. Besides some > cleanups in multiple functions this are the two major changes: > > Removal of a_IO_write_chunks, mainly because it isn't used anywhere and it > doesn't add any real functionality, it does the same only in a different > way. Thanks to CVS it is easy to add it back when you really needed, if > you want. > > Removal of the ValidIOs list. This is the logical next step after > g_source_remove was discovered, because the extra indirection isn't needed > anymore. > > All in all the result is a much smaller IO.c (400 lines instead of 700), > smaller Dillo (about 3K with -O2), and O(1) behaviour instead of O(n) in > the IO engine. > > The changes have really no negative points as far as I can tell. > > Link to the patch: > > http://www.xs4all.nl/~dorinek/dillo/IO-cleanup.patch.gz > > Greetings, > > Indan > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

Nov. 23, 2003

[patch] Cleanup of IO.c

by Indan Zupancic

Hi, Just cleaned IO.c up, so nothing fundamental changed. Besides some cleanups in multiple functions this are the two major changes: Removal of a_IO_write_chunks, mainly because it isn't used anywhere and it doesn't add any real functionality, it does the same only in a different way. Thanks to CVS it is easy to add it back when you really needed, if you want. Removal of the ValidIOs list. This is the logical next step after g_source_remove was discovered, because the extra indirection isn't needed anymore. All in all the result is a much smaller IO.c (400 lines instead of 700), smaller Dillo (about 3K with -O2), and O(1) behaviour instead of O(n) in the IO engine. The changes have really no negative points as far as I can tell. Link to the patch: http://www.xs4all.nl/~dorinek/dillo/IO-cleanup.patch.gz Greetings, Indan

Nov. 22, 2003

patch: toggle force_my_colors

by Paul Pelzl

Hi folks, I have attached a pair of Dillo patches. They add a toggle-able menu item to the right-button context menu, which enables/disables the force_my_colors preference on the fly. I find this useful for some occasional websites that Dillo renders rather poorly, as well as sites that simply choose a horrid color scheme. The first patch applies on top of Frank's monster patch v15; the second applies against Dillo CVS of 20031119. I hope others find it useful. Paul

Nov. 22, 2003

Re: [Dillo-dev] [PATCH] Version 15 of tab/frame/kbnav/etc patch, now with keywords and more...

by Paul Pelzl

On Fri, Nov 21, 2003 at 04:46:31PM +0100, Frank de Lange wrote: > The next version (15) of my tab/frame/keyboard navigation patch is > ready (see bottom of this message for download instructions). I've got a couple of early bugs to report: 1) when using kbnav to move from a link to an entry box in a form, the most recently selected link is not properly deselected. Example: google.com. 2) the "keywords" user pref is apparently not read in a robust manner. If I separate keywords by a newline instead of a space, I can generate a segfault upon typing any URL in the location bar. Other than that, it's looking pretty solid so far. I'll keep hammering... Paul

Nov. 22, 2003

Re: [Dillo-dev] Sigh... CVS out of sync 5 minutes after I upload my patches

by Indan Zupancic

> It is as if the devil plays with it... 5 minutes after I upload my > latest patches, CVS gets updated and the patch does not apply anymore. Oh so funny. :) I saw you updated your patch today, and the first thing I thought was: Why didn't Frank say that he used the CVS version of yesterday, because CVS didn't change for two days, and _if_ CVS would be updated today, there will be problems. So, the easy sollution is to rename your patch to "dillo-20031120-tabs.patch.gz" and everything will work just fine. Although not with the current CVS of course, but that will happen anyway if you wait long enough. Are the recent changes worth it to update your patch, that's the question. Apparently you already did that, but there is no reason to include the whole source. What Thorben said is exactly what my installer script does; the -D option is nice. Offtopic: Could you reply to the CVS offer from Trent Jarvi and say what you think about a CVS branch? See: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-November/001470.html I think a seperate CVS branch would be useful, one hosted by the same server as the official Dillo CVS, or an external one, like Trent's. Where doesn't matter much I guess. At least the patches are centralized then.

Nov. 21, 2003

Re: [Dillo-dev] Sigh... CVS out of sync 5 minutes after I upload my patches

by Thorben Thuermer

On Fri, 21 Nov 2003 22:41:25 +0100 Frank de Lange <frank(a)unternet.org> wrote: > Anyone who wants to try tab/frame patch no. 15 can download the CVS > source on which it is based from the patch site: > > http://www.geocities.com/ikbenfrank/dillo-200311191409.tar.gz cvs -d :pserver:anonymous@dillo.org:/sfhome/cvs/dillo co -D 'Nov 19 14:09 2003' dillo why not use CVS's features? </offtopic>, before we get a new development model discussion > Cheers//Frank Thorben

Nov. 21, 2003

Sigh... CVS out of sync 5 minutes after I upload my patches

by Frank de Lange

It is as if the devil plays with it... 5 minutes after I upload my latest patches, CVS gets updated and the patch does not apply anymore. Well, this time I was prepared for that. Anyone who wants to try tab/frame patch no. 15 can download the CVS source on which it is based from the patch site: http://www.geocities.com/ikbenfrank/dillo-200311191409.tar.gz This is the UNPATCHED CVS code that was used to create the patch. To get a working tabbed/frames/etc browser, download this tarball and the patch, then apply the patch. From now on I will always include the CVS code on which the patch was based to get around these irritating synchronisation problems. Indan, if you want to update your HTTPS patch, may I suggest you use this source code tarball instead of current Dillo CVS? This way we are less dependent on the state of CVS... 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." ]

Nov. 21, 2003

latest commit: cleanup on glib ids

by Jorge Arellano Cid

Hi Sebastian! While making the latest patch (now in CVS), I finally had the time to track gtk_timeout_add, gtk_idle_add and g_io_add_watch inside gtk/gdk/glib sources. The interesting part is that after the related wrappers, they all end using g_source_add; this function uses hook_id (ghook.h) which gets the id from seq_id. :-) In short: seq_id starts from 1 and hook_id is largely used with zero as a non-used/non-active/non-valid value! I updated dillo accordingly and eliminated the uneasy feel of initializing a guint with -1 as an invalid value. Regards Jorge.-

Nov. 21, 2003

Re: [Dillo-dev] [PATCH] Version 15 of tab/frame/kbnav/etc patch, now with key\ words an more...

by billy＠idiom.com

Frank de Lange Fri, Nov 21, 2003 at 07:33:03PM +0100: > Your mail includes a weird 'reply-to' header, which points to my domain: > > Reply-To: 3FBE3357.3040003(a)unternet.org > > Please don't do that... I'd rather not get replies to mail I did not send > myself on a non-existing address... Sorry, that should have gone in the In-Reply-To, not Reply-To header. I was cutting and pasting, and pasted wrong. -- -billy

Nov. 21, 2003

Re: [Dillo-dev] [PATCH] Version 15 of tab/frame/kbnav/etc patch, now with key words an more...

by Frank de Lange

p.s... Your mail includes a weird 'reply-to' header, which points to my domain: Reply-To: 3FBE3357.3040003(a)unternet.org Please don't do that... I'd rather not get replies to mail I did not send myself on a non-existing address... 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." ]

Nov. 21, 2003

Re: [Dillo-dev] [PATCH] Version 15 of tab/frame/kbnav/etc patch, now with key words an more...

by Frank de Lange

Billy wrote: >In src/prefs.h you specify DILLO_SPLASH as file:/usr/share/dillo/dillo.html >We don't install into that prefix. > > Oh, do you not? Then use the pref splash=file:/wherever/you/want/to/install/instead The next version of the patch will contain a more elegant solution to this 'problem'... 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." ]

Nov. 21, 2003

Re: [Dillo-dev] [PATCH] Version 15 of tab/frame/kbnav/etc patch, now with key words an more...

by Billy

In src/prefs.h you specify DILLO_SPLASH as file:/usr/share/dillo/dillo.html We don't install into that prefix. I made 2 changes. Added a dep for prefs.h and a rule which fixes the splash path as well as changing DILLO_SPLASH to file%%PREFIX%%/share... It's an ugle Makefile hack, but I didn't want to wade through the morass of autoconf for the correct solution. --- src/Makefile.am Fri Nov 21 09:35:45 2003 +++ src/Makefile.am.orig Tue Nov 11 07:13:59 2003 @@ -1,9 +1,3 @@ -.fixed_splash_path: - cp prefs.h x && cat x | sed 's@%%PREFIX%%@$(prefix)@' > prefs.h && rm -f x - touch .fixed_splash_path - -prefs.h: .fixed_splash_path - AM_CPPFLAGS=-DDILLORC_SYS='"$(sysconfdir)/dillorc"' SUBDIRS = IO @@ -24,8 +18,6 @@ capi.c \ capi.h \ debug.h \ - doc.c \ - doc.h \ dw.h \ dw.c \ dw_aligned_page.c \ @@ -68,18 +60,12 @@ dw_tooltip.h \ dw_widget.c \ dw_widget.h \ - gtkframeset.c \ - gtkframeset.h \ findtext.c \ findtext.h \ selection.c \ selection.h \ - focus.c \ - focus.h \ web.c \ web.h \ - pagemark.c \ - pagemark.h \ progressbar.c \ progressbar.h \ dillo.c \ @@ -100,8 +86,6 @@ image.h \ misc.c \ misc.h \ - tab.c \ - tab.h \ interface.h \ interface.c \ history.c \ --- src/prefs.h Fri Nov 21 09:35:11 2003 +++ src/prefs.h.orig Sat Nov 15 14:13:03 2003 @@ -8,8 +8,6 @@ #endif /* __cplusplus */ #define DILLO_HOME "http://www.dillo.org/" -#define DILLO_SPLASH "file:%%PREFIX%%/share/dillo/dillo.html" - #define D_GEOMETRY_DEFAULT_WIDTH 640 #define D_GEOMETRY_DEFAULT_HEIGHT 550 @@ -19,15 +17,6 @@ #define DW_COLOR_DEFAULT_PURPLE 0x800080 #define DW_COLOR_DEFAULT_BGND 0xd6d6c0 -#define COMPRESS_COMMON_PREFIXES "index of ;re: ;fwd: ;www.;welcome to ;the " - -/* target enumeration */ -enum { - TARGET_SELF, - TARGET_TAB, - TARGET_WINDOW -}; - /* define enumeration values to be returned */ enum { PARSE_OK = 0, @@ -49,8 +38,6 @@ DRC_TOKEN_TEXT_COLOR, DRC_TOKEN_USE_OBLIQUE, DRC_TOKEN_HOME, - DRC_TOKEN_SPLASH, - DRC_TOKEN_KEY_BINDINGS, DRC_TOKEN_PANEL_SIZE, DRC_TOKEN_SMALL_ICONS, DRC_TOKEN_FONT_FACTOR, @@ -69,10 +56,8 @@ DRC_TOKEN_SHOW_URL, DRC_TOKEN_SHOW_SEARCH, DRC_TOKEN_SHOW_PROGRESS_BOX, - DRC_TOKEN_SHOW_POPUP_NAVIGATION, DRC_TOKEN_FULLWINDOW_START, DRC_TOKEN_TRANSIENT_DIALOGS, - DRC_TOKEN_POPUP_DIALOGS, DRC_TOKEN_FW_FONT, DRC_TOKEN_VW_FONT, DRC_TOKEN_GENERATE_SUBMIT, @@ -81,14 +66,6 @@ DRC_TOKEN_SHOW_HTML_WARNINGS, DRC_TOKEN_SHOW_MSG, DRC_TOKEN_USE_OLD_PARSER, - DRC_TOKEN_KEYWORDS, - DRC_TOKEN_TARGET_BLANK, - DRC_TOKEN_TAB_LOAD_IN_BACKGROUND, - DRC_TOKEN_TAB_BAR_SHOW_FULLSCREEN, - DRC_TOKEN_TAB_BAR_SHOW_SINGLE_TAB, - DRC_TOKEN_TAB_BAR_SCROLLER, - DRC_TOKEN_TAB_TITLE_COMPRESS, - DRC_TOKEN_COMPRESS_COMMON_PREFIXES, DRC_TOKEN_LAST } Dillo_Rc_TokenType; @@ -102,8 +79,6 @@ gchar *no_proxy; gchar **no_proxy_vec; DilloUrl *home; - gchar *splash; - gboolean show_splash; guint32 link_color; guint32 visited_color; guint32 bg_color; @@ -130,10 +105,8 @@ gboolean show_url; gboolean show_search; gboolean show_progress_box; - gboolean show_popup_navigation; gboolean fullwindow_start; gboolean transient_dialogs; - gboolean popup_dialogs; gchar *vw_fontname; gchar *fw_fontname; gboolean generate_submit; @@ -142,16 +115,6 @@ gboolean show_html_warnings; gboolean show_msg; gboolean use_old_parser; - gchar *keywords; - gchar **keywords_vec; - gint target_blank; - gboolean tab_load_in_background; - gboolean tab_bar_show_fullscreen; - gboolean tab_bar_show_single_tab; - gboolean tab_bar_scroller; - gboolean tab_title_compress; - gchar *compress_common_prefixes; - gchar **compress_common_prefixes_vec; }; -- billy "Who get's bigger evertime you void, It's Hank the Happy Hemorroid."

Nov. 21, 2003

[PATCH] Version 4 of kbnav patch is ready

by Frank de Lange

Hi'all, The next version (4) of my keyboard navigation patch is ready. See the end of this message for download instructions. Do note that the tab/frame patch already contains this functionality, so there is no need (and no way) to apply this patch on top of that or the other way around. This release does not add many new features. It does however fix most known bugs, which is a good enough reason for applying it I'd say... One new feature is that is is now possible to popup context menus with keyboard navigation. The default key binding is Alt-Enter (and Alt-KP_Enter), this can of course be changed using the appropriate preference incantation. For more info on what this patch does, see the doc/Keyboard_Navigation.txt document (after applying the patch, naturally...) Fixed bugs ---------- - all known segfaults - most 'weird navigation order' problems - related issue (now fixed in CVS): a_Findtext_search returned FALSE (instead of FINDTEXT_NOT_FOUND) when a search was performed on an empty page. Since this function is supposed to return a FindtextResult enum value (and the first value in that enum is FINDTEXT_SUCCESS) this made the focus code try to focus a link in an empty page leading to a segfault in the scrolled_window. TODO ==== - add x scrolling capability to Dillo (change anchors, URL_POS, scrolling functions, iterators, etc...). This is needed for better keyboard navigation on wide pages. Download instructions ===================== There is currently only one version of the patch, made against 2003119@14:09GMT CVS. As always, have a look at the patch website (http://www.geocities.com/ikbenfrank/) for the latest version of the patch. This patch does NOT apply on top of the tab/frame patch, and the tab/frame patch does not apply on top of this one! The tab/frame patch already contains this functionality, so it is not needed. http://www.geocities.com/ikbenfrank/dillo-200311211558-kbnav.patch.gz size: 30615 bytes (gzipped, as downloaded) 152903 bytes (uncompressed) md5sum: 29aa01c8c5eabe3c7294b975155255ce (gzipped, as downloaded) 5c848e7f0e281e3135392522c8a7f980 (uncompressed) 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." ]

Nov. 21, 2003

[PATCH] Version 15 of tab/frame/kbnav/etc patch, now with keywords and more...

by Frank de Lange

Hi'all, The next version (15) of my tab/frame/keyboard navigation patch is ready (see bottom of this message for download instructions). This release incorporates a number of bug fixes to keyboard navigation, in response to feedback on the list. It also fixes several other bugs (see non-exhaustive list further down). And, last but not least, there are several new features: keywords, use of location bar for search, local document handling on location bar, user configurable '_blank' target, repeated search, many more configurable key bindings, etc... /* ATTENTION */ This is the first release *without the conditional compile options* for tabs and frames. Tabs, frames and keyboard navigation are standard now, and there is no provision to compile Dillo without support for these features. This is a BIG patch, with many changes. Please test it, and tell me (through the list) about any problems. New features ------------ - keywords Keywords can be used to access sites and locations with short commands in the location bar (and elsewhere). They are defined in the dillorc as a space-separated list of keyword:url pairs: keywords = "<keyword>:<url> <keyword>:<url> ..." %s is in url is replaced by (escaped) location bar contents Example: (in dillorc) keywords="s:http://www.google.com/search?q=%s" "s dillo patch" in the location bar will execute a search on google for the words 'dillo patch'. There is one default keyword, "search". This corresponds to the search_url preference. The web search feature has been changed to use the new code. Keywords currently work in the location bar, in the "open url" window and *from the command line*. This way you can search the web from the command line: dillo "search whatever you want to search for" (enter) [ programming info ] To add keyword processing to a url, you need to make an explicit call to a_Url_string_process_keywords(gchar *str). I explicitly did NOT add the keyword processing code to the default url code path, so keywords can not be initiated through external links. Better safe than sorry... - local file handling in the location bar: type a valid absolute path in the location bar and it will be transformed into a valid file: url. [ programming info ] To add local path processing to a url, you need to make an explicit call to a_Url_string_process_local(gchar *str, gboolean relative) Set relative to TRUE to include relative path processing (from the current directory) to the code path. - location bar search using keywords and/or with popup_dialogs=NO. If you have popup_dialogs=NO in dillorc, pressing the search button on the toolbar or using the search key combination (ALT-s) will search the web for whatever you typed in the location bar (if you have entered search terms) or focus the location bar with the search keyword set. In the latter case just add search terms and press enter to search. - location bar contents are selected when it is focused, deselected when the content area is focused. - the contents of the findtext and websearch entries are selected when they are re-opened. Type a new search term to replace the old term. Use the cursor keys to deselect the contents when you want to add to the existing search term. - the splash screen no longer lives in the binary (as suggested by Indan Zupancic). It is installed by the makefile and should be distributed with dillo. The default location is in the 'sharedstate' directory (default /usr/share/dillo/dillo.html). There is a preference for those who want to change this: splash = NO | <url> This takes any url. Set it to NO to suppress the splash screen alltogether (you will still be able to get to the splash screen by visiting about:splash). The default value is defined in prefs.h: #define DILLO_SPLASH "file:/usr/share/dillo/dillo.html" - There is a new preference for control of the "_blank" tag and handling of new windows in general (as suggested by Andreas Schweitzer): target_blank = SELF | TAB | [WINDOW] Set this to "self" to disable the "_blank" target (no more new windows popping up all around). The other two settings are self-explanatory I guess... This also works for documents opened using the middle mouse button, and documents opened on the command line. For the latter the "self" setting is ignored (it defaults to new windows in that case). - Repeated search by pressing CTRL-g at any time. Unhiglight search by pressing Escape. If search resulted in a highlighted link, this will be unhighlighted as well (to follow that link, press Enter instead of Escape). - many more configurable key bindings. To avoid overloading the scrolled_frame with content-related signals I added a general 'content_command' signal, which gets passed one parameter of type DilloCommand (defined in commands.h). To adjust a keybinding for a command, set a key for the signal 'content_command' for the widget named 'dillo-content' (or for the class GtkDwScrolledFrame). As an example the following binding sets the 'F3' key for the 'repeat find' command (like it does in Mozilla): key_bindings = "binding 'mozilla-keys' { bind 'F3' { 'content_command' (9) } ... (add more bindings if needed) ... } widget '*dillo-content' binding 'mozilla-keys'" There are currently 30 available commands: DILLO_COMMAND_NAVIGATE_BACK, /* 0 */ DILLO_COMMAND_NAVIGATE_FORWARD, /* 1 */ DILLO_COMMAND_NAVIGATE_RELOAD, /* 2 */ DILLO_COMMAND_NAVIGATE_STOP, /* 3 */ DILLO_COMMAND_NAVIGATE_HOME, /* 4 */ DILLO_COMMAND_DUPLICATE_WINDOW, /* 5 */ DILLO_COMMAND_DUPLICATE_TAB, /* 6 */ DILLO_COMMAND_FINDTEXT, /* 7 */ DILLO_COMMAND_FINDTEXT_INCREMENTAL, /* 8 */ DILLO_COMMAND_FINDTEXT_REPEAT_LAST_SEARCH, /* 9 */ DILLO_COMMAND_FINDTEXT_UNHIGHLIGHT, /* 10 */ DILLO_COMMAND_SAVE, /* 11 */ DILLO_COMMAND_SAVE_LINK, /* 12 */ DILLO_COMMAND_BOOKMARK, /* 13 */ DILLO_COMMAND_NEW_WINDOW, /* 14 */ DILLO_COMMAND_NEW_TAB, /* 15 */ DILLO_COMMAND_OPEN_FILE, /* 16 */ DILLO_COMMAND_OPEN_URL, /* 17 */ DILLO_COMMAND_OPEN_LINK, /* 18 */ DILLO_COMMAND_OPEN_LINK_NEW_WINDOW, /* 19 */ DILLO_COMMAND_OPEN_LINK_NEW_TAB, /* 20 */ DILLO_COMMAND_CLOSE_WINDOW, /* 21 */ DILLO_COMMAND_CLOSE_TAB, /* 22 */ DILLO_COMMAND_EXIT, /* 23 */ DILLO_COMMAND_TAB_PREVIOUS, /* 24 */ DILLO_COMMAND_TAB_NEXT, /* 25 */ DILLO_COMMAND_VIEW_SOURCE, /* 26 */ DILLO_COMMAND_VIEW_BOOKMARKS, /* 27 */ DILLO_COMMAND_FOCUS_LOCATION, /* 28 */ DILLO_COMMAND_WEBSEARCH, /* 29 */ DILLO_COMMAND_TOGGLE_FULLWINDOW /* 30 */ DILLO_COMMAND_FOCUS_ACTIVATE, /* 31 */ DILLO_COMMAND_FOCUS_ACTIVATE_NEW_WINDOW, /* 32 */ DILLO_COMMAND_FOCUS_ACTIVATE_NEW_TAB, /* 33 */ DILLO_COMMAND_FOCUS_POPUP, /* 34 */ DILLO_COMMAND_FOCUS_HIDE, /* 35 */ DILLO_COMMAND_FOCUS_MOVE_UP, /* 36 */ DILLO_COMMAND_FOCUS_MOVE_DOWN, /* 37 */ DILLO_COMMAND_FOCUS_MOVE_LEFT, /* 38 */ DILLO_COMMAND_FOCUS_MOVE_RIGHT, /* 39 */ DILLO_COMMAND_FOCUS_MOVE_TAB_BACK, /* 40 */ DILLO_COMMAND_FOCUS_MOVE_TAB_FORWARD, /* 41 */ DILLO_COMMAND_SCROLL_UP, /* 42 */ DILLO_COMMAND_SCROLL_DOWN, /* 43 */ DILLO_COMMAND_SCROLL_LEFT, /* 44 */ DILLO_COMMAND_SCROLL_RIGHT, /* 45 */ DILLO_COMMAND_SCROLL_PAGE_UP, /* 46 */ DILLO_COMMAND_SCROLL_PAGE_DOWN, /* 47 */ DILLO_COMMAND_SCROLL_PAGE_LEFT, /* 48 */ DILLO_COMMAND_SCROLL_PAGE_RIGHT, /* 49 */ DILLO_COMMAND_SCROLL_EDGE_TOP, /* 50 */ DILLO_COMMAND_SCROLL_EDGE_BOTTOM, /* 51 */ DILLO_COMMAND_SCROLL_EDGE_LEFT, /* 52 */ DILLO_COMMAND_SCROLL_EDGE_RIGHT /* 53 */ If you'd like to see any other commands, tell me or the list! [programming info] To add a new command, simply add the name to the DilloCommand enum, add a handler to a_Commands_handler() and, optionally, add a default key binding to a_Commands_init(). The commands.[ch] files are in a bit of a state of flux, as many commands are currently present in two forms: one with a *dd interface, the other (older) with a *bw interface. Where appropriate the older (*bw) versions can and will be removed - the View Source window can now be closed by pressing Escape. View source is (over)due for an overhaul by the way. I might implement the view-source protocol in one of the next patches. - Tab movement is now cyclic, thanks to a patch by Stephan Goetter - the Frame context menu now has navigation controls (as suggested by Stephan Goetter), so it is possible to go back in the frame history. The main history is not yet synchronised with frame actions. [LIST: Is this necessary? Should the 'back' button and menu remember actions inside nested frames or should it do what it does now, remember actions in the top-level document?] - Keyboard navigation can be used to popup context menus, as suggested by Melvin Hadasht. The default binding for context menu is Alt-Enter (and Alt-KP_Enter). The related DILLO_COMMAND is DILLO_COMMAND_FOCUS_POPUP. Fixed bugs ---------- keyboard navigation - all known segfaults - most 'weird navigation order' problems - related issue (now fixed in CVS): a_Findtext_search returned FALSE (instead of FINDTEXT_NOT_FOUND) when a search was performed on an empty page. Since this function is supposed to return a FindtextResult enum value (and the first value in that enum is FINDTEXT_SUCCESS) this made the focus code try to focus a link in an empty page leading to a segfault in the scrolled_window. document abstraction - a problem with tab/page duplication which had the potential to cause segfaults is fixed - selection copy did not work because I forgot to set the owner for the selection in tab mode. This is fixed. REMOVED PREFERENCES =================== These preferences have been removed from the patch. Update your dillorc if you used them. Complain to me (on the list) if you want them back. * tab_instead_of_window: merged into the new target_blank pref * focus_location_on_new: did anyone use the NO setting? * tab_bar_homogeneous: did anyone use the NO setting? * compress_vowels: can be changed during compile if needed, COMPRESS_VOWELS in src/misc.h CHANGED KEY COMBINATIONS ======================== * Internet search: ALT-s (was CTRL-g, CVS CTRL-s) * Repeat search CTRL-g (was nothing, CVS nothing) * View source: ALT-u (was CTRL-u, CVS nothing) * Open URL: CTRL-l (was SHIFT-CTRL-l, CVS CTRL-l) * focus location bar: CTRL-u (was CTRL-l, CVS CTRL-u) If you want the old keys back, add a binding for the related command (see above) If something doesn't work they way it should (or the way you *think* it should), I want to know! For more info on keyboard navigation, see the doc/Keyboard_Navigation.txt document (after applying the patch, naturally...). More information on tabs can be found in doc/Browser_Tabs.txt, for frames see doc/Browser_Frames.txt. The mailing list archives are also a good place to look for answers to questions relating to this patch. REMOVED COMPILE OPTIONS ======================= * --disable-tabs Tabs are a fixed part of the code now * --enable-xhtml-dtd Full frameset support is a fixed part of the code now TODO ==== - add x scrolling capability to Dillo (change anchors, URL_POS, scrolling functions, iterators, etc...). This is needed for better keyboard navigation on wide pages. Tabs, Frames and browser bloat ============================== version: 0.8.0-pre patch: dillo-20031121-tabs.patch.gz unpatched: 297172 bytes patched: 333364 bytes (gcc 3.2.2, binutils 2.13.90.0.18, CFLAGS "-Os") Download instructions ===================== The patch is made against 20031119@15:09 CVS. Do not forget to run ./autogen.sh after applying the patch. You can find the patch on the usual (ad-happy, use an ad-blocking proxy or sane browser) site: http://www.geocities.com/ikbenfrank/ More specifically: Dillo 0.8.0-pre (CVS) ===================== http://www.geocities.com/ikbenfrank/dillo-20031121-tabs.patch.gz size: 116678 bytes (gzipped, as downloaded) 529298 bytes (uncompressed) md5sum: 846a6be5100809cd95553e2cae595f3b (gzipped, as downloaded) 7a94882aa87a8787d959105231fcfacf (uncompressed) As always, check the site for the most recent version 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." ]

Nov. 21, 2003

Re: [Dillo-dev] FLTK

by Frank de Lange

Melvin Hadasht wrote: >Another advantage is that when used with Gnome, GTK2 gains accessibility >functionality for handicapped persons. I like to think that the kbnav is >already one big step toward offering such functionality (perhaps it lacks >a way to open context menus), thanks to Frank. After reading this message I implemented this in the coming version of the patch (available today if I find the time to release it). The default key binding is ALT-Enter (or Alt-KP_Enter). It can be bound to any other key using the appropriate preference setting (see the README documents for more info on this). The menu pops up under the link for keyboard navigation, under the pointer for mouse actions. Any other suggestions to make Dillo more accessible for both non-handicapped and handicapped users? 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." ]

Nov. 21, 2003

Re: [Dillo-dev] Emacs

by Frank de Lange

Sebastian Geerken wrote: >>>(Emacs' use of tabs >>>messes up things sometimes, and the 2-space indent it uses are not >>>consistent with Dillo's conventions). >>> >>> > >Emacs users, put the following code into ~/.emacs: > >---------------------------------------------------------------------- >(defun array-find (a1 a2 &optional index-or-nil) > (let ((index (if index-or-nil index-or-nil 0)) > (l1 (length a1)) > (l2 (length a2))) > (if (> (+ index l2) l1) > nil > (let ((i 0)) > (while (and (< i l2) > (= (aref a1 (+ index i)) (aref a2 i))) > (setq i (+ i 1))) > (if (= i l2) > index > (array-find a1 a2 (+ index 1))))))) > >(defun my-c-hook () > (if (array-find (buffer-file-name) "/dillo") > (progn > ;; dillo conventions > (set-variable 'indent-tabs-mode nil) > (set-variable 'c-basic-offset 3)) > ;; conventions for other code > (set-variable 'indent-tabs-mode t) > (set-variable 'c-basic-offset 2))) > >(add-hook 'c-mode-hook 'my-c-hook) > > Thanks... Makes it a bit easier to be Dillo-compliant... 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." ]

Nov. 21, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Indan Zupancic

> I mean, removing the possibility of having another Dillo instance is > equivalent restricting its usage. That's why I suggested the other solution. True, that's why I will probably make it a cmd option too, seeing that running only one Dillo is not what people seem to want, and difficult in other cases. > Your patch was also meant to get rid of dpid, if I understood correctly. No, my patch made it only easier to get rid of it in the future. > My point was that I don't think dpid is so expensive apart maybe for > https: The structure of dpid is not optimal for https: the dpidservice > gets data from internet and the it passes it to dillo. It adds a proxy, > and that may reduce throughput. But this should be quantified and proved. That's what you get if you treat https as a protocol instead of just http over ssl/tls, if you ask me. ;) > This is in fact a X feature. It just happens that gtk-1.2 did not support > it. Of course it is a X feature, but one that is impossible to use when the widget doesn't support it. Seems like it's not needed though. Greetings, Indan

Nov. 20, 2003

Re: [Dillo-dev] Re: kbnav3 patch test

by Frank de Lange

Jorge Arellano Cid wrote: >>I have taken a look at your patch-to-my-patch, but did not apply it to >>the version I will publish later today. >> >> OK, later tomorrow, did not have time today... Both patches. Anyway, the reason I did not apply the patch was because it was incomplete, and I had changed my version in the meantime (as you'll notice when it finally is available to the masses, tomorrow...). > Thanks, we strive to be style consistent. > BTW, I didn't try to fix indentation in the patch, it >was just to do a test run. > > I'd like to teach my Emacsen to 'do the right thing', but they all have a will of their own when it comes to indentation. And the use of tabs instead of spaces. But as Emacs' indentation (GNU-style) is what I generally use that's no problem for me. Except in the case of Dillo... >focus.c: In function `Focus_state_find_list': >focus.c:268: warning: `list' might be used uninitialized in this >function >focus.c: In function `Focus_state_find_link': >focus.c:465: warning: `list' might be used uninitialized in this >function > >gcc version 3.2.3 > > Hmmmm... Nothing here with 3.2.2, weird. I'll have a look at this... >>(including the one causing the Tarot page to crash by the way - see my >>message dated Wed, 12 Nov 2003 11:00:58 +0100). >> >> > > Oh, I didn't find anything about it at GMANE !? > > http://article.gmane.org/gmane.comp.web.dillo.devel/1458 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." ]

Nov. 20, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Melvin Hadasht

> Always having one Dillo even when you exec dillo is practically the same > as always having one Dillo. And as a sort of server mode, in the sense > that you just send a message and exit instead of running and doing the > stuff. I took a look at your patch, you mainly do the same as I did, but > you added much code to handle all the extra commands. I would handle the > "server" commands the same as the cmd commands, they are mostly the same > anyway. Simpler, more code reuse, smaller and less code. My patch doesn't > do that yet, but that's because dillo.c needs to be rearranged a bit to > make it possible, wanted a working patch first, and see what people think > about it before wasting time finishing it. I mean, removing the possibility of having another Dillo instance is equivalent restricting its usage. That's why I suggested the other solution. > > Concerning the second advantage (not using dpid): performance reasons > > would be of concern especially when large amount of data need to > > be passed from and to dillo (https), but maybe we need to quantify this > > before. > > I don't understand your point, performance reasons are of concern only > when using dpid, because dpid copies data, so what exactly has this to do > with my patch? Your patch was also meant to get rid of dpid, if I understood correctly. My point was that I don't think dpid is so expensive apart maybe for https: The structure of dpid is not optimal for https: the dpidservice gets data from internet and the it passes it to dillo. It adds a proxy, and that may reduce throughput. But this should be quantified and proved. > Good to know it's possible, and that it depends only on the widget toolset > if it's supported or not. This is in fact a X feature. It just happens that gtk-1.2 did not support it. -- Melvin Hadasht

Nov. 20, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Indan Zupancic

Hello, Accidentally activated some hidden command to search (damn firebird, should have used Dillo :), so lost the email I waswriting... Summary below: > I think that the advantage of always having one Dillo is not an argument, > because even now you can run only one instance. If you want that every > "dillo" command uses the first instance, then another approach would be > to use a "remote" or "server" mode, like mozilla, nedit, xemacs and vim > have. > I once made a patch for Dillo to support this. The patch is not uptodate, > but I can update it on request. Always having one Dillo even when you exec dillo is practically the same as always having one Dillo. And as a sort of server mode, in the sense that you just send a message and exit instead of running and doing the stuff. I took a look at your patch, you mainly do the same as I did, but you added much code to handle all the extra commands. I would handle the "server" commands the same as the cmd commands, they are mostly the same anyway. Simpler, more code reuse, smaller and less code. My patch doesn't do that yet, but that's because dillo.c needs to be rearranged a bit to make it possible, wanted a working patch first, and see what people think about it before wasting time finishing it. > Concerning the second advantage (not using dpid): performance reasons > would be of concern especially when large amount of data need to > be passed from and to dillo (https), but maybe we need to quantify this > before. I don't understand your point, performance reasons are of concern only when using dpid, because dpid copies data, so what exactly has this to do with my patch? > gtk1.2 cannot do this, but gtk2.0 can migrate a window from display to > display. It can also open a new window in another display (display being > another X server, like a remote host). Good to know it's possible, and that it depends only on the widget toolset if it's supported or not. In reply to Jyri Jokinen: > I said "browser tabs". Window manager level window grouping is ok, > and renders browser tabs useless. That was/is the point. Think about all those poor souls using some window manager which has no grouping/tabs or something similar. Also, tabs in a browser means only extra subgroups, very useful when you have a lot browsers open. Greetings, Indan

Nov. 20, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Jyri Jokinen

On Thu, Nov 20, 2003 at 08:48:56PM +0100, Indan Zupancic wrote: > 1369 k/Dillo versus 795 k/window. That's not really an issue. I gladly accept the larger memory consumption when it gives me better reliability and still is, in comparision with the rest of the web browsers, minimal. > > I think it's the stupidest idea since browser tabs. (*) > Thanks for your (honest and to the point) oppinion, but really, 50 windows > open, and you hate tabs? I said "browser tabs". Window manager level window grouping is ok, and renders browser tabs useless. That was/is the point. I don't like seeing code duplication, and certainly not somewhere it doesn't belong. Web browsers should help the user with web browsing, window managers with window managing. Somehow I feel I have said this before. :) -- shared, pekwm people

Nov. 20, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Melvin Hadasht

Hi, Paul Pelzl wrote: > If this were the only concern, then maybe the solution is to > implement some sort of commandline option (e.g. --unified) that will > > 1) launch a new dillo if none are already running > 2) open a new window (or tab?) if there is already a dillo running > > Interested users could then "alias dillo='dillo --unified'" to get the > behavior you want. Of course, this does not have the benefit of > simplifying the code, but it would be a nice feature. I have a patch against old CVS at: http://melvin.hadasht.free.fr/home/dillo/server/index.html -- Melvin Hadasht

Nov. 20, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Paul Pelzl

On Thu, Nov 20, 2003 at 08:48:56PM +0100, Indan Zupancic wrote: > I did a little test, I compared the memory usage between opening new > Dillo's and opening just new windows, both opened the splash screen. I > opened 50 new Dillo's and 20 new windows (20 because I had to load the > splash screen manually, and the memory usage is constant anyway). I used > top and the total used memory numbers. One Dillo was already running (used > to open new windows and precache stuff). > > Results: > > 1369 k/Dillo versus 795 k/window. > > This means that a new Dillo uses 1.7 times more memory than a new window. If this were the only concern, then maybe the solution is to implement some sort of commandline option (e.g. --unified) that will 1) launch a new dillo if none are already running 2) open a new window (or tab?) if there is already a dillo running Interested users could then "alias dillo='dillo --unified'" to get the behavior you want. Of course, this does not have the benefit of simplifying the code, but it would be a nice feature. I think being able to launch multiple dillo processes can be useful. Paul

Nov. 20, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Melvin Hadasht

Hi, Indan Zupancic wrote: > >> What do you think about it? I think that the advantage of always having one Dillo is not an argument, because even now you can run only one instance. If you want that every "dillo" command uses the first instance, then another approach would be to use a "remote" or "server" mode, like mozilla, nedit, xemacs and vim have. I once made a patch for Dillo to support this. The patch is not uptodate, but I can update it on request. Concerning the second advantage (not using dpid): performance reasons would be of concern especially when large amount of data need to be passed from and to dillo (https), but maybe we need to quantify this before. > Different displays is indeed an issue. It is easy to open a new Dillo when > the display is different, but that means it should be possible to run > multiple Dillo's at the same time. Adding the fact that some people would > like to have it as an option, this means that Dillo can't rely on being > the only one running, and thus undoing one of the biggest advantages. :( > > Is it possible to open a new window on another display as program? If so, > it would be very easy to solve the multiple display problem. gtk1.2 cannot do this, but gtk2.0 can migrate a window from display to display. It can also open a new window in another display (display being another X server, like a remote host). -- Melvin Hadasht

Nov. 20, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Indan Zupancic

Hello, In reply to Jyri Jokinen: > I'm not really qualified but that has never stopped me before eather. Sure you are, you're a user. > You want to get rid of dpid in favor of library plugins and make dillo > execute as one process only. I'm right this far? Well, yes, but the first part is a more personal issue, executing Dillo as one process only is the main purpose (plugins can be still seperated processes of course, but it's only not necessary anymore). > 20+ browsing windows spirited away. > > How many times has this happened with Mozilla, M-Firebird or just > about any other web browser? How much did you swear after it? Maybe I'm just lucky, but it only happened with a certain browser on another OS, but then it took the whole OS down with it, so... I see your point though, but it practically means that it should never crash, and if it doesn't, we won't hear you complain, right? :) > Right now I practically allways launch a new dillo when i need a new > browser window. It's just so much nicer when all those 50 or more > windows I often have open don't go at one blow if something bad happens. I did a little test, I compared the memory usage between opening new Dillo's and opening just new windows, both opened the splash screen. I opened 50 new Dillo's and 20 new windows (20 because I had to load the splash screen manually, and the memory usage is constant anyway). I used top and the total used memory numbers. One Dillo was already running (used to open new windows and precache stuff). Results: 1369 k/Dillo versus 795 k/window. This means that a new Dillo uses 1.7 times more memory than a new window. Considering that Dillo is meant to be able to run on computers with little ram, it isn't such bad idea to in some way optimize for it a bit. And as you said, you almost always open a new Dillo, so wouldn't it be nice if you open a new window when it's possible. In other words, if you have a nice old pc with 4 mb ram free you can open 3 extra Dillo's, or 5 extra windows. Your choice. But you say you often have 50 windows open, which need 75 mb ram, so I guess ram isn't an issue for you. >> What do you think about it? > > I think it's the stupidest idea since browser tabs. (*) Thanks for your (honest and to the point) oppinion, but really, 50 windows open, and you hate tabs? I have fluxbox, with tabs, so I can manage 50 open windows easily, but how do you do that without any tabs? In reply to Frank Gevaerts: Different displays is indeed an issue. It is easy to open a new Dillo when the display is different, but that means it should be possible to run multiple Dillo's at the same time. Adding the fact that some people would like to have it as an option, this means that Dillo can't rely on being the only one running, and thus undoing one of the biggest advantages. :( Is it possible to open a new window on another display as program? If so, it would be very easy to solve the multiple display problem. Thanks for the feedback, Indan

Nov. 20, 2003

Emacs (was: kbnav3 patch test)

by Sebastian Geerken

> > (Emacs' use of tabs > > messes up things sometimes, and the 2-space indent it uses are not > > consistent with Dillo's conventions). Emacs users, put the following code into ~/.emacs: ---------------------------------------------------------------------- (defun array-find (a1 a2 &optional index-or-nil) (let ((index (if index-or-nil index-or-nil 0)) (l1 (length a1)) (l2 (length a2))) (if (> (+ index l2) l1) nil (let ((i 0)) (while (and (< i l2) (= (aref a1 (+ index i)) (aref a2 i))) (setq i (+ i 1))) (if (= i l2) index (array-find a1 a2 (+ index 1))))))) (defun my-c-hook () (if (array-find (buffer-file-name) "/dillo") (progn ;; dillo conventions (set-variable 'indent-tabs-mode nil) (set-variable 'c-basic-offset 3)) ;; conventions for other code (set-variable 'indent-tabs-mode t) (set-variable 'c-basic-offset 2))) (add-hook 'c-mode-hook 'my-c-hook) ---------------------------------------------------------------------- This hook for the C mode switches between different coding styles, a file with a path containing "/dillo" is considered to be part of dillo. (I'm not that familiar with Emacs lisp, probably, there is alraedy something like "array-find".) Sebastian

Nov. 20, 2003

Re: Re: [Dillo-dev] FLTK

by Melvin Hadasht

Jorge Arellano Cid wrote: > Hi there! Hi! > At this point, having an FLTK-based dillo starts to be a very > interesting option (especially after considering Owen's remarks, > the pango issues, and the new expose model in GTK2 which adds a > redesign stage for our progressive rendering). Maybe someone that has gtkhtml2 installed can tell us how it compares with respect to the current gtk2 patched Dillo ? I can only experiment with Firebird-gtk2-xft, and I must say that the difference with the gtk1.2 version exist but it way smaller than the difference between dillo-gtk2 and dillo-gtk1. I experimented lately with mlterm, a multilanguage terminal with bidi-support and xft. It is currently slower than xterm+xft and has annonying flickers when scrolling. This makes me feel that the bottleneck will be mainly pango, the drawing path being more easily optimized with proper drawing algorithm. In my app, I had to create a special gtktreeview to have good performance and low memory usage on +1000 items. The optimization was done on the algorithm level and a bit also on the expose path. > Why did we want to go to GTK2? Mainly because of UTF-8 support. To my eyes, there are two things that are important to allow most people access to Internet: Unicode support and Accessibility functionality. One advantage of GTK2 is proper Unicode support plus a Bidirectional algorithms and text layout and character shaping for many languages. Do you know if fltk2 has bidi support? I could not find any link about this. Another advantage is that when used with Gnome, GTK2 gains accessibility functionality for handicapped persons. I like to think that the kbnav is already one big step toward offering such functionality (perhaps it lacks a way to open context menus), thanks to Frank. But I must say I do not have any experience with Gnome and its accessibility functions. > Finally, from what I've seen, images can also be "handed" over > to FLTK. Avoiding having to decode them into RGB, and manage them > inside dillo (png.c, gif.c, jpeg.c, dicache.c, image.c, > dw_image.c, ...). Gtk2 comes with gdk-pixbuf. So you only need to pass it a file name or a pointer to a data. > This native FLTK images also provide an alpha channel so > background images should be easy to implement too. Do we really need alpha channel for background images? I mean, background images can drawn before foreground widgets, without the need for alpha channel. > I've been playing with fltk-1.1.4 for a while. It comes with a > manual and lots of examples. I played with version 2 from cvs, and it is amazingly fast. It is a shame that Gtk2 follows the inflation in resource needs like commercial products. -- Melvin Hadasht

Nov. 20, 2003

Re: [Dillo-dev] FLTK

by Jorge Arellano Cid

Hi there! Here come the latest news about the FLTK port feasibility analysis. There're lots of issues, but only a few major ones, so trying to be brief: "The main point of joy in dillo is its extraordinary speed." If porting to GTK2 leads to a much slower browser (as for instance like what Eric's tests showed), and with much bigger memory consumption (twice or more as Owen considered plausible), it certainly becomes a big concern. If the difference between using a BIG browser and dillo narrows to the point of making it better to wait for the BIG one and have all the features, dillo becomes irrelevant. (This is a compose statement because it adds the fact that BIG browsers have more features, which is a thing you currently trade-off for the joy of the speed in dillo). At this point, having an FLTK-based dillo starts to be a very interesting option (especially after considering Owen's remarks, the pango issues, and the new expose model in GTK2 which adds a redesign stage for our progressive rendering). Why did we want to go to GTK2? Mainly because of UTF-8 support. Now, I'll quote some very good news from FLTK's maintainer, Michael Sweet: <q> Jorge, I haven't made the official announcement yet, but we've decided to do a 1.2.x version of FLTK that incorporates many of the FLTK 2.0 things using a FLTK 1.x compatible API. Some things of note: - UTF-8 support - Display/print device support (same code that draws to the screen can print to a printer) - 32-bit coordinates - Basic style/scheme/theme API - New menu, browser, table, spinbox, etc. widgets - Better OSX integration using Quartz instead of QuickDraw - Better RGBA image display using Xrender on X11, AlphaBlend on WIN32, and Quartz on OSX when available. The developers of the FLTK UTF-8 and Fl_Device patches will be joining the project, and we have already completed the initial merge to start things off. We'll probably have beta snapshots available before Christmas, with a "gold" release in early 2004. -- ______________________________________________________________________ Michael Sweet, Easy Software Products mike at easysw dot com Printing Software for UNIX http://www.easysw.com </q> So we'd have: UTF-8, 32-bit coordinates, printer!, themes, antialiasing, etc, and with a much leaner engine. Another strong point is that with the new table widget, and the FLTK layout mechanism, much of the complexity in rendering/resize/event-handling/etc can be sent to FLTK instead of having to directly code it in our widgets. <q author="Michael Sweet"> The current FLTK layout mechanism is infinitely flexible, but takes a little getting used to since there are no layout "hints", just resizeable widgets inside groups. In short, you group widgets (and sometimes create empty "box" widgets) to get the layout behavior you want. This is actually a lot faster than the older Motif-style layout stuff that GTK+ uses... There are specialized group widgets (Fl_Pack, Fl_Tile, etc.) that provide for special positioning/resizing capabilities separate from the user resizing the window. </q> Finally, from what I've seen, images can also be "handed" over to FLTK. Avoiding having to decode them into RGB, and manage them inside dillo (png.c, gif.c, jpeg.c, dicache.c, image.c, dw_image.c, ...). This native FLTK images also provide an alpha channel so background images should be easy to implement too. I've been playing with fltk-1.1.4 for a while. It comes with a manual and lots of examples. ftp://ftp.easysw.com/pub/fltk/1.1.4/fltk-1.1.4-source.tar.bz2 (1.3 MB) Just: ./configure --enable-xft make cd test; ./help to have an idea of HTML rendering with antialiased fonts. then: ./demo to get a feel of the widget set. An interesting exercise. Cheers Jorge.- PS: Sebastian: I'm especially interested in your opinion and concerns about this. We have a very interesting opportunity, and we can ask Michael or Bill Spitzak. PS2: dillo-0.8.0 will be GTK1. (probably with kbnav, frames and tabs). (maybe https as explained in a former email)

Nov. 20, 2003

FORM:DICKSON M.

by MR Dickson Mubane.

FGood Day Friend, With warm heart I offer my friendship, and my greetings, and I hope this letter meets you in good time. It will be surprising to you to receive this proposal from me since you do not know me personally. However, I am sincerely seeking your confidence in this transaction, which I propose with my free mind and as a person of integrity and from a family with high moral respect . My name is Dickson Mubane, the first son of Mapele Mubane, of the most popular black farmer from Zimbabwe, murdered in the land dispute in my country. As led by my instict, My motherand Idecided to contact you through email, after searching for contacts via the internet,as it is the only means I can contact anybody since I am cutting off ties with Zimbabwe for security and safety reasons. However, I apologize if this is not acceptable to you. The purpose of this letter is to seek your most needed assistance in a business venture. Due to the land and political problems in Zimbabwe, as a result of President Robert Mugabe's introduction of new Land Act Reform wholly affecting the rich white farmers and the few rich black farmers, and his desire to hold on to power for life, my father for saw the danger that came in Zimbabwe. Before he was murdered, he withdrewall of our business foreign accounts in dollars and sold up our sharesin major companies. We then went to SOUTH AFRICA to deposit the sum of US$50.million (Fifty million, US dollars),in a private security company. This money was deposited with this Private Security company for safety and security reasons, and was to be used for the purchase of land, new machines and chemicals establishment of new farms in Europe.President Mugabe's support for the violent Zimbabwean war veterans andsome lunatics in the society, led to the murder of my beloved fatherand other innocent lives. I was continually threatened to abandon myinheritance from my father after he was murdered. I resited for awhile, but when the danger became unbearable, and I survived two murderattempts, I fled Zimbabwe. I am currently staying in the Netherlands where I am seeking political asylum. In fact my decision to come hereto seek asylum, is because the security company from South Africa, hasa branch here, and they have moved the deposit from their office in Johannesburg down here. I need you to assist in receiving thisconsignment from the security compamy. Since the law of Netherlands prohibits a refugee (asylum seeker) to be involved in such transactions and my mother advised that it will be better for our foreign partner to help receive this fund to avoid any eye brown being raised by Robert Mugabe, this is why I am seeking a genuine and reliable partner,who will assist in receiving the funds and also investing it wisely in a profitable venture.You have to understand that this decision taken by me entrusts my future and in your hands, as a result of the safe keeping of this money. If you accept to assist me, all I want you to do for me, is to assist with arrangements to claim the deposit from the security company from their office here in The Netherlands, as it has now been transfered from Johannesburg,South Africa to their branch in The Netherlands. The company will be legally informed of you representing my family. For your assistance, I have two options for you. Firstly you can choose to have 10% of the money for your assistance, and helping my family investing this funds, or you can go into partnership with me for the proper profitable investment of the money in your country. Whichever the option you want, please to notify me in your reply. I have also set aside 1% of this money for all kinds of expenses that come our way in the process of this transaction, and 4% of the total sum for Charitydonation.If you prefer to accept the 10% for assisting in representing my family to receive this funds, then 85%will be left for my family.Please, I want you to maintain the absolute secrecy for the purpose of this transaction. I look forward to your reply and co-operation, and Ithank you in advance as I anticipate your co-operation.You can reach me on my private line which is or via email Sincerely, Dickson Mubane. PLEASE YOU CAN READ ABOUT PROBLEMS IN ZIMBABWE FROM THE LINKS BELOW. http://news.bbc.co.uk/1/hi/world/africa/918781.stm http://news.bbc.co.uk/1/hi/world/africa/715001.stm http://news.bbc.co.uk/1/hi/world/africa/1063785.stm

Nov. 20, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Jyri Jokinen

On Thu, Nov 20, 2003 at 04:50:14PM +0100, Indan Zupancic wrote: > Always one Dillo has less overhead than running multiple instances at > the same time. > Beside, if Dillo uses library plugins then there is no need to fork at > all. I'm not really qualified but that has never stopped me before eather. You want to get rid of dpid in favor of library plugins and make dillo execute as one process only. I'm right this far? And once one happens to have 20+ dillo windows open with your proposed way, some library plugin (or dillo itself) decides to halt everything. Or segfault. 20+ browsing windows spirited away. How many times has this happened with Mozilla, M-Firebird or just about any other web browser? How much did you swear after it? Right now I practically allways launch a new dillo when i need a new browser window. It's just so much nicer when all those 50 or more windows I often have open don't go at one blow if something bad happens. > What do you think about it? I think it's the stupidest idea since browser tabs. (*) You asked. Dunno if my facts are right, but this is what my user experience tells me. Feel free to flame me if I got something terribly wrong. -- shared, (*) Nothing personal at Frank, you're a hard working guy doing things you believe in, appreciate it truly even I disagree with some of it.

Nov. 20, 2003

Re: [Dillo-dev] Proposal: United Dillo

by Frank Gevaerts

On Thu, Nov 20, 2003 at 04:50:14PM +0100, Indan Zupancic wrote: > A user can't run more than one Dillo instance. Sometimes it's wanted to > run multiple Dillo's, for instance two different versions. But that isn't > possible at all, or if version awareness is added, without losing > synchronization. It is often useful to be able to run multiple browsers on different displays. Frank -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan

Nov. 20, 2003

Re: [Dillo-dev] Small bug with combined frames/tabs/https patch and gcc 2.9x

by Indan Zupancic

> ssize_t St = SSL_read.... > > TO: > > ssize_t St; > St = SSL_read... The real problem is the "errno = 0" before the St. I handled it as a declaration, while it obviously isn't one. Just realized that after Paul Pelzl pointed it out (say thanks to Paul, he also sent a patch that adds proper openssl autoconfiguration :). I edited the patches, should be fixed now. New https version soon (after making sure the changes I made are worth it). Greetings, Indan

Nov. 20, 2003

Proposal: United Dillo

by Indan Zupancic

Hello, With "united Dillo" I mean that there is always just one Dillo running per user, so when you start Dillo while it is already running, then the current one will open a new window. I made a patch as proof of concept, see: http://www.xs4all.nl/~dorinek/dillo This approach has two big advantages: 1) Always one Dillo has less overhead than running multiple instances at the same time. 2) Automatic synchronization/no need for synchronization anymore. First advantage is in the spirit of Dillo, wanting to be small, light and fast. Second advantage means that doing certain things will be much simpler, like having always cookies, no need to synchronize plugins, meaning that dpid is not really needed anymore, because most of the points from the problem list are solved (see Dpid.txt). Problems that aren't solved: * Forks can be expensive (Dillo had to fork its dpis). But dpid does much more than simply forking: it forks and then starts up an external program (which often also forks and starts up wget). Beside, if Dillo uses library plugins then there is no need to fork at all. * It increments dillo's core size. The patch adds about 70 lines of code to dillo.c and increases dillo with about 1 K. It is true that if you get rid of dpid then more code is needed in Dillo's core. But that's only moving the code to some other place, no real increase if you ask me. Having a seperate dpid has much more overhead at runtime (seperate process versus bigger executable). You can always make a plugin handling library, then it isn't part of Dillo's core. Of course a united Dillo has problems/disadvantages too: It is sometimes still needed to synchronize multiple windows. If it's not implemented carefully, you may lose functionality (aka command line options). A user can't run more than one Dillo instance. Sometimes it's wanted to run multiple Dillo's, for instance two different versions. But that isn't possible at all, or if version awareness is added, without losing synchronization. What do you think about it? Greetings, Indan

Nov. 20, 2003

Small bug with combined frames/tabs/https patch and gcc 2.9x

by Mike Eriksen

I friend of mine ran into trouble with the lovely combined frames/tabs/https patch and gcc 2.9x. It turned out to be an issue already discussed earlier for the stand-alone version of the https patch concerning a small difference between gcc 2.9x and 3.x, but possibly some people did't catch this original discussion. The cure goes like this: At line 842 in dillo/src/IO/IO.c change FROM: ssize_t St = SSL_read.... TO: ssize_t St; St = SSL_read... The same goes for line 872. I had the impression this already was fixed by Indan, but apparently not. Best regards, Mike -- Thinstation FAQ maintainer http://thinstation.sourceforge.net - a light, full featured linux based thin client OS

Nov. 20, 2003

Re: kbnav3 patch test

by Jorge Arellano Cid

Frank, > Jorge Arellano Cid wrote: > > >Hi Frank, > > > > After waiting for a week as you suggested, today I gave a > >review to the new kbnav patch. It feels good! > > > > After some testing I came across a page that produces a > >segfault. The attached patch is against today's CVS + a couple of > >compiler-warning removals. The page is also attached. Beware that > >the segfault is only caught when the new parser is used, and that > >the page has bad-html. The case is interesting though, because a > >weird widget tree is generated and iterators should be able to > >handle/survive them! > > > > Please give it a look. > > > > Cheers > > Jorge.- > > > I have taken a look at your patch-to-my-patch, but did not apply it to > the version I will publish later today. :-o > I did do some manual > reformatting to correct some tab-related problems Good! > (Emacs' use of tabs > messes up things sometimes, and the 2-space indent it uses are not > consistent with Dillo's conventions). Thanks, we strive to be style consistent. BTW, I didn't try to fix indentation in the patch, it was just to do a test run. > Some files seem to be missing from > the patch you sent me, I guess you did not make any changes to those? My mistake. > > I did not see anything in your patch which would have corrected any > compiler warnings by that way, with a possible exception for the > disputed URL_ILLEGAL_CHARS_ macro. In my patch I used > URL_ILLEGAL_CHARS_(u) in html.c, while you use URL_ILLEGAL_CHARS(u). In > the current patch I use URL_ILLEGAL_CHARS(u) as well. The end result > should be the same however now that both versions exist. What compiler > warnings did you get which were corrected by your modifications to my patch? focus.c: In function `Focus_state_find_list': focus.c:268: warning: `list' might be used uninitialized in this function focus.c: In function `Focus_state_find_link': focus.c:465: warning: `list' might be used uninitialized in this function gcc version 3.2.3 > > On that Tarot-page you added to the message, I can say that navigation > is still quirky. But so is the page, it produces 9 warnings about > misplaced </a> tags. If you look at the source, you'll notice that it > misses several closing </A> tags (causing Dillo to allocate links all > over the page). It also contains some links with <BR> in them, which > used to crash patched Dillo because of the problem with > a_Dw_page_construct_iterator (which used to always set the mask to > DW_CONTENT_ALL, I changed this to a user-settable mask like all other > iterators have). I guess you attached the page because of those crashes? Yes, for you to have a way to reproduce it. BTW, that is what I meant with: "page has bad-html". > I will probably publish a new version of the patch (4) today, together > with a new version of the tab/frame patch. That version should be more > or less ready to commit, as no serious problems have cropped up for > several days now. See the list for problems found and corrected > (including the one causing the Tarot page to crash by the way - see my > message dated Wed, 12 Nov 2003 11:00:58 +0100). Oh, I didn't find anything about it at GMANE !? Cheers Jorge.-

Nov. 20, 2003

mail adress

by Sebastian Geerken

Hi! Please send private mail to me via <s.geerken(a)ping.de>. Do not use <sgeerken(a)student.physik.uni-dortmund.de>, the latter causes some problems. Sebastian

Nov. 18, 2003

Re: [Dillo-dev] tabs, https, ...

by Indan Zupancic

Hello, Thank you for your kind offer, but as it looks now it's just Frank and me who could use a CVS branch, and perhaps the Dillo developers are willing to make a CVS branch too, then you don't have to be bothered with mirroring the base Dillo and serving it. Having one or more CVS branches would be great, the question is if the Dillo developers are willing to cooperate and provide them, or that we should make use of your offer. Let's see what Frank has to say about it. Greetings, Indan

Nov. 17, 2003