- Dillo-dev - lists.mailman3.com

Dillo Configuration

by Ringwraith

I'd first like to say thanks for Dillo, its sooo great loading the complete list of CPAN modules in less than 2 seconds, as compared with the nice 5 to 10 seconds with mozilla/firebird :) I do not know if this has been discussed but: One thing I noticed, as Dillo matures, it will obviously need a configuration/preferences menu. I am really starting to get pissed off (pardon lang) at how other browsers use the standard toolkit based widgets to do their configuration. This, IMHO, with the features of today's browsers, clutters up the user interface and causes bloat with the browser. I think having a PURE html interface to doing web browser configuration would do two important things: 1. Gives the flexibility to have a feature rich browser while maintain simplicity. It is a web browser, 90% of the user interface is a web page, so why not make the GUI something the user is familiar with. 2. Reduces bloat. IMHO not so much importantly, 3. Allows for nice customization (themes) of the user interface by someone who knows HTML and vi w/o having to recompile dillo. ;) I am considering to attempt to make a module for the configuration of Dillo that will do this: 1. Configure all aspect of the browser including the (upcoming?) plugin support. 2. Allow pluggable configuration. If plugins have any configurable options (sometimes they do), they will also be configurable using the interface. This module would be accessed through something like: config:// or about:config (i like config:// much better) It would obviously have some security built in so that no one can pull a IE type trick on us and be able to do things they shouldn't. Anyhow this is just a brainstorm, what are your thoughts on doing something like this?

Sept. 29, 2003

Re: [Dillo-dev] Yes or No: optional compilation of 'extra' features

by Frank de Lange

On Tue, Sep 30, 2003 at 04:41:19PM +0200, Sebastian Geerken wrote: > Its not a matter of liking or not, users may simply ignore tabs (and > there may perhaps be a _user_ option for alternative presentations of > frames). However, conditional compilation makes maintaining more > difficult (and since that's the task of Jorge and me, the list is the > wrong place to ask) ...beep... wrong I could of course split the tree, and maintain the tabbed/framed version separately. The list is the place to ask all developers, there is no hierarchy in this brave new world, if one does not pick up a task someone else will... I think the list is a good place to ask things like this, since that is the place where (prospective) developers go for information on these issues. , so it is a question whether the reduced binary > size outweighs the increased maintaining problems. For you, maybe. For someone who wants as small a program as possible, maybe not. Who are we to say? The thing is, currently there is a clear separation in the code, which does seem to be beneficial for at least some people. Removing that separation makes it a bit easier to maintain the code later on, but also removes the benefits. Choice is good... The needs of the many, or the few, outweigh the needs of the one (thanks, Spock). Anyway, I vote to keep the separation of the tab code, but remove the separation for the frame code. > What I meant is that the link menu should have to entries, "Open link > in new tab", and "Open link in new background tab" (or so). Options > should reflect different user's taste, while this difference depends > on the situation. That can be implemented simply, but clutters the menu. I think having the option to chose a default behaviour is a good thing. The default is eg. used when opening a tab for the "_blank" URL target, on middle click, etc. Renaming Doc to something else is no big deal, but should only be done when really needed. And Doc does not deal with presentation, it deals with keeping state for a document. Presentation is BrowserWindow, Tab, Frameset, Frame. Or it should be, in any case. The separation is not really complete yet... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / \ \ `--| _/ <Hacker for Hire> \ `---' \ +46-734352015 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Sept. 28, 2003

Problems with cookies

by johannes leimbach

Hi ! I am using dillo 0.7.3 on my gentoo box, and it just works great! It's fast, does good rendering, short: I like it One thing bugs me though, it does not save cookies from any message boards (PHPBB). I have cookies enabled (DEFAULT ACCEPT in cookiesrc, file cookies does exist), but still: No writing. I have just noticed google does place a cookie, so it isn't entirely borked. Hey, how can i change this? It would rally make that browser perfect :) Thanks for answer & cu

Sept. 28, 2003

Re: [Dillo-dev] Re: Gtk-WARNING with link/image menu

by Frank de Lange

On Sat, Sep 27, 2003 at 10:33:44AM -0400, Jorge Arellano Cid wrote: > > On Thu, 25 Sep 2003, Frank de Lange wrote: > > > Jorge, > > > > Your patch for the link/image menu makes Dillo give Gtk-CRITICAL warnings: > > > > Gtk-WARNING **: invalid cast from (NULL) pointer to `GtkObject' > > > > Gtk-CRITICAL **: file gtkobject.c: line 1100 (gtk_object_remove_data): > > assertion `object != NULL' failed. > > > > These are caused by attempts to remove data from non-existing objects in > > menu.c: > > Really weird, as the "non-existing" object is created with the > bw and destroyed with it. > > Anyway to reproduce it? Yeah: 1: Open a frameset 2: in a frame in this frameset, choose "This Frame->Show only this frame" 3: watch the error (that is, without the patch... I have added it to the tab/frame patch, so you will NOT see it with my patch... just remove the if(...) to see it... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / \ \ `--| _/ <Hacker for Hire> \ `---' \ +46-734352015 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Sept. 28, 2003

Re: Gtk-WARNING with link/image menu

by Jorge Arellano Cid

On Thu, 25 Sep 2003, Frank de Lange wrote: > Jorge, > > Your patch for the link/image menu makes Dillo give Gtk-CRITICAL warnings: > > Gtk-WARNING **: invalid cast from (NULL) pointer to `GtkObject' > > Gtk-CRITICAL **: file gtkobject.c: line 1100 (gtk_object_remove_data): > assertion `object != NULL' failed. > > These are caused by attempts to remove data from non-existing objects in > menu.c: Really weird, as the "non-existing" object is created with the bw and destroyed with it. Anyway to reproduce it? Jorge.-

Sept. 27, 2003

Re: [Dillo-dev] [PATCH] Version 10 of tab/frame patch is ready...

by Victor Sahlstedt

On Sat, 27 Sep 2003 12:56:59 +0200 Frank de Lange <frank(a)unternet.org> wrote: > Which patch are you actually using, and which CVS version? Patch 10 (the one I > just released) is against 09/26 CVS (not 08/21 like you state in your message), > and the patch file is dillo-20030926-tabs.patch.gz (not > dillo-20030821-tabs.patch.gz). My wrong. I fetched the patch from http://www.geocities.com/ikbenfrank/ but didn't reflect over the fact that it was dated 08/21, not 09/26. No wonder it didn't apply to 9/26-CVS. The 9/26-patch worked fine with 9/26-CVS, keep up the good work. - Victor

Sept. 27, 2003

Re: [Dillo-dev] [PATCH] Version 10 of tab/frame patch is ready...

by Frank de Lange

On Sat, Sep 27, 2003 at 02:47:22AM +0200, Victor Sahlstedt wrote: > On Fri, 26 Sep 2003 19:48:04 +0200 > Frank de Lange <frank(a)unternet.org> wrote: > > > The next version (10) of my tab patch is ready > > salan@smedjan:~/incoming/cvs/dillo> gmake -s > Making all in doc > Making all in src > Making all in IO > http.c: In function `Http_use_socket': > http.c:228: structure has no member named `bw' > http.c:232: structure has no member named `bw' > http.c: In function `Http_connect_socket': > http.c:320: structure has no member named `bw' > http.c: In function `Http_send_query': > http.c:339: structure has no member named `bw' > http.c: In function `Http_get': > http.c:406: structure has no member named `bw' > http.c: In function `a_Http_ccc': > http.c:437: structure has no member named `bw' > http.c:466: structure has no member named `bw' > http.c:477: structure has no member named `bw' > http.c:502: structure has no member named `bw' > gmake[3]: *** [http.o] Error 1 > gmake[2]: *** [all-recursive] Error 1 > gmake[1]: *** [all-recursive] Error 1 > gmake: *** [all] Error 2 > > dillo-20030821-tabs.patch.gz patched against 08/21 CVS. > It's related to the patch as Dillo compiles fine without it. > > OpenBSD 3.3 / GCC 2.95.3 > > - Victor Hm, sounds like BW_MSG is not patched correctly in your case, did the patch not apply cleanly? Which patch are you actually using, and which CVS version? Patch 10 (the one I just released) is against 09/26 CVS (not 08/21 like you state in your message), and the patch file is dillo-20030926-tabs.patch.gz (not dillo-20030821-tabs.patch.gz). Try again with the correct versions, and if it does not work, by all means let me know... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / \ \ `--| _/ <Hacker for Hire> \ `---' \ +46-734352015 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Sept. 27, 2003

Re: [Dillo-dev] [PATCH] Version 10 of tab/frame patch is ready...

by Kelson Vibber

On Friday 26 September 2003 10:48 am, Frank de Lange wrote: > The next version (10) of my tab patch is ready (see bottom of this > message for download instructions). In case anyone's interested, I've posted RPMs for most of my usual set of distributions, based on 0.7.3 and the new tab patch at http://www.hyperborea.org/software/dillo/modified.html This covers Red Hat 6,7,8, and 9, Mandrake 8.1 and 8.2, Mandrake 9.1 PPC, and the source RPM, plus a CVS-based RPM or SuSE 8.1 contributed by Patrick Shanahan. I'll get the last two (SuSE 8.2 and Mandrake 9.1 x86) posted tomorrow. -- Kelson Vibber kelson(a)pobox.com http://www.hyperborea.org/ Creative Writing - Photography - The Flash

Sept. 27, 2003

Re: [Dillo-dev] Mac OS X Aqua port and new project HEML

by Kelson Vibber

Sorry to extend this thread again... I just wanted to apologize for anything inflammatory I said earlier. Andreas has the right idea: let the past stay in the past and move on. -- Kelson Vibber www.hyperborea.org

Sept. 27, 2003

Re: [Dillo-dev] [PATCH] Version 10 of tab/frame patch is ready...

by Victor Sahlstedt

On Fri, 26 Sep 2003 19:48:04 +0200 Frank de Lange <frank(a)unternet.org> wrote: > The next version (10) of my tab patch is ready salan@smedjan:~/incoming/cvs/dillo> gmake -s Making all in doc Making all in src Making all in IO http.c: In function `Http_use_socket': http.c:228: structure has no member named `bw' http.c:232: structure has no member named `bw' http.c: In function `Http_connect_socket': http.c:320: structure has no member named `bw' http.c: In function `Http_send_query': http.c:339: structure has no member named `bw' http.c: In function `Http_get': http.c:406: structure has no member named `bw' http.c: In function `a_Http_ccc': http.c:437: structure has no member named `bw' http.c:466: structure has no member named `bw' http.c:477: structure has no member named `bw' http.c:502: structure has no member named `bw' gmake[3]: *** [http.o] Error 1 gmake[2]: *** [all-recursive] Error 1 gmake[1]: *** [all-recursive] Error 1 gmake: *** [all] Error 2 dillo-20030821-tabs.patch.gz patched against 08/21 CVS. It's related to the patch as Dillo compiles fine without it. OpenBSD 3.3 / GCC 2.95.3 - Victor

Sept. 27, 2003

[PATCH] Version 10 of tab/frame patch is ready...

by Frank de Lange

Hi'all, The next version (10) of my tab patch is ready (see bottom of this message for download instructions). Control over margins in (i)frames has been improved (no more extraneous margin space in iframe). Dillo (when configured for frameset support) now always renders frameset - even when body content is placed outside the frameset. Frame resize support has been improved a bit. Worked around a bug in GtkContainer which messed up the 'tab' order (focus got stuck in GtkToolbar widgets). Improved/corrected focus handling in dw_gtk_scrolled_frame. New features: - interactive search ('find as you type') on "/" key - new preference: popup_dialogs=([YES]/NO) when set to NO the status bar and location bar are used for search and open URL. Open file and save file still use popup dialogs, though. Changed preferences from previous versions of patch: - frame_blank_in_tab and tab_on_middle_click are now merged into a new preference: tab_instead_of_window=(YES/[NO]) - document_title_use_url is gone, this functionality is now default - (for those who downloaded the interim-patch with find_as_you_type) find_as_you_type is gone, this functionality is bound by default to the "/" key. Use Ctrl-F for normal (non-interactive) search Some behavioural changes with regard to stock (CVS) Dillo: - Shift-Ctrl-L (instead of Ctrl-L) for "open URL" dialog - Ctrl-L for "focus location bar" - Ctrl-S for "Save page As..." - Ctrl-U for "view source" while in a document, "clear entry" everywhere else (in stock Dillo this key is bound to "focus location bar" while in a document) - Ctrl-B for "Bookmark this page" - Alt-H for "Home" - "/" starts incremental search instead of normal search. For normal (non-incremental) search use Ctrl-F The popup menu over images and hand cursor over input image features wihch used to be part of this patch have meanwhile been committed to CVS. The same goes for the bug fixes to dw_image and dw_widget. Support for the 0.7.3 branch will be dropped for the next version of this patch. Some of the new features (interactive search, popup dialog=NO, tab order bug fix) are not availabe in the 0.7.3 version of the patch. if you want the new features you'll have to switch to 0.8.0-pre. Sorry, folks, but that is the price you pay for progress... Currently, both tab and frame support can be turned off completely, producing a smaller binary. I might (on request of other Dillo developers) remove the conditional compilation, thereby making tab and frame support a permanent feature of Dillo. If you want to keep the conditional compilation feature, speak out on the mailing list! Frameset (and iframe) support is enabled by default, it can be disabled using the configure option --enable-xhtml-dtd=strict. You can also use --enable-xhtml-dtd=transitional, which will give you iframe but no frameset support. The default option, --enable-xhtml-dtd=frameset, gives both iframe and frameset support. As usual, tab support can be disabled using --disable-tabs. What does not work yet: - the full_screen_off_button is not shown in frame documents. Use double-click instead to toggle the full screen setting... - the frameborder attribute works, but dw_gtk_scrolled_frame always draws a (focus) shadow around itself - even with the border size is set to 0. This can be solved in several ways - adding a 'borderless' attribute to dw_gtk_scrolled_frame, using a special borderless GTK theme for the widget, etc. In GTK2 this is all much easier (just set the widget's style's xthickness/ythickness to 0), but we're not there yet... - borderless frames can not be resized, even though Dillo always shows a thin border (see above). Who cares about resizing borderless frames? Mozilla does it, but I don't think this is an issue. Agree? - iframes always have a border (see above) Tabs, Frames and browser bloat ============================== version: 0.8.0-pre patch: dillo-20030926-tabs.patch.gz unpatched: 292372 bytes patched, no tabs, no frames: 298624 bytes patched, with tabs, no frames: 306176 bytes patched, no tabs, with frames: 315200 bytes patched, with tabs, with frames: 322784 bytes version: 0.7.3 patch: dillo-0.7.3-20030926-tabs.patch.gz unpatched: 285248 bytes patched, no tabs, no frames: 291852 bytes patched, with tabs, no frames: 298700 bytes patched, no tabs, with frames: 308268 bytes patched, with tabs, with frames: 316556 bytes (gcc 3.2.2, binutils 2.13.90.0.18, CFLAGS "-Os") Download instructions ===================== There are two versions of the patch, one for Dillo 0.7.3 (release) and one for Dillo 0.8.0-pre (CVS). Make sure to download the correct version for the Dillo source you want to patch! If you patch the CVS source, do not forget to run ./autogen.sh after applying the patch. The CVS patch is made against 20030926 CVS, while the 0.7.3 patch is made against Dillo-0.7.3.tar.bz2 (the source tarball on the main Dillo website). Both versions of the patch can be downloaded from the usual (ad-happy, but...) Geocities site: http://www.geocities.com/ikbenfrank/ More specifically for both versions: Dillo 0.8.0-pre (CVS) ===================== http://www.geocities.com/ikbenfrank/dillo-20030926-tabs.patch.gz size: 73796 bytes (gzipped, as downloaded) 315210 bytes (uncompressed) md5sum: e8e1bf9d20ff26991c9d3b7cc1202ee2 (gzipped, as downloaded) 127d224ff29ce263d685718c7ca511f1 (uncompressed) Dillo 0.7.3 (release) ===================== http://www.geocities.com/ikbenfrank/dillo-0.7.3-20030926-tabs.patch.gz size: 88264 bytes (gzipped, as downloaded) 369994 bytes (uncompressed) md5sum: 51df11b26723283124ada4368a9958ea (gzipped, as downloaded) 64769d5f996cec2ac248578a234b32a7 (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." ]

Sept. 26, 2003

Re: [Dillo-dev] Dillo authorization question...

by Kelson Vibber

At 11:30 AM 9/25/2003, Ronald W. Henderson wrote: >Does dillo authorization via a popup login authorization dialog? >... >Is there a patch for this? There's at least one: http://www.zone.ee/myzz/dillo/0.7.3/dillo-0.7.3-mzz.html Kelson Vibber www.hyperborea.org

Sept. 26, 2003

Re: [Dillo-dev] Yes or No: optional compilation of 'extra' features

by Andreas Kemnade

On Thu, 25 Sep 2003 14:51:45 +0200 Frank de Lange <frank(a)unternet.org> wrote: > Hi'all, > > Those of you who have tried my tab/frames patch will know that I usually make > all 'extra' features optional. This allows those who {do not {need|like}|can > not afford} those features to leave them out of the resulting binary. However, > it also makes the code somewhat more complex, as the optional features are > enabled/disabled through conditional compilation (#ifdef/#ifndef....#endif). > The space saved by leaving out tabs and frames is currently about 25 kilobytes > (Kib, kB, KB, choose your acronym...). > > I have gotten some comments on this, suggesting the removal of these > conditional statements. This way, Dillo would ALWAYS have the extra features > (tabs and frames). > > Before I say 'yes' or 'no' to these suggestions, I'd like to know what your > thoughts are on this. > 25 KB can be important on PDAs. I guess having real frame support is not always a good idea on PDAs because of the low resoltion. On many pages you can easily find the navbar and then go to the content pages from there. So the simple frame support now in cvs is enough in some situations. Greetings Andreas Kemnade

Sept. 26, 2003

Re: [Dillo-dev] Yes or No: optional compilation of 'extra' features

by Patrick Shanahan

* Frank de Lange <frank(a)unternet.org> [09-25-03 16:14]: > On Thu, Sep 25, 2003 at 09:17:12PM +0200, Andreas Schweitzer wrote: > > > I'm guessing almost everybody wants to have frames, so maybe removing > > > the conditional compilation of frames is worthwhile for the sake of > > > simplifying code. > > > > Not only everybody *wants* it. Afterall, frames are part of > > the HTML standard. So it makes sense to have them. > > > > But then again, as far as I understood some of the last e-mails > > from Jorge : isn't he reviewing this patch now or pretty > > soon ? > > It was in reaction to comments from Sebastian that I posed this question to the > list. He suggested removing the conditional compile, but I want to know what > the list has to say on this. As a quick look at the list archives will show, > not everyone likes these new additions to Dillo. The _tabbed_ browsing is wonderful and, afaiac, necessary, along with the tab_on_middle_click. > - exchange tab_load_in_background with a UI element/choice (I think this > should be delayed until Dillo has a preference UI/plugin to avoid > unnecessary complexity and one-off solutions) acceptable > I will release a new version today or tomorrow Looking forward. Will provide a SuSE 8.1 rpm if I am able to compile. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org

Sept. 25, 2003

Re: [Dillo-dev] Yes or No: optional compilation of 'extra' features

by Frank de Lange

On Thu, Sep 25, 2003 at 09:17:12PM +0200, Andreas Schweitzer wrote: > > I'm guessing almost everybody wants to have frames, so maybe removing > > the conditional compilation of frames is worthwhile for the sake of > > simplifying code. > > Not only everybody *wants* it. Afterall, frames are part of > the HTML standard. So it makes sense to have them. > > But then again, as far as I understood some of the last e-mails > from Jorge : isn't he reviewing this patch now or pretty > soon ? It was in reaction to comments from Sebastian that I posed this question to the list. He suggested removing the conditional compile, but I want to know what the list has to say on this. As a quick look at the list archives will show, not everyone likes these new additions to Dillo. I have already removed some preferences which could be combined (frame_blank_in_tab and tab_on_middle_click -> tab_instead_of_window) or which should be defaulted to the new functionality (document_title_use_url). Other suggestions Sebastian made are: - Remove tab title compression/shortening (I might create a new label widget which compresses/shortens text to a given size for this functionality) - exchange tab_load_in_background with a UI element/choice (I think this should be delayed until Dillo has a preference UI/plugin to avoid unnecessary complexity and one-off solutions) - rename "DilloDoc" to something else (I do not agree, DilloDoc is descriptive and short) The current state of the patch is: - still have conditional compile - have removed unnecessary preferences - have removed some recent changes to CVS nav.c which conflict with document/interface separation (have mailed Jorge about this) - have added incremental search and status-bar search widget (instead of popup) I will release a new version 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." ]

Sept. 25, 2003

Re: [Dillo-dev] Yes or No: optional compilation of 'extra' features

by Andreas Schweitzer

> I'm guessing almost everybody wants to have frames, so maybe removing > the conditional compilation of frames is worthwhile for the sake of > simplifying code. Not only everybody *wants* it. Afterall, frames are part of the HTML standard. So it makes sense to have them. But then again, as far as I understood some of the last e-mails from Jorge : isn't he reviewing this patch now or pretty soon ? > Thanks for all your work, Frank. I second that ! Great work ! Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Sept. 25, 2003

Dillo authorization question...

by Ronald W. Henderson

Group: Does dillo authorization via a popup login authorization dialog? I want to use dillo to manage my linksys router. When I use html management with this router I get the following output from dillo: 401 Unauthorized Authorization Required. I have dillo version 0.7.3 Is there a patch for this? Thanks.... Ronald W. Henderson

Sept. 25, 2003

Re: [Dillo-dev] Yes or No: optional compilation of 'extra' features

by Paul Pelzl

On Thu, Sep 25, 2003 at 02:51:45PM +0200, Frank de Lange wrote: > Those of you who have tried my tab/frames patch will know that I usually make > all 'extra' features optional. This allows those who {do not {need|like}|can > not afford} those features to leave them out of the resulting binary. However, > it also makes the code somewhat more complex, as the optional features are > enabled/disabled through conditional compilation (#ifdef/#ifndef....#endif). > The space saved by leaving out tabs and frames is currently about 25 kilobytes > (Kib, kB, KB, choose your acronym...). > > I have gotten some comments on this, suggesting the removal of these > conditional statements. This way, Dillo would ALWAYS have the extra features > (tabs and frames). > > Before I say 'yes' or 'no' to these suggestions, I'd like to know what your > thoughts are on this. > > So, speak up. Have a look at the code (look for #ifdef XHTML_DTD_... and > #ifndef DISABLE_FRAMES) and tell me whether the savings in space are worth the > added complexity... Judging by previous threads in this list, a number of people seem to strongly dislike tabs, so it would seem that DISABLE_TABS is a good thing. (I personally disable tabs, but only because I use a tabbing window manager. I think having tab support in Dillo is a great thing.) I'm guessing almost everybody wants to have frames, so maybe removing the conditional compilation of frames is worthwhile for the sake of simplifying code. Thanks for all your work, Frank. Frames support is really nice for browsing groups.google.com. Paul

Sept. 25, 2003

Re: [Dillo-dev] Yes or No: optional compilation of 'extra' features

by Frank de Lange

On Thu, Sep 25, 2003 at 01:53:01PM -0400, Paul Pelzl wrote: > Thanks for all your work, Frank. Frames support is really nice for > browsing groups.google.com. :-) That was one of my main reasons to implement frames... 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." ]

Sept. 25, 2003

recent changes to nav.c

by Frank de Lange

Jorge, Recently you added a new function (a_Nav_push_nw()) to nav.c. Though that function works fine, it should not be there... Why not? IMO, nav.c should NOT be concerned with windows, tabs, frames or whatever 'visual/physical' location a document is displayed in. It should just concern itself with the state of the document itself. This way, interface and document code are better separated, making it much easier and cleaner to add interface functionality (like tabs, frames, whatever) to Dillo. I have removed this function from my tab/frame patch, as the functionality it provides is - and has for a long time - already present in commands.c. That seems to be a better location for this type of functionality (even though commands.c does end up being a sort of grab-bag for miscellaneous stuff, maybe it should be reorganized a bit...) 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." ]

Sept. 25, 2003

Re: [Dillo-dev] Yes or No: optional compilation of 'extra' features

by Frank de Lange

On Thu, Sep 25, 2003 at 09:52:20AM -0500, Patrick Shanahan wrote: > > So, speak up. Have a look at the code (look for #ifdef XHTML_DTD_... > > #and ifndef DISABLE_FRAMES) and tell me whether the savings in space > > #are worth the > > added complexity... > > IANAP, but why not control the _optional_ FEATURES thru the rc file, > (on/off, yes/no, 1/0)? That is possible, but it does not save any space in the resulting binary. Conditional compilation does. This can be an issue, even though the total size of tabs+frames tops at about 25 K. If I remove the conditional compilation, I will probably add a pref to disable tabs though, as these seem to be 'controversial'... (as similar functionality can be provided by some WM's) 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." ]

Sept. 25, 2003

errno and glibc

by Frank de Lange

Hi'all, Some of you might have run into the same problem as I did when I tried to compile the latest CVS with -Werror: dpi_service.o(.text+0x1d4): In function `dpi_dir': ../../../dillo_tabs/dpid/dpi_service.c:127: undefined reference to `errno' dpi_service.o(.text+0x3fc): In function `rd_dpi_dir': ../../../dillo_tabs/dpid/dpi_service.c:187: undefined reference to `errno' dpi_service.o(.text+0x57b):../../../dillo_tabs/dpid/dpi_service.c:211: undefined reference to `errno' dpi_service.o(.text+0x8df): In function `send_servers_list': ../../../dillo_tabs/dpid/dpi_service.c:290: undefined reference to `errno' This is caused by the failure to include <errno.h>, which is where errno is declared. Just add #include <errno.h> to dpid/dpi_service.c and it compiles cleanly (at least here...) <PATCH> --- dillo/dpid/dpi_service.c 2003-09-15 02:56:41.000000000 +0200 +++ dillo_tabs/dpid/dpi_service.c 2003-09-25 17:13:31.263098504 +0200 @@ -25,6 +25,7 @@ #include <string.h> #include <dirent.h> #include <error.h> +#include <errno.h> #include <glib.h> #ifdef TEST #include "testdat.h" </PATCH> Jorge, can you apply this patch? Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Sept. 25, 2003

Re: [Dillo-dev] Yes or No: optional compilation of 'extra' features

by Patrick Shanahan

* Frank de Lange <frank(a)unternet.org> [09-25-03 08:39]: > > Those of you who have tried my tab/frames patch will know that I > usually make all 'extra' features optional. This allows those who {do > not {need|like}|can not afford} those features to leave them out of > the resulting binary. However, it also makes the code somewhat more > complex, as the optional features are enabled/disabled through > conditional compilation (#ifdef/#ifndef....#endif). The space saved > by leaving out tabs and frames is currently about 25 kilobytes (Kib, > kB, KB, choose your acronym...). > > I have gotten some comments on this, suggesting the removal of these > conditional statements. This way, Dillo would ALWAYS have the extra > features (tabs and frames). > > Before I say 'yes' or 'no' to these suggestions, I'd like to know > what your thoughts are on this. > > So, speak up. Have a look at the code (look for #ifdef XHTML_DTD_... > #and ifndef DISABLE_FRAMES) and tell me whether the savings in space > #are worth the > added complexity... IANAP, but why not control the _optional_ FEATURES thru the rc file, (on/off, yes/no, 1/0)? -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org

Sept. 25, 2003

Re: [Dillo-dev] Yes or No: optional compilation of 'extra' features

by Victor Sahlstedt

On Thu, 25 Sep 2003 14:51:45 +0200 Frank de Lange <frank(a)unternet.org> wrote: > I have gotten some comments on this, suggesting the removal of these > conditional statements. This way, Dillo would ALWAYS have the extra features > (tabs and frames). Well, I doubt 25kB is an issue for anyone and if people are uncomfortable with tabs they still have the ability to open a new window. I can't speak for the majority but personally I don't see a reason why anyone wouldn't want the frames. > Before I say 'yes' or 'no' to these suggestions, I'd like to know what your > thoughts are on this. > > So, speak up. Have a look at the code (look for #ifdef XHTML_DTD_... and > #ifndef DISABLE_FRAMES) and tell me whether the savings in space are worth the > added complexity... Personally, I don't think it's worth it. As I use the features myself though I might be a bit biased. - Victor

Sept. 25, 2003

Yes or No: optional compilation of 'extra' features

by Frank de Lange

Hi'all, Those of you who have tried my tab/frames patch will know that I usually make all 'extra' features optional. This allows those who {do not {need|like}|can not afford} those features to leave them out of the resulting binary. However, it also makes the code somewhat more complex, as the optional features are enabled/disabled through conditional compilation (#ifdef/#ifndef....#endif). The space saved by leaving out tabs and frames is currently about 25 kilobytes (Kib, kB, KB, choose your acronym...). I have gotten some comments on this, suggesting the removal of these conditional statements. This way, Dillo would ALWAYS have the extra features (tabs and frames). Before I say 'yes' or 'no' to these suggestions, I'd like to know what your thoughts are on this. So, speak up. Have a look at the code (look for #ifdef XHTML_DTD_... and #ifndef DISABLE_FRAMES) and tell me whether the savings in space are worth the added complexity... BTW, I do not mind either way... As always, look for the patch at http://www.geocities.com/ikbenfrank A new patch, with some new functionality (sorry Sebastian, functionality was added before you asked me not to add anything new...) will be ready soon. It improves upon the way frame margins are handled, adds an alternative for the find and load popup menu, and includes 'find as you type' (or 'incremental search'). Small parts of the patch (image menu, hand cursor, fixes to widgets) are slowly been added to CVS now. If you want to see the rest added as well, help me out and provide some feedback... 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." ]

Sept. 25, 2003

Re: [Dillo-dev] Mac OS X Aqua port and new project HEML

by Andreas Schweitzer

> I did follow the posts. As in any escalations, things took turns a > bit at a time. And I think not all burden is to be put onto Robin. > > I re-read the thread. I'm not out to find culprits, I hate this kind > of game. I agree. We should just leave this topic behind, it's not worth digging in the past. I think there were wrong words, wrong interpretations, taking issues too personally and whatnot. Actually, I've seen it a few times in totally different projects. And it just hurts the project. If people would talk to each other face to face, the parties would see more than just some (possibly) badly formulated words. > But I do believe that the list could have been more > cooperative. If they ask questions here, let's just answer them. For the sake of good software. Just my opinion. Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Sept. 25, 2003

Re: [Dillo-dev] Mac OS X Aqua port and new project HEML

by tomas＠fabula.de

On Wed, Sep 24, 2003 at 09:23:05AM -0700, Kelson Vibber wrote: > At 02:27 AM 9/24/2003, tomas(a)fabula.de wrote: > >I was quite sad to see the hostility you found on this list, and > >still don't understand why a windows port doesn't seem to be welcome. > > Go back and read the archives. In order. Just about all the feedback he > got was positive until he started complaining about how unwelcome he was. > > First thread: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-August/001036.html Some private mail has been written in between here. It's difficult to asess its importance. > Second thread: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-September/001076.ht… > A few scattered messages: > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-September/thread.ht… > > Seriously, follow the entire thread. I don't see how *any* of that can be > considered hostile before Mr. Rowe basically stated "Jorge doesn't want to > help me port to Windows, therefore you all hate me." I did follow the posts. As in any escalations, things took turns a bit at a time. And I think not all burden is to be put onto Robin. I re-read the thread. I'm not out to find culprits, I hate this kind of game. But I do believe that the list could have been more cooperative. Thanks -- tomas

Sept. 25, 2003

Re: [Dillo-dev] Mac OS X Aqua port and new project HEML

by Kelson Vibber

At 02:27 AM 9/24/2003, tomas(a)fabula.de wrote: >I was quite sad to see the hostility you found on this list, and >still don't understand why a windows port doesn't seem to be welcome. Go back and read the archives. In order. Just about all the feedback he got was positive until he started complaining about how unwelcome he was. First thread: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-August/001036.html Second thread: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-September/001076.ht… A few scattered messages: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-September/thread.ht… Seriously, follow the entire thread. I don't see how *any* of that can be considered hostile before Mr. Rowe basically stated "Jorge doesn't want to help me port to Windows, therefore you all hate me." Don't just take the "hostility" claim at face value, read for yourself and make up your own mind. (For the record, I see porting Dillo to Windows as a good thing, but I would much rather have seen a more friendly relationship between the core Dillo project and the Windows port. And from what I can see, Mr. Rowe brought any hostility on himself.) Kelson Vibber www.hyperborea.org

Sept. 24, 2003

Re: [Dillo-dev] Mac OS X Aqua port and new project HEML

by tomas＠fabula.de

On Mon, Sep 22, 2003 at 04:16:32PM -0700, Robin Rowe wrote: > FYI, a screenshot of dillo running native on Mac OS X Aqua. > > http://heml.sourceforge.net/pix/dillo.aqua.811x734.png > > That and my Windows port are still under development. Looking to have those > ready for users by the end of the year. Thank you, Robin for your work. Although not a Windows user myself (alas, I'm nearly a strict free software user!), I do appreciate what you are doing, since it builds a bridge which might help people to meet free software. I was quite sad to see the hostility you found on this list, and still don't understand why a windows port doesn't seem to be welcome. (Folks, don't get me wrong: I don't want to start a flame war, we had it already. I would put strict criteria on whatever ports, mainly that they don't uglify the code all over the place. But heck, even Emacs has a Windows port, and that is a Damn Good Thing, IMHO). Regards -- tomas

Sept. 24, 2003

Image submenu for images that are links

by Jorge Arellano Cid

Hi there, I just commited this patch (see subject). I got some GTK+ warnings while developing it but have no longer been able to reproduce them. Maybe they were wiped out maybe not. Please test it. Cheers Jorge.-

Sept. 23, 2003

Mac OS X Aqua port and new project HEML

by Robin Rowe

FYI, a screenshot of dillo running native on Mac OS X Aqua. http://heml.sourceforge.net/pix/dillo.aqua.811x734.png That and my Windows port are still under development. Looking to have those ready for users by the end of the year. Devout Linux advocates on the dillo team will be relieved to know that these ports will not be known as dillo, that I've founded a new project on SourceForge called HEML. We will support Linux, Mac, and Windows without prejudice. http://heml.sourceforge.net/ I'm letting you know about it to avoid confusion. Not seeking your help or interest. Ciao, Robin --------------------------------------------------------------------------- Robin.Rowe(a)MovieEditor.com Hollywood, California www.CinePaint.org Free motion picture and still image editing software

Sept. 22, 2003

Re: [Dillo-dev] dillo browser repaint

by Jorge Arellano Cid

Hi, On Thu, 11 Sep 2003, Vikram wrote: > > Hi, I force dillo to browse to a new page based on some external event; > the code is as follows [with text containing the url to goto] > > <snip> > gchar* new_text = a_Url_string_strip_delimiters((gchar*)text); > DilloUrl* url = a_Url_new(new_text, NULL, 0, 0); > if (url) { > a_Nav_push(transfer_bw,url); > a_Url_free(url); > } > </snip> It looks OK. Placing may play a role though. > > however i notice that the though the browser DOES goto the new url the > screen [browser window] doesn't get painted properly. i seem to have to > scroll up and down a couple of times to get it to repaint completely. Any > idea why this would be ? It shouldn't happen. I'd be surprised if wrong placement of the url-pushing code is the root of the problem. But it can be. > [I don't know if this is related but the url's > dillo is forced to goto are served typically by a tomcat servlet engine] Try the same URL (from the tomcat server) from an unpatched dillo from the location bar. If it renders OK, the problem is with the patch (repeat the test with the same and other URLs, under different load/network conditions to be sure. You can also try Melvin's remote control patch. HTH Jorge.-

Sept. 21, 2003

Re: [Dillo-dev] patches

by Patrick Shanahan

* landy <landy(a)despiertapr.com> [09-15-03 17:17]: > where can i find patches for dillo Check the archives, http://lists.auriga.wearlab.de/pipermail/dillo-dev/ -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org

Sept. 15, 2003

patches

by landy

where can i find patches for dillo

Sept. 15, 2003

Image popup

by Jorge Arellano Cid

Hi, A right-mouse-button popup for images has been added, please test and enjoy! :-) When the image is also a link, the link popup will appear instead. The plan is to add an "Image menu..." submenu entry at the end of it, and handle it in way similar to the "Jump to..." submenu in the page popup. Cheers Jorge.-

Sept. 15, 2003

Re: [Dillo-dev] Re: [Patch] Search feature and more

by Jorge Arellano Cid

On Wed, 10 Sep 2003, Johan Hovold wrote: > Hi Jorge! > > 2.- Accelerator keys. > > > > Huh! These are to be picked very carefully! It took me a lot of > > work to figure simple mnemonic shortcuts that integrate well with > > the UI model. > > > > The chosen ones are: > > > > Shortcut Mnemonic > > ------------------------------------------------------------ > > Ctrl-U "Ctrl-URL" (to edit the URL) > > Ctrl-H "Ctrl-Hide" (Hide/show controls) > > Ctrl-S "Ctrl-Search" (search the web) > > Ctrl-R "Ctrl-Reload" (reload current page) > > ------------------------------------------------------------ > > (integrating with the existent) > > Ctrl-L "Ctrl-Location" (enters a new URL) > > Ctrl-F "Ctrl-Find" (find text) > > Ctrl-Q "ctrl-Quit" (quit window) > > > > (Note: Ctrl-S is not implemented yet) > > > > These should provide good defaults as Havoc suggests. Please > > give them a test drive to get the feel. > Some issues noted (which you may already have considered): > > Ctrl-U "Ctrl-URL" (to edit the URL) > - Conflicts with gtk text entry's "Delete line" shortcut. > - Could perhaps be considered a feature, since one ctrl-u gets you to > the location bar and another clears it? > - Has the irritating consequence that you cannot use it while in a html text > entry widged. > - May cause undesired "url lossage" ;-) when already in the location entry. > > Ctrl-H "Ctrl-Hide" (Hide/show controls) > - Conflicts with the gtk text entry's "Delete Backward Character > (Backspace)" > - Hence cannot be used while in html text entry forms or location > entry. > - F11 seems to be the standard keybinding for full screen. > > Ctrl-S "Ctrl-Search" (search the web) > - Frank's note that this is a standard shortcut for "Save Page", > implies that perhaps Ctrl-S isn't such a good choice, and > an alternative should be thought out. > - ...but a search bar doesn't solve the problem, since it should also be > accessible through a shortcut. > - My original proposal "s <keywords>" is still an option... > > > General issues concerning the Locationbar/dialog > - Ctrl-U doesn't select the url (just focuses), hence another > keypress is required in order to enter a new url (same goes for > Ctrl-L - open location dialog). > - Perhaps both the location dialog and location entry, should select > all text on Ctrl-L and Ctrl-U respectively? > - Considering the conflicts noted above, isn't Ctrl-L for focusing > (and perhaps selecting the contents of) the location bar and > Ctrl-Shift-L for opening location dialog a better and more > consistent solution? > > > Ah, while thinking of it, I thought it'd be good to add the ESC > > key as a way to switch from the location box into the main > > window, it can be easily done with the key handler you wrote. > Isn't this a (unneccessary) violation of Havoc's guidelines, since a > single tab press focuses the document window? (I.e. it would be a > duplication.) > (Just a note: an ESC press in the location box in mozilla and opera > selects the text and clears the text, respectively) > > > 3.- Search feature > > > > Uncommited yet, the functionality is perfect. Just some minor > > details in the UI: > > > > A small icon to the right of the location box (hideable as the > > othe icons), with Ctrl-S as shortcut, that pops up a dialog (just > > as find text and open url). > Shall I keep the "s <keywords>" interface as well, or just go with > the search box. The overhead is minimal, and people disliking dialogs > would be pleased. > > Is there someone out there who could add a nice magnifying glass icon > (or whatever is preferred), to pixmap.h? > > > The icon's tooltip can be "Search the Internet", "Search the > > Web", or something better :-) > Since the search engine to us is an option(search_url), perhaps > another preference is desired, e.g. a search_name option, and then > setting the tooltip to "Search using <search_name>". > Alternatively, the server name could be extracted from search_url, but > this may not always work as desired. > > > * It'd be also good to add middle-click over the clear-url > > button, as a way to "paste-push" an URLs. Instead of the the > > current three step sequence: > > > > - Press clear-url > > - Paste URL > > - Press enter > A really great idea! But, just to be a smart ass ;-), doesn't this > break the cognitive model behind dillo's interface in the same way as > did the "s <keywords>" interface... > > > I carefully considered your previous email and this model > > should take good care of the several points we talked about. Half > > of the work is on CVS now, and the above mentioned details are > > pending. Please send me a new patch with the modifications to > > fast-track-commit-it-in! > As noted above, you may already have considered the issues noted. So > if you've already made up your mind, I'll go ahead and implement the > remaining parts as soon as possible. Thanks. Attached goes a pixmap. As for the UI comments. It is not a black or white decision, it has many shades/tradeoffs. What I try to do is to chose the ones that better fit in the UI model as a whole. Ctrl-S is very interesting: it could be used for "Search" and "Save". As "Search" is much more used than save, I decided to let it have it (featuring a one-step cognitive association, as the other shortcuts). The other interesting option is to use Ctrl-W for "Web search" and Ctrl-S for save, but it introduces one two-step association (the required action is to search (ctrl-S), but that's not the shortcut, so a second association is needed). For instance: Where: the Web -> Ctrl-W, but this time it requires two-steps and breaks the cognitive model by introducing a non compliant association. The price to pay is that the unconsciously assimilated model now has an inconsistency, and the user certainly needs to update his mental model of it in order to use it. Once the new model is accomodated, all the other key bindings will most probably introduce a hesitation (depending on how the user made the accomodation), and the "perceived easiness" as a whole is compromised. An interesting related phenomena is that expert users already come with a bunch of unrelated shortcuts "hardcoded" in their brains, depending on the apps. they are used to. In that case, it is easier for them to try to make the new app. behave as they've come to expect, rather than to try to understand it, and assimilate its UI. I understand this fact, an so I think that providing a way to override _some_ shortcuts (as the Ctrl+<key> in dillo) may be a good thing to have (at the price of a bit of cluttering in dillorc). Now, providing a way to override almost every keybinding in dillo, and ways to accomodate for several different ways or styles of UI, is absolutely not a goal of this project (which is much more closer to what Havoc suggests). > Is there planned release date for 0.8.0? Maybe in a month or two. We have to integrate a lot of code yet and also stabilze the dpi[pd]. I'll write a bit more about it in another email. Cheers Jorge.-

Sept. 15, 2003

Cosmetic 0.7.3 patch

by Andrew R. Greenwood

Greetings, I originally started changing the following for fun, but after I had finished I found these cosmetic touches give Dillo a more polished and appealing look. I felt it was a nice improvement, so I decided to diff the changes (as instructed on the site) and subscribe to this mailing list. I hope others like these changes as much as I do. Here is a summary of what I've done: * Added a space at the beginning and end of the image and page progressbar text to offer a nice clean padded look in all of the panel_size modes * Cleaned up case inconsistencies and wording in context menus; verbage from Mozilla * Removed trailing menu separators and uppercase title menu entries from context menus to give them a more polished look * Changed the "View Source" window title to "Dillo: View Source" for window management consistency Any feedback will be greatly appreciated =) Andrew R. Greenwood <shadearg(a)sdf.lonestar.org>

Sept. 13, 2003

Re: ipaq dash keys

by Vikram

Hi, I got the keypress problem fixed [thanks to phil bushnell]. This has to do with the keylauncher application with the familiar distribution which launches specific applications on keys hence eating up the keypresses of the ipaq keys. Once the /etc/keylaunchrc is edited to not launch any application and the keylauncher daemon is restarted the the ipaq dash keypresses reaches dillo via the Interface_key_press_handler in interface.c just like the arrow keys. Maybe this information will help someone else later. Thanks, Vikram On Wed, 10 Sep 2003, Vikram wrote: > > Hi I am using familiar 0.7 on a h3670. I have a modified version of dillo > which adds some custom functionality to it. I need to be able to trigger > certain events on pressing the ipaq dash buttons [these are the ones which > launch calendar, filemanager etc and are wrapped all round the arrow keys > of the ipaq]. > > I see that dillo via GdkEventKey [in interface.c] senses the arrow keys > but this function does not seem to get events from the ipaq dash key > presses. Is there anyway I can get such keypresses ? Is it necessary I > have change some system wide seting [like use xmodmap?] ? > > Thanks, > > Vikram > > > >

Sept. 12, 2003

Re: [Dillo-dev] New dpid patch

by Jorge Arellano Cid

Hi there! I just commited big patches to the dpi framework (version5), a near 1800 lines patch. On Mon, 25 Aug 2003, Ferdi Franceschini wrote: > There is a new dpid patch for dillo-0.8-pre available from > http://www.geocities.com/ferdif2003/ > > Plugins are now stored in a directory structure under libdir/dillo/dpi. > You need to put > dpi_dir=/usr/local/lib/dillo/dpi Or the directory you choose. Note that you'll need to recompile the dpis as now they names tell whether they are a filter or socket server. This is still in state of flux, but working. Beware. > in ~/.dillo/dpidrc so that dpid can find the plugins, there should be no other > entries in this file. Dpid now uses a .filter suffix in the plugin name to > identify plugins which read and write to stdio (eg hello.filter.dpi). Cheers Jorge.-

Sept. 11, 2003

dillo browser repaint

by Vikram

Hi, I force dillo to browse to a new page based on some external event; the code is as follows [with text containing the url to goto] <snip> gchar* new_text = a_Url_string_strip_delimiters((gchar*)text); DilloUrl* url = a_Url_new(new_text, NULL, 0, 0); if (url) { a_Nav_push(transfer_bw,url); a_Url_free(url); } </snip> however i notice that the though the browser DOES goto the new url the screen [browser window] doesn't get painted properly. i seem to have to scroll up and down a couple of times to get it to repaint completely. Any idea why this would be ? [I don't know if this is related but the url's dillo is forced to goto are served typically by a tomcat servlet engine] Thanks, Vikram

Sept. 11, 2003

Re: [Dillo-dev] [RFC] Find as you type, statusbar instead of popups, etc

by Johan Hovold

On Wed, Sep 10, 2003 at 09:27:29PM +0200, Frank de Lange wrote: > User controls for find (and find_as_you_type) are the same as the normal find dialog ("/" or CTRL-F to start find, ESC to close, enter to search/search next), but find now retains the last search string between searches. A find_as_you_type feature would be great (I'm not a great fan of dialogs either). But wouldn't the mozilla style, '/' for find_as_you_type and ctrl-f for find_using_dialog, be a better approach? I'd also prefer ctrl-g for find_again (rather than enter), which could be used both with find_dialog and find_as_you_type. If/when keyboard navigation support is implemented, enter would probably be used to follow links. Regards, Johan

Sept. 11, 2003

Re: [Dillo-dev] Re: [RFC] Find as you type, statusbar instead of popups, etc

by Frank de Lange

On Thu, 11 Sep 2003 01:02:53 +0200 Melvin Hadasht <mhadasht(a)freefluid.dyndns.org> wrote: > Hi, > > > My current tab/frame patch (which will probably be released AFTER the 20th of september, as I am going abroad for a while) contains a find_as_you_type implementation (like Mozilla, search results are updated interactively). > > I was very happy when Mozilla implemented Emacs' incremental seach, so > I would really like to find it in Dillo, too. Is the patch available somewhere? Well, the highly-experimental-not-for-release-yet current version of the tab/frame patch, containing this feature, is at the patch site: http://www.geocities.com/ikbenfrank/dillo-200309102310-tabs.patch.gz size: 83700 bytes (gzipped, as downloaded) 366075 bytes (uncompressed) md5sum: 7df18dc069447dcc725abdcb64477a21 (gzipped, as downloaded) ad5ed7c538c8ae3801aebe229e79b177 (uncompressed) It is not even guaranteed to compile though, as it is just a current patch between my development tree and yesterdays CVS. Feel free to give it a try though. Set (in dillorc) 'popup_dialogs=NO' to use the status-bar version, otherwise you get the popup version (which also supports find_as_you_type by the way). Set find_as_you_type=YES to get that feature. > (could we add shift-enter to search backwards?) Yes, we could. > So what do you think about making a menu entry for each Dillo command? > That would create numerous new entries but then the user does not need Well, I would not make menu-entries for everything, but might consider making everything available for binding. Just like you can do in Emacs... > I would also find it useful if we could navigate through links using the keyboard. Yes, that is another planned feature. 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." ]

Sept. 11, 2003

ipaq dash keys

by Vikram

Hi I am using familiar 0.7 on a h3670. I have a modified version of dillo which adds some custom functionality to it. I need to be able to trigger certain events on pressing the ipaq dash buttons [these are the ones which launch calendar, filemanager etc and are wrapped all round the arrow keys of the ipaq]. I see that dillo via GdkEventKey [in interface.c] senses the arrow keys but this function does not seem to get events from the ipaq dash key presses. Is there anyway I can get such keypresses ? Is it necessary I have change some system wide seting [like use xmodmap?] ? Thanks, Vikram

Sept. 11, 2003

Re: [RFC] Find as you type, statusbar instead of popups, etc

by Melvin Hadasht

Hi, > My current tab/frame patch (which will probably be released AFTER the 20th of september, as I am going abroad for a while) contains a find_as_you_type implementation (like Mozilla, search results are updated interactively). I was very happy when Mozilla implemented Emacs' incremental seach, so I would really like to find it in Dillo, too. Is the patch available somewhere? > I also included an option to use the status bar and location bar instead of popup windows for search and open_url (popups are quite often not worth the hassle...). Yes, I agree, and I would make use of this patch. But popups should still be there, so new users won't be lost. > User controls for find (and find_as_you_type) are the same as the normal find dialog ("/" or CTRL-F to start find, ESC to close, enter to search/search next), but find now retains the last search string between searches. (could we add shift-enter to search backwards?) I really liked Gtk ability to let the user customize menu key bindings. So what do you think about making a menu entry for each Dillo command? That would create numerous new entries but then the user does not need to read the manual to know that '/' is for incremental-search and he would be able to customize the key-bindings to his taste. The drawback, is that there will be more menu entries. (You use Sylpheed-Claws, you can see that we moved most advanced editing commands in Compose/Edit/ Advanced.. to lighten the edit menu while allowing the user to set her preferred key-bindings (Ctrl-A being one of the most controversial)). > Is this something you'd like to see in Dillo, or should I keep these to myself? Definitely, I would use it quite frequently. I would also find it useful if we could navigate through links using the keyboard.

Sept. 10, 2003

[RFC] Find as you type, statusbar instead of popups, etc

by Frank de Lange

Hi'all, My current tab/frame patch (which will probably be released AFTER the 20th of september, as I am going abroad for a while) contains a find_as_you_type implementation (like Mozilla, search results are updated interactively). I also included an option to use the status bar and location bar instead of popup windows for search and open_url (popups are quite often not worth the hassle...). User controls for find (and find_as_you_type) are the same as the normal find dialog ("/" or CTRL-F to start find, ESC to close, enter to search/search next), but find now retains the last search string between searches. Code size impact is minimal, in case of a popup_less version code is actually quite a bit less complex (and a bit smaller) than the current CVS implementation. Is this something you'd like to see in Dillo, or should I keep these to myself? On the frameset front, control over margins in (i)frames has been improved (no more extraneous margin space in iframe). Dillo (when configured for frameset support) now always renders frameset - even when body content is placed outside the frameset. Frame resize support has been improved a bit. These changes introduce two new preferences (popup_dialogs and find_as_you_type). Both have defaults which reflect unpatched Dillo's behaviour. Please let me know if this sounds like an improvement (or the opposite) to you. 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." ]

Sept. 10, 2003

[PATCHES] GTK1 focus problem, solution

by Frank de Lange

Jorge, Sebastian, world, In a previous message I described a focus problem with Dillo (focus is 'trapped' in invisible widget). I have traced the problem to the GtkToolbar class. GtkToolbar is a GtkContainer, so it always gets focus even when GTK_CAN_FOCUS is unset. Hoewever, it redefines the focus signal function to NULL, thereby trapping focus inside the widget. To get normal focus behaviour, the GtkToolbar class's focus function needs to be changed to something like { return FALSE; }. I have patched interface.c to this extent. Patch is attached to this message. To get a complete, two-way tab focus chain (ability to tab around all focusable widgets in Dillo, forward and backward) my focus patch for dw_gtk_scrolled_frame is needed, otherwise dw_gtk_scrolled_frame will trap focus inside itself. You can find the patches on my patch site: http://www.geocities.com/ikbenfrank/dillo-200309101437-interface_focus.patc… (size: 660 bytes) http://www.geocities.com/ikbenfrank/dillo-200309101116-focus_chain.patch.gz (size: 910 bytes) Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Sept. 10, 2003

Re: [Dillo-dev] Re: [Patch] Search feature and more

by Johan Hovold

Hi Jorge! > 2.- Accelerator keys. > > Huh! These are to be picked very carefully! It took me a lot of > work to figure simple mnemonic shortcuts that integrate well with > the UI model. > > The chosen ones are: > > Shortcut Mnemonic > ------------------------------------------------------------ > Ctrl-U "Ctrl-URL" (to edit the URL) > Ctrl-H "Ctrl-Hide" (Hide/show controls) > Ctrl-S "Ctrl-Search" (search the web) > Ctrl-R "Ctrl-Reload" (reload current page) > ------------------------------------------------------------ > (integrating with the existent) > Ctrl-L "Ctrl-Location" (enters a new URL) > Ctrl-F "Ctrl-Find" (find text) > Ctrl-Q "ctrl-Quit" (quit window) > > (Note: Ctrl-S is not implemented yet) > > These should provide good defaults as Havoc suggests. Please > give them a test drive to get the feel. Some issues noted (which you may already have considered): Ctrl-U "Ctrl-URL" (to edit the URL) - Conflicts with gtk text entry's "Delete line" shortcut. - Could perhaps be considered a feature, since one ctrl-u gets you to the location bar and another clears it? - Has the irritating consequence that you cannot use it while in a html text entry widged. - May cause undesired "url lossage" ;-) when already in the location entry. Ctrl-H "Ctrl-Hide" (Hide/show controls) - Conflicts with the gtk text entry's "Delete Backward Character (Backspace)" - Hence cannot be used while in html text entry forms or location entry. - F11 seems to be the standard keybinding for full screen. Ctrl-S "Ctrl-Search" (search the web) - Frank's note that this is a standard shortcut for "Save Page", implies that perhaps Ctrl-S isn't such a good choice, and an alternative should be thought out. - ...but a search bar doesn't solve the problem, since it should also be accessible through a shortcut. - My original proposal "s <keywords>" is still an option... General issues concerning the Locationbar/dialog - Ctrl-U doesn't select the url (just focuses), hence another keypress is required in order to enter a new url (same goes for Ctrl-L - open location dialog). - Perhaps both the location dialog and location entry, should select all text on Ctrl-L and Ctrl-U respectively? - Considering the conflicts noted above, isn't Ctrl-L for focusing (and perhaps selecting the contents of) the location bar and Ctrl-Shift-L for opening location dialog a better and more consistent solution? > Ah, while thinking of it, I thought it'd be good to add the ESC > key as a way to switch from the location box into the main > window, it can be easily done with the key handler you wrote. Isn't this a (unneccessary) violation of Havoc's guidelines, since a single tab press focuses the document window? (I.e. it would be a duplication.) (Just a note: an ESC press in the location box in mozilla and opera selects the text and clears the text, respectively) > 3.- Search feature > > Uncommited yet, the functionality is perfect. Just some minor > details in the UI: > > A small icon to the right of the location box (hideable as the > othe icons), with Ctrl-S as shortcut, that pops up a dialog (just > as find text and open url). Shall I keep the "s <keywords>" interface as well, or just go with the search box. The overhead is minimal, and people disliking dialogs would be pleased. Is there someone out there who could add a nice magnifying glass icon (or whatever is preferred), to pixmap.h? > The icon's tooltip can be "Search the Internet", "Search the > Web", or something better :-) Since the search engine to us is an option(search_url), perhaps another preference is desired, e.g. a search_name option, and then setting the tooltip to "Search using <search_name>". Alternatively, the server name could be extracted from search_url, but this may not always work as desired. > * It'd be also good to add middle-click over the clear-url > button, as a way to "paste-push" an URLs. Instead of the the > current three step sequence: > > - Press clear-url > - Paste URL > - Press enter A really great idea! But, just to be a smart ass ;-), doesn't this break the cognitive model behind dillo's interface in the same way as did the "s <keywords>" interface... > I carefully considered your previous email and this model > should take good care of the several points we talked about. Half > of the work is on CVS now, and the above mentioned details are > pending. Please send me a new patch with the modifications to > fast-track-commit-it-in! As noted above, you may already have considered the issues noted. So if you've already made up your mind, I'll go ahead and implement the remaining parts as soon as possible. Is there planned release date for 0.8.0? Best regards, Johan Hovold

Sept. 10, 2003

Re: [Dillo-dev] Re: [PATCHES] hand_cursor and image_popup, some remarks

by Frank de Lange

On Tue, 9 Sep 2003 15:57:42 -0400 (CLT) Jorge Arellano Cid <jcid(a)dillo.org> wrote: > Yes, that problem is known since a long time. It was very hard > to root down! The good news is that it's solved. > > It's not a problem of dillo but of GTK1. details here: > > http://mail.gnome.org/archives/gtk-list/2003-June/msg00289.html > > (As Sebastian, I think we'd better solve this with GTK2.) This is not the same problem. set-focus-chain allows you to program around this problem... The real problem, however, is still there... There is a widget, somewhere, which gets focussed without showing a visible focus cue (this is the problem you described, which could be avoided by setting an explicit focus chain) and - the real problem - does not allow the tab key OR gtk_widget_grab_focus(some_other_widget) to shift away focus from it. > > > > Clashing with other apps. is almost unavoidable (unless we > > > clone), but we have chosen to rely over an underlying cognitive > > > model for our UI. It has been very succesful, and praised! > > > > > > Now, as a matter of serendipity :), the bouncing keyboard may > > > have shown us both a better way. If we make Ctrl-L focus the > > > location bar (as Ctrl-U does now) and a second Ctrl-L to clear > > > it, that may be a good choice. > > > > Well, Ctrl-U is generally used for 'clear entry' in GTK1 (not > > in GTK2 though), so I think it is best to use it for that purpose > > in Dillo as well. For GTK2, following the toolkit default > > bindings is the logical thing to do. > > For now, I'll leave it as explained here: > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-September/001113.ht… Well, let's just say that I do not agree with all the choices (Ctrl-S for searhc the web? While just about every other application uses that for 'save'? And while searching can be done from the location bar or a search box? Please, no...) and, since I am not only a developer of (my version of) Dillo but also a user, I want my browser to do what I want, not what someone else thinks it should do. Hence the preferences. I guess I'm not the only one who feels like that - I know I'm not - so I feel that user choice is a good thing. Havoc's ideas notwithstanding. By the way, Havoc speaks about 'having good defaults'. Well, I think Dillo has some good defaults. But some defaults are less than good. Those which are - in the user's opinion - less than good can be changed using a preference (in the dillorc or some future preference plugin), those which are fine are left at their default setting. So, the user has as few or many preferences in the preference file as s/he wishes. Ain't choice a beautiful thing? Those who want their I-want-to-be-able-to-control-EVERYTHING app can have it, while those who are happy with the defaults can go by without any preferences at all... 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." ]

Sept. 10, 2003

Re: [PATCHES] hand_cursor and image_popup, some remarks

by Jorge Arellano Cid

Hi there! On Tue, 9 Sep 2003, Frank de Lange wrote: > [ Jorge, your mailserver is not healthy... I tried to send this 3 times > without success, so it goes to the list instead... ] Yes, softhome has being acting strange the latter months. Fortunately we've being working with Andi K. to enable email from the wearlab. Please try: jcid at dillo.org It's working, so please use it (we're testing). With regard to softhome, I've received two of your 3 email attempts there (it sometimes reports a timeout error and _after_ that, accepts the mail ;) > On Mon, 8 Sep 2003 11:13:32 -0400 (CLT) > Jorge Arellano Cid <jcid(a)softhome.org> wrote: > > > You're right. In that case it causes more troubles than help. > > Please send me the patch to commit it to CVS. > > It is part of the tab/frame patch... It uses the document > abstraction. In non-patched Dillo, it would be something like: > > if(bw->nav_stack_ptr != -1) > gtk_widget_grab_focus(GTK_BIN(bw->docwin)->child); > else > gtk_widget_grab_focus(bw->location); Hmmm, I see. Read below. > > By the way, there are some problems with 'hidden focus' in Dw. > These problems only become directly noticeable in the tab/frame > patched version, but they are present in CVS Dillo as well. To > see the problem: > > 1. start dillo on a longish directory listing or a long document (so that the vertical scroll bar appears) > 2. use up and down arrow keys to scroll the document. This works in unpatched Dillo. In the (current) patched version, it only works AFTER pressing the UP key once... > 3. press SHIFT-TAB twice. Focus is now set on... something. Something invisible. There is no visible focus cue > 4. press DOWN key. Nothing happens, no matter how often you press it... Same for TAB, ENTER, RIGHT, ... > 5. press UP or SHIFT-TAB or LEFT key. Focus is now on the document, and scrolling keys work as they should. > > The problem does not show (in patched or unpatched Dillo) when in fullscreen mode. > > I've searched for the cause of this problem, but have not yet found it. Yes, that problem is known since a long time. It was very hard to root down! The good news is that it's solved. It's not a problem of dillo but of GTK1. details here: http://mail.gnome.org/archives/gtk-list/2003-June/msg00289.html (As Sebastian, I think we'd better solve this with GTK2.) > > Clashing with other apps. is almost unavoidable (unless we > > clone), but we have chosen to rely over an underlying cognitive > > model for our UI. It has been very succesful, and praised! > > > > Now, as a matter of serendipity :), the bouncing keyboard may > > have shown us both a better way. If we make Ctrl-L focus the > > location bar (as Ctrl-U does now) and a second Ctrl-L to clear > > it, that may be a good choice. > > Well, Ctrl-U is generally used for 'clear entry' in GTK1 (not > in GTK2 though), so I think it is best to use it for that purpose > in Dillo as well. For GTK2, following the toolkit default > bindings is the logical thing to do. For now, I'll leave it as explained here: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-September/001113.ht… > Even better is to allow users to decide for themselves which > bindings they want. GTK2 does not allow this by default, but it > can be re-enabled. No matter how well thought out a model is, the > user should *always* be able to override the designer's defaults. > Even if that user messes up a perfectly thought out cognitive model. > > That is also why I make just about everything user-selectable > using preferences with sane default values. > > So, one of my next goals will probably be to implement > user-selectable accelerators in Dillo... Based on GTK's default > mechanisms for doing such a thing. We agree more with the line of GTK+2 authors. BTW, we follow Havoc's guidelines: http://www.dillo.org/ui-prefs-tips.html http://ometer.com/free-software-ui.html Consequently, I'd rather set a low priority on it. I'd much prefer the work to be focused on enabling basic DOM data-access, CSS parsing, floating-objects handling and thinks like that. > > > Of course, a more orthogonal way to do it, is the same > > functionality, but inside the location popup. But please > > experiment with the above suggested idea, and tell me your > > findings. > > Generally I find that popup menu's are more a hinder than a > help. This is more of a problem with window managers which do not > correctly manage them than with the basic concept of popups, but > as the state of the art currently stands I try to avoid them as > much as possible. > > I will therefore try to implement the functionality of Dillo's > transient popups (find and open url) in the main window, the > former probably in the status bar and the latter in the location > bar. And, of course, make a preference to allow the user to choose > which version to use - popup or main window. (same as above) > > Attached two patches, one for hand_cursor, one for right_click on image. > Some remarks: > > [...] Thanks. We'll look at them with Sebastian. > Maybe the image popup should be a submenu on other popups? See > the frame/frameset popups (in the tab/frame patch) for an example > of what I mean. That way, the image can also be accessed in links > (and, maybe, in input images, even those currently do not react > to RMB-clicks for obvious reason...) FWIW, we have this implemented with Eric for probably more than a year. The only reason it was held is to keep the UI consistent. > Please be aware of the fact that I will have to keep on adding > these patches to the tab/frame patch while the document > abstraction has not been committed to CVS... So I will have to > patch my own patches, not something I want to keep on doing too > long... I know the problem pretty well: that's why I suggested to select a release, or CVS date to base the patch on. Now, considering all the facts, the document abstraction seems a good part to start reviewing/merging. Please isolate it to start working on it. Regards Jorge.-

Sept. 9, 2003

Re: FW: [Dillo-dev] How do your clear the dillo cache

by Thorben Thuermer

On Sun, 7 Sep 2003 17:25:08 -0400 "Ronald W. Henderson" <rwhalb(a)nycap.rr.com> wrote: > The graphic images (which are *.png files) are the ones which are cached. If > I hit the reload botton the html code updates ok but the graphics don't. I > need to start and stop > Dillo for the graphic images to be updated. the way dillo implements refreshing does currently not support this, only the main document is reloaded, images referenced from it remain in the cache unchanged. you can, for example, open the individual images and reload them, then they will be updated on the next reload of the page.

Sept. 9, 2003